RE: [Geopriv] More on the contents of the Location header URI - http
"Winterbottom, James" <[email protected]>
| Newsgroups | gmane.ietf.sip,gmane.ietf.geopriv |
|---|---|
| Message-ID | <[email protected]> |
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