Re: [Sip] SIPit 20 survey summary

A point for discussion: I believe below is evidence that the complexity of 
implementation may hinder deployment of emergency services, and may even be 
a root cause of things breaking down at a critical moment. People's lives 
may depend on a proxy interpreting location information properly

Especially for the use case of emergency calls, would it not be wise to 
select a much more simple approach/syntax, e.g.:
Emergency-Location: lat=x; lon=y

So no XML, no mime/multipart, as simple as possible (no complex semantics, 
usage-rules etc), something to reduce the barrier of 
implementation/deployment, and to reduce the risk for interop issues?

Regards,
Jeroen

Brian Rosen wrote:
> I'd like to point out one thing about this:
>
>> This is how they answered for multipart/mime:
>>     2% I break if someone sends me multipart/mime
>>    24% I pretend multipart/mime doesn't exist if someone sends it to
>>    me 24% I ignore multipart/mime but will proxy it or hand it to my
>> application if it shows up
>>    10% I try to do something useful with multipart/mime I receive,
>> but I never send it
>>     4% I ignore multipart/mime that I receive, but I try to do
>> something useful with multipart/mime I send
>>    24% I try to do something useful with multipart/mime I send and
>> receive
>>    12% Other
>
> Moving forward, SIP UAs and proxies will be required to support
> location-conveyance (currently draft-ietf-sip-location-conveyance-07)
> in order to support location for emergency calls (citizen to
> authority, like 1-1-2 or
> 9-1-1).  -conveyance requires multipart support.
>
> The consequences of not supporting emergency call location will be
> serious. I believe it is likely that there will eventually be
> regulatory requirements to support emergency calls in some
> jurisdictions.  Upgrades to several components of today's
> infrastructure will be needed before this all works, but stack
> vendors and UA developers should put multipart (and
> location-conveyance) on their development plans for next year at the
> latest.
>
> Brian
>
>
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip