ietf
[Top] [All Lists]

Re: Last Call: <draft-ietf-slim-negotiating-human-language-06.txt> (Negotiating Human Language in Real-Time Communications) to Proposed Standard

2017-02-13 11:54:20
Gunnar Hellström wrote:

5. Make use of the asterisk modifier on media level with session scope
also for media level purposes 

The asterisk modifier optionally appended on attribute values has in
the original -06 draft only a session effect. It is specified to
indicate if the call should be rejected or not if languages do not
match. It can be appended to any humintlang attribute in the whole SDP
without any change in effect. This independancy of placement indicates
that it is wrongly placed. With the current definition, it should be a
single separate session level attribute. Instead of specifying a
separate session level attribute, it is proposed that the asterisk
gets an expanded definition, so that its placement conveys meaning of
value for the successful language negotiation. 

It has been discussed in the SLIM WG that the specification lacks two
functions, required by the specifications by other bodies who are
waiting for the results of SLIM real-time work. (e.g. 3GPP TS 22.228
and ETSI TR 103 201). 3GPP TS 22.228 requires "The system should be
able to negotiate the user's desired language(s) and modalities, per
media stream and/or session, in order of preference." Thus negotiation
with preference indication within the session is required, not only
within each media. ETSI TR 103 201 says "the Total Conversation user
should be able to indicate the preferred method of communication for
each direction of the session, so that the call-taker can be selected
appropriately or an appropriate assisting service be invoked. " Saying
"preferred" means that it should also be possible to indicate less
preferred alternatives.

Gunnar, who participated extensively in the SLIM WG, appears to be
attempting to re-introduce a mechanism to indicate preference of
modality which was considered and rejected multiple times by the WG.

WG rejection of Gunnar's previous proposals to do this was based on
reluctance to try to solve this particular problem in the first version
of the spec, not on any of the specific mechanisms proposed to solve the
problem. Proposing a new or modified mechanism during IETF LC appears to
be an attempt to rehash an argument made, but not won, in the WG.

If this concerns a different issue, not merely a different way of
approaching it, please accept my apology and explain more clearly how it
is different.

 
--
Doug Ewell | Thornton, CO, US | ewellic.org