Subject: [Geopriv] Location header

From: "Martin Thomson" <[email-masked]>
Date: Tue, 9 Aug 2005 10:39:17 +1000

A little while back, I sent a message to the authors of the
draft-daviel-http-geo-header-03.txt that recommended that the drafts be
extended to include a generic location header that includes location
by-reference.  Since that didn't elicit a response, I will raise this in the
larger forum.

I think that there would be some benefit in defining a header.  This also
covers the SIP location conveyance draft, but the information could be made
more generic - I see no reason why HTTP and SIP can't both use the same
header.

To that end, I propose that the following header be supported:

	(HCOLON definition from RFC 3261, URI from RFC 3986)
	location-header = "Location" HCOLON URI

This forces the use of the cid scheme when location is included by-value,
but ensures that where location information is included it can be
unambiguously identified.

The other values that are included in SIP location conveyance provide no
additional value, except perhaps the convey-uac/convey-uas values [*].  The
only value that these might add is to indicate that a UA/client knows that
it could/should include location information but has not.  I don't see this
as sufficiently important, since the only case where this applies is where
the UA is "location-aware" but doesn't care to include the information.
Also, there are only two reasons I see for not including location
information: it doesn't have it at the time; or, including LI when it may or
may not be required increases the message size substantially.  The first is
addressed by the SIP 425 response code.  The second is either resolved by
the 425 code, or always providing location by-reference.

[*] I shouldn't comment on the convey-uac/convey-uas values (I don't profess
to know enough about SIP header policies), but they do look like they
warrant a separate header: Convey-Location: uac|uas.

Martin 

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 09 Aug 2005 08:57:09 -0500

Martin

Any discussion about the SIP Location Conveyance ID should be done on the 
SIP list, as that WG owns the ID and there will be next to zero 
cross-polination.

But to give an update to this list on the status of the SIP Location ID:

 From my preso in the SIP WG last week, convey-uas and convey-uac 
option-tags are gone. These features will be replaced with feature tags 
within the Contact header.

The unknown option-tag is there (barely), and more for future 
considerations than anything.

The geo-loc and civic-loc option-tags are still there for the OPTIONS 
Request of another's location.

The Location option-tag will be added for the Require, Proxy-Require, 
Supported and Unsupported headers for SIP elements that do or do not 
support this header.

The SUBSCRIBE Method for requesting location of another UA will be a 
Presence event package done in SIMPLE, but exampled in this document so 
folks will be able to see it.

I foresee a fair rewrite of the requirements section based on firm feedback 
from a few vocal individuals, and I'm still sifting through my notes on 
those discussions, which will have an impact on ECRIT.

At 10:39 AM 8/9/2005 +1000, Martin Thomson wrote:

>by-reference.  Since that didn't elicit a response, I will raise this in 
>the larger forum.
>
>covers the SIP location conveyance draft, but the information could be 
>made more generic - I see no reason why HTTP and SIP can't both use the 
>same header.
>
>additional value, except perhaps the convey-uac/convey-uas values 
>[*].  The only value that these might add is to indicate that a UA/client 
>knows that it could/should include location information but has not.  I 
>don't see this as sufficiently important, since the only case where this 
>applies is where the UA is "location-aware" but doesn't care to include 
>the information.  Also, there are only two reasons I see for not including 
>location information: it doesn't have it at the time; or, including LI 
>when it may or may not be required increases the message size 
>substantially.  The first is addressed by the SIP 425 response code.  The 
>second is either resolved by the 425 code, or always providing location 
>by-reference.
>
>[*] I shouldn't comment on the convey-uac/convey-uas values (I don't 
>profess to know enough about SIP header policies), but they do look like 
>they warrant a separate header: Convey-Location: uac|uas.
>
>Martin

cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.