On Apr 7, 2014, at 1:39 PM, Ben Campbell <b...@nostrum.com> wrote: > 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 >> >>>> >>>>> --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.
I think they all probably make sense for some postal address format used somewhere in the world. The real question is whether we can guess how to sensibly render something with, say, two <city> elements. My guess is "no", and we'll end up telling the author to instead use a bunch of <postalLine> elements instead. >>>>> -- 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. Correct, and this has convinced me to remove the auto-generation of anchors from <blockquote> and <cref>. (And, since writing last, I have discovered that even anchors to <cref> doesn't even render in the current xml2rfc, so that is of questionable value as well. >>>>> -- 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. It really depends on what you mean by "binary". The v2 format supports inclusion of files in a few places already; a malicious submitter could make those files "binary". Further, a processor doesn't render anything: it puts out files. So, at best, the advice is "don't have a buffer overrun when including a file that you might output", which seems dumb. I'm still open to adding a security consideration, but I guess I feel it has to at least be marginally useful. --Paul Hoffman _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
