[rfc-i] New v3 draft

Paul Kyzivat 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 
few comments/suggestions:

<artwork>

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 
others.)

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 
the message.

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.)

<dl>:

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.

<refcontent>:

The example doesn't include <refcontent>! Instead, it includes 
<innerRefContent>.

<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 
source file.)

	Thanks,
	Paul




More information about the rfc-interest mailing list