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

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

Den 2017-02-23 kl. 05:15, skrev Randall Gellens:
> Version -07 addresses all comments except for the unresolved issue of 
> renaming the two attributes which is currently being discussed on the 
> list, and adding a new attribute for bidirectionality.
>
> Per Dale's suggestion, the draft adds advice that if a call is 
> rejected due to no languages in common, SIP response code 488 (Not 
> Acceptable Here) or 606 (Not Acceptable) be used, along with a Warning 
> header field indicating the supported languages.  The draft registers 
> a new entry in the warn-code sub-registry of SIP parameters for this 
> purpose.  The draft also has an expanded set of examples.
>
Good progress. Good to see the enriched examples chapter 5.5.
I have a few comments on version -07:

1.  Section  4. second line
------------old text----------------------
but is not sufficiently sufficiently
------------new text--------------------------
but is not sufficiently
----------end of change 1-----------------
Motivation: New typo in version -07

2. Section 5.2, first line
----------------old text-----------------
This document defines two new media-level ..
----------------new text----------------------
This document defines two media-level ...
----------------end of change 2----------------
Motivation: It was commented that when the draft is published, this is 
not new anymore.
There are three more occasions of "new" in the document that may be 
modified as well.

3.  5.2 second paragraph
-------------------old text--------------------------------
In an offer, the 'humintlang-send' values indicates the language(s)
    the offerer is willing to use when sending using the media, and the
    'humintlang-recv' values indicates the language(s) the offerer is
    willing to use when receiving using the media.
-----------------new text---------------------------------
In an offer, the 'humintlang-send' values indicate the language(s)
the offerer is willing to select from for use when sending using the
media, and the 'humintlang-recv' values indicate the language(s) the
offerer is willing to receive one of in the media stream.
----------------end of change----------------------------------
Motivation 1:) change from "indicates" to "indicate" in two places to 
match the new use of plural "values".
Motivation 2:) Be sure to indicate that we only intend to negotiate one 
language per media and direction, so that we do not end up as 
unspecified regarding number of matches required as the sdp "lang" 
attribute is.

4.  5.2 Second paragraph
-----------------old text-----------------------
When a media is intended
    for use in one direction only
----------------new text---------------------
When a media is intended
    for use for language communication in one direction only
----------------end of change---------------------------
Motivation: Deletion of a note in this sentence made it less obvious 
that we are only talking about directions of use of language 
communication, and not about establishing asymmetric media connections. 
Therefore add this clarification.

5.  5.2 Deleted paragraph 6 before "Clients acting on behalf..."
----------reinsert modified paragraph----------------------------
While signed language tags are used with a video stream to
indicate sign language, a spoken language tag for a video stream
indicates a request or offer to see the speaker, when that is of
importance for language perception.
-------------end of change-------------------------------------------
Motivation: There was in the LC mail exchange a discussion about 
sharpening up the specification of use of "unusual combinations".
There was no agreement to delete them all. The one described in this 
paragraph is the main one that has widespread use and needs to be 
clearly specified for use by a large number of hard-of-hearing and deaf 
users.

6.  5.2 Sixth paragraph
--------------------current text--------------------
(or for unidirectional streams, one of)
------------------new text ------------------------
(or for asymmetrical use of languages, one of)
-----------------end of change----------------------
Motivation: We are not primarily talking about enabled transmission 
directions of the streams, but about language use in the streams. We do 
not want to limit the media stream directions just because we do not 
specify an initial language to use for that direction. There are other 
usage of media, and there may even be occasional use of language in the 
direction, just not worth mentioning as an initial and preferred use. 
The suggested change should make that clear.

7.   5.3 Next to last paragraph
------------------old text------------------------------
a list of supported languages.
-------------------new text-------------------------
a list of supported languages, media and directions.
-------------------end of change----------------
Motivation: It is not sufficient to know which languages are supported, 
it is also essential to know in which media they are supported and in 
which directions. (media could be replaced with modality, but the media 
can become ambigous then, so use media here to be brief.

8.      5.3, last line
--------------old text----------------------------------
  Supported languages are: es, en"
--------------new text-------------------------------
  Supported languages are: es, en transmission in audio; es, en 
reception in audio"
----------------------------------------------------------
Motivation: Same as for 7.

9.  5.4 Undefined combinations
----------------------------old text--------------------------------------
    The behavior when specifying a non-signed language tag for a video
    media stream, or a signed language tag for an audio or text media
    stream, is not defined.
---------------------------new text-----------------------------------------
There is no way specified for indicating use of text based language in a 
video media stream.
There is no meaning assigned to specification of  sign language in an 
audio or text media stream.
--------------------------end of change-------------------------------
Motivation: Seeing the speaker in video is an important combination 
reinserted above in section 5.2.
This section therefore needed rewording to not include that combination.


10.     6.2 Last sentence
-----------------current text---------------------
Supported languages are: [list of supported languages]."
-----------------new text------------------------
Supported languages and media and transmission directions are:[list of 
supported languages and media and transmission directions.]"
-----------------end of change--------------------------
Motivation: Same as for 7.

11.  6.1 MUX Category
----------old text in two locations-------------------
MUX Category:  normal
---------new text in same two locations--------------
Mux Category:  NORMAL
---------end of change-----------------
Motivation: Follow RFC 4566bis and IANA habits regarding use of capitals

12.  5.3
-------------old text-----------------
5.3 No Language in Common
-------------new text----------------
5.3 Preference parameter
------------end of change 1 in 5.3---------------

-------------old text-in 5.3, second 
paragraph-------------------------------
The mechanism for indicating this preference is that, in an offer, if
the last character of any of the 'humintlang-recv' or 'humintlang-
send' values is an asterisk, this indicates a request to not fail the call.
--------------------------new text-------------------------------
The mechanism for indicating this preference is that, in an offer, if
    the last character of any of the 'humintlang-recv' or 'humintlang-
    send' values is an asterisk, this indicates a request to not fail 
the call.
The asterisk should be attached to attributes with languages of lower
preference to be matched if such difference can be specified. Thereby
the location of the asterisk can be used to support the decision on
which languages to use in the call.
---------------------------end of change 2 in 
5.3--------------------------------------
Motivation: There has not yet been any conclusion for my proposal no 5 
in the IETF LC comments of Feb 12.
This is a dramatically reduced version that may be easier to accept at 
this stage, still covering one of the missing functionalities in the draft.
The asterisk is used as a preference parameter in the attributes. 
Thereby the proposed title change on 5.3
With this additional rule about where the asterisk(s) are placed, the 
answering parties get good clues about the preferences between 
alternatives presented by the offeror. The chance to set up calls with 
satisfied users increase dramatically compared to letting the answering 
party select by chance between alternatives.

Regards

Gunnar

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