Subject: [Slim] The use of multiple lang attributes in SDP

From: Gunnar Hellström <[email-masked]>
Date: Sun, 4 Oct 2015 09:59:29 +0200

I have looked a bit further into the vague specification of use of 
multiple a= lang attributes in SDP, as discussed in section 6 of
https://tools.ietf.org/html/draft-gellens-slim-negotiating-human-language-02

My conclusion 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 as the current interpretation 
in the draft leans towards.
By that interpretation, we can also assume that an offer/answer exchange 
can negotiate the language(s) to use in a session to be a subset of what 
the offer contained.

The wording from RFC 4566, repeated in the draft, section 6 is:

"

Multiple lang attributes can be
       provided either at session or media level if the session
       description 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."

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 since then.

In the mail announcing the introduction it was said that the intention 
was to fulfill requirements from a draft by Harald Alvestrand 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 current interpretation in our draft 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 that was the intention. A very simple change makes it more realistic:
"if the session or media*can*  *use*  multiple languages".

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 with real-time conversation that events during the conversation causes decision to use
    just one language.

3. The following discussion 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 and the importance is a grading of preference.

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

To put this assumption in words, we could either just insert the word "can" in the sentence from RFC 4566,
or make a more elaborated rewording, e.g. into:

" Multiple lang attributes can be provided either at session or media level if the session or media has
capability to use multiple languages, in which case the order of the attributes indicates the order of
preference of the various possible languages in the session or media from most preferred to least preferred.
Events during the session may influence which language(s) are used, and for real-time sessions, the
participants are not strictly bound to only use the declared languages."

( the last sentence was inspired from a similar specification, I do not remember from where. It may have been from CLUE or XCON )

Which wording do you prefer?

Is it realistic to propose an errata to rfc 4566 for this kind of diffuse interpretation issue, or is it sufficient to declare the interpretation in our draft?

If the reasoning above is accepted in slim, it would require changes in section 6 of the draft and open for some
use of the current lang attributes for simple cases. But since we do not get directionality from the current attributes,
there is still a need to add the humintlang attributes.

/Gunnar

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 4 Oct 2015 12:47:09 -0400

> Is it realistic to propose an errata to rfc 4566 for this kind of diffuse interpretation issue, or is it sufficient to declare the interpretation in our draft?

Since a bis for rfc4566 is underway, any clarifications should be done 
there.

	Thanks,
	Paul

> _______________________________________________
> SLIM mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/slim
>

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 4 Oct 2015 20:33:27 +0200

Paul,
Thanks for the reminder that there is a 4566bis on the way.
I will make a proposal to mmusic.

/Gunnar

Den 2015-10-04 kl. 18:47, skrev Paul Kyzivat:
>> The central word creating the current interpretation in our draft 
>> that all languages must be used is "use" in this phrase:
>> 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
>> ( the last sentence was inspired from a similar specification, I do 
>> not remember from where. It may have been from CLUE or XCON )
>>
>> Is it realistic to propose an errata to rfc 4566 for this kind of 
>> diffuse interpretation issue, or is it sufficient to declare the 
>> interpretation in our draft?
>
>> If the reasoning above is accepted in slim, it would require changes 
>> in section 6 of the draft and open for some
>> use of the current lang attributes for simple cases. But since we do 
>> not get directionality from the current attributes,