Re: SIMPLE and Emergency Services
Bernard Aboba <[email protected]> Thu, 1 Nov 2012 11:34:28 -0700
| Newsgroups | gmane.ietf.simple |
|---|---|
| Message-ID | <[email protected]> |
--===============4558010128242942980==
Content-Type: multipart/alternative;
boundary="_6768b62c-b049-46ca-96aa-4fc4c22bd7d2_"
--_6768b62c-b049-46ca-96aa-4fc4c22bd7d2_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Saul wrote:=20
> I see you are mentioning SIP MESSAGE all along=2C but (please someone cor=
rect me if I'm wrong) the IM functionality advocated by SIMPLE is MSRP=2C n=
ot SIP MESSAGE. For translating SMS messages SIP MESSAGE works=2C but it la=
cks the concept of a 'session'=2C so it doesn't fit well a model for a conv=
ersation.
[BA] NENA i3 requires implementation of both MSRP and MESSAGE at the PSAP. =
ECRIT PhoneBCP also mentions both. So for emergency uses=2C both MSRP an=
d MESSAGE are potentially relevant.=20
> Realtime text is another stream type negotiated with an INVITE=2C so I gu=
ess MSRP could be used just fine for the same purpose by sending one MSRP c=
hunk with a single character at a time. There would be a bit of overhead=2C=
however.
[BA] Currently the Access Board and other regulatory bodies do not have MS=
RP on the list of approved "realtime text" standards.=20
> I'm unfamiliar with those documents=2C but are we talking presence here? =
Because this whole thing started about the presence part. To my knowledge t=
here are no interoperability problems with MSRP implementations following t=
he standard.
[BA] Presence and address books are not relevant to emergency services beca=
use the PSAP is neither a presentity nor a watcher.
=
--_6768b62c-b049-46ca-96aa-4fc4c22bd7d2_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<style><!--
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 12pt=3B
font-family:Calibri
}
--></style></head>
<body class=3D'hmmessage'><div dir=3D'ltr'>Saul wrote: <br><br><div>>=3B =
I see you are mentioning SIP MESSAGE all along=2C but (please someone corre=
ct me if I'm wrong) the IM functionality advocated by SIMPLE is MSRP=2C not=
SIP MESSAGE. For translating SMS messages SIP MESSAGE works=2C but it lack=
s the concept of a 'session'=2C so it doesn't fit well a model for a conver=
sation.<br><br>[BA] NENA i3 requires implementation of both MSRP and MESSAG=
E at the PSAP. =3B ECRIT PhoneBCP also mentions both. =3B So for em=
ergency =3B uses=2C both MSRP and MESSAGE are potentially relevant. <br=
><br>>=3B Realtime text is another stream type negotiated with an INVITE=
=2C so I guess MSRP could be used just fine for the same purpose by sending=
one MSRP chunk with a single character at a time. There would be a bit of =
overhead=2C however.<br><br>[BA] =3B Currently the Access Board and oth=
er regulatory bodies do not have MSRP on the list of approved "realtime tex=
t" standards. <br><br>>=3B I'm unfamiliar with those documents=2C but are=
we talking presence here? Because this whole thing started about the prese=
nce part. To my knowledge there are no interoperability problems with MSRP =
implementations following the standard.<br><br>[BA] Presence and address bo=
oks are not relevant to emergency services because the PSAP is neither a pr=
esentity nor a watcher.<br></div> </div></body>
</html>=
--_6768b62c-b049-46ca-96aa-4fc4c22bd7d2_--
--===============4558010128242942980==
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
--===============4558010128242942980==--