Amen. FM
On Sat, 2007-04-28 at 11:19 +0200, Jeroen van Bemmel wrote: > 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 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
