[MMUSIC] Notes from Orlando human language draft discussion

Randall Gellens <randy@qti.qualcomm.com> Fri, 15 March 2013 18:50 UTC

Return-Path: <randy@qti.qualcomm.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id F01D621F86E8 for <mmusic@ietfa.amsl.com>; Fri, 15 Mar 2013 11:50:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.224
X-Spam-Status: No, score=-106.224 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id c5qtAb3bWImK for <mmusic@ietfa.amsl.com>; Fri, 15 Mar 2013 11:50:16 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com []) by ietfa.amsl.com (Postfix) with ESMTP id 272DF21F86D5 for <mmusic@ietf.org>; Fri, 15 Mar 2013 11:50:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1363373416; x=1394909416; h=message-id:date:to:from:subject:cc:mime-version; bh=Duvbl8qTC4s024e/mWmdXeUFvH/cOD9fQZ3K9eKSVkg=; b=xRBdZGUB5Fxw4m1p7I1sjjH+rryAXsBBCgqgI7WuBWWG7TyIukkfjKUR TJySlRsoTcRKhCdRWK1pJiahDjrjSZ601JYQF4j5Gip/EtTA5BXv/KKo5 aj1Q1MEkX34jxn30fWbYVZU+t8uftiGtxbzqAtG58W6+txgZUKweKtsVG Y=;
X-IronPort-AV: E=Sophos;i="4.84,853,1355126400"; d="scan'208";a="30086197"
Received: from ironmsg03-l.qualcomm.com ([]) by wolverine02.qualcomm.com with ESMTP; 15 Mar 2013 11:50:14 -0700
X-IronPort-AV: E=Sophos;i="4.84,853,1355126400"; d="scan'208";a="443061809"
Received: from nasanexhc08.na.qualcomm.com ([]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 15 Mar 2013 11:50:08 -0700
Received: from dhcp-42ec.meeting.ietf.org ( by qcmail1.qualcomm.com ( with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 15 Mar 2013 11:50:07 -0700
Message-ID: <p0624061acd691d9b38bc@dhcp-42ec.meeting.ietf.org>
X-Mailer: Eudora for Mac OS X
Date: Fri, 15 Mar 2013 11:49:49 -0700
From: Randall Gellens <randy@qti.qualcomm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Originating-IP: []
Cc: ietf-languages-bounces@alvestrand.no, mmusic@ietf.org
Subject: [MMUSIC] Notes from Orlando human language draft discussion
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Mar 2013 18:50:17 -0000

Hi everyone,

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

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