Re: I-D ACTION:draft-ietf-sip-location-conveyance-05.txt

I think this draft is much improved. While there are some things to 
clean up, I think it now reads well and the form/structure seem close to 
done.

I agree with Jeroen about the syntax. Rather than explicitly including 
<> in the syntax you could simply allow name-addr / addr-spec as many 
headers do. This allows either form and display names as well, even if 
they don't have a lot of use here. Allowing both forms would probably 
save a lot of grief.

Regarding header parameters in the syntax: there might already be value 
in a parameter to indicate preference among multiple geolocations, or to 
identify the party that supplied the header. Multiple locations are at 
SHOULD NOT strength, but I bet they will occur. It would be helpful to 
have a way to specify some context or reason for the presence of one. 
Another possibility is q-values.

I have a number of other comments:

In section 3.2:

    There MUST NOT be more than one
    cid-url pointing to the same location message body (part) in a SIP
    message.

Hmm. Its conceivable that the UA might want to include this, and then a 
proxy might want to add another geolocation header that refers to the 
same body in order to add its own assertion that this is the proper 
location. This would make more sense if there were parameters indicating 
that one was from the UA and another was from a proxy. Its also possible 
that a UAC might want to reference the location for purpose of 
location-conveyance and for some entirely unrelated purpose. I admit 
this is a stretch, but I see no reason to forbid it.

In section 3.5:

    A UAC MUST NOT include this option tag in a Proxy-Require header,
    due to the fact that the UAC is not likely to understand the
    topology of the infrastructure, and therefore does not understand
    which proxy will do the location-based routing function.

In the above, SHOULD NOT seems more appropriate. While a UAC may not be 
likely to understand the topology, in some cases it might.

When using location-by-value, what Content-Disposition is to be used? 
The default is "render", which may not be appropriate. Perhaps 
"attachment" would be suitable. Also, it should probably contain a 
"handling=optional" in case the recipient doesn't support it.

In example 4.2 there is no Content-Id header matching the CID URI in the 
Geolocation header. When using S/MIME to protect a location-by-value, 
should the Content-Id referenced by the Geolocation header be on the 
application/pkcs7-mime body, or on the enclosed application/pidf+xml 
body? Are there variations on how this can be done? (For instance if the 
intent is to use the S/MIME body to protect both the location and the sdp.)

In 5.1:

    ... A location body
    sent without a Geolocation header MUST NOT occur.

This seems overly restrictive. It precludes the use of location bodies 
for purposes entirely unrelated to Geolocation and location conveyance 
as defined in this draft. The whole point of CID is so that headers can 
point to body parts and add context about how they are to be used. I 
think this draft should be silent on this point, or simply mention that 
a location body that is not referenced by a CID URI in a Geolocation 
header has no relevance to location conveyance as defined in this draft.

In 5.2:

    If the geolocation option tag is present in the Supported header of
    a request, the UAS will look to the Geolocation header to see if
    location has been conveyed ...

Is there any reason why the UAS shouldn't interpret Geolocation even 
when Supported: geolocation is not present? In fact, the UAS needs to do 
this when the UAC didn't support, but a proxy added location information.

    A Require header with the geolocation option tag indicates that the
    UAC requests the UAS' location.

Really? Normally a Require would only mean that the UAS is required to 
*understand* geolocation. But I guess there is some precedent for making 
additional demands. I presume this does not mean that the UAS must fail 
the request if it can't return its location - rather I think it at most 
means that the UAS should attempt to return its location if it can. (It 
might not know its location.)

	That's all for now,
	Paul


Jeroen van Bemmel wrote:
> I think this draft has much improved. However, there remains an issue 
> with the ABNF:
> 
> Geolocation        =  "Geolocation" HCOLON (locationURI *(COMMA
>                          locationURI))
> locationURI        =  sip-URI / sips-URI / pres-URI / cid-URI
>                          / absoluteURI
> cidURI             =  "cid:" content-id
> content-id         =  addr-spec ; URL encoding of RFC3261 addr-spec
> I would suggest to use '<' '>' around the URI, and allow for generic 
> header parameters. This is inline with the second example used in 
> section 4.2:
> 
> Geolocation        =  "Geolocation" HCOLON (locationValue *(COMMA
>                          locationValue))locationValue      =  LAQUOT 
> locationURI RAQUOT *(SEMI generic-param)locationURI        =  sip-URI / 
> sips-URI / pres-URI / cid-URI
>                          / absoluteURI
> cidURI             =  "cid:" content-id
> content-id         =  addr-spec ; URL encoding of RFC3261 addr-spec
> Second comment: section 3.5 still contains the phrase "Appearance of the 
> option tag in the Require header is a request for location to be 
> conveyed." Such  semantics are not common for Require
> 
> Regards,
> Jeroen
> 
> 
> [email protected] wrote:
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>> This draft is a work item of the Session Initiation Protocol Working
>>> Group of the IETF.
>>>
>>> Title : Session Initiation Protocol Location Conveyance
>>> Author(s) : J. Polk, B. Rosen
>>> Filename : draft-ietf-sip-location-conveyance-05.txt
>>> Pages : 26
>>> Date : 2006-10-19
>>>
>>> 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.
>>>
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-05.txt 
>>>
>>>
>>> To remove yourself from the I-D Announcement list, send a message to
>>> [email protected] with the word unsubscribe in the body
>>> of
>>> the message.
>>> You can also visit
>>> https://www1.ietf.org/mailman/listinfo/I-D-announce
>>> to change your subscription settings.
>>>
>>> Internet-Drafts are also available by anonymous FTP. Login with the
>>> username "anonymous" and a password of your e-mail address. After
>>> logging in, type "cd internet-drafts" and then
>>> "get draft-ietf-sip-location-conveyance-05.txt".
>>>
>>> A list of Internet-Drafts directories can be found in
>>> http://www.ietf.org/shadow.html
>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>
>>> Internet-Drafts can also be obtained by e-mail.
>>>
>>> Send a message to:
>>> [email protected].
>>> In the body type:
>>> "FILE /internet-drafts/draft-ietf-sip-location-conveyance-05.txt".
>>>
>>> NOTE: The mail server at ietf.org can return the document in
>>> MIME-encoded form by using the "mpack" utility.  To use this
>>> feature, insert the command "ENCODING mime" before the "FILE"
>>> command.  To decode the response(s), you will need "munpack" or
>>> a MIME-compliant mail reader.  Different MIME-compliant mail readers
>>> exhibit different behavior, especially when dealing with
>>> "multipart" MIME messages (i.e. documents which have been split
>>> up into multiple messages), so check your local documentation on
>>> how to manipulate these messages.
>>>
>>> Below is the data which will enable a MIME compliant mail reader
>>> implementation to automatically retrieve the ASCII version of the
>>> Internet-Draft.
>>>
>>
>>
>>
>>> _______________________________________________
>>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>> This list is for NEW development of the core SIP Protocol
>>> Use [email protected] for questions on current sip
>>> Use [email protected] for new developments on the application of sip 
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email protected] for questions on current sip
> Use [email protected] for new developments on the application of sip
> 

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