Re: [MMUSIC] IANA registry structure for IANA attributes

"Drage, Keith (Nokia - GB)" <keith.drage@nokia.com> Tue, 05 April 2016 14:50 UTC

Return-Path: <keith.drage@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 778A712D1A3 for <mmusic@ietfa.amsl.com>; Tue, 5 Apr 2016 07:50:25 -0700 (PDT)
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 Dfos_aZHefyX for <mmusic@ietfa.amsl.com>; Tue, 5 Apr 2016 07:50:23 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 6360212D154 for <mmusic@ietf.org>; Tue, 5 Apr 2016 07:50:23 -0700 (PDT)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 11326AB3EA2FD for <mmusic@ietf.org>; Tue, 5 Apr 2016 14:50:19 +0000 (GMT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u35EoLDu004026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <mmusic@ietf.org>; Tue, 5 Apr 2016 14:50:21 GMT
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u35Eo9NO000349 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <mmusic@ietf.org>; Tue, 5 Apr 2016 16:50:20 +0200
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.185]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Tue, 5 Apr 2016 16:50:17 +0200
From: "Drage, Keith (Nokia - GB)" <keith.drage@nokia.com>
To: "Drage, Keith (Nokia - GB)" <keith.drage@nokia.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: IANA registry structure for IANA attributes
Thread-Index: AdGPSJD+Iat0mrlPTP6P2AK2ugo7kwAAZ1Mg
Date: Tue, 05 Apr 2016 14:50:17 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8BADEB9F73@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <949EF20990823C4C85C18D59AA11AD8BADEB9F2E@FR712WXCHMBA11.zeu.alcatel-lucent.com>
In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADEB9F2E@FR712WXCHMBA11.zeu.alcatel-lucent.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.39]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/csf7ekUSDCVs8C1kM7eGTU3a9Zg>
Subject: Re: [MMUSIC] IANA registry structure for IANA attributes
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: Tue, 05 Apr 2016 14:50:25 -0000

I am listening to the discussion as it occurs in the meeting.

I do not really agree that dcsa is a something separate and special.

In general, anything that can be used at the media level can be used in dcsa. Mostly any usage will be determined on whether it still makes sense when used in dcsa.

There will generally be nothing to say about dcsa usage over and above that.

I do not want to create some new draft that has to work through all the existing attributes just to formally defined that.

Keith

-----Original Message-----
From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of EXT Drage, Keith (Nokia - GB)
Sent: 05 April 2016 15:39
To: mmusic@ietf.org
Subject: [MMUSIC] IANA registry structure for IANA attributes

Firstly I agree with Cullen that if any RFC updates the semantics of an existing attribute (i.e. makes normative changes to it) then that RFC formally needs to update the prior RFC.

The registry should allow multiple references to RFCs where those RFCs make define additional semantics to an attribute, and MMUSIC should attempt to revise the attribute registry if these are missing.

I think the separation of attributes into multiple subregistries is a bit historical rather than something that is needed. I am not proposing taking it away (although conversely would not object if it did provided this information was normatively clear in the base RFCs), but it goes beyond what is required.

I do not think there is anything special about dcsa usage. Most dcsa usage does not change the semantics of the underlying attributes. Obviously if dcsa usage does change the semantics of an underlying attribute then the dcsa usage document should update the reference list. I do not think the msrp dcsa document makes any semantic change to any MSRP attributes - they can just be used.

I have a problem with a new DCSA level if it implies that an attribute cannot be used within dsca if it does not appear in this list.

Regards

Keith

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic