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

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 25 Jul 2006 16:42:35 -0400

Thanks.

To define the "retransmission for routing" bit, we need to rev PIDF-LO.
I don't think doing that in location-conveyance is the right place.
Would you agree?

Is there consensus one way or the other on this?  Generally, I do agree
explicit is better than implicit for any kind of permission.  I'm loath
to generate yet one more RFC, but this one looks simple enough.

With respect to an HTTP protocol for location by reference
dereferencing, I have no problem with having some other document specify
this.  We're going to have a simple mechanism defined in
location-conveyance to allow such an extension; it won't require the SIP
change process.  If that is an acceptable compromise, then we can close
this issue, although I'll certainly be holding off a couple of days to
hear from other folks.

Brian

> -----Original Message-----
> From: Ted Hardie [mailto:[email-masked]]
> Sent: Tuesday, July 25, 2006 4:34 PM
> To: Rosen, Brian; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Geopriv] Consensus on changes to location-conveyance
> 
> At 2:45 PM -0400 7/25/06, Rosen, Brian wrote:
> >Summarizing, you think hop-by-hop security (TLS) is acceptable when
the
> >location is sent for the purposes of location based routing, but you
are
> >not in favor of defining "retransmission=no" to permit sending the
> >location to the routing database (e.g. LoST).  You want a more
explicit
> >permission.
> 
> Yes.
> 
> >I don't think a cid: with a ruleset is acceptable, as it would not
> >permit location by reference added by a proxy to specify this.
> 
> Fair enough.
> 
> 
> 
> >If this is the consensus, I think we would have to add a bit to the
PIDF
> >to explicitly control this behavior.
> 
> I think an extension that says "retransmission for routing=yes" is the
> cleanest
> way to go.
> 
> 
> >Why do you think we must specify an HTTP dereference procedure in
this
> >document?  What is the purpose when the SIP based method is
available?
> >We had believed we had to have SOME method of dereferencing to make
> >location-by-reference meaningful in the document.  If we have one sip
> >based method, we meet the requirement.  Having more options,
especially
> >completely new HTTP based protocols IN THIS DOCUMENT seems
unnecessary
> >and unwise.  For example, if we define such a protocol, it becomes a
> >geopriv "using protocol" and needs an explicit analysis against the
> >geopriv criteria.
> 
> I don't think we have to do it in this document, but I read your
previous
> message as a statement of consensus about the HTTP dereference
mechanisms
> that have been discussed.   I don't agree with that statement, since I
> think the
> HTTP discussions somewhat over-thought the potential problems.  In
> particular, a
> lot of the discussion was around the idea that
> http://dereference.example.org/foo-pidf-lo
> might mean lots of different things, depending on what http meant.
There
> are
> already ways to deal with that; none of them are perfect (see, for
> example,
> the discussion in draft-reschke-webdav-mount-05.txt and its appendix A
for
> a similar
> problem in a different context), but they can work, especially if you
set
> a baseline
> approach.
> 
> 				regards,
> 					Ted Hardie
> 
> 
> 
> >Brian
> >
> >> -----Original Message-----
> >> From: Ted Hardie [mailto:[email-masked]]
> >> Sent: Tuesday, July 25, 2006 2:19 PM
> >> To: Rosen, Brian; [email-masked]
> >> Cc: [email-masked]
> >> Subject: Re: [Geopriv] Consensus on changes to location-conveyance
> >>
> >> At 1:38 PM -0400 7/25/06, Rosen, Brian wrote:
> >> >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.
> >>
> >> Actually, I commented on the same problem, though it may have been
> >> connected to one of the related threads; here's the text of that
> >message:
> >>
> >> >At 5:23 PM -0400 7/19/06, Brian Rosen wrote:
> >> >>NOTE: THIS MESSAGE IS COPIED TO SIP AND ECRIT, IF YOU REPLY, SEND
IT
> >> ONLY TO
> >> >>GEOPRIV
> >> >>However, this opens up the issue of geopriv privacy concerns
because
> >the
> >> >>sender does not know the identity of the element (proxy) that
will
> >route
> >> the
> >> >>call using LoST.  It may be that the UAC itself does this, but it
> >may be
> >> >>some other intermediary.
> >> >>
> >> >>If the identity of the intermediary is not known, then protecting
> >the
> >> >>location information becomes more difficult, because we cannot
> >encrypt
> >> using
> >> >>keying material from the intended recipient.
> >> >
> >> >Just to mention this, it appears to also rule out the idea of
> >encrypting
> >> >with the user's key, since there is no way of knowing whether the
> >> "intended
> >> >recipient" has that key material either.  Intended recipient is
> >actually
> >> >a bit of a problematic term here, since it's really the on-path
> >network
> >> elements
> >> >which consume the information.  They aren't the intended recipient
of
> >> >the communication, they are the recipients of the signaling (of
which
> >> location
> >> >is now a part).
> >> >
> >> >This is a bit confusing because it seems to be possible to include
a
> >> >"re-transmission allowed"  rule with a value of "no" (intended to
be
> >> >consumed by the "intended recipient" of the underlying
> >communication),
> >> >while still wanting to allow the location to be passed along the
> >path.
> >> >
> >> >>In fact, we would need to use
> >> >>hop-by-hop security, with transitive trust.  This is what the
> >emergency
> >> case
> >> >>does, but it also allows no channel security if necessary
(usually
> >> meaning,
> >> >>try it with TLS and if that fails, try again without TLS).
> >> >
> >> >While I certainly encourage hop-by-hop security, I don't think it
> >really
> >> >meets the geopriv privacy concerns.  I think you  have to have
some
> >way
> >> of
> >> >expressing "re-transmission for routing permitted" (and likely
> >retention
> >> >limited), since that is a separate statement.
> >> >
> >> >Just typing aloud here, but could we come up with a way to use an
> >> >external ruleset to express this?  With an embedded cid, that
would
> >> >not actually require dereferencing.
> >> >					Ted
> >> >
> >>
> >>
> >>
> >> >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.
> >>
> >> To reiterate this, I do not believe that this is sufficient; I
think
> >you
> >> have to
> >> have some way of saying "re-transmission for routing permitted"
before
> >> you meet the geopriv privacy concerns.
> >>
> >> >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.
> >>
> >> I believe that an HTTP GET of a PIDF-LO object is a reasonable
> >baseline.
> >> Saying that other mechanisms should update this document with their
> >> dereferencing mechanisms if they could be confused with the
baseline
> >> seems to me to be sufficient.  I'm not sure a registry is needed.
In
> >> practice,
> >> I don't think we would hit the interoperability problems often.
These
> >> days,
> >> extensions to HTTP commonly use different  mime types to indicate
the
> >> special
> >> handling, and I expect anyone creating a more feature-rich
> >dereferencing
> >> mechanism built on HTTP would not end up using pidf-lo.
> >>
> >> That means the "uri confusion" aspects of the discussion are
probably
> >not
> >> that severe.  The only issue is if someone supports only the more
> >feature-
> >> rich
> >> alternative and not a baseline GET of the pidf-lo.  I think we
should
> >> discourage that, by establishing a real baseline.
> >>
> >> Note also that HTTP URIs don't indicate the HTTP Method directly;
> >often
> >> they
> >> support multiple methods (e.g. HEAD and GET).
> >>
> >> >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 share some of Martin's skepticism here, but I won't fall on my
sword
> >> if the WG goes in this direction.
> >>
> >> Thanks for the clear set of issues and opportunity to comment,
> >>
> >>					Ted Hardie

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

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 25 Jul 2006 17:09:14 -0400

A couple notes on the whole "Do not Distribute" flag and its meaning in a SIP context.

Firstly, I think it's obligatory to flex the muscles of location by-reference in response to this. When you send only a reference to location information in an INVITE, that INVITE is not sharing the location information with routing entities, is not a using protocol, and is not "distributing" location information in any sense. Any routing entity that dereferences the URI, and attempts to acquire location information, can be individually authorized by the Location Server, and the protocol over which location information is transmitted to those entities (be it SIP NOTIFYs or whatever) is the using protocol, and is distributing presence information. The entities that receive PIDF-LO through that mechanism are bound not to retransmit it by the "Do not Distribute" flag, but can use it for their personal consumption to make decisions. In short, my contention would be that nothing is broken in this case.

So, what if you're using location by-value? Well, if you can use encryption, then "Do not Distribute" still has some plausible applicability. Of course, encrypting the PIDF-LO object is cumbersome, and you have to be certain to whom you are encrypting it, but I don't think the PIDF-LO can be said to have been "distributed" to anyone that can't even inspect it. They're just relaying a closed envelope to the entity that can open it. That entity would be bound by any "Do not Distribute" flag. Without speaking to the details of the LoST protocol, or making any specific proposal to modify it, I can imagine an approach where the PIDF-LO object could only be decrypted by the LoST server, and even the proxy that sends the query to LoST could not decrypt the object.

And supposing you can't or won't encrypt? Well, in that case I agree that sending location information by-value in an INVITE is ambiguous with regards to the "Do not Distribute" flag. Many, if not most, SIP proxies don't inspect MIME bodies by default, and probably wouldn't even be aware that they are distributing location information - we can't reasonably hold automata responsible for violating the flag in the course of their conventional behavior, anyway. I think back in the day, we roughly concluded that if you need to send location information by-value in cleartext in something like a SIP INVITE, you should set the flag off. There was much talk back at the time that in emergency services cases, you had to sacrifice a certain expectation of privacy that you might want to retain for other location-based services.

I also would like to stress something that I've said a couple of times in the history of this draft - that location conveyance does not exist solely for the purposes of ECRIT's use cases. Don't forget that there are other location-based services that we want to enable in a SIP context, and that even if some approaches wouldn't make sense for ECRIT, that doesn't mean that they shouldn't be specified.

Jon Peterson
NeuStar, Inc.

> Sent: Tuesday, July 25, 2006 11:19 AM
> >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
> 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.
> 
> connected to one of the related threads; here's the text of 
> that message:
> 
> >>NOTE: THIS MESSAGE IS COPIED TO SIP AND ECRIT, IF YOU 
> REPLY, SEND IT ONLY TO
> >>GEOPRIV
> >>However, this opens up the issue of geopriv privacy 
> concerns because the
> >>sender does not know the identity of the element (proxy) 
> that will route the
> >>call using LoST.  It may be that the UAC itself does this, 
> but it may be
> >>some other intermediary.
> >>
> >>If the identity of the intermediary is not known, then 
> protecting the
> >>location information becomes more difficult, because we 
> cannot encrypt using
> >Just to mention this, it appears to also rule out the idea 
> of encrypting
> >with the user's key, since there is no way of knowing 
> whether the "intended
> >recipient" has that key material either.  Intended recipient 
> is actually
> >a bit of a problematic term here, since it's really the 
> on-path network elements
> >which consume the information.  They aren't the intended recipient of
> >the communication, they are the recipients of the signaling 
> (of which location
> >is now a part).
> >
> >This is a bit confusing because it seems to be possible to include a
> >"re-transmission allowed"  rule with a value of "no" (intended to be
> >while still wanting to allow the location to be passed along 
> the path.
> >
> >>hop-by-hop security, with transitive trust.  This is what 
> the emergency case
> (usually meaning,
> >While I certainly encourage hop-by-hop security, I don't 
> think it really
> >meets the geopriv privacy concerns.  I think you  have to 
> have some way of
> >expressing "re-transmission for routing permitted" (and 
> likely retention
> >external ruleset to express this?  With an embedded cid, that would
> >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
> To reiterate this, I do not believe that this is sufficient; 
> I think you have to
> have some way of saying "re-transmission for routing permitted" before
> >multiple ways to dereference a location where HTTP(S) was 
> the transport.
> I believe that an HTTP GET of a PIDF-LO object is a 
> reasonable baseline.
> dereferencing mechanisms if they could be confused with the baseline
> seems to me to be sufficient.  I'm not sure a registry is 
> needed.  In practice,
> I don't think we would hit the interoperability problems 
> often. These days,
> extensions to HTTP commonly use different  mime types to 
> indicate the special
> probably not
> that severe.  The only issue is if someone supports only the 
> more feature-rich
> alternative and not a baseline GET of the pidf-lo.  I think we should
> Note also that HTTP URIs don't indicate the HTTP Method 
> directly; often they
> >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
> >proposal, with the parameter and registry entirely.  There 
> was some list
> >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 share some of Martin's skepticism here, but I won't fall on my sword

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 25 Jul 2006 20:56:48 -0400

Ah, yes, but they can do the same with endpoint assertion of location,
except that the user has more control over it.

Don't object to carriers, or other service providers, making money off
of location based routing.  I just want the user to decide when it is,
and isn't, okay to do that with his location.  Controlling when the
location header is attached to the message is a really hard stop on
not-so-nice folks.  When you let them assert location, then it's harder.

Now, reiterating what I have said several times, I think location
assertion by proxy is a done deal, whether I like it or not, just as I
think location by reference is a done deal.  There is one use case I
like -- emergency call during transition, when the network knows, in
some circumstances, where you are, but the endpoint and/or the access
network is not yet upgraded.  I just hate opening a big loophole for
that one case though.

Brian

> From: Winterbottom, James [mailto:[email-masked]]
> Sent: Tuesday, July 25, 2006 8:46 PM
> To: Brian Rosen; Andrew Newton; Jeroen van Bemmel
> Cc: [email-masked]; Rosen, Brian; Marc Linsner; [email-masked];
Peterson,
> Jon
> Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to location-
> conveyance
> 
> Brian,
> 
> The fact that people can make money out of a solution scarcely seems a
> good reason not to permit it!
> 
> 
> 
> > From: Brian Rosen [mailto:[email-masked]]
> > Sent: Wednesday, 26 July 2006 10:40 AM
> > To: 'Andrew Newton'; 'Jeroen van Bemmel'
> > Cc: [email-masked]; Rosen, Brian; 'Marc Linsner'; [email-masked];
> > Peterson,Jon
> > Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to location-
> > conveyance
> >
> > > Please tell me that you are merely suggesting guidelines and
> > > considerations by operators and are not suggesting 2119 language
for
> > > these?  Because just like you'd never get agreement on the
intended
> > > duration or accuracy or confidence of location-by-value, you'd
never
> > > get agreement on these.
> > I agree here
> >
> > >
> > > > For the latter point: except for emergency scenario's, the UAC
> > > > should include some flag in the INVITE saying "proxy: please
> append
> > > > location". You'd probably also want some feedback (eg proxy or
UAS
> > > > adding a header to the response saying 'this is the URL that I
> > > > appended/got'
> > >
> > > Just thinking out loud here, but maybe the rule should be that
> > > proxies never append a Location header except for emergencies.
> > Works for me.  Probably wouldn't work for those carriers who do not
> intend
> > to support location acquisition by endpoints and do plan to support
> > commercial location based routing.  They plan to make mucho dineros
> > charging
> > for location used for location based routing, and don't want those
> pesky
> > users to get in the way of their plans.  Of course, they can
overcome
> all
> > manner of protocol machinery with "As a condition of providing
> service,
> > user
> > agrees ...."
> >
> > Brian
> >
> >
------------------------------------------------------------------------
--
> ----------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original.  Any unauthorized use of
> this email is prohibited.
>
------------------------------------------------------------------------
--
> ----------------------
> [mf2]

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 26 Jul 2006 09:12:30 -0400

I'm in (on?) Mars today, but the ISP doesn't seem to be responding

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Wednesday, July 26, 2006 9:11 AM
> To: Marc Linsner
> Cc: 'Brian Rosen'; Peterson, Jon; 'Andrew Newton'; Rosen, Brian;
> [email-masked]; [email-masked]
> Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-
> conveyance
> 
> 
> 
> Marc Linsner wrote:
> > In-line...
> >
> >> So, you are arguing against proxy insertion of a
> >> location-by-reference?
> >
> > No, if done properly....but reading the latest threads, I get the
> feeling
> > that www.whereintheworldisbrianrosen.com is an acceptable reference.
> 
> Damn! I was hoping, but www.whereintheworldisbrianrosen.com doesn't
seem
> to be working today. :-(
> 	Paul

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 26 Jul 2006 16:56:12 -0500

At 03:50 PM 7/25/2006 -0400, Rosen, Brian wrote:
>When the original PIDF-LO RFC came out, location-by-reference was
>defined.
>
>You have a URI.  You can exchange the URI for location.  There is a
>protocol defined for that purpose (SIP SUBSCRIBE).  That is location by
>reference.  It also serves as the location update mechanism, clearly
>something we need.

Actually, UPDATE serves as the update mechanism for the UAC detecting it 
has changed locations.  This has been in the ID from day 1, and clarified 
in WG meetings over the years.

How a UAC determines/d it has moved obviously not defined in the IETF.

SUBSCRIBE was thought of a a good pull retreaval protocol action for 
updating the location of a target.

---

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Thu, 27 Jul 2006 15:13:40 +0200

(as individual)

I am not sure I understand your argument here.

As far as I understand, and in addition to any other constraints, any
protocol used as a result of the reference to carrt location must be a
location using protocol in and pass the IETF (as policed by GEOPRIV)
privacy provisions on location.

In the absence of any other normative document by GEOPRIV that
normatively lists those protocols, the dereferencing protocol
specification (currently specified in sip-location-conveyance) must
normatively indicate that list. Whether it does it by ABNF or text is
academic - they are both normative specifications, and they both need an
RFC to update them. 

I believe we do have a requirement that the dereferencing protocol
entity MUST NOT use a protocol that is not a location using protocol.

Regards

Keith

> Sent: 27 July 2006 00:31
> To: Abbott, Nadine B; Brian Rosen; [email-masked]
> Cc: [email-masked]
> I don't care if you don't mention how to de-reference URI 
> types other than sip/sips/cid/pres in the document or not. 
> But I do not want the schema artificially constrained to 
> exclude URI types such as HTTP. There is clearly not 
> consensus to justify this exclusion, so please leave schema 
> unchanged and make your recommendations in the text.
> 
> Cheers
> James
> 
>  
> 
> From: Abbott, Nadine B [mailto:[email-masked]]
> Sent: Thursday, 27 July 2006 7:44 AM
> To: Brian Rosen; [email-masked]
> Cc: [email-masked]
> Actually, I was thinking that in other industry work which is 
> trying to leverage and provide transitional strategies to 
> migrate to using SIP to support emergency services, the and 
> long-term solutions that we have defined assume a capabity to 
> provide location-by-reference.  I think it would be very 
> useful to have this defined in a standard SIP header 
> mechanism in such a way that we need not redefine migratory 
> solutions that have begun to be implemented. If an HTTPS URI 
> can be used as the location-by-reference, this will be 
> helpful, I think.  
> 
> I don't understand your urgency to make location-by-reference 
> only an all-sip-all-the-time thing.
> And from all the other emails on this topic, it didn't seem 
> to me that there is a consensus to do this.
> 
> Nadine 
> 
> Sent: Wednesday, July 26, 2006 3:15 PM
> To: Abbott, Nadine B; [email-masked]
> Cc: [email-masked]
> Nadine
> Are you saying that it's your opinion sip-location-conveyance 
> MUST define an HTTP dereference procedure?
> 
> If you do, why?  What is the use-case or requirement?
> 
> Would it not be pretty reasonable to require a separate 
> document that defines a location-by-reference mechanism, 
> protocol, and geopriv "using protocol" analysis?  If that 
> document specifically extended what was allowed in the 
> location header, would that not be reasonable?
> 
> I think we have to include "A" dereference mechanism in the 
> location-conveyance document.  It seems just including 
> sip/sips/prez is a reasonable, all-sip-all-the-time approach 
> IN THIS DOCUMENT.  That certainly does not preclude another 
> document describing another way.
> 
> Doesn't it seem just a little weird to have a 
> sip-location-conveyance document describing any kind of http 
> based location conveyance
> (de-reference) protocol, especially one created whole cloth 
> without any other parts?
> 
> Doesn't it seem in keeping with the geopriv approach that in 
> order to have another "using protocol" it has to have a 
> geopriv review?  That is what leads to restricting the URI 
> schemes.  Would you prefer to let it be wide open, so any 
> protocol anyone thinks about can be used with the location 
> header?  I can't see geopriv going along with that.  We're 
> going to make it a one line ABNF to add a new scheme to the 
> list of allowed schemes.
> 
> It seems to me that if it's desired to define some bare-bones 
> HTTP location by reference protocol, then that should be a 
> separate document, which can easily extend the allowable 
> schemes in the Location header.
> I'm not sure it might be better to define ALL of that in the 
> L7 protocol, but I wouldn't be opposed to a simple "raw GET" 
> RFC as long as it got a full geopriv review.
> I just don't see where it makes any sense to force that into 
> a sip document.
> 
> Brian
> 
> > From: Abbott, Nadine B [mailto:[email-masked]]
> > Sent: Wednesday, July 26, 2006 2:14 PM
> > To: [email-masked]
> > Cc: [email-masked]
> > 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
> > 
> > From: Rosen, Brian [mailto:[email-masked]]
> > Sent: Tuesday, July 25, 2006 1:38 PM
> > To: [email-masked]
> > Cc: [email-masked]
> > 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.
> > 
> > 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"
> > 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.
> > 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.
> > 
> > proposal, with the parameter and registry entirely.  There was some 
> > list traffic in favor of this.  Martin Thompson is 
> skeptical that SIP 
> not have 
> > If this does not reflect your position, please speak up now.
> > 
> > Brian
> > 
> --------------------------------------------------------------
> ----------------------------------
> --------------------------------------------------------------
> ----------------------------------
> [mf2]
>

---

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Thu, 27 Jul 2006 16:22:32 +0200

(as SIP WG chair)
(Warning - degree of rant is directly proportional to the value of the
item number, I decided that 6 through 10 were not publishable)

1)	I think we do have a significant amount of discussion and
agreement already that does need to be reflected in a revised draft. You
promised that revised draft in early August, and whatever the state of
the open issues, you should still provide that revised draft, and merely
indicate in the text that open issues exist in particular areas if they
do not get resolved before you hit the send button. We are certainly
getting repeats of comments that relate to stuff that will already be
addressed in the revised version.

2)	This document is making SIP a "using protocol" for location. Any
normative requirements in this document must be consistent with GEOPRIV
documentation in RFC 3693, RFC 3694, RFC 4079 and RFC 4119. Therefore if
comments are being made that are inconsistent with any of these
documents, then the commentors should in the first instance be
addressing their comments to GEOPRIV in terms of corrections to these
RFCs. I don't want a SIP document held hostage because someone either
refused to read a GEOPRIV document before it was approved, or at the
very least failed to understand what was written at that time. If it is
a question of interpretation of the GEOPRIV documents, then I guess
there is room for some discussion, but at least Jon Peterson, who played
a key role in this work in GEOPRIV, has indicated that the presence work
is a GEOPRIV using protocol. On that basis, I would allow him to hum
directly into the microphone if a hum was in progress on this one.

3)	Using protocols are sanctioned by GEOPRIV. If GEOPRIV has not
made a decision, then it does not exist as a using protocol!

4)	We are past the design stage on this document. The document has
had its current technical content for 12 months. In my view that raises
the bar somewhat. If something new is required in this document, then we
are not in the process of just adding it as yet another variant - if
only because that hits interoperability. I want to see clear statements
about why the current stuff does not work, and what is improved by the
new addition. In many cases, I am failing to see reasoned arguments
based on the GEOPRIV documents, or other IETF work, as to why something
is right or wrong - I do not want to see proposals based on general
feelings, or, "that is what I want to implement therefore it has got to
be included". 

5)	We still have to make decisions by concensus. We need consensus
to take something out, we need consensus to put something in. While the
editors do need to represent that consensus, they are also entitled to
their views on the discussion as individuals. At the end of the day, if
we fail to reach consensus about the document, then we kill either the
charter item, or the SIP WG itself.

Regards

Keith

> Sent: 27 July 2006 04:08
> To: 'Andrew Newton'; 'Winterbottom, James'
> Cc: [email-masked]; [email-masked]; 'Henning Schulzrinne'; 
> 'Abbott, Nadine B'
> Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to 
> location-conveyance
> 
> At this point, I think we need some chair guidance and by 
> that I think it's a combo of geopriv and sip chairs.
> 
> We seem to have a couple of significant open questions.  I 
> think most of the other stuff (like the "allow sending to 
> router") will converge.
> 
> There seems to be some opposition to allowing sip/sips/pres: 
> in a Location Header.  The opposition seems to be that 
> despite 4119, somehow, SIP (presence subscription) is not a 
> "using protocol".  I "think" a ruling from the bench on that 
> would work.
> 
> There is also opposition to defining the allowed schemes as a 
> specific list, with a defined (easy) extension mechanism.  
> 
> Related to that, there are some who want location-conveyance 
> to define an HTTP based location dereference mechanism, and 
> on the opposite end, we have people saying we haven't even 
> agreed to support any form of location-by-reference.  
> 
> The authors would like to know what to do now.
> 
> Brian
> 
> > From: Andrew Newton [mailto:[email-masked]]
> > Sent: Wednesday, July 26, 2006 9:58 PM
> > To: Winterbottom, James
> > Cc: [email-masked]; [email-masked]; Abbott, Nadine B; Henning 
> > Schulzrinne
> > On Jul 26, 2006, at 9:43 PM, Winterbottom, James wrote:
> > 
> > > Andy,
> > >
> > > RFC-4119 says "However, the usage of this location object 
> format is 
> > > not
> > >    limited to presence-using protocols-- any protocol 
> that can carry 
> > > XML
> > >    or MIME types can carry PIDF."
> > >
> > > It seems to me that restricting the allowed schema in what is 
> > > supposed to be a location conveyance specification is in 
> opposition 
> > > to this statement.
> > 
> > Did somebody say that HTTP was a presence-using protocol?
> > 
> > -andy
> > 
> > ps.  you can find my location with the following reference URIs:
> > 
> > gopher://fatchance.hxr.us/you-still-have-a-gopher-client
> > news:alt.locations.people.secretly-being-watched
> > telnet://screen-scrapers.are.us/
> > dns:cached-publicly-around-the-world.com?type=HOST
> > 
> > 
> >

---

From: "Stark, Barbara" <[email-masked]>
Date: Thu, 27 Jul 2006 15:02:00 -0500

This gets my vote.
Barbara

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Wednesday, July 26, 2006 11:25 PM
> To: Brian Rosen
> Cc: IETF SIP List; [email-masked]
> Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to
> location-conveyance
> 
> 
> My suggestion would be
> 
> - to focus the draft on just defining the Location header syntax,  
> without ruling out any particular mechanism or scheme; this would  
> make the draft really short (which I would find helpful).
> 
> - and then add one section to the draft that prototypically defines  
> what a particular scheme that wants to appear in the Location header  
> needs to define, using the non-controversial cid mechanism as the  
> example. Other, separate, drafts can then define other modes,  
> following the same template. Documents such as the phone-bcp 
> can then  
> pick some suitable must-implement subset and make emergency-call- 
> specific recommendations, rather than sprinkling these 
> throughout the  
> conveyance document and repeating some in the phone-bcp. Most of  
> these are, in any event, operational recommendations, not for  
> ensuring protocol-level interoperability.
> 
> That way, the conveyance draft can be extremely short (even shorter  
> if the requirements are omitted...) and can get done, and we avoid  
> engineering operational requirements on the fly, commingling  
> emergency and non-emergency cases, as seems to be happening now.
> 
> I think protocol documents should define what's needed for  
> interoperability; BCPs can make more specific, situation-specific  
> recommendations. Commingling the two seems to be a recipe for  
> deadlock or arbitrary, non-technically-grounded decisions that are  
> more lawyer-like than engineering-like ("you did not mention  
> technique X in some meeting N years ago and thus you can't bring it  
> up now!")
> 
> Henning
> 
> On Jul 26, 2006, at 11:08 PM, Brian Rosen wrote:
> 
> > At this point, I think we need some chair guidance and by that I  
> > think it's
> > a combo of geopriv and sip chairs.
> >
> > We seem to have a couple of significant open questions.  I think  
> > most of the
> > other stuff (like the "allow sending to router") will converge.
> >
> > There seems to be some opposition to allowing sip/sips/pres: in a  
> > Location
> > Header.  The opposition seems to be that despite 4119, somehow, SIP
> > (presence subscription) is not a "using protocol".  I "think" a  
> > ruling from
> > the bench on that would work.
> >
> > specific list,
> > with a defined (easy) extension mechanism.
> >
> > Related to that, there are some who want location-conveyance to  
> > define an
> > HTTP based location dereference mechanism, and on the 
> opposite end,  
> > we have
> > people saying we haven't even agreed to support any form of
> > location-by-reference.
> >
> >>>    limited to presence-using protocols-- any protocol that can
> >>> carry XML
> >>> supposed
> >>> to be a location conveyance specification is in opposition to this
> >>> statement.
> >>

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 162