[rfc-i] New v3 draft

[tony at att.com (Tony Hansen)]

On 4/21/14, 10:08 AM, Paul Kyzivat wrote:
> 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.)

I've known of similar cases with languages like IMAP, such as section 8 
RFC 2060:

S:   * 12 FETCH (FLAGS (\Seen) INTERNALDATE "17-Jul-1996 02:44:25 -0700"
       RFC822.SIZE 4286 ENVELOPE ("Wed, 17 Jul 1996 02:23:25 -0700 (PDT)"
       "IMAP4rev1 WG mtg summary and minutes"
       (("Terry Gray" NIL "gray" "cac.washington.edu"))
       (("Terry Gray" NIL "gray" "cac.washington.edu"))
       (("Terry Gray" NIL "gray" "cac.washington.edu"))
       ((NIL NIL "imap" "cac.washington.edu"))
       ((NIL NIL "minutes" "CNRI.Reston.VA.US")
       ("John Klensin" NIL "KLENSIN" "INFOODS.MIT.EDU")) NIL NIL
       "<B27397-0100000 at cac.washington.edu>")
        BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028 92))



For SIP, though, except for the case of examples where digital 
signatures need to account for every single octet of input, this looks 
like a bug in RFC7131, because SIP allows headers to be folded just like 
in email:

RFC 3261, section 7.3.1:
    Header fields follow the same generic header format as that given in
    Section 2.2 of RFC 2822 [3]. ...
    Header fields can be extended over multiple lines by preceding each
    extra line with at least one SP or horizontal tab (HT).  The line
    break and the whitespace at the beginning of the next line are
    treated as a single SP character.  Thus, the following are
    equivalent:

       Subject: I know you're there, pick up the phone and talk to me!
       Subject: I know you're there,
                pick up the phone
                and talk to me!

> draft-ietf-bliss-shared-appearances-15 uses "<all-one-line>". (With 
> explanation.)
>
> I'm sure there are others.

And that's definitely one of the least-pleasing examples I've ever seen 
of how to work around this "problem". (And given SIP's header folding 
rules, it shouldn't even be necessary.)


With appropriate markup, there ARE other ways to show carriage returns 
that should not be there. For example, you could use

<em>&lt;no-CRLF&gt;</em>

at the end of a line.

     Tony Hansen