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

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

Randall,

Fine, I find that we have only issues 5, 6 and 12 still to discuss.

You did not answer issue 6, use of asymmetrical language rather than 
unidirectional media. I assume you accepted it.

On 5, the request to reinsert wording about seeing the speaker in video, 
it is still a huge difference in specifying a preference to see the 
speaker for language perception reasons, versus only specifying that I 
want a video stream for supplementary purposes. With the current wording 
in version -07, section 5.3 says that that combination is undefined. 
Nothing in the LC discussion indicated that it should be undefined. Why 
did you suddenly want to delete it? It is useful. Please reinsert with 
the wording changes I propose.

On 12, the meaning of the placement of the asterisk, you ask:
"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."

The answering party should aim at answering with one of the languages 
that is without the asterisk in the offer. Only if the answering party 
does not have capability in a language without an asterisk, one with 
asterisk should be selected. Thereby you get the best opportunity to 
start the call in a language combination that satisfies both users.

Example: A hard-of-hearing user can just barely conduct spoken calls 
with persons she knows. From others it is much more reliable to get 
text.  She calls and declares:

m=audio
a=huml-send:en
a=huml-recv:en*
m=text
a=huml-recv:en

The answering party with text capabilities sees that matching text for 
sending is higher preferred than talking, and thus  responds:

m=audio
a=huml-recv:en
m=text
a=huml-send:en

The answering party sends the initial greeting in text and the call 
continues smoothly in well managed langauage/modality combinations.

Another called party may not have text capabilities, and may therefore 
select the less favoured alternative with using speech both ways, answering:

m=audio
a=huml-recv:en
a=huml-send:en
m=text 0

The answering party starts taking and the parties try as well as 
possible to manage the call in this less preferred combination that may 
be less reliable.

If the placement of the asterisk had no special meaning as it is in 
version -07, it is a high risk that the answering party in the first 
example would select to answer with spoken language that would be 
unreliably received. Time and effort would be spent by speech to make 
the answering party switch to sending text instead of talking in order 
to arrange for a more reliable call situation.

If instead the caller only indicated the most favoured combinations,

m=audio
a=huml-send:en
m=text
a=huml-recv:en

Then the answering parties without text capability would not dare to try 
to answer, and a reasonably successful call would be missed.

Many other similar realistic examples can be created, where placement of 
the asterisk(s) would be a sufficient indication of lower preference for 
language match among alternatives that would make call establishment 
successful and smooth in many more cases than without this indication 
opportunity.

Do you want more examples?

Please accept proposal 12.

Regards

Gunnar







Den 2017-02-25 kl. 01:32, skrev Randall Gellens:
> 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.
>
>

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