Re: [MMUSIC] Notes from Orlando human language draft discussion

Randall Gellens <randy@qti.qualcomm.com> Sun, 17 March 2013 19:43 UTC

Return-Path: <randy@qti.qualcomm.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2BC421F8B74 for <mmusic@ietfa.amsl.com>; Sun, 17 Mar 2013 12:43:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.374
X-Spam-Level:
X-Spam-Status: No, score=-106.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6N2PIGbwX3sQ for <mmusic@ietfa.amsl.com>; Sun, 17 Mar 2013 12:43:32 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 7E16321F8AA0 for <mmusic@ietf.org>; Sun, 17 Mar 2013 12:43:32 -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=1363549412; x=1395085412; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=mYnNlDOWxw0ldCnuibzZV0tkj6lp2cNygXYTYThyx2E=; b=ABK+tI29QBCgVP7lKBKt8uNJvGjhD5n/WkSFIH0d8eBAcfntnjEYMBbC Y2ie9PCrQY3YDubyBX4MHCzLMTQe4vJooaFoF3BJV8NspKSQ8rMqa1n38 9QogQZfsN6SO0TOOMIzrkD1fe4IoTU138apOHIVRvt93faKrY4zEUEUnG U=;
X-IronPort-AV: E=Sophos;i="4.84,860,1355126400"; d="scan'208";a="30395716"
Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP; 17 Mar 2013 12:43:31 -0700
X-IronPort-AV: E=Sophos;i="4.84,860,1355126400"; d="scan'208";a="443843191"
Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 17 Mar 2013 12:43:31 -0700
Received: from [99.111.97.136] (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.2.318.4; Sun, 17 Mar 2013 12:43:31 -0700
Message-ID: <p06240600cd6bc8856061@[99.111.97.136]>
In-Reply-To: <4CB74555-CA6A-4FE8-B410-AAD1EF2354A6@acmepacket.com>
References: <p0624061acd691d9b38bc@dhcp-42ec.meeting.ietf.org> <B0295A41-BF2B-4520-8495-7A88B4803F30@acmepacket.com> <p06240603cd6a994b05ad@dhcp-42ec.meeting.ietf.org> <4CB74555-CA6A-4FE8-B410-AAD1EF2354A6@acmepacket.com>
X-Mailer: Eudora for Mac OS X
Date: Sun, 17 Mar 2013 12:36:22 -0700
To: Hadriel Kaplan <HKaplan@acmepacket.com>
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: [172.30.48.1]
Cc: Randall Gellens <randy@qti.qualcomm.com>, "ietf-languages-bounces@alvestrand.no" <ietf-languages-bounces@alvestrand.no>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [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: Sun, 17 Mar 2013 19:43:34 -0000

At 1:03 AM +0000 3/17/13, Hadriel Kaplan wrote:

>  On Mar 16, 2013, at 5:54 PM, Randall Gellens <randy@qti.qualcomm.com> wrote:
>
>>>  What's the use-case when the two directions are not identical? 
>>> I.e., when does it make sense to receive Latin but send Swahili 
>>> for the same media?
>>>  I ask because this separation complicates things quite a bit in 
>>> code/testing/error-handling, obviously.
>>
>>  I'll let Harald speak to this as he was pretty insistent that it 
>> was a misuse of SDP (if I understood him) to use the same 
>> attribute for sending and receiving.
>
>  That may be true for attributes specific to a format/payload 
> type... maybe.  But for just attributes applying to a media or 
> session section, I don't think so.  You can look up the registered 
> SDP attributes in IANA and find a bunch that really apply to both 
> directions, at least in practice.

I don't want to put words in Harald's mouth, but my recollection is 
that he specifically mentioned the "in practice" as being an abuse.

>   For example: the 'a=inactive' attribute.  It's not inactive for a 
> specific direction, it's inactive for both directions.

That makes sense, and personally I'm in favor of keeping things as 
simple as possible.  But I also don't want to be accused of fomenting 
further misuse of SDP :-)

>>  The result of the discussion is to add a token for the caller to 
>> indicate a preference for the language being mandatory or 
>> advisory, but the callee is not required to honor this preference.
>
>  If the callee is not required to honor a mandatory preference, then 
> it's not really mandatory is it?
>  Is there a third token for "I really mean it"? ;)

The preference is not mandatory (if it was, it wouldn't be a 
preference, it would be a demand).  The preference indicates if the 
caller wants the callee to treat language as mandatory versus 
advisory.

>>  I can imagine scenarios where failing the call might be preferred, 
>> such as a caller who will call an alternate party if the required 
>> language isn't supported.
>
>  I can imagine scenarios where the caller will call an alternate 
> party as well, but that's what we let them do by letting them 
> hang-up/end the session.

If this is really what is wanted, it is quicker if the call fails 
during setup rather than going through full setup, possible queues 
(remember, a major use case is calling call centers), attempting to 
speak to a representative, and then hanging up in frustration.

>  And I'm not saying that to be flippant.  I'm really worried calls 
> will fail when the user didn't want them to, and that would be bad. 
> Bad because I don't want them having to read a manual to make a 
> call work, or having them contact their provider's tech support to 
> figure out why their call failed.

I am also concerned about introducing features where it is not 
obvious what the client should do.  I can see obvious ways for a 
client to make a reasonable default language choice, and ways to 
allow the user to configure it.  It's harder to see how a client 
knows if the advisory token should be set to fail or proceed.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
The fetters imposed on liberty at home have ever been forged out of the
weapons provided for defence against real, pretended, or imaginary
dangers from abroad.
        --James Madison, 4th US president (1751-1836)