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

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:
> 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
> 
> 
>>-----Original Message-----
>>From: Winterbottom, James [mailto:[email protected]]
>>Sent: Wednesday, July 19, 2006 7:26 PM
>>To: Rosen, Brian; [email protected]
>>Cc: [email protected]
>>Subject: [Sip] RE: [Geopriv] More on the contents of the Location header
>>URI- http
>>
>>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 protected]]
>>>Sent: Thursday, 20 July 2006 7:33 AM
>>>To: [email protected]
>>>Cc: [email protected]
>>>Subject: [Geopriv] More on the contents of the Location header URI -
>>
>>http
>>
>>>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 protected]
>>>https://www1.ietf.org/mailman/listinfo/geopriv
>>
>>--------------------------------------------------------------------------
>>----------------------
>>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]
>>
>>_______________________________________________
>>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
> 
> 
> 
> _______________________________________________
> 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
> 
> 


_______________________________________________
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