On Apr 7, 2014, at 2:42 PM, Paul Hoffman <paul.hoff...@vpnc.org> wrote:
> 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:
>
>
[...]
>>>
>>>> --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.
>
Well, that was the original question--are multiple of the same sub-element
allowed :-)
I guess a better followup question than "how do you render it" would be "are
there cases where multiples of the same sub-type clearly does or does not make
sense according to RFC style.
>>
>> [...]
>>
>>>
>>>> -- 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.
Okay, I give in on this one.
>
>>
>>>
>>>> -- 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.
I think this means that, at least for blockquote, even if you leave out anchor
attribute in the xml, you will get whatever sort of identifier makes sense in
the rendered output (e.g. an id attribute in HTML)? I read it to mean that the
processor would auto generate a (perhaps ephemeral) anchor in the XML itself,
which is not quite the same thing.
>
>>
>>>
>>>> --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.
Okay
>
>>
>> [...]
>>
>>>> -- 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.
Okay
>
>>
>> [...]
>>
>>>
>>>> -- 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".
Just as a strawman example:
Unlike previous versions, XML2RFC V3 allows the inclusion of potentially binary
content via the "src" attribute of the <artwork> element. Processor
implementors should bear in mind that such content may have vulnerabilities of
its own. For example, certain JPEG renderers have been vulnerable to
buffer-overflow attacks. An xml2rfc processor that allows the inclusion of
artwork in JPEG format might be subject to buffer overrun attacks on both its
XML parser and in its JPEG rendering code.
[...]
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
