Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-language-00.txt - asymmetric preferences

[Gunnar Hellstrom <[e-mail]>]

Randall,
It is good to see this shape up.

One initial comment:

The draft discourages in an infavourable way from specifying 
asymmetrical preferences.

In 7.1, it says:

"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.  Both SHOULD have the same values in the same order, because
    otherwise it is harder to match desired resources."


A typical example of a user who do not want to specify the same value in 
both directions is a hard-of-hearing user who prefers to speak English 
but might accept to type English text on the transmission side,  but 
prefers to read English text and do not have sufficient hearing to at 
all handle hearing spoken English on the receiving side.

In the audio media specification there would then be humintlang-send 
value English,  and nothing in the humintlang-recv.
While in the text media specification there would be humintlang-send 
value for English, that would need a very much lower preference than the 
audio send, and the humintlang-recv value for English.

Note also the need for an absolute preference indication. Or relative 
between media. This user will be quite disappointed to be forced to 
handle the call in text both ways.

With this background, the SHOULD in the cited section is not desirable. 
I suggest to delete that sentence.

There is a similar problem with the last paragraph in 7.1

"  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 both 'humintlang-send' and 'humintlang-recv'
    attributes (to avoid ambiguity), and both SHOULD be set to the same
    values in the same order."

Since users may have capability for only one direction of a modality, it is not reasonable to require them to
  specify a value in the direction they do not have a capability in.


So this paragraph should be deleted or modified.


Thanks

Gunnar










------------------------------------------------------------------------
Gunnar Hellström
Omnitor
[e-mail]
[phone]
On 2013-07-08 00:39, [e-mail] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
> 	Title           : Negotiating Human Language Using SDP
> 	Author(s)       : Randall Gellens
> 	Filename        : draft-gellens-mmusic-negotiating-human-language-00.txt
> 	Pages           : 13
> 	Date            : 2013-07-07
>
> Abstract:
>     Users have various human (natural) language needs, abilities, and
>     preferences regarding spoken, written, and signed languages.  When
>     establishing interactive communication "calls" there needs to be a
>     way to communicate and ideally match (i.e., negotiate) the caller's
>     language preferences with the capabilities of the called party.  This
>     is especially important with emergency calls, where a call can be
>     routed to a Public Safety Answering Point (PSAP) or call taker
>     capable of communicating with the user, or a translator or relay
>     operator can be bridged into the call during setup, but this applies
>     to non-emergency calls as well (as an example, when calling a company
>     call center).
>
>     This document describes the need and expected use, and describes a
>     solution using new SDP stream attributes plus an optional SIP "hint."
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-gellens-mmusic-negotiating-human-language
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-gellens-mmusic-negotiating-human-language-00
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt