Re: [Sip] geoloc implementation (Was: SIPit 20 survey summary)

[Paul Kyzivat <[e-mail]>]

I ignored my mail over the weekend and a lot of water has flowed over 
the dam.

I agree with Dale on this - what is the big deal here?

It was a *huge* mistake not to require multipart support in 3261. Since 
then what has  been lacking is a strong motivator for implementors to 
support it. If this provides the motivation, then hurrah!

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.

	Paul

[e-mail] wrote:
> Is this really as much of a problem as people are making out?
> 
> OK, it's *possible* that redesigning the geolocation specification
> would be a good thing.  But given the amount of work that has already
> been done on it, and the complexity of the requirements, it would take
> me a month of work straight to verify that I truly had a Better Idea.
> So I am not about to suggest that.
> 
> 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.)
> 
> The difficulty in practice is "How does the UA get its geloc data?"
> (Or how does an intermediate agent get the data for the UA?)  This
> does not become simpler if we change the format of geoloc data.
> 
> I expect that the major barrier to implementing geoloc support has
> been the instability of the geoloc specification, combined with the
> fact that SIP is not yet entering the mainstream where emergency
> services support is required by regulation.
> 
> Dale
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [e-mail] for questions on current sip
> Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip