Thanks Mark, And Kevin - I agree that particular uses, including emergency uses, are beyond this committee -- unless a feature in the technical spec can enable or disable an application of the technology or its use in that application. Then it should be raised I would think. I had thought that was the case here -- especially since with emergency systems communication networks they are putting gateways and translators in the path (to allow all types of communication to reach the NG9-1-1 centers) so the final point may not be able to directly see the originating point -and may not even be using the same technology. That was the only reason I raised the topic.
However, I think Mark has found a balance. Hope that works. Gregg -------------------------------------------------------- Gregg Vanderheiden Ph.D. Director Trace R&D Center Professor Industrial & Systems Engineering and Biomedical Engineering University of Wisconsin-Madison Co-Director, Raising the Floor - International and the Global Public Inclusive Infrastructure Project http://Raisingthefloor.org --- http://GPII.net On Jul 1, 2012, at 11:08 AM, Mark Rejhon wrote: > On Sun, Jul 1, 2012 at 11:34 AM, Kurt Zeilenga <[email protected]> > wrote: > In short, I think the potential use of XMPP IM/RTT in emergency services > should not only be beyond the scope of this spec, and used as basis for > making any design design or stating of any particular > requirement/recommendation. The use of non-specialized XMPP software/systems > for emergency services seems quite speculative. > > Attention everyone... good discussion...but the crisis is solved. (minor spec > fix was made). > > Let's give the list a little relief. > I have been hogging this mailing list quite a bit for the last 3 days. > I'd like to get done with that ASAP -- before the XMPP gods burn me at the > stake for hogging the list. :-) > > Goal is publish next XEP-0301 update by early this week. The original goal > was Friday, but the publishing is postponed to at least Monday/Tuesday due to > the huge number of public comments and private emails I've received, and this > being done outside my work hours, and during weekends. LAST CALL should be > quiet because this is already a de-facto LAST CALL already. > > Sincerely, > Mark Rejhon
smime.p7s
Description: S/MIME cryptographic signature
