Re: [Simple] Fwd: Response to an LS from ETSI

[Bruno von Niman <[e-mail]>]

Hi Ben,

Thanks for raising this very valid issue - I totally agree!

No, it's not (other than to ETSI members - published documents are...) but
I'm sure we'll find a good way to make it available for comments to anyone
interested; there are workarounds.
I'll have a word with Gonzalo on Tuesday and we'll get back on the topic
(through the mailing list or the Dispatch session on Thursday latest),
Bruno


On 08/11/10 03:20, "Ben Campbell" <[e-mail]> wrote:

> ( as SIMPLE chair)
> 
> Hi,
> 
> The working group discussion so far has relied entirely on the liaison
> statement. It might help if we could view the mentioned draft directly. Is
> that draft publicly available?
> 
> Thanks,
> 
> Ben.
> 
> On Nov 8, 2010, at 7:02 AM, Bruno von Niman <[e-mail]> wrote:
> 
>> Dear SIMPLE!
>> 
>> ETSI TC Human Factors has received your liaison reply (available, together
>> with the liaison statement, at
>> https://datatracker.ietf.org/documents/LIAISON/file1119.txt and
>> https://datatracker.ietf.org/documents/LIAISON/file1085.doc) and will
>> address it at its next meeting, in February 2011.
>> 
>> As work item rapporteur, I'd like to thank you for it and follow it up in
>> some more detail through this thread, for some clarifications and individual
>> comments (especially as due to our lack of experience with IETF work, the
>> discussion between us never really got going).
>> 
>> To recap: the technology referred to in the liaison is deployed in all
>> Nordic countries (except Iceland), in Germany and some others and is used to
>> provide societal accessibility services, as required in the respective
>> countries, to hearing impaired people and those who telecommunicate with
>> them, over mobile and IP-based main stream infrastructures and devices.
>> 
>> For the future, in the IMS era (foreseen to become enough penetrated and
>> mature in some years' time in 3G/4G environments), there are
>> state-of-the-art technologies envisaged and well specified (in 3GPP, or
>> through the GSM Association Rich Communication Suite (RCS)), expected to
>> become the main stream. However, no solutions requiring this kind of
>> technology enablers are yet deployed today and will probably not be tomorrow
>> either; it will most probably take years until they do.
>> Deaf people cannot wait years, until this environment becomes a market
>> reality, as they'd love to communicate today - across the reliably available
>> mainstream infrastructures and devices of today!
>> 
>> This has been sorted out in the Nordic countries; it's a gap-filler but it
>> works now, across all networks (with a Nordic gateway under development).
>> However, to allow third parties to develop their products and avoid
>> segmentation and proprietary, non-interoperable solutions, there is a need
>> for an open specification standard.
>> 
>> In your reply, you explain that our P-header registration request seems to
>> fit the spirit of RFC 5727 and would likely be approved by a Designated
>> Expert, assuming the expert agreed with the rest of the proposal.
>> However, you also mention that the proposal as described appears to overlap
>> and conflict with RFC 4103, RFC 4351, and RFC 5194 and it may lead to
>> disjoint message behaviors.
>> We do not believe this will necessarily be the case, as these are covering
>> different scopes and are used for different purposes (as explained in the
>> liaison and below).
>> Furthermore, the disjoint behavior referred to is well managed through
>> personal preferences on the user interface level of the device and will
>> deliver upon the applicable user preference expectations, as there are
>> typically two categories of users with regard to this (segmented by the use
>> of predictive text input preferences).
>> The proposed header(s) do not undermine SIP security in any sense ­on the
>> contrary! This request is to guarantee the full delivery of all characters
>> in the text strings, not achievable with RFC4103 (due to character loss), as
>> well as the integrity of the communicating parties (see below).
>> Would this not cover all scenarios you've thought of, we'd appreciate if you
>> could develop it a little more in detail.
>> We'd rather comply, than use a different type of header (unless necessary)!
>> 
>> As for the use of RFC 3428 for Real-Time Text: the calculation of the IETF
>> SIMPLE experts (33kbps) corresponds in magnitude to the empirical data we
>> have collected from several sites running the service in real-life
>> installations (stretching between 15 kbps to 50 kbps in older version
>> installations). They may be small (although Germany has the largest
>> population in the EU!) - but they are real and correspond to the need of
>> most European countries, as the current service is a societal service and it
>> IS limited to hearing impaired people and their contacts.
>> This service is not intended to become available to any larger segments of
>> the population.
>> Last but not least, it is considerably more important for the service
>> provider to offer the best possible service quality (as character losses in
>> text communication may lead to serious implications) than to save some bucks
>> on server capacity (that will be dimensioned as needed).
>> 
>> In your reply, you mention that "...a similar session using RTP (as
>> described in RFC 4103) only requires 4 kbps, and only traverses network
>> nodes participating in the media streams. This is a difference on the order
>> of 10 to 1" (although we'd rather say "considerable", as the ratio may be as
>> low as 4:1 in some cases - but that's less relevant, as there is absolutely
>> no evidence of capacity issues).
>> The problem with RFC 4103-based implementations in today's networks is NAT
>> traversal in GSM (that still doesn't work), with new issues faced for Wi-Fi
>> and character loss in transmissions- two heavy reliability reasons to why
>> it's been completely rejected so far by service providers (there are NO
>> deployed services in operations, running RFC 4103 today).
>> In the future, as mentioned above, it's a different story - but the gap to
>> fill is NOW!
>> Even so, to be forward-looking, we'd like to mention the fact that there are
>> sharp interoperability requirements with RFC4103 in the ETSI draft Technical
>> Spec. 
>> 
>> Consultation with the RFC Editors indicates that the "SHOULD NOT" used in
>> RFC 3428 is to be interpreted as a "don't do it, unless you have a good
>> reason to do it". We believe to have a real good reason- or even two! So,
>> hopefully, it should be a show-stopper!
>> 
>> We'd be glad to continue discussions (over email, in or around this week's
>> meeting and after it), to agree some reasonable solution and consensus that
>> could allow you to accept or endorse the standardization of the described
>> use of the SIP MESSAGE method as an exceptional transport for real-time text
>> applications under the highly extraordinary circumstances described in the
>> liaison statement, as a gap-filler.
>> We'd be glad to use text-over-RTP, as recommended by you and as described in
>> RFC 4103 and RFC 5194 - if it was a workable direction for today's networks.
>> It is not, but we still need to offer hearing impaired people inclusive
>> communication services on equal terms NOW; we much hope that you can
>> contribute to achieving that vision, rather than raising another difficulty
>> (it's been quite some to pass already)!
>> 
>> With best regards,
>> Bruno von Niman
>> ETSI Human Factors
>> ETSI HF work item Rapporteur
>> 
>> 
>> On 27/09/10 20:14, "Gonzalo Camarillo" <[e-mail]>
>> wrote:
>> 
>>> FYI.
>>> 
>>> Gonzalo
>>> 
>>> -------- Original Message --------
>>> Subject: Response to an LS from ETSI
>>> Date: Mon, 27 Sep 2010 21:14:10 +0300
>>> From: Gonzalo Camarillo <[e-mail]>
>>> To: [e-mail]
>>> CC: Robert Sparks <[e-mail]>
>>> 
>>> Hi,
>>> 
>>> as you probably know, we have received the following liaison from ETSI:
>>> 
>>> https://datatracker.ietf.org/documents/LIAISON/file1085.doc
>>> 
>>> Based on the discussions on the SIMPLE WG list, we have put together the
>>> response in the attachment. We intend to send it to ETSI on Thursday.
>>> Let us know if you have any comments on it before then.
>>> 
>>> Thanks,
>>> 
>>> Gonzalo
>>> 
>>> 
>>> _______________________________________________
>>> Simple mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/simple
>> 
>> 
>> _______________________________________________
>> Simple mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/simple
>