Subject: [Sip] New Location Conveyance -06 submitted

From: "James M. Polk" <[email-masked]>
Date: Tue, 02 Jan 2007 17:29:18 -0600

I've submitted the -06 version of Location Conveyance for review

http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-06.txt

    This document defines an extension to the Session Initiation
    Protocol (SIP) to convey geographic location information from one
    SIP entity to another SIP entity.  The extension covers end to end
    conveyance as well as location-based routing, where proxy servers
    make routing decisions based on the location of the UAC.

The changes from -05 to -06 are as follows:

    - cleaned up some inconsistencies wrt the S/MIME example in Section
      4.2

    - changed the ABNF to include the ability to indicate which SIP
      element inserted a particular location URI, and how a message
      routing server indicates which location the message was routed
      upon (based on the location in the message)

    - give examples of the above in section 5.3.1

    - changed the granular error code from a Reason header indication to
      a Warning code indication (section 3.4), and IANA registered 14
      new Warning codes in this document

    - As a consequence of the above bullet, changed the specific SIP
      element behaviors of each SIP element regarding sending or
      receiving a 424 response with a Warning header

    - Added rules about indicating which SIP element inserted a
      particular location into a message (a new Geolocation header
      parameter), as well as when a server adds another new header
      parameter indicating the request was routed based on a particular
      location included in the message

Please comment

James

_______________________________________________
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: Matt Lepinski <[email-masked]>
Date: Thu, 04 Jan 2007 14:50:32 -0500

James,

Here are some comments on the latest conveyance draft. I generally like 
the document, so it's mostly small stuff, but hopefully helpful, 
nonetheless.

First, you refer

Section 1: Introduction
----------------------------
 I have trouble understanding the last sentance of the first paragraph. 
Consider condensing the sentence. For example,
"We use the term "conveyance" to distinguish this work from other 
cirmustances in which location is used, such as location sighting or 
location configuration."
The above sentance might be too vague, another possibility:
"We use the term "conveyance" to distinguish this work from other 
circumstance in which location is used, such as the initial generation 
of location information or the acquisition of location information by 
the SIP entity."

Section 3.3: 424 Response Code
---------------------------------------
The final sentance of the final paragraph reads:
"An initial set of location error codes are in [ID-ERROR]"
I don't know if a concesus was reached regarding the future of the 
ID-ERROR (Geopriv error code registry draft).
 However, it seems that either:
- The reference to ID-ERROR should be removed because the ID-ERROR draft 
is not moving forward,
or else
- Additional text should be added to clarify the relationship between 
the error code registry draft and the new warning codes provided in 
Section 3.4

Section 3.4: New Warning Codes for Location Error Granularity
-----------------------------------------------------------------------------
 The final sentance of paragraph 2 should read:
"This can be useful for troubleshooting."  (added the word 'be')

Section 3.4.1
----------------
The third sentance reads: "... only understood location in RFC4119 
PIDF-LO format (civic or geo)."
In this context it may be unclear to the reader what you mean by "geo".
I'm not sure what you should call the format that's not civic, but it's 
important to be consistant (and as clear as possible).
In this document, you refer to "geo" in 3.4.1, "Geo-location Format" in 
3.4.2, and "Coordinate Format" in 4.1
Also, RFC 4119 refers to this format as GML 3.0, and the LoST drafts 
refer to this format as "Geodetic Coordinate".
So basically, I don't know how you should refer to this format, but 
using "geo" as short hand without defining it, may cause confusion.
(Also, consider adding a space between RFC and 4119.)

Next, in the 5th (second to last) sentence of the first paragraph, the 
'SHOULD' is capitalized, but in the last sentence the 'should' is not 
capitalized. My inclination is that since these are just examples, the 
'should' should not be capitalized in either case. However, if you want 
the text to be normative, you should captialize both occurances of 'should'

Section 3.4.3
----------------
In the second paragraph, the word 'Warning' probably does not need to be 
capitolized.

Section 3.4.4
----------------
The first sentance is missing a comma and should read:
"... means the location provided, whether by-value or by-reference, in a 
request is not well formed."

Section 3.4.5
----------------
I found the second paragraph to be unclear. Consider re-wording it as 
follows:
"A typical reaction to receiving this warning code is for the location 
sender to verify that it has indeed included location information in the 
request and then to send the request again."

Section 3.4.6
----------------
In the second paragraph, consider changing 'error' to 'warning code' for 
consistancy.

Section 3.4.7
----------------
Consider re-wording the second paragraph as follows:
"A typical reaction to receiving this warning code is for the location 
sender to convey more information, if doing so is allowed by local policy."

Section 3.4.12
-----------------
In the second paragraph, consider changing 'error' to 'warning code' for 
consistancy.

Section 3.6
--------------
In the last sentance of the first paragraph, consider adding a space 
between RFC and 3693.

I had trouble understanding the first sentance of the second paragraph. 
Consider a re-wording such as:
"... treating the URI as a presence URI and dereferencing it by sending 
a SUBSCRIBE request to a presence server as per [RFC3856]."

In the last sentance of the third paragraph, add the word 'is' before 
the phrase 'the purpose of this extension'

Section 5
-----------
In the fourth paragraph, add the word 'a' between 'for protecting' and 
'PIDF'

Consider rewording the first sentance of the last paragraph as follows:
"... in the same SIP message, so long as each is in a separate message 
body part."

Section 5.1
-------------
In the first sentance of the third paragraph, consider adding the phrase 
'or wish to convey' between 'does not know' and 'its location at this time'.

In sentance three of paragraph five, I find the phrase 'learn from the 
Warning code' to be unclear. Consider re-wording the sentance as follows:
"Upon receiving an error response, the UAC SHOULD take appropriate steps 
based on the warning code before attempting to convey location again."

I had trouble with the final paragraph of this section. I understand 
that if the UAC has a problem with location information sent by the UAS 
it doesn't have an oppertunity to send a warning code and should just 
ignore the information. However, you go on to say that "A subscription 
is a better means of getting a UAS's location". By 'a subscription' do 
you mean location-by-reference as opposed to location-by-value? Also, 
it's not clear why a subscription is a better way of obtaining the 
location of a UAS. Perhaps you could write a small amount of additional 
text clarifying this notion.

Section 5.2
--------------
Consider re-wording the first sentance of the first paragraph as follows:
"... is present, the type of URI contained in the header field will 
indicate if location ..."

In the first sentance of the second paragraph, consider changing "or 
error the message" to "or else send an error response"

Section 5.3
-------------
Consider re-wording the first sentance of the first paragraph as follows:
"Proxies that perform location-based routing may need to consult 
external databases or systems to determine the route."

Section 5.3.1
----------------
In the first sentance of the first paragraph, consider adding the word 
'geolocation' between 'any existing' and 'header'.

The first paragraph indicates that any existing header parameter MUST 
NOT be modified or deleted by a proxy. However, the last paragraph 
describes a case where the proxy MUST remove the incoming 
"message-routed-on-this-uri". If "message-routed-on-this-uri" is a 
header parameter than this is a contradiction. (Alternatively, if this 
is not a contradiction, then it's unclear to me what a header parameter is).