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

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

Den 2018-01-11 kl. 16:43, skrev Bernard Aboba:
> Randall said:
>
> "Choosing among language and modality will often require trade-offs.  
> A call may indicate audio with Spanish (most preferred), Italian 
> (second choice), and English.  If the call is received by a PSAP that 
> has call takers who natively speak English but can bridge in Spanish 
> translation, accepting English forces the caller to use a 
> less-preferred language while accepting Spanish forces the call 
> through translation, which makes the communication slower and 
> typically more difficult, as well as adding cost to the PSAP.  If we 
> add modality choice into the mix, it becomes more complex, with 
> trade-offs. Further, in the example, if the PSAP indicates Spanish in 
> the answer, then it will bridge in translation services, while if if 
> indicates English, it won't; so if it indicates English, it wouldn't 
> also indicate Spanish, even if the syntax permitted it."
>
> [BA] That makes sense - if putting in secondary languages would 
> require distinct resources to be allocated then the callee might 
> choose not to.  But I'm wondering if there are circumstances in which 
> it might be valuable for the Answer to return more than one language, 
> indicating all the capabilities of the callee endpoint. For example, a 
> call indicating Spanish (most preferred) and English (second choice) 
> might be routed to a dispatcher who is bi-lingual in Spanish and 
> English.The Answer could include just Spanish, but if the callee is 
> bi-lingual and can switch languages on request without having to 
> bridge in a translator, why can't the Answer include Spanish (primary) 
> and English (secondary)?

<GH>There is one reason for the answerer to only provide one language in 
only one media for hlang-send.
-That is to better prepare the offeror exactly for the language and 
modality the offerer will receive.

But the discussion we have had now has revealed a number of reasons to 
allow more than one.
-Less complexity for the negotiation application. Decision can more 
easily be taken by the application without asking the user.
-Possibility to provide all supported alternatives when there is no 
match. That increases opportunity to find some anyway usable language.
-Prepare for feasible language switch during the call when the initial 
selection did not work well.
-Inform offeror of the options if translating resources will be brought 
in by the offeror after completed negotiation.
-Multiple languages in use.

If we just allow more than one language per media and direction in the 
answer, we do not need to have any normative wording for how the 
application handles it. Those who prefer to send just one language per 
media and direction do so, and those who see value in providing more 
info do.
OK?


>
>
> On Thu, Jan 11, 2018 at 7:24 AM, Randall Gellens 
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     At 8:59 PM -0800 1/10/18, Bernard Aboba wrote:
>
>          Gunnar said:
>
>          ""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.""
>
>          [BA] This came from Ben Campbell, but other ADs with many
>         years of experience in realtime communications have asked
>         questions along similar lines.  So it seems that even
>         experienced readers could use some clarification.
>
>          The reason for the language selection negotiation is to
>         enable the right individuals and resources to be brought into
>         the conversation so as to maximize the changes of successful
>         communications. What happens once the call is brought up is up
>         to the conversants.
>
>
>     [RG] We can text along the lines of the above paragraph, as a
>     clarification.
>
>
>          The precise meaning of the negotiation depends in part on the
>         choice of a single language or multiple languages in the Answer.
>
>          If an offer indicates the ability to receive English and
>         French, if an Answer can only contain a single language, then
>         an Answer indicating the ability to send English would
>         establish that the call is expected to be conducted in
>         English. That wouldn't necessarily preclude the use of French,
>         but doesn't provide any indication that it could be supported
>         as an alternative.
>
>          Whereas if the Answer was allowed to include multiple
>         languages and included both English and French, then the
>         Answer would indicate that the conversation could use either
>         language with a preference for English over French.  That does
>         strike me as potentially valuable in some circumstances (e.g.
>         a visitor from Spain with an emergency offering Spanish
>         primary and English secondary and being able to get an answer
>         indicating English with secondary Spanish support, rather than
>         just English).
>
>
>     [RG] Choosing among language and modality will often require
>     trade-offs.  A call may indicate audio with Spanish (most
>     preferred), Italian (second choice), and English.  If the call is
>     received by a PSAP that has call takers who natively speak English
>     but can bridge in Spanish translation, accepting English forces
>     the caller to use a less-preferred language while accepting
>     Spanish forces the call through translation, which makes the
>     communication slower and typically more difficult, as well as
>     adding cost to the PSAP.  If we add modality choice into the mix,
>     it becomes more complex, with trade-offs. Further, in the example,
>     if the PSAP indicates Spanish in the answer, then it will bridge
>     in translation services, while if if indicates English, it won't;
>     so if it indicates English, it wouldn't also indicate Spanish,
>     even if the syntax permitted it.
>
>
>          In either case, the conversants can switch languages by
>         mutual agreement.
>
>
>     [RG] Conversants are always free to use any language they like.
>
<GH>Yes, but the whole idea of the negotiation is that the result is of 
guidance for a smooth start of the call, so it is very desirable that 
the users obey the negotiation result initially.

Gunnar
>
>
>     --Randall
>
>
>
>          On Wed, Jan 10, 2018 at 2:35 PM, Gunnar Hellström
>         <<mailto:[e-mail]
>         <mailto:[e-mail]>>[e-mail]
>         <mailto:[e-mail]>> 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
>          <mailto:[e-mail]
>         <mailto:[e-mail]>>[e-mail]
>         <mailto:[e-mail]>
>          <tel:%2B46%20708%20204%20288>[phone]
>         <tel:%2B46%20708%20204%20288>
>
>
>
>          _______________________________________________
>          SLIM mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/slim
>         <https://www.ietf.org/mailman/listinfo/slim>
>
>
>
>     -- 
>     Randall Gellens
>     Opinions are personal;    facts are suspect;    I speak for myself
>     only
>     -------------- Randomly selected tag: ---------------
>     There is hardly anything in the world that some one cannot make a
>     little worse, and sell a little cheaper.  --John Ruskin (1819-1900)
>
>

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