Subject: Re: [Slim] IETF95, was: Re: Change proposals for draft-ietf-slim-negotiating-human-language-00.txt

From: Natasha Rooney <[email-masked]>
Date: Fri, 1 Apr 2016 12:47:05 +0000

Hi all!

I have uploaded an agenda for our meeting next week. Please let me know if you wish to make any changes. I will also double check the remote participation is set up for those who will be attending remotely.

https://datatracker.ietf.org/meeting/95/agenda/slim/

Many thanks!

Natasha

Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | [email-masked]<mailto:[email-masked]> | +44 (0) 7730 219 765 | @thisNatasha | Skype: [email-masked]<mailto:[email-masked]>

On Mar 31, 2016, at 5:39 PM, Natasha Rooney <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

It’s about time (or, perhaps late by two weeks!) that we decide on our agenda for next week’s meeting. We have an hour between 16:20-17:20 on Thursday and we will have both remote and present attendees.

In this meeting we will be discussing the below open issue and updates that have been made / will be made to the existing documents. The meeting should be less than an hour. A guidelines agenda is:

Welcome
Update on SLIM new and existing docs
draft-ietf-slim-multilangcontent-00
draft-ietf-slim-negotiating-human-language-01
draft-ietf-slim-use-cases-00
Open Issue(s)

If you have something else to add please do let me know as soon as you can so I can add this to the agenda. I will publish this tomorrow.

Also, please let me know if you are attending in person or not if you haven’t already!

Thanks all!

Natasha

Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | [email-masked]<mailto:[email-masked]> | +44 (0) 7730 219 765 | @thisNatasha | Skype: [email-masked]<mailto:[email-masked]>

On Mar 21, 2016, at 8:47 PM, Gunnar Hellström <[email-masked]<mailto:[email-masked]>> wrote:

Hi Randall,
Den 2016-03-21 kl. 17:53, skrev Randall Gellens:
Hi Gunnar,

I do not believe we are forcing an interpretation on RFC 4566, rather, the drafts says, in an explanatory aside in parentheses, how the authors interpret it.  This is quite far from a normative statement.
It will be documented anyway, and just as you looked at the discussion around the STOX - example and got influenced by it, there is a risk that we spread more uncertainty in the topic or lead others to make unlogical conclusions.
Let it be sufficient to say that 'lang' does not have the detailing we need.

I have re-read the text on language directionality within a media stream, and I do not see that we have an interoperability problem. It's possible that multiple streams with a language in the same direction are established, and it's possible that not all of them are actually used (e.g., if higher priority streams are established, perhaps the lower priority ones are not used).  I don't see that as causing an interoperability problem.
See use cases 2.3, 2.4, 2.5 and 2.6 in the use-case document just published by Natasha. Thanks!
Only 2.3 is solved by the current specification. The other needs cross-media preferences.
They could need media and language grouping as well, but I prefer that we try to solve that with a rule saying that languages in different media specified on the same preference level shall be seen as a group that is required together, while languages in different media specified with different preference levels specify single languages provided for selection.

Note also that the primary function of these attributes are not to guide which media streams shall be accepted and activated, it is usually good with media streams even if they are not used for language.
The function I see as the main purpose is to make sure that the caller gets in contact with a person with the right language competence and if needed a suitable relay service is invoked in the call in order to cover any gaps in language coverage.
Of course a media stream must not be excluded that is needed for the selected language combination.  But the opposite should not happen - that a media stream is ignored because it is not needed for language communication.

I could add a statement that both 'lang' and 'humintlang-' attributes should not be used in the same stream, due to potential confusion.
Yes, if we cannot agree on how to interpret 'lang', it would be a solution.
But the problem is also between media. 'lang' in one medium and 'humintlang' in another is also undefined if it represents an offered selection, or a required combination and if selection, what preference levels do they represent?
We must then also think about the conflict between 'lang' on session level and 'humintlang' on media level.

/Gunnar

At 7:19 AM +0100 3/21/16, Gunnar Hellström wrote:

Randall,

I think it is unfair to RFC 4566 and RFC 3264 that we force an interpretation of the use of the 'lang' attribute on them that we do not agree on.

If we do not come to an agreement, we could instead just refrain from documenting an interpretation of how the 'lang' attribute works and  conclude with

"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."

We must also make sure that we do not make the same kind of unders-pecification as apparently has been done in RFC 4566.
We need to describe what it means if we have language indications for the same direction in two (or more) media.
Shall it be understood as an indication that
    1) I am prepared to use both in the session or that
    2) I require both to be used or that
    3) I am not prepared to use both but offer them for selection.
If the normal interpretation is that it is for selection of one, how is the preference for one or the other indicated?
And if the normal interpretation is for a selection, how do we then indicate the case when we really strongly prefer to get both. ( e.g. voice plus captions ).

We also need to describe how use of both 'lang' and 'humintlang-' attributes in the same sdp shall be interpreted.

Regards

Gunnar

Den 2016-03-21 kl. 01:32, skrev Randall Gellens:
Hi Gunnar,

Thanks very much for your comments.  Please see in-line:

At 7:36 AM +0100 3/16/16, Gunnar Hellström wrote:

 In addition to the changes proposed in draft-ietf-slim-negotiating-human-language-00 for the preference regardless of media recently submitted, I have the following proposals for changes:

 1. Change the first paragraph of section 5 from:

--------------------------------------------------------------------------------------------------
  <https://tools.ietf.org/html/rfc4566>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

---------------------------------------------------------------------------------------
  <https://tools.ietf.org/html/rfc4566>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.

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

I disagree.  I've reread the text in the draft and in RFC 4566 multiple times.  However, I added clarifying wording to the draft.

 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 (erroniously 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."

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

While I disagree with your interpretation, I don't think it's needed to go into this level of detail at this point in the draft, so I left it unchanged.

 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 <https://tools.ietf.org/html/rfc5646>RFC 5646 [<https://tools.ietf.org/html/rfc5646>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 <https://tools.ietf.org/html/rfc5646>RFC 5646 [<https://tools.ietf.org/html/rfc5646>RFC5646]
    The new attribute can appear together with the existing 'lang'
    attribute to compose the preferred language/modality combinations
    offered or negotiated.
----------------------------------------------------------------------

I don't think we have consensus on doing this, so I left it unchanged.

--
-----------------------------------------
Gunnar Hellström
Omnitor
[email-masked]<mailto:[email-masked]>
+46 708 204 288

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

--
-----------------------------------------
Gunnar Hellström
Omnitor
[email-masked]<mailto:[email-masked]>
+46 708 204 288

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

This email and its attachments are intended for the above named only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this email or call +44 207 356 0600 and highlight the error.

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

This email and its attachments are intended for the above named only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this email or call +44 207 356 0600 and highlight the error.