IETF Logo Mail Archive

Re: [dispatch] Conceptual proposal for extensibility of Alert-Info URNs

"WORLEY, Dale R (Dale)" <dworley@avaya.com> Thu, 17 June 2010 19:32 UTC

Return-Path: <dworley@avaya.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9560A3A690C for <dispatch@core3.amsl.com>; Thu, 17 Jun 2010 12:32:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.2
X-Spam-Level:
X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_05=-1.11]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOGpOSQrERJJ for <dispatch@core3.amsl.com>; Thu, 17 Jun 2010 12:32:18 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 53EE93A6954 for <dispatch@ietf.org>; Thu, 17 Jun 2010 12:32:18 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.53,433,1272859200"; d="scan'208";a="223609857"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 17 Jun 2010 15:32:22 -0400
X-IronPort-AV: E=Sophos;i="4.53,433,1272859200"; d="scan'208";a="473529064"
Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 17 Jun 2010 15:32:22 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.188]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Thu, 17 Jun 2010 15:32:22 -0400
From: "WORLEY, Dale R (Dale)" <dworley@avaya.com>
To: Paul Kyzivat <pkyzivat@cisco.com>, Laura Liess <laura.liess.dt@googlemail.com>
Date: Thu, 17 Jun 2010 15:32:22 -0400
Thread-Topic: [dispatch] Conceptual proposal for extensibility of Alert-Info URNs
Thread-Index: AcsOI0UcV/k3eLSCS/SNsIEu1TF/9gAL8XOQ
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B21FD7361AF@DC-US1MBEX4.global.avaya.com>
References: <CD5674C3CD99574EBA7432465FC13C1B21FD73619B@DC-US1MBEX4.global.avaya.com> <AANLkTik6DISW4wY-q4yoJsOfuRk_dWsr-_N_iKC9vy6x@mail.gmail.com> <CD5674C3CD99574EBA7432465FC13C1B21FD7361A2@DC-US1MBEX4.global.avaya.com> <AANLkTiksRlgdu7HIjSbPqq6u-XM-wtbnlX3U9a3Nerb8@mail.gmail.com> <AANLkTimrLwQklCZG31MT19ddULanpOozJe_z2Dz4rvRY@mail.gmail.com>, <4C1A26AE.2060401@cisco.com>
In-Reply-To: <4C1A26AE.2060401@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dispatch@ietf.org" <dispatch@ietf.org>
Subject: Re: [dispatch] Conceptual proposal for extensibility of Alert-Info URNs
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Jun 2010 19:32:20 -0000

From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat [pkyzivat@cisco.com]

> I don't see a problem there. In the general case, if there are multiple
> URIs then the recipient has to decide how to rationalize them into
> something to be done. So what is wrong with giving some guidance in that
> regard?

We could do that, but it seems to me to be opening a can of worms, in
that the guidance would be (in the general case) how to rationalize an
arbitrary set of URIs.  If we limit the rationalization process to the
elements of a single URN of a particular namespace, the problem
becomes simpler.

> Requiring all the categories to be specified in one URN has the downside
> that all category values need to be standardized as part of a single URN
> spec.

Strictly speaking, you don't have to define the entire set of standard
categories in one RFC.  You do need some sort of registry for them and
their standardized values, but you can extend the registry with new
RFCs.  Of course, the vendor-specific extensions aren't cataloged
anywhere.

> Conversely, consolidating multiple URNs gives the potential to
> define a new category via an entirely new URN scheme. (I guess we
> should discuss if that is a good thing or a bad thing.)

I'd vote for considering that to be a bad thing.

Dale

v2.23.0 | Report a Bug | By Email