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

From: Randall Gellens <[email-masked]>
Date: Sun, 14 Jul 2013 02:05:57 -0700

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.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
The mind of a bigot is like the pupil of the eye. The more light you
shine on it, the more it contracts.      --Oliver Wendell Holmes, Jr.

---

From: Gunnar Hellstrom <[email-masked]>
Date: Mon, 15 Jul 2013 00:14:33 +0200

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
[email-masked]
+46708204288

---

From: Christian Groves <[email-masked]>
Date: Mon, 15 Jul 2013 12:20:47 +1000

Hello Randall,

Please see my comment below.

..snip..
On 15/07/2013 8:14 AM, Gunnar Hellstrom wrote:
> ...
[CNG] I guess this is a question of scope. I would think that the draft 
would just describe the syntax and procedures of this new language tag 
in a generic manner. The application level behaviour of call centres and 
PSAPs would be defined elsewhere?

Regards, Christian

---

From: Randall Gellens <[email-masked]>
Date: Thu, 18 Jul 2013 09:10:31 -0700

At 12:14 AM +0200 7/15/13, Gunnar Hellstrom wrote:

Randall,

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-

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?

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".

[RG] I have a -02 (which I can submit when the submission window
re-opens) in which I've attempted to clarify this by adding:

In cases where a media is

not primarily intended for language (for example, a
video or audio

stream intended for background only) both SHOULD be
unset.

However, I'm not convinced that in reality clients will know how
the user intends to use various streams.  I'd like to hear more
discussion on this point.

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

"

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

I do not see the background for this paragraph, and think it will be
better to delete it.

[RG] The reasoning is an attempt to not overly-complicate call
set-up with requirements that in reality will be difficult for clients
to handle in a reasonable way.  I'd like to hear more views on
deleting it or modifying it.

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.

Regards

Gunnar

Gunnar Hellström

Omnitor

+46708204288

On 2013-07-14 11:05, Randall Gellens
wrote:

Hi all,

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.

_______________________________________________

mmusic mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/mmusic

--

Randall Gellens

Opinions are personal;    facts are
suspect;    I speak for myself only

-------------- Randomly selected tag: ---------------

Books have to be read (worse luck it takes so long a time).  It is the

only way of discovering what they contain.  A few savage tribes eat

them, but reading is the only method of assimilation revealed to the

West.

--E.M. Forster

---

From: Randall Gellens <[email-masked]>
Date: Thu, 18 Jul 2013 09:16:08 -0700

At 12:20 PM +1000 7/15/13, Christian Groves wrote:

>>  If a user gets an incoming call, with humintlang specifications, 
>> it can compare with its own profile and decide to invoke a
>  [CNG] I guess this is a question of scope. I would think that the 
> draft would just describe the syntax and procedures of this new 
> language tag in a generic manner. The application level behaviour 
> of call centres and PSAPs would be defined elsewhere?

[RG] That would be fine with me; my attempt in adding the text using 
descriptive rather than normative language was to clarify the 
intended use without imposing mandates on call centers and PSAPs 
(which, as you say, will be done elsewhere).

-------------- Randomly selected tag: ---------------
Mythology, n.:
    The body of a primitive people's beliefs concerning its
origin, early history, heroes, deities and so forth, as
distinguished from the true accounts which it invents later.
                   --Ambrose Bierce, "The Devil's Dictionary"

---

From: Gunnar Hellstrom <[email-masked]>
Date: Thu, 18 Jul 2013 23:19:34 +0200

On 2013-07-18 18:16, Randall Gellens wrote:
>>> incoming calls, and for end-users as well as call-centers and PSAPs.
>>> language preferences, or just prepare for what media, modalities and
>> language tag in a generic manner. The application level behaviour of 
>> call centres and PSAPs would be defined elsewhere?
>
> descriptive rather than normative language was to clarify the intended 
> use without imposing mandates on call centers and PSAPs (which, as you 
> say, will be done elsewhere).
But since your assumption of use was far from mine, I hope that you 
accept to delete the paragraph.

Or change it to:

  "
  Clients are expected to set one or both
      'humintlang-send' and 'humintlang-recv' attributes on each media
      stream in an offer and answer for which the users has any 
preferences or capabilities for use in human communication. Systems are 
expected to take into account the
      values when processing inbound calls or when processing the 
answers on outbound calls. The values can also be used for call handling 
decisions by service providers.
  "

Regards

Gunnar

---

From: Gunnar Hellstrom <[email-masked]>
Date: Fri, 19 Jul 2013 08:16:33 +0200

We also have the need for absolute preferences to handle and decide on.

> and a "-" a non-preferred, but possible language and modality.

The background was in an earlier mail:
There is also a need for absolute preference. Or relative order of 
preference between media.

It is easy to use a sign language example fort that situation.

A person prefers to use British sign language in both directions but is 
capable with some reluctance to use English text. That is natural. Text 
is always slower and less expressive than sign language or spoken language.

A call goes to a call center that declared spoken English and English 
text in both directions.
The result can be a direct connection using English text, or invocation 
of a sign relay service translating between British sign language and 
spoken English.

An ability to declare that the British sign language is preferred over 
the English text would result in the invocation of the sign relay 
service and make both sides happy with a call with good flow.

Without the relative preference between media, the call will likely 
result in the direct text communication that will work but with less 
satisfaction.

This can be solved either by an absolute preference indication  : 
British sing language *preferred*  , English text *managed*
Or by some order of preference between the media;  video *preferred* 
text *managed*

I think an absolute preference indication is easiest to handle. Media 
preference will collide with relative preference between languages in 
each medium.

I suggest that that is introduced with some suitable coding.

It seems best t enter this in a paragraph in 7.1. I also propose that 
7.1 is subdivided in subsections to make it easier to navigate.

This addition would fit as a paragraph after this existing one:

"

  In an offer, the 'humintlang-send' values constitute a list in
    preference order (first is most preferred) of the languages the
    offerer wishes to send, and the 'humintlang-recv' values constitute a
    list in preference order of the languages the offerer wishes to
    receive.  In cases where the user wishes to use one media for sending
    and another for receiving (such as a speech-impaired user who wishes
    to send using text and receive using audio), one of the two will be
    unset.  In other cases, both SHOULD have the same values in the same
    order.  The two SHOULD NOT be set to languages which are difficult to
    match together (e.g., specifying a desire to send audio in Hungarian
    and receive audio in Portuguese will make it difficult to
    successfully complete the call)."

I suggest to add this paragraph:

"
In order to express order of preference between different media, an absolute
preference indication MAY be inserted in the attribute, after the language tag.
An exclamation mark "!" is used to indicate a strongly preferred language and modality,
no addition is used to indicate a managed language and modality, and a hash sign "#"
is used to indicate a non-preferred but possible fall-back language and modality.
An example can be a person who prefers to use British sign language in both directions but
is capable with some reluctance to use English text, calling a call center that has
competence for spoken English and English text in both directions. The result can be
a direct connection using English text, or invocation of a sign relay service translating
between British sign language and spoken English. The preference indication on British
sign language guides the call centre in this case to invoke a relay service to get most
satisfaction in the call, while in another case, a relay service for the discovered
gap between the preferred languages might not be available, and then the fall-back to
English text is a viable alternative.  "

Introduction of this coding with "!" , nothing, and "#" creates a need for a syntax chapter,
where the allowed combinations of the language tag, these markers and the "*" for connect
anyway are described more formally.

Regards,
Gunnar