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

From: Hannes Tschofenig ^lt;Hannes.Tschofenig@gmx.net>
Date: Thu Jul 27 2006 - 10:33:59 EDT

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
> Geopriv@ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv
>
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Thu, 27 Jul 2006 16:33:59 +0200

This archive was generated by hypermail 2.1.8 : Thu Jul 27 2006 - 10:34:37 EDT