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

From: "Abbott, Nadine B" <[email-masked]>
Date: Wed, 26 Jul 2006 14:14:00 -0400

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

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-masked]
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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 26 Jul 2006 15:14:52 -0400

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]
> Subject: RE: [Geopriv] Consensus on changes to location-conveyance
> 
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 26 Jul 2006 20:33:16 -0400

On a general note and generalizing a bit on Nadine's message below, I  
find the nanny tone of this discussion a bit peculiar ("No, I don't  
want you to play with that!"). I can see the technical rationale for  
requiring implementation of a limited set of choices for  
interoperability, but proactively ruling out other choices seems  
highly unusual for an IETF protocol spec. It is clear that only a  
relatively small number of people are participating in this  
discussion, so declaring consensus to rule out one URL scheme or  
another as 'evil bits' seems a bit peculiar.

---

From: Andrew Newton <[email-masked]>
Date: Wed, 26 Jul 2006 21:36:16 -0400

I don't think Brian ever proposed ruling out URI schemes.  What he  
proposed was restricting what can go in it now and a mechanism for  
defining future URI schemes that will be allowed.  We certainly do  
want using protocols passing around PIDF-LOs getting review by GEOPRIV.

-andy

On Jul 26, 2006, at 8:33 PM, Henning Schulzrinne wrote:

> On a general note and generalizing a bit on Nadine's message below,  
> I find the nanny tone of this discussion a bit peculiar ("No, I  
> don't want you to play with that!"). I can see the technical  
> rationale for requiring implementation of a limited set of choices  
> for interoperability, but proactively ruling out other choices  
> seems highly unusual for an IETF protocol spec. It is clear that  
> only a relatively small number of people are participating in this

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 26 Jul 2006 20:43:23 -0500

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.

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]] 
Sent: Thursday, 27 July 2006 11:36 AM
To: Henning Schulzrinne
Cc: [email-masked]; [email-masked]; Abbott, Nadine B
Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to
location-conveyance

-andy

------------------------------------------------------------------------------------------------
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: Andrew Newton <[email-masked]>
Date: Wed, 26 Jul 2006 21:58:10 -0400

> to be a location conveyance specification is in opposition to this

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: "Brian Rosen" <[email-masked]>
Date: Wed, 26 Jul 2006 23:08:11 -0400

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

> Sent: Wednesday, July 26, 2006 9:58 PM
> To: Winterbottom, James
> Cc: [email-masked]; [email-masked]; Abbott, Nadine B; Henning Schulzrinne
> Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-
> conveyance
> 
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 26 Jul 2006 23:25:15 -0400

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

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 26 Jul 2006 22:25:17 -0500

Let's clarify this further Brian.

I do not want the schema to put a constraint on the URI type.
This is not the same as saying that I expect the document to describe
how to dereference all URI types.

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, 27 July 2006 1:08 PM
To: 'Andrew Newton'; Winterbottom, James
Cc: [email-masked]; [email-masked]; 'Abbott, Nadine B'; 'Henning
Schulzrinne'
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.  

Brian

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 26 Jul 2006 22:34:00 -0500

>another as 'evil bits' seems a bit peculiar.

A few folks have pointed out unique issues with HTTP and HTTPS wrt privacy 
issues. If those are true, do they need to be addressed in this document to 
satisfy Geopriv?  If yes, should a SIP doc discuss the uniqueness of HTTP's 
security stuff?  Or should that discussion be in an HTTP document?  Brian 
is suggesting that be in a HTTP focused document (likely in Geopriv), with 
the fairly unique ability to extend this document without going through the 
SIP Change process (and that's a bonus).

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 26 Jul 2006 22:43:20 -0500

Sounds like a very pragmatic approach Henning - I agree.

Cheers,
Martin

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Thursday, 27 July 2006 1:25 PM
> To: Brian Rosen
> Cc: IETF SIP List; [email-masked]
> >>> RFC-4119 says "However, the usage of this location object format
is
> >>> not

---

From: Andrew Newton <[email-masked]>
Date: Wed, 26 Jul 2006 23:55:08 -0400

> The authors would like to know what to do now.

Let's start by trying to tease apart certain positions.

Given Jon Peterson's message:
http://www1.ietf.org/mail-archive/web/sip/current/msg15537.html

Does anybody still believe that subscriptions to PIDF-LOs with pres:  
requires more definition?

-andy

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 27 Jul 2006 00:00:29 -0500

Since I raised the question, I'll answer.

We have a set of requirements on a using protocol in RFC 3693.

I believe that HTTP with proper constraints (TLS, etc...) can meet, or already meets, those requirements.  That is irrespective of any decisions that need to be made about secondary concerns like whether HTTP is desirable, optimal, deployable etc...  However, it is clear that people aren't happy with this position and are requesting that this be documented, as an RFC.  Just to get it all out in the open.  Presumably this would be a standards track RFC that, like location-conveyance, highlights how the RFC 3693 requirements are addressed.

That's a sound argument, and obviously location-conveyance had to meet that standard for us to be happy.  Now, I ask that you go back, take the above paragraph and perform one simple operation and read it again: s/HTTP/SIP/g.  Is the argument any different in the presence of RFC 4079?  Is an informational RFC that doesn't address specific requirements adequate?  I'd suggest that it wouldn't make the grade for HTTP.

> Sent: Thursday, 27 July 2006 1:55 PM
> To: IETF SIP List; GEOPRIV
> Subject: Teasing apart positions (was Re: [Sip] RE: [Geopriv] Consensus
> onchanges to location-conveyance)
> 
>

---

From: Andrew Newton <[email-masked]>
Date: Thu, 27 Jul 2006 08:36:27 -0400

Martin, you did not answer my question.  You are right that HTTP as a  
using protocol is a separate question, one which I will ask about.

-andy

On Jul 27, 2006, at 1:00 AM, Thomson, Martin wrote:

> I believe that HTTP with proper constraints (TLS, etc...) can meet,  
> or already meets, those requirements.  That is irrespective of any  
> decisions that need to be made about secondary concerns like  
> whether HTTP is desirable, optimal, deployable etc...  However, it  
> is clear that people aren't happy with this position and are  
> requesting that this be documented, as an RFC.  Just to get it all  
> out in the open.  Presumably this would be a standards track RFC  
> that, like location-conveyance, highlights how the RFC 3693  
> requirements are addressed.
>
> That's a sound argument, and obviously location-conveyance had to  
> meet that standard for us to be happy.  Now, I ask that you go  
> back, take the above paragraph and perform one simple operation and  
> read it again: s/HTTP/SIP/g.  Is the argument any different in the  
> presence of RFC 4079?  Is an informational RFC that doesn't address  
> specific requirements adequate?  I'd suggest that it wouldn't make  
> the grade for HTTP.
>

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 27 Jul 2006 08:38:39 -0400

Works for me...

-Marc- 

> Sent: Wednesday, July 26, 2006 11:25 PM
> To: Brian Rosen
> - 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.
> 
> 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
> 
> > 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.
> >
> > 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.
> >
> > list, with a defined (easy) extension mechanism.
> >
> > 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.
> >
> >>> RFC-4119 says "However, the usage of this location object 
> format is 
> >>> not
> >>>    limited to presence-using protocols-- any protocol 
> that can carry 
> >>> XML
> >>> 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.
> >>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 27 Jul 2006 16:33:33 +0200

Hi Brian,

are you talking about the end host adding a location-by-reference into 
the SIP header or a proxy doing so?

In any case I don't understand your objection against the usage of HTTP 
and your preference for SIP/SIPS/PREZ?

Ciao
Hannes

Brian Rosen wrote:
> Nadine
> 
> Are you saying that it's your opinion sip-location-conveyance MUST
> define an HTTP dereference procedure?
> 
>  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?
> 
> 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.
> 
> (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
> 
> 
>> -----Original Message----- From: Abbott, Nadine B
>> [mailto:[email-masked]] Sent: Wednesday, July 26, 2006 2:14
>> PM To: [email-masked] Cc: [email-masked] Subject: 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-masked]] Sent: Tuesday, July 25, 2006 1:38
>> PM To: [email-masked] Cc: [email-masked] Subject: [Geopriv]
>> Consensus on changes to location-conveyance
>> 
>> 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.
>> 
>> 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.
>> 
>> 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.
>> 
>> _______________________________________________ Geopriv mailing
>> list [email-masked] 
>> _______________________________________________ Geopriv mailing
>> list [email-masked] 
> _______________________________________________ Sip mailing list
> https://www1.ietf.org/mailman/listinfo/sip This list is for NEW
> development of the core SIP Protocol Use
> [email-masked] for questions on current sip Use
> [email-masked] for new developments on the application of sip
> 
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 27 Jul 2006 16:34:39 +0200

Hi Henning,

I like your suggestion.

In fact I would even go a step further. The SIP Location Conveyance 
document just defines a mechanism to carry a PIDF-LO in the body of the 
SIP message. Done.
Adding location-by-reference to the SIP header by the end host sounds OK 
but there are still some loose ends where this reference comes from.

The other stuff can be dealt with once we concluded our Geopriv-L7 work 
where all the architectural pieces should are created. The 
subscription-URI is an example where we recently proposed something and 
haven't finished our technical discussions.

I think the draft got fuzzy when it came to the area where a SIP proxy 
adds a location-by-reference. I must admit that I proposed to add 
location-by-value into the SIP header as well but in the meanwhile I 
don't think that any of the SIP proxy stories belong in there.

Ciao
Hannes

>>>>>supposed

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 27 Jul 2006 12:17:30 -0400

Either.

I object to HTTP because there is no RFC I can reference that describes an
HTTP based geopriv using protocol.  I prefer SIP/SIPS/PRES because I can.

I don't think sip-location-conveyance should define an HTTP based geopriv
using protocol.

I don't object to a separate document that defines one.  I expect to see the
L7 protocol do that, for example.

Brian

> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Thursday, July 27, 2006 10:34 AM
> To: Brian Rosen
> Cc: 'Abbott, Nadine B'; [email-masked]; [email-masked]

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 27 Jul 2006 13:32:23 -0500

At 04:33 PM 7/27/2006 +0200, Hannes Tschofenig wrote:
>Hi Brian,
>
>are you talking about the end host adding a location-by-reference into the 
>SIP header or a proxy doing so?
>

Hannes - I think Brian has a problem with a SIP doc defining how HTTP 
works.  He has stated an HTTP doc should do this.  We think this HTTP doc 
should be very, very short.  This SIP doc is allowing an extension to the 
URI schemes without going though the SIP WG as a SIP WG item (which is 
normally required - and takes a lot of time, because it must first start in 
SIPPING).

>>>allow sending of the location to the routing-by-location database, but 
>>>would obligate the proxy that did that to remove the location
>>>list [email-masked] https://www1.ietf.org/mailman/listinfo/geopriv
>>>list [email-masked] https://www1.ietf.org/mailman/listinfo/geopriv
>>