Subject: [Slim] Change proposals for the real-time SLIM draft

From: Gunnar Hellström <[email-masked]>
Date: Thu, 7 Apr 2016 10:50:40 +0200

Here is a modified re-issue of change proposals I have made for the 
real-time humintlang draft,
https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/

The reasoning for proposing them are still valid and need to be solved, 
so I suggest that continued work to satisfy the requirements are based 
on these change proposals.

*A: The current "lang" attribute is intended for selection by 
offer-answer and not as a mandatory list.*
The discussion about the current 'lang' attribute in sections 5 and 6 is 
misleading and should be changed. The attribute is useful.

1. Change the first paragraph of section 5 from:
--------------------------------------------------------------------------------------------------

  RFC 4566 specifies an attribute 'lang' which sounds similar to what
    is needed here, the difference being that it specifies that 'a=lang'
    is declarative with the semantics of multiple 'lang' attributes being
    that all of them are used, while we want a means to negotiate which
    one is used in each stream.  This difference means that the existing
    'lang' attribute can't be used and we need to define a new attribute.
-------------------------------------------------------------------------------

to
---------------------------------------------------------------------------------------

  RFC 4566 specifies an attribute 'lang' which sounds similar to what
    is needed here. It specifies that 'a=lang'
    is declarative with the semantics of multiple 'lang' attributes being
    possible, indicating a number of possible languages in the session in
    an order of preference. Each party declares their capabilities and the
    language(s) used in the session can then be selected from the common 
set.
    We have however a need to specify direction of use of each language,
    and an order of preference between languages in different modalities.
    This difference means that the existing 'lang' attribute is not 
sufficient
    for our use and we need to complement it with definition of a new 
attribute.
--------------------------------------------------------------------------------------------------

2. change the last two paragraphs of section 5 from:
--------------------------------------------------------------------------------------------------------

  A recent search of RFCs and Internet Drafts turned up only one use of
    the 'lang' attribute (in a now-expired draft), and that sole use was
    coincidentally in exactly the way we need (erroneously assuming that
    the attribute was used for negotiation).  The sole use was in an
    example in a draft not directly related to language, where the
    initial invitation contains two 'a=lang' entries for a media stream
    (for English and Italian) and the OK accepts one of them (Italian).

    The example serves as evidence of the need for an SDP attribute with
    the semantics as described in this document; unfortunately, the
    existing 'lang' attribute is not it.
----------------------------------------------------------------------
to
-----------------------------------------------------------------------------
  A recent search of RFCs and Internet Drafts turned up only one use of
    the 'lang' attribute (in a now-expired draft), and that sole use was
    coincidentally in exactly the way we need.  The sole use was in an
    example in a draft not directly related to language, where the
    initial invitation contains two 'a=lang' entries for a media stream
    (for English and Italian) and the OK accepts one of them (Italian).

    This use was questioned in a discussion of that draft because of this
    sentence in RFC 4566: "Multiple lang attributes can be
       provided either at session or media level if the session
       description or media use multiple languages."
    An interpretation was that all declared languages must be used in
    the session, while the example showed use of a selection of the
    originally indicated languages. The uncertainty caused withdrawal
    of the example because it was not essential for the draft.

   However, studying the wording in RFC 4566 further, it is evident
   that a negotiation of languages was intended for the real-time case.
   When sdp is used to declare contents of a recorded session, then it
   makes sense to list the provided languages, while for a real-time
   session, it is obvious that the capabilities of the parties and the
   development of the session influence the selection of language for
   the session.
   The continuation in RFC 4566 "the order of the attributes indicates
   the order of importance of the various languages" makes it very clear
   that the list shall be seen as a list for selection and negotiation.
   The "order of importance" has no meaning if all languages must be 
provided.

   The conclusion is that the 'lang' attribute can be used for negotiation
   of one or more common languages to select from for use in a real-time 
session.
   A clarification is prepared for a possible future revision of RFC 4566.

   Thus, the 'lang' attribute satisfies our needs in many cases.

   Unfortunately, there are cases, where the users need to use different
   modalities in different directions, and when it is important to combine
   languages in different modalities. The 'lang' attribute does not have
   the details needed to cover these cases."
-------------------------------------------------------------------------------------------------

3. Change section 6 from:
-------------------------------------------------------
6 Proposed Solution

    An SDP attribute seems the natural choice to negotiate human
    (natural) language of an interactive media stream.  The attribute
    value should be a language tag per RFC 5646 [RFC5646] "
------------------------------------------------------------------
to
-----------------------------------------------------------------------
6 Proposed Solution
    An SDP attribute seems the natural choice to negotiate human
    (natural) language of an interactive media stream.  The attribute
    value should be a language tag per RFC 5646 [RFC5646]
    The new attribute can appear together with the existing 'lang'
    attribute to compose the preferred language/modality combinations
    offered or negotiated.
----------------------------------------------------------------------

*B: Need for notation of combinations of languages and priority 
assignment valid across multi m-lines*
Some use cases require clearly priority - ordered alternatives in 
different modalities.
Other use cases require a combination of one language/modality in one 
direction and another language/modality in the other direction.
Coding to express such needs and offerings must be included.

And we must not cause uncertainty about if the indications are seen as a 
list where all must be provided or a list for selection in an 
offer/answer exchange.

-------------------------------------current text in 
6.2-------------------------------------------------

       a=humintlang-send:<language tag>
       a=humintlang-recv:<language tag>

    Each can appear multiple times in an offer for a media stream.

    In an offer, the 'humintlang-send' values constitute a list in
    preference order (first is most preferred) of the languages the
    offerer wishes to send using the media, and the 'humintlang-recv'
    values constitute a list in preference order of the languages the
    offerer wishes to receive using the media.

-------------------------------------proposed changed text in 
6.2----------------------------------

       a=humintlang-send:<language tag>[ ";" "q" "=" qvalue ]

       a=humintlang-recv:<language tag>[ ";" "q" "=" qvalue ]

    Each can appear multiple times in an offer or answer for a media stream.

    In an offer or answer the 'humintlang-send' values constitute a list 
of the languages the
    party is capable to select from for sending using the media, and the 
'humintlang-recv'
    values constitute a list of the languages in which the party is 
capable of receiving contents
    using the media.  The q-values represent a preference level
    for using the indicated language and modality relative to all other 
languages and
    modalities indicated for the same direction in the whole SDP.
    The quality value defaults to "q=1" and has the same syntax and 
usage rules as for 'Accept-Language' in RFC 2616 [RFC2616].

    If more than one language is specified in the SDP with the same 
q-value, it indicates a required grouping.
    If one of these languages is selected to be used, then all with that 
q-value SHALL be used.

Languages specified with the "lang" attribute SHALL be regarded to have 
the q-value 0.5.

   An answer SHALL only contain language specifications selected from 
the offer. It is RECOMMENDED that the answer selects one complete set of 
language indications for conducting a conversation and thereby giving 
the offeror a clear indication of which language(s) will be used.

If an answer does not include any language indication, then the session 
participants are left to use other means than the language indications 
to select the languages used (if any) in the session.

---------------------------------End of change 
proposal.---------------------------------------------

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
+46 708 204 288