Re: [Slim] Ben Campbell's Yes on draft-ietf-slim-negotiating-human-language-22: (with COMMENT)

[Randall Gellens <[e-mail]>]

It was Ben who asked about it.  I don't think we need to add more text.

--Randall

At 11:35 PM +0100 1/10/18, Gunnar Hellström wrote:

>  I saw a question somewhere but lost track of who asked it.
>
>  It was about if the users are bound to use only 
> the negotiated language(s) in the session.
>
>  I think a line about that should be inserted, 
> probably best close to the end of the 
> introduction.
>
>  Proposed text:
>  "The result of the negotiation is intended to 
> guide the selection of language(s) to use 
> initially and during the session. However, 
> nothing prevents the users from varying the use 
> of languages and media by mutual agreement 
> after the initial exchange during the call."
>
>  Gunnar
>
>
>  Den 2018-01-10 kl. 17:12, skrev Randall Gellens:
>>  At 8:21 PM -0800 1/9/18, Ben Campbell wrote:
>>
>>>   I'm balloting "yes" because I think this is 
>>> important work, but I have some
>>>   comments:
>>>
>>>   Substantive Comments:
>>>
>>>   - General: It seems to be that this is as 
>>> much about human behavior as it is
>>>   capabilities negotiating. Example case: I 
>>> make a video call and express that I
>>>   would like to receive Klingon. (Is there a 
>>> tag for that ? :-) The callee can
>>>   speak Klingon and Esperanto, so we agree on 
>>> Klingon. What keeps the callee from
>>>   speaking Esparanto instead?
>>
>>  There is a language tag for Klingon: "tlh".
>>
>>  The draft is not trying to even capture the 
>> full complexity of human language interaction, 
>> much less enforce it.  The draft provides a 
>> fairly simple mechanism to make it more likely 
>> that successful communication can occur, by 
>> identifying language needs (which can allow 
>> endpoints to take potentially required 
>> additional steps, such as bridging in 
>> translation or relay services, or having a 
>> call handled by someone who known the 
>> language(s) or can use the needed media).
>>
>>>   I realize we can't force people to stick to the negotiated languages--but
>>>   should we expect that users should at least 
>>> be given some sort of UI indication
>>>   about the negotiated language(s)? It seems like a paragraph or two on that
>>>   subject is warranted, even if it just to say it's out of scope.
>>
>>  I will add to the Introduction the following text:
>>
>>     This document does not address user interface (UI) issues, such as if
>>     or how a UE client informs a user about the result of language and
>>     media negotiation.
>>
>>>   -1, paragraph 6:  (related to Ekr's 
>>> comments) Does the selection of a single
>>>   tag in an answer imply  an assumption only 
>>> one language will be used? There are
>>>   communities where people tend to mix 2 or 
>>> more languages freely and fluidly. Is
>>>   that sort of thing out of scope?
>>
>>  Earlier versions of the draft had more 
>> explicit text that the draft did not attempt 
>> to capture the full range of human language 
>> issues, including the common practice among 
>> multilingual people of mixing languages.
>>
>>  The draft currently says:
>>
>>     (Negotiating multiple simultaneous languages within a media stream is
>>     out of scope of this document.)
>>
>>  There was text in a version of the draft as of February 2013 that said:
>>
>>     (While it is true that a conversation among multilingual people often
>>     involves multiple languages, it does not seem useful enough as a
>>     general facility to warrant complicating the desired semantics of the
>>     SDP attribute to allow negotiation of multiple simultaneous languages
>>     within an interactive media stream.)
>>
>>  I do not recall the reasons why the text was 
>> simplified, removing mention of multilingual 
>> people, and would have to search through 
>> minutes of the various WG sessions and email 
>> in 2013 where the draft was discussed.  I 
>> suspect there was desire to have the draft 
>> merely state what it does and doesn't do, and 
>> not get into a lot of value judgment 
>> discussion.
>>
>>>   - 5.1, paragraph 2:  Can you elaborate on 
>>> the motivation to have a separate
>>>   hlang-send and hlang-recv parameter vs 
>>> having a single language parameter and
>>>   instead setting the stream to send or 
>>> receive only, especially in light of the
>>>   recommendation to set both directions the same for bi-directional language
>>>   selection? I don't mean to dispute that approach; I just think a bit more
>>>   explanation of the design choice would be 
>>> helpful to the reader.  I can imagine
>>>   some use cases, for example a 
>>> speech-impaired person who does not plan to 
>>> speak
>>>   on a video call may still wish to send video 
>>> to show facial expressions, etc.
>>>   (I just re-read the discussion resulting 
>>> from Ekr's comments, and recognize
>>>   that this overlaps heavily with that.)
>>
>>  As you suggest, a media might be desired in 
>> both directions even though only one direction 
>> is primarily intended for interactive 
>> communication.  The draft currently says:
>>
>>     When a media is intended for interactive communication
>>     using a language in one direction only (e.g., a user with difficulty
>>     speaking but able to hear who indicates a desire to send using text
>>     and receive using audio), either hlang-send or hlang-recv MAY be
>>     omitted.  When a media is not primarily intended for language (for
>>     example, a video or audio stream intended for background only) both
>>     SHOULD be omitted.  Otherwise, both SHOULD have the same value.  Note
>>     that specifying different languages for each direction (as opposed to
>>     the same or essentially the same language in different modalities)
>>     can make it difficult to complete the call (e.g., specifying a desire
>>     to send audio in Hungarian and receive audio in Portuguese).
>>
>>  I will add "Note that the media can still be 
>> useful in both directions."  The text thus 
>> becomes:
>>
>>     When a media is intended for interactive communication
>>     using a language in one direction only (e.g., a user with difficulty
>>     speaking but able to hear who indicates a desire to send using text
>>     and receive using audio), either hlang-send or hlang-recv MAY be
>>     omitted.  Note that the media can still be useful in both directions.
>>     When a media is not primarily intended for language (for example, a
>>     video or audio stream intended for background only) both SHOULD be
>>     omitted.
>>
>>>   -5.1, paragraph 3: "... which in most cases is one of the
>>>      languages in the offer's..."
>>>   Are there cases where it might not?
>>
>>  Yes, it could happen.  For example, if an 
>> emergency call comes into a PSAP and requests 
>> languages that the PSAP is unable to support, 
>> the PSAP will likely want the call to proceed 
>> anyway. It's also possible that the callee 
>> might support a language that has some degree 
>> of mutual comprehensibility to those requested 
>> by the caller.  An example might be some 
>> Scandinavian languages where the caller does 
>> not include a language that is similar enough 
>> to have some comprehension but not be fluent 
>> enough to include in the UE configuration.
>>
>>>   -5.1, last paragraph: "This is not a problem."
>>>   Can you elaborate? That sort of statement 
>>> usually takes the form "This is not a
>>>   problem, because..."
>>
>>  The caller and callee are free to use any of 
>> the established media streams.  If a caller 
>> requests audio, video (with a sign language), 
>> and text, and all three are established, the 
>> caller might ignore the text or audio stream 
>> and use only the video stream.
>>
>>>   -5.2, last paragraph: Is there a reason to 
>>> give such weak guidance on how to
>>>   indicate the call is rejected?  (Along those 
>>> lines, are non-SIP uses of SDP in
>>>   scope?)
>>
>>  No one made a case for why mandating a 
>> particular rejection code was necessary, 
>> especially since the draft does not offer any 
>> suggestion as to if a call should proceed or 
>> fail when there aren't mutually supported 
>> languages.
>>
>>>
>>>   Editorial Comments and Nits:
>>>
>>>   -5.1, paragraph 4: The first MUST seems like a statement of fact.
>>
>>  You mean this sentence:
>>
>>     In an offer, each value MUST be a list of one or more language tags
>>     per BCP 47 [RFC5646], separated by white space.
>>
>>  The MUST makes sure that the values are IANA-registered language tags.
>>
>
>  --
>  -----------------------------------------
>  Gunnar Hellström
>  Omnitor
>  [e-mail]
>  [phone]
>
>  _______________________________________________
>  SLIM mailing list
>  [e-mail]
>  https://www.ietf.org/mailman/listinfo/slim


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
The attention span of a computer is only as long as its electrical cord
or battery life.