IETF Logo Mail Archive

Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg

Juergen Stoetzer-Bradler <juergen.stoetzer-bradler@nokia.com> Thu, 10 March 2016 16:06 UTC

Return-Path: <juergen.stoetzer-bradler@nokia.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 655F212D9B2 for <mmusic@ietfa.amsl.com>; Thu, 10 Mar 2016 08:06:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Level:
X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUNgsRZDbeEp for <mmusic@ietfa.amsl.com>; Thu, 10 Mar 2016 08:06:01 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-02.alcatel-lucent.com [135.245.210.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBB3612D987 for <mmusic@ietf.org>; Thu, 10 Mar 2016 08:05:41 -0800 (PST)
Received: from fr711umx2.dmz.alcatel-lucent.com (unknown [135.245.210.39]) by Websense Email Security Gateway with ESMTPS id 4C6AA12455C02 for <mmusic@ietf.org>; Thu, 10 Mar 2016 16:02:41 +0000 (GMT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr711umx2.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u2AFN44b001387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <mmusic@ietf.org>; Thu, 10 Mar 2016 15:23:04 GMT
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u2AFMu1N018549 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <mmusic@ietf.org>; Thu, 10 Mar 2016 16:23:04 +0100
Received: from [149.204.68.190] (135.239.27.39) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 10 Mar 2016 16:21:01 +0100
To: mmusic@ietf.org
References: <BBE9739C2C302046BD34B42713A1E2A22E88D533@ESESSMB105.ericsson.se> <56AACC37.8090900@cisco.com> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> <56B25159.70002@alum.mit.edu> <56B28240.7080206@cisco.com> <56B2DA8D.2000909@alum.mit.edu> <56B41A47.10901@nteczone.com> <56B63EF8.8080100@alum.mit.edu> <56B8BDA4.7060305@cisco.com> <56B8CBB5.7070507@alum.mit.edu> <56BCF47E.2000603@cisco.com> <56BDB7BC.1060104@alcatel-lucent.com> <56BDF1C6.9080707@cisco.com> <56C05B63.4030007@alcatel-lucent.com> <56C6156C.2070308@cisco.com> <56C71EF3.6040208@alcatel-lucent.com> <56C74FDE.4040902@cisco.com> <56CC5E9B.5060307@alcatel-lucent.com> <56D61704.70205@cisco.com> <56D84051.4080303@alcatel-lucent.com> <56D84FB7.4050109@cisco.com> <56DCC592.2060503@nteczone.com> <56DE4123.3030606@cisco.com> <56DED8E7.7060705@alcatel-lucent.com> <56DF7414.5090604@nteczone.com> <56E017F2.7020401@alcatel-lucent.com> <56E071B7.9080807@alum.mit.edu> <56E0AF29.7080505@nteczone.com>
From: Juergen Stoetzer-Bradler <juergen.stoetzer-bradler@nokia.com>
Message-ID: <56E190DC.3010205@alcatel-lucent.com>
Date: Thu, 10 Mar 2016 16:21:00 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56E0AF29.7080505@nteczone.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms060801040300060701060902"
X-Originating-IP: [135.239.27.39]
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/ybQREu5e289TdXltJfA2j6GeZq8>
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 10 Mar 2016 16:06:03 -0000

Paul, Christian,

In such a consolidated registry, assumingly the "source" and "dcsa" contexts of most attributes, 
which are registered today in any of the existing IANA tables, would stay empty, as most attributes 
would not specifically be described or specified for these two context?

Thanks,
Juergen

On 10.03.2016 00:18, EXT Christian Groves wrote:
> Hello Paul, all,
>
> On 10/03/2016 5:55 AM, Paul Kyzivat wrote:
>> In my opinion we should start out assuming that the existing attribute registries are 
>> consolidated into one, with an extra column, as has been planned.
>>
>> Then we consider how to build on that.
>>
>> My thought is that "dcsa" simply becomes another context, alongside "session", "media", and 
>> "source". A given attribute could be valid in any combination of those.
>
>> And then the reference section of that entry should get a reference to every document that 
>> pertains to that attribute.
> [CNG] I'm happy to go with that suggestion.
>
>>
>> That does leave the issue Juergen raises: you might need to read a bunch of documents to find 
>> which ones pertain to usage in dcsa, and to a particular subprotocol.
> [CNG] An implementor should read these documents anyway if they're going to implement a sub-protocol.
>>
>> We could consider further enhancements to the registry to make that sort of query easier. Or we 
>> could just assume it won't be a problem often enough to bother.
>
> Regards, Christian
>
> ..snip
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>

v2.23.0 | Report a Bug | By Email