Paul Kyzivat writes: > Regarding those suggesting adopting the xmpp solution: how do you > propose to incorporate it into a sip message? The most obvious answer is > to incorporate it as a body part - still requiring multipart. XMPP has > the advantage that already supports the moral equivalent of > multipart.
multipart is not a big deal to me, but 2027 lines of specification to read and implement is. [EMAIL PROTECTED] writes: > In regard to the complexity of the solution, a UA that provides geoloc > data (once it had some) would seem to have a fairly simple task, > formatting the data into a preselected body. Even multipart-MIME XML > is simple if one knows in advance the skeleton. > > The PSAPs, of course, are stuck parsing and interpreting all possible > formats. That's a hard job, but on the other hand, PSAPs are built by > a small number of vendors who will be highly motivated to do a good > job. (And PSAPs are willing to pay for this.) you try to say that only PSAPs need to deal with complexity. that is a big lie. there has already been message on this list saying that also provider and enterprise SIP proxies need to examine and add stuff to the location data. to SIP WG management: you should not disallow discussion on the madness of the resulted internet draft as whole. even if GW accepted a charter item, the end result of the work CAN BE that the requirements led to a too complex solution that is not implementable in sip proxies in any reasonable amount of work and that the project needs to be re-charted. -- juha _______________________________________________ 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
