Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)

Flemming Andreasen <fandreas@cisco.com> Mon, 25 March 2013 01:21 UTC

Return-Path: <fandreas@cisco.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 4092621F8E3D for <mmusic@ietfa.amsl.com>; Sun, 24 Mar 2013 18:21:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.83
X-Spam-Level:
X-Spam-Status: No, score=-9.83 tagged_above=-999 required=5 tests=[AWL=0.769, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 L1etlIMYWceV for <mmusic@ietfa.amsl.com>; Sun, 24 Mar 2013 18:21:39 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id EDE3321F8E3C for <mmusic@ietf.org>; Sun, 24 Mar 2013 18:21:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1235; q=dns/txt; s=iport; t=1364174499; x=1365384099; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=VcvgB87XAwZgL03y5/I8v5s1ZquqcHFfelhRb89zW8A=; b=KDV2U2XEHCp+57WnFsJGLzMBASsENoNUAhFkVAyiE9tHiyfGcj45B40M O1oXZz7IuN65zN94jN6cM5JZm8cyuBjjWnjH4dWN6vsFOJI1Cj8qKYfQR fNx1PY7VMNHhQNEev5OFZkMefr2rmhhkLlbfiilr7y4kf8EXH97p79uIQ I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAGilT1GtJXHA/2dsb2JhbABDxXyBehZ0giQBAQEDAThAAQULCw4KCRYECwkDAgECAUUGDQEFAgEBiAoGwWSPGAeDQAOWZ5EEgVSBUiA
X-IronPort-AV: E=Sophos;i="4.84,902,1355097600"; d="scan'208";a="190975142"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 25 Mar 2013 01:21:38 +0000
Received: from Flemmings-MacBook-Pro.local ([10.86.253.124]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2P1Lb2a002616; Mon, 25 Mar 2013 01:21:37 GMT
Message-ID: <514FA6A1.5050000@cisco.com>
Date: Sun, 24 Mar 2013 21:21:37 -0400
From: Flemming Andreasen <fandreas@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Hadriel Kaplan <HKaplan@acmepacket.com>
References: <5148049B.6090205@cisco.com> <D09DAE6B636851459F7575D146EFB54B2109D350@008-AM1MPN1-026.mgdnok.nokia.com> <BBF5DDFE515C3946BC18D733B20DAD2338D30F41@XMB104ADS.rim.net> <514CA4E1.50006@cisco.com> <D991A6F8-E476-43B9-813A-5DE3F039289B@vidyo.com> <15874272-F9D6-46E6-BFFB-B3C2B72CCB31@acmepacket.com>
In-Reply-To: <15874272-F9D6-46E6-BFFB-B3C2B72CCB31@acmepacket.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Jonathan Lennox <jonathan@vidyo.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
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: Mon, 25 Mar 2013 01:21:40 -0000

On 3/24/13 1:07 PM, Hadriel Kaplan wrote:
> On Mar 22, 2013, at 4:00 PM, Jonathan Lennox <jonathan@vidyo.com> wrote:
>
>> In practice, given the port number issue that started this thread, I suspect this means that the SDP offer will need to put the IN address in the actual configuration (in the c= line), and the PSTN address(es) will be in the potential configurations.
> Yes exactly.  Remove the ability for ccap to use an IP Address by changing its ABNF.
That's my problem with this whole discussion. We have defined a general 
connection data capability, and now we don't want it to be able to 
express anything beyond "PSTN" - exactly why did we do this again and 
what was it the WG agreed to when taking this on as a WG item ?

Also, if you explicitly prevent the ABNF from supporting IP-addresses, 
then you must be listing the values that actually are supported and 
hence we've further lost generality in how we define this and general 
alignment with the SDP structure where we register supported values 
separately. I'm really not in favor of any of that.

-- Flemming

>   That will remove any confusion. (though the wording of the usage still needs to be cleaned up of course)
>
> -hadriel
>
>