[MMUSIC] Clarification for multiple lang attributes in rfc4566bis

[Gunnar Hellström <[e-mail]>]

There is some uncertainty about interpretation of multiple lang 
attributes in RFC 4566 that would need to be sorted out in rfc4566bis.
The uncertainty has caused stox to select another mechanism and now also 
slim is hesitating. (see slim and its real-time draft for a deeper 
discussion)

The current text in section 6.12 of rfc4566bis is:

-----------------------------current text from 
6.12--------------------------------

Multiple lang attributes can be provided either at session or media
    level if the session or media use multiple languages, in which case
    the order of the attributes indicates the order of importance of the
    various languages in the session or media, from most important to
    least important.

    As a session-level attribute, it specifies the default language for
    the session being described.  As a media-level attribute, it
    specifies the language for that media, overriding any session-level
    languages specified.

    The "lang" attribute value must be a single [RFC5646] language tag in
    US-ASCII.  A "lang" attribute SHOULD be specified when a session is
    of sufficient scope to cross geographic boundaries where the language
    of recipients cannot be assumed, or where the session is in a
    different language from the locally assumed norm.

-----------------------------------------------------------------------------------------------

The uncertainty has been around what the wording "use multiple 
languages" means.
It can mean that all are provided simultaneously, but it can also mean 
that it is a list of capabilities and
that events during the session can decide which languages will really be 
used. There is also uncertainty
about if a negotiation can take place to agree on one or a set of common 
languages to select from as default language(s).

In order to bring some clarity, I suggest to change to the following:

-----------------------------proposed replacement text for 
6.12--------------------------------

    Multiple lang attributes can be provided either at session or media
    level if the session or media has capabilities to use multiple languages, in which case
    the order of the attributes indicates the order of preference of the
    various languages in the session or media, from most preferred to
    least preferred.

    As a session-level attribute, lang specifies a language capability for
    the session being described.  As a media-level attribute, it
    specifies a language capability for that media, overriding any session-level
    language(s) specified.

    The "lang" attribute value must be a single [RFC5646] language tag in
    US-ASCII.  A "lang" attribute SHOULD be specified when a session is
    of sufficient scope to cross geographic boundaries where the language
    of recipients cannot be assumed, or where the session has capabilities in
    languages different from the locally assumed norm.
    
    Events during the session may influence which language(s) are used, and the
    participants are not strictly bound to only use the declared languages.

    

-----------------------------------------------------------------------------------------------

My conclusion from looking at the background of the wording for lang in 
RFC 4566 is that we can safely assume that for real-time sessions, the 
meaning of multiple lang specifications is a range of capabilities, and 
not a requirement to use all languages.
By that interpretation, we can also assume that an offer/answer exchange 
can negotiate the language(s) to be suitable for use in a session to be 
a subset of what the offer contained.

I traced the introduction of the wording from an announcement in mmusic 
on 1997-11-23, and then the wording appeared in draft-ietf-mmusic-sdp-05 
on 1997-12-23. There was no further discussion and the wording has 
stayed like that with merely a swap of the paragraphs in rfc4566bis.

In the mail announcing the introduction it was said that the intention 
was to fulfill requirements from a draft that then became RFC 2277.

A relevant section in RFC 2277 is:
"

4.4.  Considerations for language negotiation

    Protocols where users have text presented to them in response to user
    actions MUST provide for support of multiple languages.

    How this is done will vary between protocols; for instance, in some
    cases, a negotiation where the client proposes a set of languages and
    the server replies with one is appropriate; in other cases, a server
    may choose to send multiple variants of a text and let the client
    pick which one to display.

    Negotiation is useful in the case where one side of the protocol
    exchange is able to present text in multiple languages to the other
    side, and the other side has a preference for one of these; the most
    common example is the text part of error responses, or Web pages that
    are available in multiple languages.

    Negotiating a language should be regarded as a permanent requirement
    of the protocol that will not go away at any time in the future.

    In many cases, it should be possible to include it as part of the
    connection establishment, together with authentication and other
    preferences negotiation. "

So it is apparent that the intention for real-time conversational cases is a negotiation with
  an offer and a selection, either in an answer or by human agreement in the session.

The central word creating the hesitation in interpretation is that all languages must be used is "use" in this phrase:
"if the session description or media*use*  multiple languages".

It is hard to believe that it was the intention that all must be used. The proposed wording is made to make the
interpretation clear that it is a set of capabilities..

There are multiple reasons for that interpretation:

1. It aligns with the requirement for language negotiation in RFC 2277 that was said to be
    the requirement behind the wording.
2. It is usually unrealistic to use multiple languages at the same time in a medium.
    It is more in line at least with real-time conversation that events during the conversation causes decision to use
    just one language.
3. The discussion in the original wording of importance of languages lose its meaning if all must be used. "the
order of the attributes indicates the order of importance of the various languages in the session or media".
There is no use of knowing how important a language is if they all must be presented. It is more likely that
this relates to a possibility to select languages and that the "importance" is a grading of preference.

This would mean that we can safely assume that the use of multiple lang attributes in SDP were and are intended as
a selection and that negotiation through offer/answer is possible.


I realize that the language about capabilities in my proposal does not match an sdp that belongs to a
static session with recorded material equally well as it does for a real-time session between human participants,
but I want anyway propose the wording.
  
/Gunnar Hellström