[rfc-i] New v3 draft

Paul Hoffman paul.hoffman at vpnc.org
Sun Apr 20 19:34:52 PDT 2014


On Apr 20, 2014, at 2:38 PM, Paul Kyzivat <pkyzivat at alum.mit.edu> wrote:

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

Well, do try again because I'm not understanding your comment at all, but I think it might be important.

> 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?

The former.

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

Can you point to a recent RFC with each of those? My ignorance of SIP is showing here...

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

Good catch. That's an artifact of the RNG-to-prose converter that Julian slaves over for this document. He has a bit more slaving to do.

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

Can you tell I changed the name during the writing of the last draft?

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

I have the same desire, but I haven't found a clean way to do that. We inherit nothing else from the filename, modification date, and so on.

--Paul Hoffman


More information about the rfc-interest mailing list