Subject: Re: [Sipping] Use of the REFER in draft-shacham-sipping-session-mobility-01

From: "Dale R. Worley" <[email-masked]>
Date: Tue, 30 May 2006 22:44:22 -0400

The message I'm replying to is old, but there are a couple of points
that should be made.  The first one is minor, but the second one is that
some of the examples in draft-shacham-sipping-session-mobility-02 need
to be significantly edited.

On Thu, 2006-02-16 at 16:11 +0100, Alexeitsev, D wrote:
> 1) On the several occurrences in the draft there are no explicit
> method=INVITE statements in the Refer-To header. Does the INVITE
> method is the default method to contact a resource addressed by the
> Refer-To header

It is not well-explained, but it comes from RFC 3261:  A URI denotes a
resource that can be accessed; the way to access it is implicit in the
scheme part of the URI.  In the case of the "sip" scheme, the way to
access it is with an INVITE SIP transaction, unless the URI has a
"method" parameter, in which case, the specified SIP method should be
used to access it.

The effect of a "method" parameter in the URI of a Refer-To: header is
implied by the general rule.

> 2) In the following example from the section "5.3.2  Retrieval of a
> session" how can it be syntaxicly differentiated, that the Replaces
> header belongs to the INVITE and not the REFER method? Why is it
> needed to wrap the Replaces URI with the escaped %22 "-sign?

draft-shacham-sipping-session-mobility-02 contains three examples of
complicated Refer-To: headers.  All three are syntactically invalid per
RFC 3261 section 25, and need to be rewritten.  I will give a detailed
exposition of how to rewrite two of them, so that people will understand
how to apply the rules.

I will use "<<<" and ">>>" as quotation marks, to avoid confusion with
the quotation marks used within the examples.  And like the I-D, I
will use whitespace freely to aid comprehension; the syntax forbids
whitespace in most places within a Refer-To: header.

Section 5.3.1:

The example gives:

      Refer-To:<sip:[email-masked];audio;video?
            Replaces="[email-masked];
                to-tag=bbb;from-tag=aaa">

Per the syntax in RFC 3261 section 25, the part after the <<<?>>>
has the syntax

	hname = hvalue

We want the hname to be "Replaces", and the hvalue to *represent*
<<<[email-masked];to-tag=bbb;from-tag=aaa>>>.

Note that "hvalue" does not admit a double-quote-based escaping
mechanism, only a %-based escaping mechanism.

But the characters that are allowed to appear unescaped in hvalue do
not include <<<@>>>, <<<;>>>, or <<<=>>>, they only include the
characters listed in "alphanum", "mark", and "hnv-unreserved".  And
note that %-HEXDIG-HEXDIG escapes may be in either case -- see RFC
2234, section 3.2.

So at a minimum, one must escape instances of the three characters I
listed:

      Refer-To:<sip:[email-masked];audio;video?
            Replaces=1%40mob.example.com%3B
                to-tag%3Dbbb%3Bfrom-tag%3Daaa>

Note that per the general URI syntax, the above characters (without
the whitespace) *are* the URI. the escapes are considered part of the
character sequence that is the URI, they are only considered to
represent their unescaped counterparts in a presumed later stage of
use of the URI to access a resource.  (This distinction will be
important when we want to represent this URI with an hvalue within
another URI.

Section 5.3.2:

The example gives:

       Refer-To:<sip:[email-masked];method=REFER
              ?Refer-To="<sip:[email-masked];audio;
                      video?Replaces=[email-masked];
                      to-tag=aaa;from-tag=bbb%22>">

First, let us examine the inner URI:

	sip:[email-masked];audio;
                      video?Replaces=[email-masked];
                      to-tag=aaa;from-tag=bbb

By the above discussion, we see that this should be written:

	sip:[email-masked];audio;
                      video?Replaces=1%40local_device.example.com%3B
                      to-tag%3Daaa%3Bfrom-tag%3Dbbb

To represent that URI (which is the character string written above,
excluding the whitespace) with the hvalue of a header part of a URI,
we must first escape the characters within it that are not allowed
unescaped within an hvalue.  That list includes <<<@>>>, <<<;>>>,
<<<=>>>, and <<<%>>>.  So that URI needs to be escaped as:

	sip:cn%40host1.macrosoft.com%3Baudio%3B
                      video?Replaces%3D1%2540local_device.example.com%253B
                      to-tag%253Daaa%253Bfrom-tag%253Dbbb

Now we can assemble the whole URI:

       sip:[email-masked];method=REFER
              ?Refer-To=sip:cn%40host1.macrosoft.com%3Baudio%3B
                      video?Replaces%3D1%2540local_device.example.com%253B
                      to-tag%253Daaa%253Bfrom-tag%253Dbbb

Note that reserved characters in the inner URI have been doubly
escaped.  This is expected, because those characters are subjected to
*two* operations of extracting and unescaping an hvalue.

The Refer-To: header thus should be:

       Refer-To:<sip:[email-masked];method=REFER
              ?Refer-To=sip:cn%40host1.macrosoft.com%3Baudio%3B
                      video?Replaces%3D1%2540local_device.example.com%253B
                      to-tag%253Daaa%253Bfrom-tag%253Dbbb>

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