[MMUSIC] Notes from Orlando human language draft discussion

[Randall Gellens <[e-mail]>]

Hi everyone,

Thanks very much for the productive discussion.  Here are my notes:

SDP or SIP:
- Use SDP for actual negotiation, but use SIP header to provide a hint
- Emergency services use case can use SDP for policy routing/handling decisions
- Other use cases may or may not have ability/desire to use SDP for 
this and can use the SIP header hint
- SDP useful in protocols other than SIP
- SIP header with hint is either a new header or caller preferences 
(RFC 3841), presumably Accept-Contact; caller sets media and language 
and optionally required; not clear if this matches our desired 
semantics
- SIP header is just a hint; it is not required to be sent or to be 
used on receipt; it is recommended to be sent

New SDP attribute(s) vs re-use of existing 'lang' attribute:
- Existing attribute semantics are unclear so should be avoided
- Minting new attributes is cheap

Directionality of SDP attributes:
- Define two new SDP media-level attributes: 'send-lang' and 
'recv-lang'.  In an offer, send-lang is a list in preference order of 
the languages the offerer wishes to send and recv-lang is a list in 
preference order of the languages the offerer wishes to receive.  In 
most cases these are expected to have the same value, because 
otherwise it is harder to match desired resources.  In an answer, 
send-lang is the accepted language the answerer will send (which in 
most cases should be one of the languages in the offer's recv-lang) 
and recv-lang is the accepted language the answerer expects to 
receive (which in most cases should be one of the languages in the 
offer's send-lang).

Advisory vs Required:
- Does call fail if no common language?
- Define token for use in offer to indicate caller's preference to 
fail call or not if no common language.
- One choice is to say that if the last character of the send-lang or 
recv-lan value an asterisk, this indicates a request to not fail the 
call (similar to SIP Accept-Language syntax).  Either way, the called 
party may ignore this, e.g., for the emergency services use case, a 
PSAP will likely not fail the call.

Other changes (from additional side discussions):
- Add advice that the value of the parameters should stick to the 
largest granularity of language tags, that is, it is recommended not 
to add subtags (e.g., for region or dialect) unless the languages 
might be mutually incomprehensible without them.
- Expand Introduction to be more clear about purpose of document and 
problem being solved
- Add more detailed use case descriptions

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
I was gratified to be able to answer promptly, and I did.  I said
I didn't know."                                      --Mark Twain