Subject: [Sip] comments on location conveyance draft

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 20 Mar 2006 01:41:29 -0500

I gave this a quick read. Some high level comments:

* The spec defines two option tags - location and unknown-location. The 
latter (I think) implies that the extension is supported but no location 
is being provided. This is really a misuse of option tags. Option tags 
merely convey whether a specification is supported or not. If you want 
to indicate that the extension is supported but no location is provided, 
then include Supported:location and omit the Location header field

* sometimes the draft talks about the option tags being used in 
Supported/Unsupported, and sometimes in the Location header field 
itself. This makes no sense; option tags should be used as part of the 
Supported/Unsupported/Require header field. What would the semantic be 
of an option tag in Location?

* The new 424 response code defined in section 4.2 doesn't talk about 
usage of Unsupported in the resonse, but the examples in the document 
include it. However, its not supposed to be used this way. Unsupported 
is supposed to be used in a 420 error response, as a consequence of a 
Require header field in a request. 424 is generated only when the UAS 
understands the extension, so it doesn't make sense to use it this way.

* The draft, though shorter than previous versions, seems still far 
longer than it needs to be. It has lots of examples, one for each method 
which might be used. As draft-ietf-sip-guidelines explains, normative 
specs are just supposed to have a single example or two. The numerous 
examples here do not lend to clarity

* The draft is missing a basic overview of operation section (also 
required by sip-guidelines)

* Its not clear to me that 424 is really useful; there are no remedies 
that can be invoked by the UAC, and the draft doesn't define the 
conditions under which it would be sent. How, then, does the system 
behavior differ if a simple 400 is used instead?

* You don't define a mandatory-to-implement URI scheme for obtaining 
location-by-reference. You need to do that, along with any other 
constraints on the URI (secure or not? mandatory content types? etc.)

* The document talks about the Requires header field - its Require

* The Location syntax allows for a token or quoted string value; but 
this is not discussed as to what it would mean

* This paragraph seems contradictory:

  It is RECOMMENDED that only one Location header be in the same
    message, but this is not mandatory.  That said, there MUST NOT be
    more than one cid-url pointing to a location message body (part) in
    a SIP message, regardless of how many Location headers there are in
    that message.  There MUST NOT be more than one location by-reference
    URI in any SIP message, regardless of how many Location headers
    there are in a message.

Why have more than one Location (btw, there is just a single header 
field - it would have multiple values), if you can't have more than one 
cid-url or location-by-reference?

* This is incorrect application of rfc2119 language:

  The SIP Request Methods that MUST convey location are the INVITE,
    REGISTER, UPDATE and MESSAGE Methods.  It is not forbidden by this

MUST/MAY/SHOUDL specify requirements for implementors. You are writing 
this as a requirement for the specification; one that is met by the 
specification itslef in any case.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

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

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 20 Mar 2006 01:14:58 -0600

Jonathan

thanks for the review

comments in-line

At 01:41 AM 3/20/2006 -0500, Jonathan Rosenberg wrote:
>is being provided. This is really a misuse of option tags.

I knew I was stretching the use here (see below)

>Option tags merely convey whether a specification is supported or not. If 
>you want to indicate that the extension is supported but no location is 
>provided, then include Supported:location and omit the Location header field

this is fine with me, as if there is location by-reference, the location 
header would need to  be there with the location URI, and if there is 
location by-value, the location header would need to be there with the cid: 
value of which message body part is carrying the PIDF-LO.

>Supported/Unsupported, and sometimes in the Location header field itself. 
>This makes no sense; option tags should be used as part of the 
>Supported/Unsupported/Require header field. What would the semantic be of 
>an option tag in Location?

Removing the Unknown-Location option-tag (agreed to above) removes this 
issue completely.

>include it. However, its not supposed to be used this way. Unsupported is 
>supposed to be used in a 420 error response, as a consequence of a Require 
>header field in a request. 424 is generated only when the UAS understands 
>the extension, so it doesn't make sense to use it this way.

I will correct this

>* The draft, though shorter than previous versions, seems still far longer 
>than it needs to be. It has lots of examples, one for each method which 
>might be used. As draft-ietf-sip-guidelines explains, normative specs are 
>just supposed to have a single example or two. The numerous examples here 
>do not lend to clarity

hmmm.... I agree that there are a number of examples, including at least 
one per method. I will look to see where I can cut down the number further 
still.

>required by sip-guidelines)

I consider the operation to be there in section 4, but I may be overlooking 
the simplicity that is needed in such a section.

>behavior differ if a simple 400 is used instead?

I expect that if a UAC receives a 424, it knows its location was not 
understood, and to refresh its location, however it got it in the first 
place *or* attempt to fetch its location from a secondary source, and send 
a subsequent SIP message.  I was leary of putting in this non-SIP text, but 
I can easily.

>constraints on the URI (secure or not? mandatory content types? etc.)

ok

>* The document talks about the Requires header field - its Require

sorry

>* The Location syntax allows for a token or quoted string value; but this 
>is not discussed as to what it would mean

I already know to fix this

>Why have more than one Location (btw, there is just a single header field 
>- it would have multiple values), if you can't have more than one cid-url 
>or location-by-reference?

the issue with all this is having more than one pointer to different 
locations. A UAS would not know which is valid for the UAC.  A PIDF-LO as 
an identity of the device, meaning, if there are two, there would be two 
devices at two locations.

This is complicated further by a UAC that S/MIME encrypts a PIDF-LO, and a 
SIP Server, not aware the message had location, adding a Location header 
which pointed at another position for that UAC.

I will work on this explanation in the section

>specification itslef in any case.

  I will correct this