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

Hi Brian,

I guess you are only talking about the current Location Conveyance 
document.

Rosen, Brian wrote:
> 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.

I don't agree with your statements but I am (in the meanwhile) convinced 
that we need to cover this in a separate document.

> 
> 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.

Ok.

> 
> 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.

I disagree with location-by-reference being added to the document (or 
suggest to get it removed from the document).

Ciao
Hannes

> 
> 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