Re: [Slim] Eric Rescorla's No Objection on draft-ietf-slim-negotiating-human-language-19: (with COMMENT)

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

Thanks Randall for providing your proposed wording.

I see a need for some small adjustments. See inline.


Den 2018-01-08 kl. 19:22, skrev Eric Rescorla:
> WFM. thanks
>
> -Ekr
>
>
> On Mon, Jan 8, 2018 at 10:10 AM, Randall Gellens 
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     At 9:57 AM -0800 1/8/18, Randall Gellens wrote:
>
>          At 9:48 AM -0800 1/8/18, Eric Rescorla wrote:
>
>               On Mon, Jan 8, 2018 at 9:41 AM, Randall Gellens
>             <<mailto:[e-mail]
>             <mailto:[e-mail]>>[e-mail]
>             <mailto:[e-mail]>> wrote:
>
>               At 5:56 PM -0800 1/7/18, Eric Rescorla wrote:
>
>                On Sun, Jan 7, 2018 at 5:22 PM, Randall Gellens
>             <<mailto:<mailto:[e-mail]
>             <mailto:[e-mail]>>[e-mail]
>             <mailto:[e-mail]>><mailto:[e-mail]
>             <mailto:[e-mail]>>[e-mail]
>             <mailto:[e-mail]>> wrote:
>
>                At 6:36 AM -0800 1/7/18, Eric Rescorla wrote:
>
>                 On Sat, Jan 6, 2018 at 7:31 PM, Bernard Aboba
>             <<mailto:<mailto:<mailto:[e-mail]
>             <mailto:[e-mail]>>[e-mail]
>             <mailto:[e-mail]>><mailto:[e-mail]
>             <mailto:[e-mail]>>[e-mail]
>             <mailto:[e-mail]>><mailto:<mailto:[e-mail]
>             <mailto:[e-mail]>>[e-mail]
>             <mailto:[e-mail]>><mailto:[e-mail]
>             <mailto:[e-mail]>>[e-mail]
>             <mailto:[e-mail]>> wrote:
>
>                 On Jan 6, 2018, at 6:55 PM, Eric Rescorla
>             <<mailto:<mailto:<mailto:[e-mail]
>             <mailto:[e-mail]>>[e-mail]
>             <mailto:[e-mail]>><mailto:[e-mail]
>             <mailto:[e-mail]>>[e-mail]
>             <mailto:[e-mail]>><mailto:<mailto:[e-mail]
>             <mailto:[e-mail]>>[e-mail]
>             <mailto:[e-mail]>><mailto:[e-mail]
>             <mailto:[e-mail]>>[e-mail] <mailto:[e-mail]>>
>             wrote:
>
>                 For disabled users, the capabilities may not be symmetric.
>
>
>                 But this is true for ordinary SDP as well. I might be
>             able to receive H.264 but not send it.
>
>
>                 [BA] Thanks. The draft should explain the reasoning.
>             IMHO the argument goes sonething like this:
>
>                 A pure recv/recv negotiation will not necessarily
>             disclose beforehand what special services are needed for
>             the call - services (e.g. ASL interpretation or RTT
>             handling) that could take time to acquire.
>
>                 Since the actual video media sent is not labelled as
>             ASL even if the answerer has ASL interpreters it can pull
>             in and therefore advertises in SDP ASL reception
>             capability in video, a recv/recv negotiation doesn't tell
>             the Answerer that the Offerer will need them, so the
>             Answerer may need to (frantically) arrange for ASL
>             interpretation after initial receipt of media. In an
>             emergency, that can chew up valuable time.
>
>
>                 Thanks. I think it would be helpful to put this logic
>             in the draft.
>
>
>                I am not clear on what logic we want to add to the
>             draft, or what about the draft this logic is explaining.
>
>
>                It would be helpful to explain in the draft why you
>             have deviated from the otherwise near-universal SDP
>             negotiation pattern of each side advertising what it accepts.
>
>
>               I'm not clear on what you're referring to.  Are you
>             talking about early offer versus late offer?  To my
>             understanding, the draft follows a typical offer/answer
>             model: the caller lists the media and languages it
>             supports, and the callee answers with the media and
>             languages it supports.
>
>
>               That's not what this draft does. The typical SDP pattern
>             is what you say here: that the offerer (which might or
>             might not be the caller) lists what it supports and the
>             answerer lists what it supports.
>               So, for instance, the offerer might list "VP8, H.264"
>             and the answerer might respond with "VP8, H.264", at which
>             point either side could use either codec (or intermix
>             them). What this draft does is have the offerer list what
>             it supports and the answerer picks exactly one. I
>             understood from the previous emails in the thread that the
>             reason for this design was so that each side then knew
>             exactly what languages would be used. However, as noted
>             upthread, this draft does not provide this function if
>             early media is used, because the media is delivered to the
>             offerer prior to receiving the answer, so the offerer is
>             in the same position as it would be with the typical
>             negotiation model.
>
>
>          Thanks, I think I understand your concern now.  You'd like
>         the draft to explain why the answer contains one language per
>         media stream, which is partly for provide knowledge so both
>         ends know what has been negotiated, but also because
>         supporting languages and/or modalities may require taking
>         extra steps, such as having a call handled by an agent who
>         speaks a requested language and/or can use a requested
>         modality, or bridging external translation or relay resources
>         into the call, etc.  The answerer indicates which additional
>         steps it is committing to.  These steps may or may not be in
>         place in time for early media.  I can add text explaining this
>         to the Introduction.
>
>
>
>     The third paragraph below is the additional text added to the
>     Introduction (the first two paragraphs are unchanged):
>
>        By treating language as another SDP attribute that is negotiated
>        along with other aspects of a media stream, it becomes possible to
>        accommodate a range of users' needs and called party
>     facilities.  For
>        example, some users may be able to speak several languages, but
>     have
>        a preference.  Some called parties may support some of those
>        languages internally but require the use of a translation
>     service for
>        others, or may have a limited number of call takers able to use
>        certain languages.  Another example would be a user who is able to
>        speak but is deaf or hard-of-hearing and and desires a voice stream
>        to send spoken language plus a text stream to receive written
>        language.  Making language a media attribute allows the standard
>        session negotiation mechanism to handle this by providing the
>        information and mechanism for the endpoints to make appropriate
>        decisions.
>
>        The term "negotiation" is used here rather than "indication"
>     because
>        human language (spoken/written/signed) can be negotiated in the
>     same
>        manner as media (audio/text/video) and codecs.  For example, if we
>        think of a user calling an airline reservation center, the user may
>        have a set of languages he or she speaks, with perhaps preferences
>        for one or a few, while the airline reservation center will
>     support a
>        fixed set of languages.  Negotiation should select the user's most
>        preferred language that is supported by the call center. Both sides
>        should be aware of which language was negotiated.  This is
>        conceptually similar to the way other aspects of each media stream
>        are negotiated using SDP (e.g., media type and codecs).
>
>        In the offer/answer model used here, the offer contains a set of
>        languages per media that the caller is capable of using, and the
>
<GH> "caller" should be "offerer" to match o/a language.
>
>        answer contains one language per media that the answerer will
>
<GH>"one language per media that the answerer will support" should be 
"one language per media and direction that the answerer will support for 
language communication"
>
>        support.  Supporting languages and/or modalities can require taking
>        extra steps, such as having a call handled by an agent who speaks a
>        requested language and/or with the ability to use a requested
>        modality, or bridging external translation or relay resources into
>        the call, etc.  The answerer indicates in the answer which
>     additional
>        steps it is committing to.  This model also provides knowledge so
>
<GH>"which additional steps it is committing to" should be "the 
resulting language and modality support when the additional steps are 
applied"
>
>        both ends know what has been negotiated.  Note that additional
>     steps
>        required to support the indicated languages or modalities may
>     or may
>        not be in place in time for any early media.
>
>
/Gunnar
>
>
>
>
>                 That said, as I noted in my review, it is still
>             possible to get some media (early media) prior to
>             receiving the answer, so this isn't a complete solution.
>
>
>                The draft provides a useful mechanism that will be
>             helpful.  As an example of the fact that others find it
>             useful, NENA has included it in it's next-generation
>             emergency call architecture standards. The draft does not
>             try to solve all problems related to human language in
>             real-time calling.
>
>
>                I don't think I claimed it wasn't useful.
>
>                The rationale provided for this design is that you wish
>             to have the answerer notify the offerer of which language
>             it would be providing. The point I am making is that there
>             is at least one important case where this design does not
>             provide that, which seems like it's relevant to the design
>             question.
>
>
>               I think I'm still not understanding your concern. Even
>             without providing a mechanism for the caller to know the
>             languages used with any early media, the draft is still
>             meeting a need.
>
>
>               I'm honestly not sure what you're responding to here.
>             I'm not saying that the draft doesn't meet a need.
>
>               -Ekr
>
>
>
>
>               --
>               Randall Gellens
>               Opinions are personal;    facts are suspect;    I speak
>             for myself only
>               -------------- Randomly selected tag: ---------------
>               Imagination is more important than facts. --Albert Einstein
>
>
>
>               _______________________________________________
>               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: ---------------
>          Algol was a great improvement on most of its successors.
>                                                   --C.A.R Hoare
>
>          _______________________________________________
>          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: ---------------
>     If we do not change our direction we are likely to end up where we are
>     headed.
>
>
>
>
> _______________________________________________
> SLIM mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/slim

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