Re: SIMPLE and Emergency Services
"Olle E. Johansson" <[email protected]> Thu, 1 Nov 2012 16:38:13 +0100
| Newsgroups | gmane.ietf.simple |
|---|---|
| Message-ID | <[email protected]> |
--===============1682067055201252007== Content-Type: multipart/alternative; boundary="Apple-Mail=_C96FB200-A0DC-4D28-8BB1-1442C01E3EC4" --Apple-Mail=_C96FB200-A0DC-4D28-8BB1-1442C01E3EC4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 31 okt 2012 kl. 23:08 skrev Bernard Aboba <[email protected]>: > In response to Olle's question about whether SIMPLE is an abject and = irredeemable failure, I would note that SIMPLE is still under = consideration for use in emergency services, if only because XMPP isn't = yet a viable alternative. For example, both NENA i3 and ECRIT PhoneBCP = mention SIMPLE, but refer to XMPP support of emergency services as = future work. In emergency scenarios, presence and address books are = typically not considered since the PSAP is neither a presentity nor a = watcher. Instead, SIMPLE is used as a way of conveying information = between the caller and PSAP, including location, a message body and = additional data.=20 >=20 > With SMS to 911 under active discussion with regulatory bodies, the = question about whether we can rely on SIMPLE for emergency use has = become a "hot issue". As an example, there has been a suggestion that = MESSAGE could be used to support conveyance of SMS text messages to a = "text gateway" that would then pass them on to the PSAP (possibly in a = different form, such as translating to TTY/TDD). Not only might this = help standardize the transport of SMS messages to 911, but it would also = support future uses of MESSAGE for next generation emergency services.=20= >=20 > While documents like NENAi3 and ECRIT PhoneBCP still point to SIMPLE = specs, some folks have pointed to the lack of support for MESSAGE in SIP = trunking services as an indication that even basic uses of SIMPLE are = unlikely to see much deployment, and that alternatives for disabled = access to emergency services (such as RFC 4103 realtime text) should be = given priority.=20 >=20 > IMHO, unless XMPP for emergency uses is specified by IETF in the near = future, it is likely that SIMPLE will find its way into emergency = services architectures in some form. Since the IETF is still = recommending SIMPLE in documents such as ECRIT PhoneBCP, IMHO the IETF = has a responsibility to public safety to address interop issues that = will arise in next generation emergency services scenarios. AFAIK, = SIMPLE interop issues haven't killed anyone yet. Hopefully this will = remain true in the future. =20 Thank you for your response, Bernard. Yes, if the emergency services don't want to sign a contract with a = single vendor of both servers and clients, but wants to have a choice - = we need to fix interoperability. I do understand that many of the issues = we've discussed here doesn't apply - like XCAP documents and buddy = lists, so it MAY be easier, to use RFC language :-) Realtime Text with RFC 4103/T.140 is implemented in many places today = (and supported by Asterisk :-) ) so that's something that should not be ignored, regardless of plans to = support IM/Chat. /O >=20 > Olle E. Johansson said:=20 > "Any other thoughts in regards to SIMPLE? >=20 > Is it a failure or not? >=20 > Do we have a chance of fixing this within the IETF? >=20 > Is anyone interested in fixing it so we actually reach the WG goal of = interoperability?" >=20 >=20 > _______________________________________________ > Simple mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/simple --Apple-Mail=_C96FB200-A0DC-4D28-8BB1-1442C01E3EC4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Diso-8859-1"><base href=3D"x-msg://286/"></head><body = style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = -webkit-line-break: after-white-space; "><br><div><div>31 okt 2012 kl. = 23:08 skrev Bernard Aboba <<a = href=3D"mailto:[email protected]">[email protected]</a>>= ;:</div><br class=3D"Apple-interchange-newline"><blockquote = type=3D"cite"><div class=3D"hmmessage" style=3D"font-size: 12pt; = font-family: Calibri; font-style: normal; font-variant: normal; = font-weight: normal; letter-spacing: normal; line-height: normal; = orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: = none; white-space: normal; widows: 2; word-spacing: 0px; = -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div = dir=3D"ltr"><h1><font face=3D"Calibri, sans-serif" size=3D"3"><span = style=3D"font-weight: normal; white-space: pre-wrap; ">In response to = Olle's question about whether SIMPLE is an abject and irredeemable = failure, I would note that SIMPLE is still under consideration for = use in emergency services, if only because XMPP isn't yet a viable = alternative. </span></font><span style=3D"font-family: Calibri, = sans-serif; font-size: 12pt; font-weight: normal; white-space: pre-wrap; = ">For example, both NENA i3 and ECRIT PhoneBCP mention SIMPLE, but refer = to XMPP support of emergency services as future work. In emergency = scenarios, presence and address books are typically not considered since = the PSAP is neither a presentity nor a watcher. Instead, SIMPLE = is used as a way of conveying information between the caller and PSAP, = including location, a message body and additional data. = </span></h1><div><font face=3D"Calibri, sans-serif"><span = style=3D"white-space: pre-wrap; ">With SMS to 911 under active = discussion with regulatory bodies, the question about whether we can = rely on SIMPLE for emergency use has become a "hot issue". As an = example, there has been a suggestion that MESSAGE could be used to = </span></font><span style=3D"white-space: pre-wrap; font-family: = Calibri, sans-serif; "> support conveyance of SMS text messages to a = "text gateway" that would then pass them on to the PSAP (possibly in a = different form, such as translating to TTY/TDD). Not only might = this help standardize the transport of SMS messages to 911, but it would = also support future uses of MESSAGE for next generation emergency = services. </span></div><div><span style=3D"white-space: pre-wrap; = font-family: Calibri, sans-serif; "><br></span></div><div><span = style=3D"white-space: pre-wrap; font-family: Calibri, sans-serif; = ">While documents like NENAi3 and ECRIT PhoneBCP still point to SIMPLE = specs, some folks have pointed to the lack of support for MESSAGE in SIP = trunking services as an indication that even basic uses of SIMPLE are = unlikely to see much deployment, and that alternatives for disabled = access to emergency services (such as RFC 4103 realtime text) should be = given priority. </span></div><div><span style=3D"white-space: = pre-wrap; font-family: Calibri, sans-serif; = "><br></span></div><div><span style=3D"white-space: pre-wrap; = font-family: Calibri, sans-serif; ">IMHO, unless XMPP for emergency = uses is specified by IETF in the near future, it is likely that SIMPLE = will find its way into emergency services architectures in some form. = Since the IETF is still recommending SIMPLE in documents such as ECRIT = PhoneBCP, IMHO the IETF has a responsibility to public safety to address = interop issues that will arise in next generation emergency services = scenarios. AFAIK, SIMPLE interop issues haven't killed anyone yet. = Hopefully this will remain true in the future. = </span></div></div></div></blockquote>Thank you for your response, = Bernard.</div><div><br></div><div>Yes, if the emergency services don't = want to sign a contract with a single vendor of both servers and = clients, but wants to have a choice - we need to fix interoperability. I = do understand that many of the issues we've discussed here doesn't apply = - like XCAP documents and buddy lists, so it MAY be easier, to use RFC = language :-)</div><div><br></div><div>Realtime Text with RFC 4103/T.140 = is implemented in many places today (and supported by Asterisk :-) = )</div><div>so that's something that should not be ignored, regardless = of plans to support = IM/Chat.</div><div><br></div><div>/O</div><div><br><blockquote = type=3D"cite"><div class=3D"hmmessage" style=3D"font-size: 12pt; = font-family: Calibri; font-style: normal; font-variant: normal; = font-weight: normal; letter-spacing: normal; line-height: normal; = orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: = none; white-space: normal; widows: 2; word-spacing: 0px; = -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div = dir=3D"ltr"><div><font face=3D"Calibri, sans-serif"><span = style=3D"white-space: pre-wrap; "><br></span></font></div><div><span = style=3D"font-family: Calibri, sans-serif; font-size: 12pt; white-space: = pre-wrap; ">Olle E. Johansson said: </span></div><pre = style=3D"font-family: Calibri, sans-serif; font-size: 12pt; white-space: = pre-wrap; word-wrap: break-word; width: 1111.5px; ">"Any other thoughts = in regards to SIMPLE? Is it a failure or not? Do we have a chance of fixing this within the IETF? Is anyone interested in fixing it so we actually reach the WG goal of = interoperability?" = <br></pre></div>_______________________________________________<br>Simple = mailing list<br><a = href=3D"mailto:[email protected]">[email protected]</a><br><a = href=3D"https://www.ietf.org/mailman/listinfo/simple">https://www.ietf.org= /mailman/listinfo/simple</a><br></div></blockquote></div><br></body></html= >= --Apple-Mail=_C96FB200-A0DC-4D28-8BB1-1442C01E3EC4-- --===============1682067055201252007== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list [email protected] https://www.ietf.org/mailman/listinfo/simple --===============1682067055201252007==--