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

( 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 <bruno@vonniman.com> 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" <Gonzalo.Camarillo@ericsson.com>
> wrote:
> 
>> FYI.
>> 
>> Gonzalo
>> 
>> -------- Original Message --------
>> Subject: Response to an LS from ETSI
>> Date: Mon, 27 Sep 2010 21:14:10 +0300
>> From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
>> To: rai@ietf.org
>> CC: Robert Sparks <rjsparks@nostrum.com>
>> 
>> 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
>> Simple@ietf.org
>> https://www.ietf.org/mailman/listinfo/simple
> 
> 
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www.ietf.org/mailman/listinfo/simple