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

[Randall Gellens <[e-mail]>]

At 8:01 PM +0100 1/8/18, Gunnar Hellström wrote:

>  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 
>> <<mailto:[e-mail]>[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:<mailto:[e-mail]>[e-mail]><mailto:[e-mail]>[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:<mailto:[e-mail]>[e-mail]><mailto:[e-mail]>[e-mail]><mailto:<mailto:[e-mail]>[e-mail]><mailto:[e-mail]>[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:<mailto:[e-mail]>[e-mail]><mailto:[e-mail]>[e-mail]><mailto:<mailto:[e-mail]>[e-mail]><mailto:[e-mail]>[e-mail]><mailto:<mailto:<mailto:[e-mail]>[e-mail]><mailto:[e-mail]>[e-mail]><mailto:<mailto:[e-mail]>[e-mail]><mailto:[e-mail]>[e-mail]> 
>> wrote:
>>
>>      On Jan 6, 2018, at 6:55 PM, Eric Rescorla 
>> <<mailto:<mailto:<mailto:<mailto:[e-mail]>[e-mail]><mailto:[e-mail]>[e-mail]><mailto:<mailto:[e-mail]>[e-mail]><mailto:[e-mail]>[e-mail]><mailto:<mailto:<mailto:[e-mail]>[e-mail]><mailto:[e-mail]>[e-mail]><mailto:<mailto:[e-mail]>[e-mail]><mailto:[e-mail]>[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.
>>
>>

OK, here is the revised paragraph:

    In the offer/answer model used here, the offer contains a set of
    languages per media (and direction) that the offerer is capable of
    using, and the answer contains one language per media (and direction)
    that the answerer will 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 answer indicates the
    media and languages that the answerer is committing to support
    (possibly after additional steps have been taken).  This model also
    provides knowledge so 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.



>
>>
>>
>>
>>      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
>>    <mailto:[e-mail]>[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
>>   <mailto:[e-mail]>[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
>>  <mailto:[e-mail]>[e-mail]
>> 
>> <https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim
>>
>
>  --
>  -----------------------------------------
>  Gunnar Hellström
>  Omnitor
>  <mailto:[e-mail]>[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: ---------------
In the United States the majority undertakes to supply a multitude of
ready-made opinions for the use of individuals, who are thus relieved
from the necessity of forming opinions of their own
      --Alexis de Tocqueville