[rfc-i] New v3 draft
pkyzivat at alum.mit.edu
Sun Apr 20 14:38:10 PDT 2014
I've been following this work but been mostly silent. You all seem to be
getting along just fine without my comments, and it's been easier to
just be lazy. I decided I would read through this version, and I have a
The text says:
Alternatively, the "src" attribute allows referencing an external
graphics file, such as a bitmap or a vector drawing, using a URI. In
this case, the textual content acts as fallback for output formats
that do not support graphics, and thus ought to contain either a
"line art" variant of the graphics, or otherwise prose that describes
the included image in sufficient detail.
If "src" is used, and the content is a textual description, then it
might be desirable for that content to be flowed, rather than forcing it
to be manually formatted.
(But I don't have a great idea of exactly how to specify that.)
For the preferred values of 'type': is this just informal? Or is it
intended to imply that the content conforms to some defined syntax for
each type? Also, perhaps 'sip' and 'sdp' should be listed as preferred
type values, for artwork or sourcecode. (And there are probably lots of
It occurs to me that we have had an ongoing problem when producing
figures containing examples of SIP messages: These messages are
generally human readable text, but they sometimes must contain lines
that are longer that may be reproduced in an RFC. Various informal
conventions have been used to introduce formatting line breaks and
indents that can be distinguished from those that are actually part of
Often people want to extract these from an RFC for machine processing.
It would be nice if we could find a way to handle this in a consistent
way, so that it need not be respecified in every document, and so that
automated extraction tools could work on the .txt or the .xml form.
(This comment probably applies to <sourcecode> also, or instead.)
Says each entry has a pair of <dt> and <dl>. But then the Content model
seems to have a sequence of <dt>s followed by a sequence of <dl>s.
The example doesn't include <refcontent>! Instead, it includes
<rfc> 'docName' attribute:
It is a pain to keep updating the docname to match the version number of
the document. Can we find some way to allow the processor to figure out
the version number, and perhaps also the name? (E.g., Based on the xml
More information about the rfc-interest