Comment-on-comments below. I now have one new action item.
--Paul Hoffman
On Apr 7, 2014, at 11:37 AM, Ben Campbell <b...@nostrum.com> wrote:
> 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?
All good questions. I'll open a thread on rfc-interest with the question, but I
strongly suspect it will end up having a non-answer.
>
>>
>>> -- 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.
Nope. The format is the format: it allows multiple sub-elements, and it would
be wrong for a processor to reject an input based on that. It is probably fine
for a processor to not render them all, although it would be better if it
issued a warning. It would be best if we had rules for how processors should
render each entity, but we haven't gone to that level of detail yet.
>
> [...]
>
>>
>>> -- 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?
No to both.
>
>>
>>> 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.
That was my first reaction. :-)
> 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.")
In an ideal world where authors understood typesetting, yes. That's the world I
began work in 35 years ago. (Cue the DEC formatting language theme music...)
But that's not what is typical among IETF authors who are, not surprisingly,
often literal-minded and goal-oriented.
>
>>
>>> -- 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?
<blockquote cite="#anchorname">, I believe.
>
>>
>>> -- 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?
After the RFC is published, other documents can reference the anchor.
Currently, the document only specifies this for <blockquote> and <cref>, but it
has been mentioned for other elements as well.
>
>>
>>> --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?
Yes and yes. Each list is free-standing. The need for continued numbering
between lists in v2 is mostly obviated by allowing <t> in lists in v3. The
semantics of "here is a second list whose numbers don't start at 1" are
unclear, and we're trying to make v3 more semantically clearer.
>
> [...]
>
>>> -- 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.
Noted. I'd prefer to make all levels headings numbered if that's the overall
style.
>
> [...]
>
>>
>>> -- 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?
Um, maybe. I'm not at all sure how to word a security consideration about that
that would be more useful than "a processor should not be stupid when doing
includes".
>
> [...]
>
>>
>>> -- 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
