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

["Doug Ewell" <[e-mail]>]

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