Subject: [Sip] I-D ACTION:draft-ietf-sip-location-conveyance-05.txt

From: [email-masked]
Date: Thu, 19 Oct 2006 18:50:02 -0400

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-masked] 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-masked].
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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Fri, 20 Oct 2006 08:29:58 +0200

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-masked] wrote:
>> You can also visit
>> https://www1.ietf.org/mailman/listinfo/I-D-announce

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Fri, 20 Oct 2006 08:37:51 +0200

"The entities receiving location MUST obey the privacy and security rules in 
the PIDF-LO as described in RFC4119, regarding retransmission and 
retention."

Does this mean that a SIP proxy receiving a request with a Geolocation must 
first inspect the location object before forwarding? For 
location-by-reference, this may introduce an unacceptable delay, especially 
when the proxy does not do anything with the location information itself.

Proxies that don't understand Geolocation will forward as usual, possibly 
violating the forwarding policy. You may want to spend some words on this. 
For proxies that do understand, you could consider inserting a flag in a SIP 
Geolocation header for the by-reference case, such that a dereference is not 
needed to obtain the policy

Regards,
Jeroen

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 22 Oct 2006 18:54:52 -0500

The extra PIDF-LO tag is the only feature of the draft that I have a problem with.  This seems like a case where the letter of the law is taken over the spirit of the law.

I agree with Jeroen in that a SIP proxy should not have to change its behaviour.  What would be more sensible is to acknowledge that a SIP message with an unencrypted body can be seen by all proxies.  By including a PIDF-LO in this way, you _implicitly_ give proxies permission to forward it.  You don't need special tags for that.  That covers the large number of proxies that don't care, that haven't been upgraded, or that will not be upgraded.

I also don't like the idea that this updates RFC 4119 without saying it.

~
Martin

* My understanding is that the "routing-query-allowed" tag only applies to by-value; a by-reference URI can be forwarded without concerns**.

** There are now cases where this may no longer be true... FFS.

> -----Original Message-----
> From: Jeroen van Bemmel [mailto:[email-masked]]
> Sent: Friday, 20 October 2006 4:38 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Geopriv] Re: [Sip] I-DACTION:draft-ietf-sip-location-conveyance-
> 05.txt
> 
> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Oct 2006 14:44:20 -0400

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:
> 
> 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:
> 
> option tag in the Require header is a request for location to be 
> conveyed." Such  semantics are not common for Require
> 
> Regards,
> Jeroen
> 
>

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 24 Oct 2006 21:27:21 +0200

> they don't have a lot of use here. Allowing both forms would probably

I simply followed the syntax of headers like Call-Info and Error-Info. A 
DisplayName could have a use as a name for the location ("Home"), it's not a 
bad idea to include something for presentation to humans. Would typically 
serve as a tag one would display on a generated map, for example

Regards,
Jeroen

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 30 Oct 2006 11:41:11 -0600

At 06:54 PM 10/22/2006 -0500, Thomson, Martin wrote:
>Content-Type: text/plain;
>         charset="utf-8"
>Content-class: urn:content-classes:message
>
>The extra PIDF-LO tag is the only feature of the draft that I have a 
>problem with.

Martin

I'm not sure I understand which extra tag you are referring to

>  This seems like a case where the letter of the law is taken over the 
> spirit of the law.
>
>I agree with Jeroen in that a SIP proxy should not have to change its 
>behaviour.  What would be more sensible is to acknowledge that a SIP 
>message with an unencrypted body can be seen by all proxies.

I think this is obvious by this in the draft

       Header field             where proxy INV ACK CAN BYE REG OPT PRA
       ----------------------------------------------------------------
       Geolocation              Rr    ar     o   -   -   o   o   o   -

       Header field             where proxy SUB NOT UPD MSG REF INF PUB
       ----------------------------------------------------------------
       Geolocation              Rr    ar     o   o   o   o   o   o   -

                Table 1: Summary of the Geolocation Header

where it clearly states the proxy can read the message body.

>By including a PIDF-LO in this way, you _implicitly_ give proxies 
>permission to forward it.  You don't need special tags for that.  That 
>covers the large number of proxies that don't care, that haven't been 
>upgraded, or that will not be upgraded.
>

My co-author snuck in a RFC4119 update in -04, which was removed in 
-05.  Can you tell me where else you think this ID officially (or how you 
read if should be officially) updates 4119?

Currently, I think -05 of this doc only updates RFC3326 with a new Reason 
protocol.

There has been mention of taking the Location Error Code Registry ID and 
incorporating it into this Conveyance ID, which will add to this update of 
3326.

>~
>Martin
>
>* My understanding is that the "routing-query-allowed" tag only applies to 
>by-value; a by-reference URI can be forwarded without concerns**.
>
>[mf_______________________________________________
>Geopriv mailing list
>[email-masked]

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 30 Oct 2006 12:02:34 -0600

>option tag in the Require header is a request for location to be conveyed."

I missed this when taking out the whole idea of using OPTIONS to learn the 
UAS's location (sorry!). This will be removed.

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 30 Oct 2006 15:43:22 -0600

> I'm not sure I understand which extra tag you are referring to

The PIDF-LO tag "routing-query-allowed" was in the -04 draft (note the date on my email :).  Obviously, my comments don't apply to the -05 draft; thank you.

M

> From: James M. Polk [mailto:[email-masked]]
> Sent: Tuesday, 31 October 2006 4:41 AM
> To: Thomson, Martin; Jeroen van Bemmel; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Geopriv] Re: [Sip] I-DACTION:draft-ietf-sip-location-
> conveyance-05.txt
> 
> > > "The entities receiving location MUST obey the privacy and security
> rules
> > > in
> > > For proxies that do understand, you could consider inserting a flag in
> a
> > > SIP
> > > Geolocation header for the by-reference case, such that a dereference
> is
> > > not
> > > >> This draft is a work item of the Session Initiation Protocol
> Working
> > > >> Group of the IETF.
> > > >>
> > > >> http://www.ietf.org/internet-drafts/draft-ietf-sip-location-
> conveyance-
> > > 05.txt
> > > >>