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

From: Randall Gellens <[email-masked]>
Date: Sun, 1 Nov 2015 22:01:35 -0800

At 9:59 AM +0200 10/4/15, Gunnar Hellström wrote:

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.

This was not my interpretation from the wording, and also from an
example (it's been years so I am no longer sure of the source of the
example) which was a clip of a TV interview where the person being
interviewed spoke another language from that of the interviewer.

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.

If this wording is correct, then we don't need anything new, we
can use the existing lang attribute for negotiation, and the real-time
milestone of the group can be declared moot and we can move on.
That would be great, but doesn't match my understanding.

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

_______________________________________________

SLIM mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/slim

--

Randall Gellens

Opinions are personal;    facts are
suspect;    I speak for myself only

-------------- Randomly selected tag: ---------------

He knows nothing, and he thinks he knows everything. That points

clearly to a political career.

-- George Bernard Shaw

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 2 Nov 2015 08:32:41 +0100

Den 2015-11-02 kl. 07:01, skrev Randall Gellens:
> Re: [Slim] The use of multiple lang attributes in SDP
>> 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>
>>
>> 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.
>
> If this wording is correct, then we don't need anything new, we can 
> use the existing lang attribute for negotiation, and the real-time 
> milestone of the group can be declared moot and we can move on. That 
> would be great, but doesn't match my understanding.
There was a brief mail exchange on this topic in mmusic - RFC4566bis 
under the subject:
[MMUSIC] Clarification for multiple lang attributes in rfc4566bis
and the current conclusion is that the interpretation I suggest is 
acceptable and that a wording change is on its way into RFC 4566 bis.
We could work for an errata to RFC 4566 also, but I think that that is 
overkill for this kind of subtile wording interpretation.
But we should change the humintlang draft accordingly.

The humintlang added value over the lang attribute is still needed for 
the cases of
1. different preferences for different directions, ( e.g. speak and read )
2. linked requirements between media (e.g. must speak and must read )
3. (absolute) preference relation between language in different media ( 
e.g. prefer sign language in video  but can accept to use written text )

And we need to describe how lang and humintlang attributes interact.

/Gunnar

>>       provided either at session or media level if the session
>>       description or media use multiple languages, in which case the
>>       various languages in the session or media from most important to
>>       least important."
>>
>> 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.
>>
>> 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
>>    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
>>    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
>>  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".
>>
>> "if the session or media*can use* multiple languages".
>>
>> 1. It aligns with the requirement for language negotiation in RFC 
>> 2277 that was said to be
>>    the requirement behind the wording.
>>    It is more in line with real-time conversation that events during 
>> the conversation causes decision to use
>>    just one language.
>>
>> " Multiple lang attributes can be provided either at session or media 
>> level if the session or media has
>> participants are not strictly bound to only use the declared languages."
>>
> Opinions are personal;    facts are suspect;    I speak for myself only