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

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

Den 2018-01-08 kl. 02:56, skrev Eric Rescorla:
>
>
> On Sun, Jan 7, 2018 at 5:22 PM, Randall Gellens 
> <[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:[e-mail]
>         <mailto:[e-mail]>>[e-mail]
>         <mailto:[e-mail]>> wrote:
>
>          On Jan 6, 2018, at 6:55 PM, Eric Rescorla
>         <<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.
>
>
>
>          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.
<GH> I also have problems seeing where we should add clarifications, and 
what they should contain. One possible place is chapter 3: Desired 
semantics, where we could add more explanations about why a separate 
indication per direction is desirable.

Another possible place is somewhere in 5.2, before the note at the end. 
Some more reasoning about the asymmetric cases could be added there.

It is not only that the answerer provides information of the language 
selection to the offerer that is of value. It is also that the offerer 
provides information about what is possible in the complete interaction, 
so that the answerer can select a language and modality to receive that 
matches what the offerer can send.

The offerer indicating "I intend to send English text and want to 
receive spoken English" provides guidance to the answerer to accept the 
call in a device that can handle text conveniently and start looking in 
the text fields and start the call with a spoken greeting. Without an 
indication about what the offerer wanted to send, the answerer maybe 
would forget to look in the text fields, or would answer in a tiny 
device mainly suitable for spoken communication.

The inability to tell in what language and modality early media is 
provided may be a concern in some cases. But the contents of early media 
can anyway use languages and modalities that the offerer can perceive 
and understand. If the end user is given an opportunity to influence the 
answer, the finally transmitted language and modality may change when 
the final answer is sent and the real answering end user enters the call.

You answered on my hint that we have similarities with RFC 4796 SDP 
Content Attribute, that that is not negotiation but only metadata 
decoration. It seems to me that the negotiation in our draft is also not 
a real negotiation. It is not only metadata decoration, but close.  That 
is indicated by the parentheses in this paragraph:  "In an answer, 
'hlang-send' is the language the answerer will send if using the media 
for language (which in most cases is one of the languages in the offer's 
'hlang-recv'), and 'hlang-recv' is the language the answerer expects to 
receive if using the media for language (which in most cases is one of 
the languages in the offer's 'hlang-send'). "

Thus the answerer can propose new languages and modalities not seen in 
the offer, and we have no strict rules about how to handle these 
situations. So, we should maybe not look for the same strict logic in 
this negotiation as we have in media and codec negotiation, but rather 
see the negotiation as an exchange of hints intended to prepare for a 
smooth start of the human language session.

Wording proposals trying to add to the reasoning to satisfy Eric's concerns:

---------------Chapter 3, old 
text--------------------------------------------
3.  Desired Semantics

    The desired solution is a media attribute (preferably per direction)
    that may be used within an offer to indicate the preferred
    language(s) of each (direction of a) media stream, and within an
    answer to indicate the accepted language.  The semantics of including
    multiple languages for a media stream within an offer is that the
    languages are listed in order of preference.

    (Negotiating multiple simultaneous languages within a media stream is
    out of scope of this document.)
--------------Chapter 3, new 
text---------------------------------------------
3.  Desired Semantics

In human conversational communication it is most common to use
the same language and modality in both directions. There are however 
situations when an asymmetric use of languages and modalities is 
preferred or needed, so that different media are used for the language 
communication in the different directions. Such asymmetry is sometimes 
called for because of the capabilities of the human users, and sometimes 
by the conditions in the usage environment.  In order to prepare devices 
and users for a successful human language exchange in a session, an 
exchange of preferences and capabilities for use of languages and 
modalities in the two communication directions is desired.
    The desired solution is a media attribute per direction
    that may be used within an offer to indicate the preferred
    language(s) of each direction of a media stream, and within an
    answer to indicate the accepted language in each direction of that
    media stream if it is intended for language use.  The semantics
   of including  multiple languages for a media stream within an offer
   is that the languages are listed in order of preference.
Loosely formulated negotiating rules for selection of languages and 
modalities for use during the session are desired, to match the flexible 
capabilities of human users in conversational settings.
The parties are free to agree on deviation from the initially negotiated 
result during the session.

  Negotiating multiple simultaneous languages in the same direction of a 
media stream is
  out of scope of this document.
---------------End of wording proposal for chapter 
3------------------------------

-------New paragraph in chapter 5.2 after first 
paragraph---------------------------------------------------------------
The capabilities and preferences are divided in attributes per 
transmission direction. Both sending and receiving direction can be 
declared separately in order to give the receiver of the attributes an 
opportunity to prepare both for reception of language and own production 
of language to form a convenient combination for the session.
-------End of new text for 
5.2.-------------------------------------------------------------


/Gunnar





>
> -Ekr
>
>
>
>     -- 
>     Randall Gellens
>     Opinions are personal;    facts are suspect;    I speak for myself
>     only
>     -------------- Randomly selected tag: ---------------
>     (If you can't hear me, it's because I'm in parentheses)
>
>
>
>
> _______________________________________________
> SLIM mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/slim

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