RE: [Geopriv] Consensus on changes to location-conveyance

 
I don't agree that there is a consensus to preclude the use of HTTP. 
I would favor not placing your proposed restriction on the URI scheme
for expressing a location reference in the SIP location conveyance
draft; or at least including HTTP as a valid location-reference URI
type.

Regards,
Nadine Abbott

-----Original Message-----
From: Rosen, Brian [mailto:[email protected]] 
Sent: Tuesday, July 25, 2006 1:38 PM
To: [email protected]
Cc: [email protected]
Subject: [Geopriv] Consensus on changes to location-conveyance

I have put out a number of emails on proposed changes to location
conveyance.  Some of them have sparked a number of comments.  My summary
of consensus on these issues is:

1. We proposed to explicitly disallow use of a Data URI, which would
allow specification of a Location-by-value in a header.  There was a lot
of list traffic on this, currently in the state where Keith asked for a
real use case for it.  So far, we don't see a use case that cannot be
provided by location-by-reference in a header.  If we don't get a good
use case, I think consensus is to disallow location-by-value in a
header.

2. Dereferencing location-by-reference.  We had initially proposed to
document a process to use a raw HTTP(S) Get to dereference.  There was a
lot of discussion, and then I made a new proposal, see item 6. 

3. We proposed to allow a Reason header with a 424 Bad Location
response.  This seems to be acceptable to the WG.  Geopriv will create
and populate the registry in a separate draft.

4. We proposed to explicitly allow hop-by-hop TLS security for location
when the endpoint wished to allow routing based on location.  We further
proposed to interpret "Do not Distribute" flags as allowing sending of
the location to the routing database (LoST for example).  Hannes pointed
out that there was a proposal to allow two Location headers, one of
which could be used for routing and another for onward forwarding to the
recipient.  Hannes' message seemed to agree that "Do not distribute"
would allow sending of the location to the routing-by-location database,
but would obligate the proxy that did that to remove the location before
it forwarded the message.  There were no other messages on this thread.
We conclude that allowing hop-by-hop security for location based routing
is acceptable, and Do Not Distribute DOES allow forwarding to a routing
database, but requires that the proxy doing the location based route to
remove the location it uses for that purpose.

5. We proposed to create a parameter and a registry to distinguish
multiple ways to dereference a location where HTTP(S) was the transport.
Resolution of this issue depends on resolution of issue 6.

6. We proposed to allow sip/sips and pres: in the location header.  I
later speculated that if we allow this, it forms a simple way to do
location-by-reference, and we could eliminate the raw HTTP(S) Get
proposal, with the parameter and registry entirely.  There was some list
traffic in favor of this.  Martin Thompson is skeptical that SIP
Presence Subscribe/Notify is actually allowed as a geopriv "using
protocol".  Several of think that it is.  If we don't get any more
comments on this proposal, we will allow sip/sips and pres, not have any
http(s) resolution text, and not propose a parameter and accompanying
registry.

If this does not reflect your position, please speak up now.

Brian

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

_______________________________________________
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