Subject: [Slim] [slim] #10 (negotiating-human-language): Summary of issues to the negotiating-human-language-04 draft

From: "slim issue tracker" <[email-masked]>
Date: Fri, 12 Aug 2016 20:11:43 -0000

#10: Summary of issues to the negotiating-human-language-04 draft

 Here is a summary of the issues 2-9 to the negotiating-human-language-04
 draft.

 1. Move the session level parameter about rejecting or connecting the call
 in case of no language match to session level. There is no logically
 correct place for this parameter in the media level attributes.  Issue #7.

 2. Revert the default value of the rejecting or connecting the call at no
 match to be connecting. That matches the scope of the parameter better,
 and is in line with the discussion in the mail list. Issue #7

 3. Add a value "improve" to the session level attribute, with the meaning
 "I can improve language matches by introduction of means not initially
 indicated. ( such as a caller not invoking a relay service initially, but
 after the answer when it shows that a relay service is needed. ) Issue #7.

 4. Introduce a modality parameter in the humintlang-send and humintlang-
 recv attribute values. Default values handle most cases, but there are
 cases when an explicit value is needed, because it is not evident from the
 m-line and the language tag what modality indicated. This is especially
 true for m=application cases.
 (A complex alternative would be to specify all cases we know now
 explicitly of language use where it is not explicit by the mime type and
 the language tag what modality is intended, but I think that is too
 inflexible. )   Issue #6.

 5. Combine all languages for one media, modality and direction in a space
 separated list as value to one humintlang-send or humintlang-recv
 attribute. That matches the format of the SIP Accept-Language field value.
 It also matches the logic of only indicating one highest favoured
 language.
 It would be possible to have only one language per humintlang-send or
 humintlang-recv attribute and include multiple attributes per media and
 direction. But then the syntax of the most favoured parameter gets less
 logical. Therefore I propose the changed attribute syntax. Issue #9.

 6. Introduce a mark for most favoured media, meaning that the first
 language in the value list of the corresponding attribute is the most
 favoured for that direction. This can enable the negotiation to result in
 good decisions so that language exchange gets efficient. Without it, the
 start of the call will be in randomly selected modality and language among
 a set with undefined relative favour, causing problems to correct the
 modality and language when it gets initially wrong. Issue #6, #8

 7. Allow indication of up to two highest favoured modalities per
 direction, or one highest favoured and one complementing, so that good
 decisions can be made.
 That enables specifying the needs behind the use of some common types of
 relay services or favoured behavior of the other party. Without this,
 there are calls that will not be answered in the most efficient way,
 instead causing confusion and delay. Issue #6,#8

 8. Follow the format for attribute definition from rfc4566bis.
 Issue #9.

 9. Wording change proposals: Issue #2, 3,4,5.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-slim-
  [email-masked]        |  [email-masked]
     Type:  enhancement              |     Status:  new
 Priority:  major                    |  Milestone:
Component:  negotiating-human-       |    Version:
  language                           |   Keywords:
 Severity:  In WG Last Call          |
-------------------------------------+-------------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/slim/trac/ticket/10>
slim <https://tools.ietf.org/slim/>