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 [email protected] for questions on current sip > Use [EMAIL PROTECTED] for new developments on the application of sip _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
