IETF Logo Mail Archive

[MMUSIC] IANA registry structure for IANA attributes

"Drage, Keith (Nokia - GB)" <keith.drage@nokia.com> Tue, 05 April 2016 14:38 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 BDF1212D0ED for <mmusic@ietfa.amsl.com>; Tue, 5 Apr 2016 07:38:51 -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 FQzsEU2ik6OJ for <mmusic@ietfa.amsl.com>; Tue, 5 Apr 2016 07:38:49 -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 1284E12D0BA for <mmusic@ietf.org>; Tue, 5 Apr 2016 07:38:49 -0700 (PDT)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 0491961DB0C37 for <mmusic@ietf.org>; Tue, 5 Apr 2016 14:38:45 +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 u35Ecl7o019069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <mmusic@ietf.org>; Tue, 5 Apr 2016 14:38:47 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 u35Eckil008104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <mmusic@ietf.org>; Tue, 5 Apr 2016 16:38:46 +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:38:46 +0200
From: "Drage, Keith (Nokia - GB)" <keith.drage@nokia.com>
To: "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: IANA registry structure for IANA attributes
Thread-Index: AdGPSJD+Iat0mrlPTP6P2AK2ugo7kw==
Date: Tue, 05 Apr 2016 14:38:45 +0000
Message-ID: <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/U-l6srge2Sf-rKlFnzbLtvha8hQ>
Subject: [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:38:52 -0000

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

v2.23.0 | Report a Bug | By Email