[rfc-i] New v3 draft

Tony,

The SIP header folding rules aren't sufficient. The "fold" is equivalent 
to a space, so it can only be used where a space is allowed. Sometimes 
that isn't sufficient.

And even when it is "sufficient", this is being used for *examples*. So 
even if one could fold the line *somewhere* to meet the draft line 
length requirements, that may not be the place that will make the 
example easily understandable.

Also, the sip examples typically include SDP, and the SDP doesn't allow 
line folding.

So this is generally a problem.

(BTW, in retrospect we would not have included the line folding rule in 
sip. It is really only needed for examples, and it isn't sufficient for 
that.)

	Thanks,
	Paul

On 4/21/14 4:38 PM, Tony Hansen wrote:
>
> 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
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
>