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

[Randall Gellens <[e-mail]>]

At 5:35 PM +0100 2/24/17, Gunnar Hellström wrote:

>  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

Thanks.

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

OK.

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

Reworded.

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

Reworded.

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

The text as it is now does not prohibit anything 
and explicitly mentions negotiating supplemental 
video by omitting language attributes on a video 
media.

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

I don't know that we can require this, but I'll 
add SHOULD kist supported languages and media. 
Demanding direction as well might be too unwieldy.

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

Fixed as above.

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

The draft explicitly mentions video for supplemental purposes.

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

Fixed as above.

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

Fixed.

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

The section is more than just the asterisk, it 
also advises use of specific SIP response codes 
if the call is failed.


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

Making the asterisk a purely-advisory hint as to 
the least-preferred media/language combination 
seems harmless enough, as it would not be 
required to support it; however, I'm not sure it 
provides any benefit: if an offer contains some 
set of media with language, and the answerer can 
support all of them, should the answerer only 
include in its answer those without an asterisk? 
It seems simpler for the answerer to include 
everything in the offer that it can support.


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
The great Chinese philosopher Confucius wrote, "When words lose their
meaning, the universe crumbles."  Theologically and cosmologically, I'm
not sure about that.  I am sure that when our government is
characterized as "amoral, godless and secularist," our public schools
as "failures" and our judges as "tyrants," simplistic solutions
promoted by demagogues will seem appropriate.
-- Barry Lynn,
   Executive Director of
   Americans United for Separation of Church and State