Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-language-01.txt

[Gunnar Hellstrom <[e-mail]>]

Randall,

Yes, version 01 is a step forward.


Comments:
1. In 7.1 you now say:

When placing an emergency call, and in any other case where the
    language cannot be assumed from context, each media stream in an
    offer SHOULD specify one or both 'humintlang-send' and 'humintlang-
    recv' attributes (to avoid ambiguity).


This might be a good advice. But to what extent SHOULD it be followed?

Some media might be included in SDP without the user having any interest 
of using it for language communication.
Video may be included without the person really preferring it for spoken 
language understanding enhancement but just for pleasure or seeing the 
scene of the other user.

Do you mean that such cases should also be specified with humintlang but 
with empty attributes?
As a clear indication that the user is not interested in using that 
medium for language transfer.
That could make sense. That is different from not providing any 
humintlang at all, that should be understood as undefined language 
preferences.


But there are media streams specified by SDP where a language preference 
specification does not make sense. There are many application and 
message media specifications that are not used for any human language 
communication. I think for example that there are media specifications 
for camera control.
Is the SHOULD a sufficient weakening of the requirement, so that the 
reader can skip using humintlang for media where it does not make sense?
If not, expand "each media stream"  to: "each media stream in which 
human language communication might occur".



2. You have also introduced this paragraph in 7.1:
"

Clients acting on behalf of end users are expected to set one or both
    'humintlang-send' and 'humintlang-recv' attributes on each media
    stream in an offer when placing an outgoing session but ignore the
    attributes when receiving incoming calls.  Systems acting on behalf
    of call centers and PSAPs are expected to take into account the
    values when processing inbound calls.
"

What is the thought behind this?

I see the humintlang specification equally valuable in outgoing as incoming calls, and for end-users as well as call-centers and PSAPs.
If a user gets an incoming call, with humintlang specifications, it can compare with its own profile and decide to invoke a
relay service or interpreter servicde to cover some differences in language preferences, or just prepare for what media, modalities and
languages to use in the call..
I do not see the background for this paragraph, and think it will be better to delete it.


3. Absolute preference is still needed.
I described earlier the need for an absolute preference indication. But I did not provide any coding proposal.
I suggest to add something at the end of the language tag. Regardless if it gets before or after the * if it is there.
Can a "+" be used to indicate a strongly preferred language and modality, no extra specification a managed language and modality
and a "-" a non-preferred, but possible language and modality.
  
( needs to be checked against syntax of language tags.)

  
Regards

Gunnar

------------------------------------------------------------------------
Gunnar Hellström
Omnitor
[e-mail]
[phone]
On 2013-07-14 11:05, Randall Gellens wrote:
> Hi all,
>
> I've tweaked the human language draft:
>
>    o  Relaxed language on setting -send and -receive to same values;
>       added text on leaving on empty to indicate asymmetric usage.
>
>    o  Added text that clients on behalf of end users are expected to set
>       the attributes on outgoing calls and ignore on incoming calls
>       while systems on behalf of call centers and PSAPs are expected to
>       take the attributes into account when processing incoming calls.
>