[rfc-i] New v3 draft

[pkyzivat at alum.mit.edu (Paul Kyzivat)]

On 4/20/14 10:34 PM, Paul Hoffman wrote:
> 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.

IIUC, the text I quoted above means that I can include an src attribute 
that provides the preferred form of the figure, and the textual content 
could be either line art or prose as backup for formats that can't use 
the preferred form. Suppose I want to use prose as the backup. Because 
the prose is artwork text, it won't be wrapped, indented, etc. But I 
might *want* the prose form to formatted like other text.

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

RFC7131 uses a trailing "\" to mark line folding. (Without explaining 
that it is doing so.)

draft-ietf-bliss-shared-appearances-15 uses "<all-one-line>". (With 
explanation.)

I'm sure there are others.

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

Maybe this just needs to be an artifact of the processor rather than of 
the format.

	Thanks,
	Paul