Subject: [Sipping] draft-ietf-sipping-service-examples-11.txt and my review of draft-ietf-sipping-service-examples-10.txt

From: [email-masked]
Date: Thu, 9 Nov 2006 23:33:57 -0500

I've compared my review of draft-ietf-sipping-service-examples-10.txt
with draft-ietf-sipping-service-examples-11.txt and have the following
comments:

> * Header line breaking
> 
> While the grammar of RFC 3261 section 25.1 allows header values to be
> broken at most delimiters, it does not allow URIs to be broken.

# I have fixed this by using the <allOneLine> tag defined in RFC 4475.

This fix is good, but it's not quite complete.  In regard to
whitespace around the point of the break, RFC 4475 says:

   Several of these examples contain unfolded lines longer than 72
   characters.  These are captured between <allOneLine/> tags.  The
   single unfolded line is reconstructed by directly concatenating all
   lines appearing between the tags (discarding any line feeds or
   carriage returns).  There will be no whitespace at the end of lines.
   Any whitespace appearing at a fold-point will appear at the beginning
   of a line.

(The final phrase "at the beginning of a line" implicitly refers to
the left margin established by the surrounding text.)  In -11, the
uses of <allOneLine> are:

page 59, message F15:

      REFER sips:[email-masked] SIP/2.0
      Via: SIP/2.0/TLS client.biloxi.example.com:5061
       ;branch=z9hG4bKnashds2g
      Max-Forwards: 70
      From: Bob <sips:[email-masked]>;tag=23431
      To: Alice <sips:[email-masked]>;tag=1234567
      Call-ID: [email-masked]
      CSeq: 1025 REFER
    <allOneLine>
      Refer-To: <sips:[email-masked]?Replaces=
       sdjfdjfskdf%40biloxi.example.com%3Bto-tag%3D5f35a3
       %3Bfrom-tag%3D8675309&Require=replaces>
    </allOneLine>
      Referred-By: <sips:[email-masked]>
      Contact: <sips:[email-masked]>
      Content-Length: 0

pages 66/67, message F5:

      <HTML>Do you want to take this call from
    <allOneLine>
      <A HREF="sips:[email-masked];gruu?Replaces=
       [email-masked]%3Bto-tag%3D3145678
       %3Bfrom-tag%3D1234567&Require=replaces">
       Alice</A>?
    </allOneLine>
       </HTML>

page 130, message F5:

      REFER sips:[email-masked] SIP/2.0
      Via: SIP/2.0/TLS client.biloxi.example.com:5061
       ;branch=z9hG4bKnashds9
      Max-Forwards: 70
      From: Bob <sips:[email-masked]>;tag=02134
      To: Park Server <sips:[email-masked]>
      Call-ID: [email-masked]
      CSeq: 1 REFER
    <allOneLine>
      Refer-To: <sips:[email-masked];gruu?Replaces=
       12345601%40atlanta.example.com%3Bfrom-tag%3D314159
       %3Bto-tag%3D1234567&Require=replaces>
    </allOneLine>
      Referred-By: <sips:[email-masked]>
      Contact: <sips:[email-masked]>
      Content-Length: 0

In all three cases, the successive displayed line are indented one
space relative to the initial displayed line, which according to RFC
4425 means that a space is present in the "real" line.  But whitespace
is not allowed in URIs (which is why they can't be broken across
lines).  The indentation needs to be removed.

> * 2.15.  Call Park

In the comment on message F14, Bob's name is truncated to "B" in one
place:

      /*  Park Server reports success back to B by returning
           a 200 OK response.  Bob obtains the dialog identifiers
           from the headers included in the response. */

> Section 2.16:
> 
> * Is <sips:[email-masked]> intended to be a GRUU?  If so,
> to align it with draft-ietf-sip-gruu-09.txt, it should be replaced
> with <sips:[email-masked];gruu>.

But "gruu" has been changed to "gr" in draft-ietf-sip-gruu-11.

Dale

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 10 Nov 2006 14:24:07 -0500

[email-masked] wrote:
> the left margin established by the surrounding text.) 

I've struggled with this myself and decided to add in my own language 
making this implicit assumption explicit.

I've wondered if we need a better convention for this - one that is 
among the common policies for drafts and RFCs rather than being 
something specific to a few sip drafts. Frankly, for readability I would 
rather that all the whitespace adjacent to the fold (both preceding and 
following) be removed. But that would require some other convention for 
inserting whitespace in such a case.

	Paul