Subject: [sipcore] -06 of Location Conveyance submitted

From: "James M. Polk" <[email-masked]>
Date: Thu, 24 Feb 2011 20:13:08 -0600

SIPCORE

I've just posted
http://www.ietf.org/internet-drafts/draft-ietf-sipcore-location-conveyance-06.txt

The changes from -05 are that the design team decided that instead of 
the Geolocation header field containing the header parameter 
"routing-allowed", to create a new header field dedicated to carry 
this meaning (Geolocation-Routing).

This separation of indications forced a new subsection within section 
4 to be written, as well as new IANA considerations within section 8 
to explain and account for this new header field.

Less than 10 other words were changed throughout the doc from -05 I 
believe, so this header split was the focus of this revision.

Comments are appreciated

James

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 25 Feb 2011 12:11:17 +0100

James,

I reviewed the diffs and the new version does seem to capture all that we discussed during last few weeks.

As a general remark, explanations concerning the Geolocation-Routing header field in 4.2 and 4.2.1 are rather verbose, and it is particularly confusing that some text talks about it granting/denying permission to view a location (at an intermediary) whereas other text talks about it granting/denying permission to route based on the location. I think there is a significant difference between the two, and we need to be quite clear what is impacted by the Geolocation-Routing header field: viewing or just routing. Viewing has broader implications, e.g., whether you could include in a log file, whether you can attempt to dereference. I can live with what we have rather than delay completion of this important document, but if others share my concern it might be worth trying to clean up the text and fix on a single semantic for this header field.

Some minor points:

1. "The Geolocation header field can have one or more locationValues. A 
   Geolocation header field MUST have at least one header-value."
I think "header-value" should be locationValue. 

2. "Additionally, the first SIP intermediary to add a locationValue adds
   it as the last locationValue in the header value. A SIP intermediary
   that adds a locationValue MUST position it as the last locationValue
   of the last Geolocation header field of the message."
Sounds like there is some repetition here. Perhaps the first sentence should be deleted.

3. "SIP intermediaries are NOT RECOMMENDED to modify existing 
   locationValue(s), and further not to delete any either."
"NOT RECOMMENDED" is not RFC 2119 language. Also the double negative "NOT RECOMMNDED.....not to delete" is surely wrong. Also is "not to delete" supposed to be part of the normative statement. I suspect what is intended is:
"SIP intermediaries SHOULD NOT modify or delete existing locationValue(s)."

4. "Values other than "yes" or "no" are permitted as a  
       mechanism for future extensions, and should be treated the same as  
       "no"."
Should the last part use RFC 2119 language?

5. "If no Geolocation-Routing header field is present in a SIP request,  
       a SIP intermediary MAY insert this header field with a RECOMMENDED  
       value of "no" by default."
I don't see why we need to recommend no - the SIP intermediary should be at liberty to choose any policy. Also I don't see why "by default" is applicable when inserting this header field - the default applies when it is not present. I think we can delete "with a RECOMMENDED value of "no" by default", but if not, we should certainly try to improve the words - it is unclear to me why both "RECOMMENDED" and "by default" are required.

6. " A Geolocation-Routing header-value is set to "no" has no special  
       security properties, this is at most a request for behavior within  
       SIP intermediaries.  "
Could not parse - it seems to contain 3 main verbs. Should it say:
"A Geolocation-Routing header-value that is set to "no" has no special  
       security properties and is nothing more than a request for behavior within  
       SIP intermediaries."

7. "If a Geolocation header field exists 
                                 (meaning a locationValue is already 
                                 present), MUST interpret the lack of a
                                 Geolocation-Routing header field by 
                                 default as if there were one present 
                                 and the header-value is set to "no"."
There is no subject before "MUST". Perhaps it should say "a SIP intermediary MUST".

8. "8.2 IANA Registration for the SIP Geolocation Header Field "
This should be "Geolocation-Routing", not "Geolocation".

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of James M. Polk
> Sent: 25 February 2011 02:13
> To: [email-masked]
> Subject: [sipcore] -06 of Location Conveyance submitted
> 
> SIPCORE
> 
> I've just posted
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>