On Apr 29, 2007, at 10:48 AM, Frank W. Miller wrote:
On Sun, 2007-04-29 at 09:58 -0400, Henning Schulzrinne wrote:
For the record, I will note that I have made proposals for simple
non-
multipart location conveyance (using the data: URL), but various
process-related arguments were made as to why we weren't allowed to
look at that. (I'd prefer even simpler solutions, such as the one
that XMPP uses, but that's beyond the political correctness limit in
GEOPRIV.)
Would it be possible to see these extensions? Keith asked for
alternative proposals, it seems like looking at that might be a good
idea now.
The data URL proposal is simple and is (nominally) allowed within the
SIP location conveyance document:
GeoLocation: data:application/xml+something,<base64 encoding of PIDF-LO>
(data URLs are defined in RFC 2397). This avoids the use of
multipart, references and the difficulty of having proxies grope
around in SIP multipart message bodies for routing-related information.
A more radical proposal is something along the lines of
Geolocation: 48.200927 16.369548 500 200
(longitude, latitude, altitude, 90% percentile accuracy of 200
meters). Unfortunately, this doesn't generalize as easily to civic
locations and to more complicated shapes.
My question is more focused on the essence of the Jeron's off-the-cuff
proposal. Does the location information belong in the body or in the
main SIP headers? I believe its the latter primarily for the argument
that was put forth, i.e. the information is so important it deserves
first-class treatment in the message headers. The fact that its
simplified comes primarily from the fact that you need to be more
compact in your representation if your in the headers.
I don't think it's a matter merely of importance, more of function.
Location is used for routing messages (as well as for the benefit of
the end system), which is a header function in SIP. Bodies are meant
for user agents.
FM
_______________________________________________
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
