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

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

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 [e-mail]:
> 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/
>
> _______________________________________________
> SLIM mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/slim

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[e-mail]