Subject: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-11.txt

From: [email-masked]
Date: Fri, 23 Jun 2017 16:46:53 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Selection of Language for Internet Media of the IETF.

        Title           : Negotiating Human Language in Real-Time Communications
        Author          : Randall Gellens
	Filename        : draft-ietf-slim-negotiating-human-language-11.txt
	Pages           : 18
	Date            : 2017-06-23

Abstract:
   Users have various human (natural) language needs, abilities, and
   preferences regarding spoken, written, and signed languages.  This
   document adds new SDP media-level attributes so that when
   establishing interactive communication sessions ("calls"), it is
   possible to negotiate (communicate and match) the caller's language
   and media needs with the capabilities of the called party.  This is
   especially important with emergency calls, where a call can be
   handled by a call taker capable of communicating with the user, or a
   translator or relay operator can be bridged into the call during
   setup, but this applies to non-emergency calls as well (as an
   example, when calling a company call center).

   This document describes the need and a solution using new SDP media
   attributes.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-11
https://datatracker.ietf.org/doc/html/draft-ietf-slim-negotiating-human-language-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-slim-negotiating-human-language-11

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 26 Jun 2017 11:30:33 +0200

Good to see progress.

I checked the numbered change proposals I submitted earlier under 
subject " I-D Action: draft-ietf-slim-negotiating-human-language-10.txt" 
and found that most of them were solved or agreed to be ignored. Only 
proposal 2.2 was not acted on, so I repeat it here together with a few 
new findings:

-----Issue 1, old 2.2 The attributes can appear in both offers and 
answers -----------
  -------Old text 2.2 at end of first paragraph of 5.2---------

     Each can appear in an offer for a media
     stream.
  --New text 2.2---
     Each can appear in an offer and answer for a media
     stream.
---Reasoning:----------

This paragraph is an introduction to the attributes. It should mention 
the full use, in both offer and answer. The following paragraphs tell 
about specifics for offer vs answer.
  --End of change 2.2---

---End of Issue 1----------

------Issue 2 , reduce info on possible extensions to not be solution 
specific----------

In section 5.2, middle:

-----Old text------------

   See Section 5.3 for more
    information and discussion.  Note that separate work
    [I-D.hellstrom-slim-modalitypref] extends the use of the asterisk to
    convey additional information regarding language/modality preferences
    among media.

-----New text proposal for Issue 2-----------

     See Section 5.3 for more information and discussion.
<paragraph separator>
    Note that separate work may introduce additional information regarding language/modality
    preferences among media.

---Reasoning: ---------
Two ways to convey language/modality preferences among media have been proposed, one based on the asterisk (draft-hellstrom-slim-modalitypref), and another based on the SDP gouping framework (draft-hellstrom-language-grouping). There are drafts for both. The clean one seems to be the method based on SDP grouping. It has no known interoperability problems.
**The proposed wording of the note (as a separate paragraph) is intended to cover both methods, but has less effect as a warning against interoperabitlity problems caused by the asterisk based solution.

*A decision is needed for which alternative to continue with, I prefer 
the one based on SDP grouping.*  

-----End of issue 2-----------------------

------Issue 3  - typo in 5.5------------

Typo in section 5.5, at the end of page 9

-------old text-----
       An offer of answer
-----new text----

    An offer or answer
-----end of issue 3------

----Issue 4  allow asterisks also in answers, but do not assign a meaning---------
The second example in 5.5 has asterisks last in the attributes and says that the example can be either an offer or an answer.

But section 5.2, fourth paragraph currently only says that the asterisk can appear in an offer.

I suggest to amend this by allowing the asterisk to appear in an answer, but not assign any meaning to it.
This is more future proof and may make implementation of the answering part easier than keeping the currect restriction.

------New paragraph after paragraph four in 5.2-------
The asterisk token MAY also be appended last in a 'hlang' attribute in an answer, but this specification does not define any meaning to an asterisk in that position.
------End of proposal for Issue 4...........
-----End of Issue 4----------------

----Issue 5 correct SDP syntax in answer example on page 10 
-------------------
In the answer example in section 5.5 on page 10, the answer shows no 
video m-line. There was an m-lne for video in the offer, then one must 
be included in the aswer.

---old text in 5.5----

    An answer for the above offer, indicating text in which the callee
    will receive written Spanish, and audio in which the callee will send
    spoken Spanish:

       m=text 45020 RTP/AVP 103 104
       a=hlang-recv:sp

       m=audio 49250 RTP/AVP 20
       a=hlang-send:sp

-------new text-----------

    An answer for the above offer, indicating text in which the callee
    will receive written Spanish, and audio in which the callee will send
    spoken Spanish. The answering party had no video capability:

       m=video 0 RTP/AVP 31 32
       m=text 45020 RTP/AVP 103 104
       a=hlang-recv:sp

       m=audio 49250 RTP/AVP 20
       a=hlang-send:sp

---------end of proposal------------
--------end of Issue 5---------------

--------Issue 6 - most examples have asterisks on all attributes, reduce 
number of asterisks -------
In section 5.5 Examples, nearly all examples including the use of the 
asterisk has the asterisk on all attribute lines in the whole SDP, even 
if it is sufficient to have it on one attribute. I think this might have 
confused the reviewers and caused some of the thoughts about assumed 
grouping and linking and wondering about semantic rules around the 
asterisk that was not intended by the draft.
--------Proposed action for Issue 6------------
Delete some of the asterisks in the examples in section 5.5, so that 
only one example has asterisks on all attributes and the others have 
just one or a varying number of asterisks.
--------End of issue 6-----------------------------------

--------Issue 7  Missing link to 'hlang-value' in the syntax section 
6.1-------------------

I suggest to insert a line in two places to link the attribute to the 
'hlang-value' syntax description, matching the format used in rfc4566bis.

------Old text in two places in section 6.1--------

  Attribute Syntax:

--------New text in two places in section 6.1-----

   Value: hlang-value
   Attribute Syntax:

---------End of Issue 7.----------------

Regards
Gunnar

Den 2017-06-24 kl. 01:46, skrev [email-masked]:
> _______________________________________________
> SLIM mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/slim

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[email-masked]

---

From: Randall Gellens <[email-masked]>
Date: Thu, 29 Jun 2017 20:15:11 -0700

At 11:30 AM +0200 6/26/17, Gunnar Hellström wrote:

>  Good to see progress.
>
>  I checked the numbered change proposals I 
> submitted earlier under subject " I-D Action: 
> draft-ietf-slim-negotiating-human-language-10.txt" 
> and found that most of them were solved or 
> agreed to be ignored. Only proposal 2.2 was not 
> acted on, so I repeat it here together with a 
> few new findings:
>
>  -----Issue 1, old 2.2 The attributes can appear 
> in both offers and answers -----------
>  This paragraph is an introduction to the 
> attributes. It should mention the full use, in 
> both offer and answer. The following paragraphs 
> tell about specifics for offer vs answer.
>  --End of change 2.2---
>

Yes, I agree.

>
>  ------Issue 2 , reduce info on possible 
> extensions to not be solution specific----------
>
>  In section 5.2, middle:
>
>     Note that separate work may introduce 
> additional information regarding 
> language/modality
>     preferences among media.
>
>  ---Reasoning: ---------
>  Two ways to convey language/modality 
> preferences among media have been proposed, one 
> based on the asterisk 
> (draft-hellstrom-slim-modalitypref), and 
> another based on the SDP gouping framework 
> (draft-hellstrom-language-grouping). There are 
> drafts for both. The clean one seems to be the 
> method based on SDP grouping. It has no known 
> interoperability problems.
>   The proposed wording of the note (as a 
> separate paragraph) is intended to cover both 
> methods, but has less effect as a warning 
> against interoperabitlity problems caused by 
> the asterisk based solution.
>
>  A decision is needed for which alternative to 
> continue with, I prefer the one based on SDP 
> grouping.
>
>
>

I will go back to my original wording, which I 
think was specific enough to give readers of this 
document a hint to read yours, and general enough 
to not constrain your document:

     "uses the asterisk (or lack thereof) to 
convey additional information between endpoints."

>  -----end of issue 3------

Thanks.

>  The second example in 5.5 has asterisks last in 
> the attributes and says that the example can be 
> either an offer or an answer.

That's an error, thanks for catching it.  It should say "an offer".

>
>  But section 5.2, fourth paragraph currently 
> only says that the asterisk can appear in an 
> offer.

It doesn't prohibit an asterisk in an answer, but 
it only defines the meaning of an asterisk in an 
offer.  I suggest we leave it this way.  Your 
draft can then define the meaning of an asterisk 
in an offer.  Note that the ABNF defining the 
syntax does not differentiate between an offer 
and an answer, hence, an asterisk is technically 
permitted in an answer.  For clarity, I will add 
to 5.2:

     An asterisk appended to any value in any media in an answer is undefined.

>
>  I suggest to amend this by allowing the 
> asterisk to appear in an answer, but not assign 
> any meaning to it.
>  This is more future proof and may make 
> implementation of the answering part easier 
> than keeping the currect restriction.
>
>  The asterisk token MAY also be appended last in 
> a 'hlang' attribute in an answer, but this 
> specification does not define any meaning to an 
> asterisk in that position.
>   ----Issue 5 correct SDP syntax in answer 
> example on page 10 -------------------
>  In the answer example in section 5.5 on page 
> 10, the answer shows no video m-line. There was 
> an m-lne for video in the offer, then one must 

Thanks.

>
>  --------Issue 6 - most examples have asterisks 
> on all attributes, reduce number of asterisks 
> -------
>  In section 5.5 Examples, nearly all examples 
> including the use of the asterisk has the 
> asterisk on all attribute lines in the whole 
> SDP, even if it is sufficient to have it on one 
> attribute. I think this might have confused the 
> reviewers and caused some of the thoughts about 
> assumed grouping and linking and wondering 
> about semantic rules around the asterisk that 
> was not intended by the draft.
>  Delete some of the asterisks in the examples in 
> section 5.5, so that only one example has 
> asterisks on all attributes and the others have 

OK.

>
>  --------Issue 7 Missing link to 'hlang-value' 
> in the syntax section 6.1-------------------
>
>  I suggest to insert a line in two places to 
> link the attribute to the 'hlang-value' syntax 
> description, matching the format used in 
> rfc4566bis.
>

OK.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Invention is the mother of necessity.       --Thorstein Veblen

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 30 Jun 2017 08:09:56 +0200

Randall,
All your resolutions are fine except for Issue 2. See explanation below.

Den 2017-06-30 kl. 05:15, skrev Randall Gellens:
>> subject " I-D Action: 
>> draft-ietf-slim-negotiating-human-language-10.txt" and found that 
>> most of them were solved or agreed to be ignored. Only proposal 2.2 
>> was not acted on, so I repeat it here together with a few new findings:
>>
>>  This paragraph is an introduction to the attributes. It should 
>> mention the full use, in both offer and answer. The following 
>> paragraphs tell about specifics for offer vs answer.
>>  --End of change 2.2---
>>
>>  ------Issue 2 , reduce info on possible extensions to not be 
>> solution specific----------
>>
>>  In section 5.2, middle:
>>
>>  Two ways to convey language/modality preferences among media have 
>> been proposed, one based on the asterisk 
>> (draft-hellstrom-slim-modalitypref), and another based on the SDP 
>> gouping framework (draft-hellstrom-language-grouping). There are 
>> drafts for both. The clean one seems to be the method based on SDP 
>> grouping. It has no known interoperability problems.
>>   The proposed wording of the note (as a separate paragraph) is 
>> intended to cover both methods, but has less effect as a warning 
>> against interoperabitlity problems caused by the asterisk based 
>> solution.
>>
>>  A decision is needed for which alternative to continue with, I 
>> prefer the one based on SDP grouping.
>>
>>
>>
> I will go back to my original wording, which I think was specific 
> enough to give readers of this document a hint to read yours, and 
> general enough to not constrain your document:
>
>     "uses the asterisk (or lack thereof) to convey additional 
> information between endpoints."
I need the whole sentence to understand the proposal. Do you mean:

"Note that separate work [I-D.hellstrom-slim-modalitypref] extends the 
use of the asterisk (or lack thereof) to
    convey additional information between endpoints."

Or did you mean:

  "Note that separate work extends the use of the asterisk (or lack 
thereof) to
    convey additional information between endpoints."

Anyway, both are currently wrong. I have submitted two alternative 
drafts for the modality preference indication, one adding meaning to the 
asterisk (draft-hellstrom-slim-modalitypref) and the other using SDP 
grouping instead, not touching the asterisk 
(draft-hellstrom-language-grouping). I prefer the SDP grouping proposal, 
but want to hear others' views.  When we have a decision, I will let one 
of them expire and we can sharpen up the note if the draft is still open 
for modifications.

So, at the moment, it is only my proposed wording in a separate note as 
shown above in issue 2 that works.

>>  The second example in 5.5 has asterisks last in the attributes and 
>> says that the example can be either an offer or an answer.
>
> It doesn't prohibit an asterisk in an answer, but it only defines the 
> meaning of an asterisk in an offer.  I suggest we leave it this way.  
> Your draft can then define the meaning of an asterisk in an offer.  
> Note that the ABNF defining the syntax does not differentiate between 
> an offer and an answer, hence, an asterisk is technically permitted in 
> an answer.  For clarity, I will add to 5.2:
>
>>  I suggest to amend this by allowing the asterisk to appear in an 
>> answer, but not assign any meaning to it.
>>  This is more future proof and may make implementation of the 
>> answering part easier than keeping the currect restriction.
>>
>>  The asterisk token MAY also be appended last in a 'hlang' attribute 
>> in an answer, but this specification does not define any meaning to 
>> an asterisk in that position.
>> video m-line. There was an m-lne for video in the offer, then one 
>> must be included in the aswer.
>>
>>  ---old text in 5.5----
>>  --------Issue 6 - most examples have asterisks on all attributes, 
>> reduce number of asterisks -------
>>  In section 5.5 Examples, nearly all examples including the use of 
>> the asterisk has the asterisk on all attribute lines in the whole 
>> SDP, even if it is sufficient to have it on one attribute. I think 
>> this might have confused the reviewers and caused some of the 
>> thoughts about assumed grouping and linking and wondering about 
>> semantic rules around the asterisk that was not intended by the draft.
>>  I suggest to insert a line in two places to link the attribute to 
>> the 'hlang-value' syntax description, matching the format used in 
>> rfc4566bis.
>>
Thanks,
Gunnar

+46 708 204 288

---

From: Randall Gellens <[email-masked]>
Date: Fri, 30 Jun 2017 06:15:19 -0700

>  All your resolutions are fine except for Issue 2. See explanation below.

OK, new wording:

    Note that separate work may introduce additional information
    regarding language/modality preferences among media.

Note that there is no longer a reference to the draft.

>>> agreed to be ignored. Only proposal 2.2 was 
>>> not acted on, so I repeat it here together 
>>> with a few new findings:
>>>
>>>   -----Issue 1, old 2.2 The attributes can 
>>> appear in both offers and answers -----------
>>> attributes. It should mention the full use, 
>>> in both offer and answer. The following 
>>> preferences among media have been proposed, 
>>> one based on the asterisk 
>>> (draft-hellstrom-language-grouping). There 
>>> are drafts for both. The clean one seems to 
>>> be the method based on SDP grouping. It has 
>>> no known interoperability problems.
>>>   A decision is needed for which alternative 
>>> to continue with, I prefer the one based on 
>>> SDP grouping.
>>>
>>>
>>>
>> think was specific enough to give readers of 
>> this document a hint to read yours, and 
>  "Note that separate work 
> [I-D.hellstrom-slim-modalitypref] extends the 
>   "Note that separate work extends the use of 
> the asterisk (or lack thereof) to
>  Anyway, both are currently wrong. I have 
> submitted two alternative drafts for the 
> modality preference indication, one adding 
> meaning to the asterisk 
> (draft-hellstrom-slim-modalitypref) and the 
> other using SDP grouping instead, not touching 
> the asterisk 
> (draft-hellstrom-language-grouping). I prefer 
> the SDP grouping proposal, but want to hear 
> others' views.  When we have a decision, I will 
> let one of them expire and we can sharpen up 
> the note if the draft is still open for 
> modifications.
>
>  So, at the moment, it is only my proposed 
> wording in a separate note as shown above in 
> issue 2 that works.
>
>
>
>>
>>>
>>>   ----Issue 4  allow asterisks also in 
>>> answers, but do not assign a meaning---------
>>>   The second example in 5.5 has asterisks last 
>>> in the attributes and says that the example 
>>> can be either an offer or an answer.
>>
>>  It doesn't prohibit an asterisk in an answer, 
>> but it only defines the meaning of an asterisk 
>> in an offer.  I suggest we leave it this way. 
>> Your draft can then define the meaning of an 
>> asterisk in an offer.  Note that the ABNF 
>> defining the syntax does not differentiate 
>> between an offer and an answer, hence, an 
>> asterisk is technically permitted in an 
>> answer.  For clarity, I will add to 5.2:
>>
>>> asterisk to appear in an answer, but not 
>>> assign any meaning to it.
>>>   The asterisk token MAY also be appended last 
>>> in a 'hlang' attribute in an answer, but this 
>>> specification does not define any meaning to 
>>> 10, the answer shows no video m-line. There 
>>> was an m-lne for video in the offer, then one 
>>>   --------Issue 6 - most examples have 
>>> asterisks on all attributes, reduce number of 
>>> asterisks -------
>>> SDP, even if it is sufficient to have it on 
>>> one attribute. I think this might have 
>>> confused the reviewers and caused some of the 
>>> thoughts about assumed grouping and linking 
>>> and wondering about semantic rules around the 
>>>   Delete some of the asterisks in the examples 
>>> in section 5.5, so that only one example has 
>>> asterisks on all attributes and the others 
>>> have just one or a varying number of 
>>> asterisks.
>>> link the attribute to the 'hlang-value' 
>>> syntax description, matching the format used 
>>> in rfc4566bis.
>>>

-------------- Randomly selected tag: ---------------
Please ignore previous fortune.

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 30 Jun 2017 15:37:41 +0200

>    regarding language/modality preferences among media.
Fine.
> Note that there is no longer a reference to the draft.
Yes, since there are currently two drafts with competing solutions, I 
think it is better to not reference them.

The new drafts have been available for 18 days now, and I have not got 
any substantial feedback. That is not promising for the progress, and 
not what I expected when I accepted to make separate drafts for the 
functionality that will add substantial usability to 
draft-ietf-slim-negotiating-human-language.

>>>>   -----Issue 1, old 2.2 The attributes can appear in both offers 
>>>> and answers -----------
>>  "Note that separate work [I-D.hellstrom-slim-modalitypref] extends 
>> the use of the asterisk (or lack thereof) to
>> drafts for the modality preference indication, one adding meaning to 
>> the asterisk (draft-hellstrom-slim-modalitypref) and the other using 
>> SDP grouping instead, not touching the asterisk 
>> (draft-hellstrom-language-grouping). I prefer the SDP grouping 
>> proposal, but want to hear others' views.  When we have a decision, I 
>> will let one of them expire and we can sharpen up the note if the 
>> draft is still open for modifications.
>>
>>  So, at the moment, it is only my proposed wording in a separate note 
>> as shown above in issue 2 that works.
>>
>>
>>
>>>
>>>>
>>>>   The second example in 5.5 has asterisks last in the attributes 
>>>> and says that the example can be either an offer or an answer.
>>>
>>>  It doesn't prohibit an asterisk in an answer, but it only defines 
>>> the meaning of an asterisk in an offer.  I suggest we leave it this 
>>> way. Your draft can then define the meaning of an asterisk in an 
>>> offer.  Note that the ABNF defining the syntax does not 
>>> differentiate between an offer and an answer, hence, an asterisk is 
>>> technically permitted in an answer.  For clarity, I will add to 5.2:
>>>
>>>>   The asterisk token MAY also be appended last in a 'hlang' 
>>>> attribute in an answer, but this specification does not define any 
>>>> meaning to an asterisk in that position.
>>>>   In the answer example in section 5.5 on page 10, the answer shows 
>>>> no video m-line. There was an m-lne for video in the offer, then 
>>>> one must be included in the aswer.
>>>>
>>>>   ---old text in 5.5----
>>>>   Delete some of the asterisks in the examples in section 5.5, so 
>>>> that only one example has asterisks on all attributes and the 
>>>> others have just one or a varying number of asterisks.
>>>>   --------Issue 7 Missing link to 'hlang-value' in the syntax 
>>>> section 6.1-------------------
>>>>
Gunnar