Hi, thanks for the quick response. Comments inline; sections that do not seem
to need further comment are deleted, and marked with "[...]"
Thanks!
Ben.
On Apr 5, 2014, at 8:10 PM, Paul Hoffman <paul.hoff...@vpnc.org> wrote:
[...]
>
>> -- Section 1, paragraph 2:
>>
>> I find it confusing that we have two drafts in parallel, one for V2 that is
>> obsoleted by this draft, and this draft for V3. With this draft copying much
>> of V2 forward, which is authoritative?
>
> Both. the v2 draft is authoritative for that version of the format (which is
> still in use); this draft will be definitive for v3 when v3 is implemented.
> Unlike a regular protocol, this format is not going to be immediately
> implemented when the draft goes to the RFC Editor.
It's not clear to me that updates to "regular protocols" always get immediately
implemented, at least not to the point of immediately replacing older version.
Especially we we are talking about formally incrementing version numbers.
I think my real question is whether V3 really obsoletes V2 in the usual sense.
Do we allow further updates (e.g. an "updates" draft with bug fixes) to V2 once
it becomes an RFC? If so, do those updates, assuming they impact "common"
parts, affect V3? Would that be automatic, or would V3 require a parallel
update? Do we intend to allow V2 to evolve independently of V3?
>
>> -- 1.1, entry for <tident>
>>
>> THANK YOU!!!! I think faking indented text using the <list> work around was
>> one of the most annoying things about previous versions.
>
> Hrm; I'm not used to seeing that in GenArt reviews. :-)
>
> And, to be fair, lots of the new features have been suggested by many people
> on the RFC Editor's design team and in the bigger community.
Okay, change that to THANK Y'ALL!!!!
>
>> --2.2:
>>
>> Can I have more than one of any given address sub-element? If so, how should
>> it render?
>
> Yep; unclear. There are a lot of things in this draft (and the in the v2
> draft) where the rendering is undefined. We may or may not clarify those in
> the doc before we are finished; if not, it will be up to the programmers.
I accept that different rendering decisions might be okay. But would you also
leave whether a specific sub-element can be repeated to the implementors? Seem
like that could lead to xml2rfc "code" that is correct for one processor but
incorrect for another.
[...]
>
>> -- 2.7:
>>
>> It seems like <b> (and also <i>) is just as much format dependent as things
>> like <width>. Wouldn't something like <em> be more useful for this purpose,
>> where you have an abstract concept of emphasis that can be rendered
>> differently for different formats?
>
> In some senses, yes, but given that we know the main expected types of
> non-canonical output (HTML, PDF, EPUB), they all handle bold and italic and
> fixed-width fonts just fine. There are plenty of people who would think that
> "emphasis" means bold, and plenty who would think it means "italic".
>
>> This seems like a place where our use cases are different than those for
>> HTML, where markup is usually rendered by browsers that have similar font
>> display capabilities.
>
> No, our use cases very much align with HTML here: that's a design choice.
Well, HTML _does_ have <em>. I realize it's not very useful in HTML, since you
rarely render HTML to a format that can't do bold or italics. But to test the
assertion, do you consider typesetting a common use case for HTML? Is it not
one for xml2rfc?
>
>> In particular, what happens to <b>text<.b> when rendered into ASCII text?
>
> Nothing. Just like today, there is a lot of formatting that is lost in the
> text output.
There are some common conventions here; they just seemed to have fallen by the
wayside. For example, a title of a long-format work gets italicized when that's
supported, but underlined on an old fashioned typewriter. There are more modern
simulations like _this_ and *this*.
OTOH, I guess an ascii rendering processor could make those same choices for
<i> and <b> as well as for <em>, so maybe I just countered my own argument. But
from a typesetting perspective, abstractions like <em> allow one to separate
the intent of the author ("I want this to be emphasized") from the intent of
the editor/publisher.("This is how our 'style' renders emphasis.")
>
>> -- 2.9:
>>
>> Why does the "cite" attribute have different requirements than, say, xref?
>> In particular, why wouldn't I want to cite a reference in the current doc,
>> rather than a URL?
>
> It can do both: the URL can be a fragment that points to a reference in the
> current doc.
How would you do that? Is there a way to construct a URL that points to an
xml2rfc anchor?
>
>> -- 2.9.1:
>>
>> How would one reference an auto generated anchor identifier? If it doesn't
>> exist until processing time...?
>
> Correct, so you can't. You can only use "target" attributes to named anchors.
If you can't reference an auto-generated anchor, why do you have them? What
else do you do with anchors?
>
>> --2.33.2
>>
>> Is it possible to continue numbering from a previous list?
>
> Not directly.
I may be misreading it, but doesn't V2 support number continuation with the
"counter" attribute of <list>? If so, is the intent to remove that capability?
[...]
>> -- 2.44.2:
>>
>> Why are numberless subsections disallowed?
>
> If it was a sub-section, the heading could easily be mistaken for free text.
>
>> It's pretty common to see documents that have non-numbered sub-heads inside
>> numbered sections.
>
> Those are probably "notes" and such, not real sections. Do you see a need for
> these? It's certainly possible to have them, but they seem more confusing
> than necessary to me.
I've seen docs (not necessarily RFCs), that did something like this:
1. Heading
1.1 Subhead
1.1.1 Minor Subhead
(no number) Really Minor Subhead
I think the idea is to label deep sub-topics without the clutter of 1.1.1.1. Is
it _necessary_? Probably not. But that's the use case I immediately envisioned
when I thought about the ability to suppress numbering.
[...]
>
>> -- 5, security considerations
>>
>> I wonder if the possibility of executable content existing in an RFC or
>> draft is worth mention here? For an extreme example, see RFC6716, Appendix
>> A. But more realistically, 2.5.5 mentions the possibility of in-lined binary
>> content, and 2.5.6 allows the identification of code in a way that a naive
>> processor implementation might take as an invitation to interpret said code.
>
> Yup, and (as above) I added a paragraph about this.
>
>> Also, does the need for a processor to potentially render binary content in
>> general (in-lined or otherwise) expand the attack surface over that for
>> previous versions of XML2RFC?
>
> Not in any way I can think of.
For example (just thinking "out loud"), if a processor could insert JPEG
artwork, does it need to worry about buffer overflow attacks on the JPEG
format, as well as attacks on the xml itself? If so, does it matter if the
artwork was in-lined vs referenced?
[...]
>
>> -- 2.48, Content Model:
>>
>> It might be worth marking deprecated elements. Otherwise a reader may not
>> follow the xref to discover a legal child element is deprecated.
>
> These are automatically generated, and marking the deprecated ones is
> probably really really hard. We thought of this and punted.
>
Okay.
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
