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. > I tend to agree that exhortations to developers generally achieve > little. On the other hand, I'm not sure that belly-aching about > multipart is all that helpful. After all, most email clients support > it and there are libraries in various languages to help with > implementation. Generating multipart bodies is pretty trivial (as > opposed to parsing them), and that's all embedded devices will > generally have to do for location conveyance. > As I said, I and others will implement whatever we're directed to. Personally, I've got Expat in there now for PIDF and even parsing MP MIME isn't really that hard. 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. Dropping the return address list to [email protected] only to minimize messages in my inbox... 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
