Re: [salud] The registry structure

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 01 May 2014 16:58 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 380F81A0926 for <salud@ietfa.amsl.com>; Thu, 1 May 2014 09:58:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 HRhwyP4dk9rQ for <salud@ietfa.amsl.com>; Thu, 1 May 2014 09:58:04 -0700 (PDT)
Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAFB1A091C for <salud@ietf.org>; Thu, 1 May 2014 09:58:04 -0700 (PDT)
Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta04.westchester.pa.mail.comcast.net with comcast id wchl1n0040bG4ec54gy2ji; Thu, 01 May 2014 16:58:02 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id wgy11n00U3ZTu2S3Pgy1Po; Thu, 01 May 2014 16:58:02 +0000
Message-ID: <53627D19.1070009@alum.mit.edu>
Date: Thu, 01 May 2014 12:58:01 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: salud@ietf.org
References: <201404251959.s3PJxXdj027687@hobgoblin.ariadne.com> <535AC0F1.3050906@alum.mit.edu> <201404302209.s3UM9xPV002457@hobgoblin.ariadne.com>
In-Reply-To: <201404302209.s3UM9xPV002457@hobgoblin.ariadne.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1398963482; bh=4u0MZUfNXVwIJJL4FhJmHastMsRlm2xNSsyI7bJqdSk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=FqM8S310zFqJNkdHnDT7erxFsBrnPWDmK2nQvfGSv1RxiQg45WzDnYwkg7/GcOXPQ Vl24F4XI4DOeazWWKvE6zzcnImkx6FqSatIZr7Rs5Q8W7Rn2o0SR7xiw3I9vbYyaRy 3EKnh5bJi3QWsQvMYsQpsf85423NOcb+NTxXWqQ0+jz6UeMSaHIu/anXRdTTECj7im frI9zeFlC31xjzudO7lmXiGvoyUrt70N8idshv1XiuMk+E/Ajuhv2p2H5KemuJ3dqM oXb/qlFR+xn6IiYzsfIjecrZ5Z8asaJBGp4t6N4IM9oSzwoYUaV2TE1yhKaDCs8JZL VxGc3ndyOPCNQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/salud/3x1HDzk7mIkltiV2yRgOyEVmCHg
Subject: Re: [salud] The registry structure
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list <salud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/salud>, <mailto:salud-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/salud/>
List-Post: <mailto:salud@ietf.org>
List-Help: <mailto:salud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/salud>, <mailto:salud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 May 2014 16:58:05 -0000

I agree with your proposal, except that the names of the tables are 
quite cumbersome. How about:

s/Alert URN Identifiers alert-categories/Alert URN alert-categories/
s/Alert URN Identifiers alert-identifiers/Alert URN alert-identifiers/

	Thanks,
	Paul

On 4/30/14 6:09 PM, Dale R. Worley wrote:
> [as an author]
>
>> From: Paul Kyzivat <pkyzivat@alum.mit.edu>
>
>> My only comment is that it is probably better that we decide what we
>> want the registry to look like than to let iana do it for us.
>
> I am looking at the following pages for examples:
> the "Uniform Resource Names (URN)" section of http://www.iana.org/protocols
> the "Service URN Labels" page,
> http://www.iana.org/assignments/urn-serviceid-labels/urn-serviceid-labels.xhtml
> the "Sieve Extensions" page,
> http://www.iana.org/assignments/sieve-extensions/sieve-extensions.xhtml
> (because it has complicated registration procedures).
>
> It seems to me that we want "Alert URN Identifiers" to be an item
> under "Uniform Resource Names (URN)", and we want it to point to a
> separate web page, as "Service URN Labels" does.
>
> How do we want to handle the registration procedures specification?
> IANA wants to know this and probably needs to know it.
>
> Most tables give the registration procedures in the header of the
> table.  E.g.,
>
>      URN Service Labels
>
>      Registration Procedure(s)
> 	Standards Action
>
>      Reference
> 	[RFC5031]
>
> But the Sieve table has a separate table that gives registration
> procedures:
>
>      Range                                 Registration Procedures
>      -----                                 -----------------------
>      vendor-controlled                     First Come First Served
>          (name begins with "vnd.")
>      IETF-controlled (no "vnd." prefix)    Standards track or
>                                            IESG-approved experimental RFC
>
> It would be simpler if there was one combined table, but it would be
> difficult to find a place to specify that alert-categories require
> standards action.
>
> Perhaps we should separate the alert-categories into a separate table:
>
>      Alert URN Identifiers alert-categories
>
>      Registration Procedure(s)
> 	Standards Action
>
>      Reference
> 	[RFCxxxx]
>
>      Name       Description               Reference     Registration Procedure(s)
> 					               for alert-identifiers
>      ----       -----------               ---------     -------------------------
>      service    Specific telephony        [RFCxxxx]     Standards Action
>                 service used in this call
>      source     Classification of the     [RFCxxxx]     Standards Action
>                 other party to the call
>
> and then
>
>      Alert URN Identifiers alert-identifiers
>
>      Registration Procedure(s)
> 	As specified in the corresponding alert-category
>
>      Reference
> 	[RFCxxxx]
>
>      Name              Description                                    Reference
> 					
>      ----              -----------                                    ---------
>      service:normal   Normal ring/ringback rendering (default value)  [RFCxxxx]
>      service:call-waiting                                             [RFCxxxx]
>                       Call waiting was initiated at the other side
>                       of the call
>      source:unclassified	                                             [RFCxxxx]
>                       Unclassified ring/ringback rendering (default
> 	             value)
>      source:internal  User at the other side of the call is internal  [RFCxxxx]
>                       to the enterprise or PBX system
>
> What do people think?
>
> Dale
>
> _______________________________________________
> salud mailing list
> salud@ietf.org
> https://www.ietf.org/mailman/listinfo/salud
>