[salud] The registry structure (was: Reply to Pearl Liang (IANA))

worley@ariadne.com (Dale R. Worley) Wed, 30 April 2014 22:10 UTC

Return-Path: <worley@ariadne.com>
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id ADA411A6F13 for <salud@ietfa.amsl.com>; Wed, 30 Apr 2014 15:10:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=unavailable
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id tRL_W2VW6qRd for <salud@ietfa.amsl.com>; Wed, 30 Apr 2014 15:10:02 -0700 (PDT)
Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 826701A094C for <salud@ietf.org>; Wed, 30 Apr 2014 15:10:02 -0700 (PDT)
Received: from omta02.westchester.pa.mail.comcast.net ([]) by QMTA11.westchester.pa.mail.comcast.net with comcast id wLvP1n0040QuhwU5BNA0Cf; Wed, 30 Apr 2014 22:10:00 +0000
Received: from hobgoblin.ariadne.com ([]) by omta02.westchester.pa.mail.comcast.net with comcast id wNA01n00L1KKtkw3NNA0K2; Wed, 30 Apr 2014 22:10:00 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com []) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s3UM9xGF002458; Wed, 30 Apr 2014 18:09:59 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s3UM9xPV002457; Wed, 30 Apr 2014 18:09:59 -0400
Date: Wed, 30 Apr 2014 18:09:59 -0400
Message-Id: <201404302209.s3UM9xPV002457@hobgoblin.ariadne.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: salud@ietf.org
In-reply-to: <535AC0F1.3050906@alum.mit.edu> (pkyzivat@alum.mit.edu)
References: <201404251959.s3PJxXdj027687@hobgoblin.ariadne.com> <535AC0F1.3050906@alum.mit.edu>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1398895800; bh=okQ6VTqvEum/mbRmB2wFFrns+fHHtee2CJ8qPsqVF2w=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=m8XlJwil8v1jUL2wIHH/nDuKghsc0ZYD26w8ADCp0b16j/+Z0KWhTwdASnOk+Yzc/ uVoTItg7E5C2b5mOKGXF4vATsz+VCQvEMrCMmGtjCXhF/XjtdZWOM8nCYho8gtDkw5 EyeN5qu0TAhFx201uW0Jm4LZV5BILqHbondAb0KanlUszU9IV18Ddya0noxuxR0Avb Fp4avInx5k2WB5oUhGFG3Og5Zapr2qJKNlfSRG77CVXGnCT5wk63OdQjqJnogSQqem 7g+L+I3OxkOp1MICNtjg+T482TmmOr7TqLrkKEKUfNplbb0Fq8dHqt0pgj1I/FyneE GflqgoWuhGm8w==
Archived-At: http://mailarchive.ietf.org/arch/msg/salud/HifefThw_SPacm8oG16bGpJXFy0
Subject: [salud] The registry structure (was: Reply to Pearl Liang (IANA))
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: Wed, 30 Apr 2014 22:10:16 -0000

[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,
the "Sieve Extensions" page,
(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


But the Sieve table has a separate table that gives registration

    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


    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


    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
    source:internal  User at the other side of the call is internal  [RFCxxxx]
                     to the enterprise or PBX system

What do people think?