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

From: "James M. Polk" <[email-masked]>
Date: Tue, 13 Feb 2007 15:39:05 -0600

SIP WG

We've submitted the -07 version of the Location Conveyance document based 
on comments from Shida Shubert and Matt Lepinski, some of which were very 
good, and well appreciated.  Most (all?) were either nits or asking for 
clarifications/rewrites of a few individual sentences that didn't seem to 
make sense as written.

We think this document is now done and have asked the chairs for WGLC on it.

Comments are appreciated

James & Brian

>To: [email-masked]
>From: [email-masked]
>Date: Tue, 13 Feb 2007 15:50:02 -0500
>Cc: [email-masked]
>Subject: [Sip] I-D ACTION:draft-ietf-sip-location-conveyance-07.txt
>
>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-07.txt
>         Pages           : 35
>         Date            : 2007-2-13
>
>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-07.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-07.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-07.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.
>Content-Type: text/plain
>Content-ID: <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-sip-location-conveyance-07.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-07.txt>
>_______________________________________________
>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

_______________________________________________
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: "Umesh Sharma" <[email-masked]>
Date: Thu, 15 Feb 2007 19:03:46 +0530

Pls find comments: 

1.  Introduction 
>> It defines a "target" as the entity whose  location is being
transmitted, in this case, it is 
>>the user agent's (UA) location. 
Target is probably only the "User Agent(UA)" (or the physical box in
which UA is present).

>> ... SIP request, where the choice of the next hop (and usually, the 
>> outgoing Request URI) is determined by the location of the UAC which
>> is in the message by-value or by-reference

May consider rewording like
"... is determined by the location of the UAC which may be conveyed in
the message."
or ".. is determined by the location of the UAC which may be present as
by-vlaue or by-reference."
etc.

3.1

>> Since body parts may not be inserted by a proxy server,
location-by-value 
>> cannot be inserted by a proxy.
A UA's proxy or server would like to insert it 
by-value, where a particular Location Server may not be globally
accessible ?

>> The "inserted-by" parameter has values of "endpoint" or "server", 
>> indicative of which entry ...
indicative of which entity 
   
>>If a SIP message is routed within the network based on the location
>> contained within that message, the "message-routed-on-this-uri"..

"within the network" -- the scope of network is not clear.

3.2 
 >>contain one of two types of URIs:contain of the two types of URIs.
>>Discussing location using the PUBLISH Request Method out of scope for
this document
]is[ out of scope for this document

3.5
>>  Appearance of the option tag in the Require header is a request for
location to
>>   be conveyed.
>From rfc3261 it is inferred that the UAS needs to understand the
conveyance information coming from UAC/etc. 
Maybe an emergency call where there are two PSAPs where call could be
forwarded, the one who understands the Geo-LocationInfo ulitmately gets
the call.

4.1
>>...indicates the content-ID location [RFC2392] within the multipart 
>>   message body of were location information is

message body of ]where[ location information is

Thanks
Umesh

-----Original Message-----
From: James M. Polk [mailto:[email-masked]] 
Sent: Wednesday, February 14, 2007 3:09 AM
To: [email-masked]
Subject: Fwd: [Sip] I-D ACTION:draft-ietf-sip-location-conveyance-07.txt

SIP WG

We've submitted the -07 version of the Location Conveyance document
based on comments from Shida Shubert and Matt Lepinski, some of which
were very good, and well appreciated.  Most (all?) were either nits or
asking for clarifications/rewrites of a few individual sentences that
didn't seem to make sense as written.

We think this document is now done and have asked the chairs for WGLC on
it.

Comments are appreciated

James & Brian

>This draft is a work item of the Session Initiation Protocol Working 
>Group of the IETF.
>
>logging in, type "cd internet-drafts" and then "get 
>draft-ietf-sip-location-conveyance-07.txt".
>
>http://www.ietf.org/shadow.html or 
>ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>         "FILE
/internet-drafts/draft-ietf-sip-location-conveyance-07.txt".
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-
>07.txt> _______________________________________________
>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

_______________________________________________
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: Hannes Tschofenig <[email-masked]>
Date: Thu, 15 Feb 2007 16:18:46 +0200

Hi James,

I have never seen the comments from Shida and Matt for this document. 
Are you referring to some older discussions?

Ciao
Hannes

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 15 Feb 2007 10:23:54 -0600

At 04:18 PM 2/15/2007 +0200, Hannes Tschofenig wrote:
>Hi James,
>
>I have never seen the comments from Shida and Matt for this 
>document. Are you referring to some older discussions?

Hannes

Shida's, I just noticed, was only to the authors, and was Dec 12th, 
06 - and his review was for -05 the day I submitted -06, which 
covered most of what he wanted changed (showing good minds think 
alike, perhaps?).

Matt's was Jan 4th, 07 to the SIP list

so these are not so old...

James

>>based on comments from Shida Shubert and Matt Lepinski, some of 
>>which were very good, and well appreciated.  Most (all?) were 
>>either nits or asking for clarifications/rewrites of a few 
>>individual sentences that didn't seem to make sense as written.
>>
>>>This draft is a work item of the Session Initiation Protocol 
>>>Working Group of the IETF.
>>>

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 15 Feb 2007 17:59:57 -0600

Hey

Thanks for the review. Please see my comments in-line

>Target is probably only the "User Agent(UA)" (or the physical box in

I reworded the first part of the second paragraph to:

"Geographic location in the IETF is discussed in RFC 3693 (Geopriv 
Requirements) [RFC3693]. It defines a "target" as the entity whose 
location is being sought. In this case, this is the user agent's (UA) 
location. "

>by-vlaue or by-reference."

Here, I am reading that you want the text to change from a case in 
which location is in the message, to one in which location *may* be 
in the message. While I agree completely that location can only be a 
MAY in general, for location based routing (the subject of this part 
of the text, we should indicate that location is present in order to 
perform this location based routing.  Do you agree?

>by-value, where a particular Location Server may not be globally

Here, I am not sure I understand your question.  RFC 3261 does not 
allow SIP Proxies from inserting message bodies, so even if the proxy 
knows where the UAC is, it cannot insert this location information 
by-value.  The terminology "Location Server" in Geopriv is the IP 
entity that builds the PIDF-LO and is first to transmit it.  Since 
proxies cannot insert location by-value, proxies cannot be Location 
Servers. UACs can be location servers, and B2BUAs can be location servers.

Within all this, you mention the location server "may not be globally 
accessible". This tells me you are actually referring to the server 
where the location-by-reference URI points to (i.e. where the UAC's 
PIDF-LO is - waiting to be accessed - which is called 
dereferencing).  This is not a "Location Server" in Geopriv, and RFC 
3693 defines this.

This document already states the dereference server needs to be 
accessible if location is conveyed by-reference, otherwise location 
is not conveyed (which is the point of this extension).

>indicative of which entity

are you taking issue with the word "indicative"? If so, how about me 
changing this to "... indicating which entity..."

>"within the network" -- the scope of network is not clear.

fair -- how about I take "within the network" out of the sentence?

>]is[ out of scope for this document

thanks, changed

>forwarded, the one who understands the Geo-LocationInfo ulitmately gets

I think this is outside the scope of this doc. This topic should be 
asked in ECRIT, as they have 2 docs defining the devices BCP and the 
Emergency calling Framework. Hopefully there will be an emergency 
services network in front of the IP enabled PSAP to route the call to 
a PSAP that can understand this extension.

That said, I believe what will happen is most (if not all?) IP based 
PSAPs understand this extension from the beginning.  NENA  and EMTEL 
are telling all PSAPs in North America and the EU to do this. Several 
other areas of the world are being told to do this also.  Of course 
we cannot be assured every IP enabled PSAP in the world will, but 
it's likely to be based on something from the IETF, the ITU-T, 3GPP 
or one of the other SDOs that attended last year's Emergency SDO 
conference that agreed to this general mechanism to convey location 
to a PSAP from a SIP phone.

>message body of ]where[ location information is

Got it, thanks!

James

> ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-sip-location-conveya 
> nce->07.txt> _______________________________________________

---

From: "Umesh Sharma" <[email-masked]>
Date: Fri, 16 Feb 2007 18:10:53 +0530

Dear James

Pls find comments inline.

Thanks
US
-----Original Message-----
From: James M. Polk [mailto:[email-masked]] 
Sent: Friday, February 16, 2007 5:30 AM
To: Umesh Sharma; [email-masked]
Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-location-conveyance-07.txt 

Hey

---
US:

I am afraid it still seems to mean the same. 

This-->target-->UA's location
I mean This-->target-->UA

UA's Location would be represented as PID-LO.

Otherwise in the reworded para:

If you say something like "In this case, this is the user agent whose
location is desired" etc. then UA becomes the entity.

---

> >> outgoing Request URI) is determined by the location of the UAC 
> >> which is in the message by-value or by-reference
>

>by-vlaue or by-reference."

Here, I am reading that you want the text to change from a case in which
location is in the message, to one in which location *may* be in the
message. While I agree completely that location can only be a MAY in
general, for location based routing (the subject of this part of the
text, we should indicate that location is present in order to perform
this location based routing.  Do you agree?

---
US: 

agreed here(MAY part).
Additionally, I wanted the sentence to be re-formatted for a better
placing of the "by-value or by-reference" part, but that is non-issue.
----

>A UA's proxy or server would like to insert it by-value, where a 
>particular Location Server may not be globally accessible ?

Here, I am not sure I understand your question.  RFC 3261 does not allow
SIP Proxies from inserting message bodies, so even if the proxy knows
where the UAC is, it cannot insert this location information by-value.
The terminology "Location Server" in Geopriv is the IP entity that
builds the PIDF-LO and is first to transmit it.  Since proxies cannot
insert location by-value, proxies cannot be Location Servers. UACs can
be location servers, and B2BUAs can be location servers.

----
US: That would be the Location Generators (entities that build PIDF-LO),
Location Servers would receive these PIDF-LO from the LGs (RFC3693)
and/or receive subscriptions from LRs.
----

Within all this, you mention the location server "may not be globally
accessible". This tells me you are actually referring to the server
where the location-by-reference URI points to (i.e. where the UAC's
PIDF-LO is - waiting to be accessed - which is called dereferencing).
This is not a "Location Server" in Geopriv, and RFC
3693 defines this.

-----
US: 

But here I think this(the server) would correspond to an entity like
Presence Agent that would respond to dereferencing SUBSCRIBE requests
with NOTIFY's but this is one of the function of a Location Server
[RFC2693]. 

----

This document already states the dereference server needs to be
accessible if location is conveyed by-reference, otherwise location is
not conveyed (which is the point of this extension).

----
Ok 
-----

----------
US: ok: "...indicating which entity added location to the message." 
------------

---
ok.
---

thanks, changed

I think this is outside the scope of this doc. This topic should be
asked in ECRIT, as they have 2 docs defining the devices BCP and the
Emergency calling Framework. Hopefully there will be an emergency
services network in front of the IP enabled PSAP to route the call to a
PSAP that can understand this extension.

That said, I believe what will happen is most (if not all?) IP based
PSAPs understand this extension from the beginning.  NENA  and EMTEL are
telling all PSAPs in North America and the EU to do this. Several other
areas of the world are being told to do this also.  Of course we cannot
be assured every IP enabled PSAP in the world will, but it's likely to
be based on something from the IETF, the ITU-T, 3GPP or one of the other
SDOs that attended last year's Emergency SDO conference that agreed to
this general mechanism to convey location to a PSAP from a SIP phone.

---
US:

Ok,  but is this contradicting the statement in Section 5.2 which says
"...A Require header with the geolocation option tag indicates the UAC
is requiring the UAS understand this extension or else send an error
response." 

as opposed to 3.5  "...Appearance of the option tag in the Require
header is a request for location to be conveyed."
---

Got it, thanks!

James

>Subject: Fwd: [Sip] I-D 
>ACTION:draft-ietf-sip-location-conveyance-07.txt
>
>
>SIP WG
>
> >http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyanc
> >e-
> >07.txt
> >
> >[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
> >         up into multiple messages), so check your local 
> > documentation
>on

---

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Mon, 19 Feb 2007 21:08:09 +0100

Can you repost those that did not appear on the SIP list to the SIP
list, so they appear in the archive.

Regards

Keith 

> Sent: 15 February 2007 16:24
> To: Hannes Tschofenig
> Cc: [email-masked]
> Subject: Re: Fwd: [Sip] I-D 
> document. 
> 06 - and his review was for -05 the day I submitted -06, 
> which covered most of what he wanted changed (showing good 
> minds think alike, perhaps?).
> 
> >>>         Filename        : 
> draft-ietf-sip-location-conveyance-07.txt
> >>>         Pages           : 35
> >>>         Date            : 2007-2-13
> >>>
> >>>e-07.txt
> documentation on
> >>><ftp://ftp.ietf.org/internet-drafts/draft-ietf-sip-location
> -conveyanc
> >>>e-07.txt>
> >>>
> [email-masked] for questions on current sip

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 19 Feb 2007 20:05:50 -0600

Keith

Below is the thread Shida and I had from Dec 12th, 06 through Jan 
2nd, 07, as you have asked for:

Shida

comments in-line

At 04:50 PM 1/2/2007 -0800, Shida Schubert wrote:

>Hi James;
>
>Thanks for the response, my comments inline..
>
>James M. Polk wrote:
> > Shida
> >
> > I spaced this message when I submitted -06 (the other day) of Location
> > conveyance.
> >
> > I have a few comments below in line which we can discuss which should
> > still modify -06 (into -07)
> >
> > At 05:44 PM 12/12/2006 -0800, Shida Schubert wrote:
> >> Hi James and Brian;
> >>
> >> I offered to review the draft so here it is.
> >>
> >> I think it needs some more clarifications. I will review the
> >> draft more thoroughly once the changes agreed at the last IETF
> >> is reflected.
> >>
> >> Section 5. 5th paragraph, 1st sentence.
> >> --------------------------------------------
> >> More than one location representation or format, for example: civic
> >> and geo, MAY be included in the same message body part, but all MUST
> >> point at the same position on the earth.
> >>
> >> This can't be a MUST as Proxy may insert the location that it thinks
> >> is correct according to its knowledge and it may not have a way to
> >> validate that the address proxy inserts
> >
> > Proxies cannot insert a message body, per RFC3261, so I don't believe
> > this comment applies.
>Yes, I must have been partially sleeping of something. I overlooked the
>"same
>message body part" especially the "body part".. My apology.

no problem

> >
> >
> >> Section 5.1, 1st paragraph, 1st sentence.
> >> --------------------------------------------
> >> The presence of the geolocation option tag in a Supported header
> >> without a Geolocation header in the same message informs a receiving
> >> SIP element the UAC understands the concept of location, but it does
> >> not know its location at this time.
> >>
> >> I don't know if this is the correct interpretation UAS should have.
> >> UAC sending the "geolocation" tag in the Supported header merely means
> >> that it understands the spec. It does not mean that it does not
> >> understand
> >> its location at that time. It may but may simply not include it because
> >> it saw no need to do so.
> >
> > the option tag shouldn't be in the request if the UA don't understand
> > the extension, and but putting it in the request - in this case -
> > without a Geolocation heder - means the UA doesn't have a location for
> > itself to include, therefore do not error the request expecting the
> > UAC to figure out it needs to put in its location in order for the
> > message to be processed properly. The error will be ignored, and the
> > subsequent request while look different how (to the proxy)? Without
> > this behavior there will be a loop of UAC sending a request without
> > location, and the proxy erroring the message, the UAC sending the
> > message again without location, and the proxy again erroring the
> > message. This doesn't stop without some indication in the request that
> > the UAC knows it doesn't have its location and to not error the message.
>Considering the cost for the location retrieval on some of the devices
>out there(dollar cost and time), UAC may only
>want to send a location information when requested. So how can we do
>this? Currently there is no way for UAS to have the
>understanding that UAC supports the location but simply did not include
>the location information when available upon requests.
>Of course we can ignore this case, and keep the current definition of
>no geolocation = do not support the spec
>geolocation + no Geolocation = do not understand the location

ah, but having the option tag means "do not error (424) this message 
expecting location to be included", it says the UAC understands the 
SIP extension. A UAS can then attempt to SUB to the original UAC (now 
the UAS of the SUB) and see if it can pull location from the UA. The 
event package will have to be specified, which it isn't.

>Added to this, what happens when geolocation + no Geolocation is set by
>UAC but proxy adds Geolocation? This does not
>necessary means that UAC understands its location but according to the
>text above, it will have that semantics.

if something were created to be added by the UAC to indicate it 
doesn't no have its location, yet understands the geolocation SIP 
extension, this would have to be removed by the SIP proxy (which is 
dangerous) that inserts the UAC's location into the message. That's 
why we are more or less implying something here, instead of being explicit.

> >
> >> Section 5.2, 1st paragraph, 2nd sentence.
> >> --------------------------------------------
> >> The paragraph only talks about when the Subscription succeeds, it
> >> should mention what would happen to the dialog if the subscription
> >> fails.
> >> I personally it should not affect the pre-existing dialog if there is
> >> a dialog already established.
> >
> > Are you suggesting a 183 be sent until location can be dereferenced or
> > not, then send a 200 OK regardless, with the difference being the
> > Warning header is in the 200 OK if the dialog is continued to be
> > established?
> >
> > Right now the 183 message isn't mentioned. Maybe it should be.
> >
> > A Warning in a 200 OK also isn't mentioned...
>This comment was arised after I read the dialog-usage. This is another
>scenario where
>pre-existing dialog is used to establish a subscription(If subscribing
>to the UAC to attain the
>location info).
>
>If it is indeed it's re-using the pre-exisiting dialog, text may want to
>mention that
>pre-existing dialog is not terminated even if the location retrieval
>fails is all I wanted to state
>here I think..

I think this is reasonable to add

>I think this is probably not a big deal.
>
> >
> >
> >>
> >> Section 5.3, 2nd paragraph,
> >> ----------------------------------
> >> It needs to be clarified how proxy would add the location information
> >> when there is already a Geolocation header present in the message. Can
> >> it add the location information to the pre-existing Geolocation header?
> >
> > I've added text to section 5.3.1 covering this
> >
> > I think this is covered in 3261:
> >
> > More than one instance of a header, such as
> >
> > Geolocation: [email-masked]
> > Geolocation: [email-masked]
> >
> > is the same as
> >
> > Geolocation: [email-masked], [email-masked]
> >
> > Is something more needing to be said here?
>Nope.
>
>Text below confused me a little bit, as it sounds as if the proxy
>is not able to add any location reference(MUST NOT modify the
>contents of an existing Geolocation sounds like adding a location
>URI can mean "modifying the contents"). It's probably my
>misinterpretation due to English being a second language for me.

actually, adding a second geolocation uri is fine, as long as the 
existing uris themselves in the geolocation header are not deleted, 
or modified. This, I hope is clear from section 5.3.1.

I will change the text (below) to state "...MUST NOT modify any 
existing URI in the Geolocation header..." to be clear that a new uri 
can be added, but the one(s) there cannot be modified or deleted.

Thanks

James

>Thanks again for your response.
>
>Regards
>Shida
>
> >
> >>
> >> Section 3.2, 3rd last paragraph has a text stating
> >> "A proxy MAY add the Geolocation header, but MUST
> >> NOT modify the contents of an existing Geolocation header."
> >>
> >> But my interpretation of the text does not prohibit the proxy from
> >> adding location information(location-by-reference) in the pre-existing
> >> Geolocation header.
> >
> > you read this correctly
>
> >
> >
> >> Regards
> >> Shida Schubert
> >>

At 02:08 PM 2/19/2007, Drage, Keith \(Keith\) wrote:
> > >>><ftp://ftp.ietf.org/internet-drafts/draft-ietf-sip-location> -conveyanc
> > >>>e-07.txt>
> > >>>