Subject: [Geopriv] More on the contents of the Location header URI - http

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 19 Jul 2006 17:33:08 -0400

I started a discussion of what can be in the location header besides a
cid:.
We remain convinced that AbsoluteURI is a poor choice; we must be more
specific, including privacy concerns. 

It is now clear that simply saying "https:" is not enough.  There could
be multiple location resolution protocols that use http transport.  We
need something else that would differentiate which one.  The simple GET
mechanism we proposed would need at least a parameter of some sort.  

After thinking about it for a while, I think the best resolution is
Andy's suggestion of a registry, used in conjunction with a parameter.
I'm ambivalent on whether the parameter is a URI parameter or a
parameter on the Location header.  We would define the registry (and the
parameter) in location-conveyance and create one entry (the simple GET
with PIDF-LO return).  It may be, for example, that the proposed L7
location acquisition protocol defines another http based resolution
protocol.  That document could define another entry in the registry.

Brian

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

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 19 Jul 2006 18:26:27 -0500

Brian,

I am not sure that I agree with you on this one.
The problem is not in the request protocol at all, the GET works fine
providing the return type is always a PIDF-LO.

Cheers
James

> -----Original Message-----
> From: Rosen, Brian [mailto:[email-masked]]
> Sent: Thursday, 20 July 2006 7:33 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Geopriv] More on the contents of the Location header URI -
http
> protocol.  That document could define another entry in the registry.

------------------------------------------------------------------------------------------------
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: "Brian Rosen" <[email-masked]>
Date: Wed, 19 Jul 2006 19:51:58 -0400

The problem is that HTTP is used as a transport protocol by several
mechanisms, and you need to know from the contents of the location header
which mechanism is used.  Is it SOAP, raw GET, LCP, RELO, HELD or something
else, all of which would say "https:blahblah"?

Brian

> From: Winterbottom, James [mailto:[email-masked]]
> Sent: Wednesday, July 19, 2006 7:26 PM
> To: Rosen, Brian; [email-masked]
> Cc: [email-masked]
> Subject: [Sip] RE: [Geopriv] More on the contents of the Location header
> URI- http
> 
> Brian,
> 
> 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: "Winterbottom, James" <[email-masked]>
Date: Wed, 19 Jul 2006 19:00:14 -0500

Providing all mechanisms support a base GET AND they return a PIDF-LO
there is no problem. That is all that needs to be said.

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Thursday, 20 July 2006 9:52 AM
> To: Winterbottom, James; Rosen, Brian; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Sip] RE: [Geopriv] More on the contents of the Location
> header URI- http
> 
> > > need something else that would differentiate which one.  The
simple
> > GET
> > > parameter on the Location header.  We would define the registry
(and
> > the
------------------------------------------------------------------------
> --
> > ----------------------
------------------------------------------------------------------------
> --
> > ----------------------

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 20 Jul 2006 11:54:00 +0200

That's fine and there are ways to address this issue. A registry would 
be fine for me with a single mandatory to implement mechanism.

Ciao
Hannes

Brian Rosen wrote:
>>>It is now clear that simply saying "https:" is not enough.  There
>>
>>could
>>
>>>need something else that would differentiate which one.  The simple
>>
>>GET
>>
>>>parameter on the Location header.  We would define the registry (and
>>
>>the
>>