Re: [salud] Reply to Pearl Liang (IANA)

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 25 April 2014 20:09 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 D3D0B1A0690 for <salud@ietfa.amsl.com>; Fri, 25 Apr 2014 13:09:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.865
X-Spam-Level: **
X-Spam-Status: No, score=2.865 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_54=0.6, J_CHICKENPOX_66=0.6, J_CHICKENPOX_84=0.6, MANGLED_BELOW=2.3, 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 Q3N8zkq0GWQ3 for <salud@ietfa.amsl.com>; Fri, 25 Apr 2014 13:09:28 -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 6783E1A0680 for <salud@ietf.org>; Fri, 25 Apr 2014 13:09:28 -0700 (PDT)
Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta04.westchester.pa.mail.comcast.net with comcast id uJyj1n0021ei1Bg54L9MZc; Fri, 25 Apr 2014 20:09:21 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id uL9M1n0093ZTu2S3kL9Mdz; Fri, 25 Apr 2014 20:09:21 +0000
Message-ID: <535AC0F1.3050906@alum.mit.edu>
Date: Fri, 25 Apr 2014 16:09:21 -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.4.0
MIME-Version: 1.0
To: salud@ietf.org
References: <201404251959.s3PJxXdj027687@hobgoblin.ariadne.com>
In-Reply-To: <201404251959.s3PJxXdj027687@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=1398456561; bh=IzfawhpPJNlpU8joujVPltU5RtxV+YzagMe2bzlf0GQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=u5vEzs98TCWKCMFiJWoOe08VviJtiCb0PiCczGYzLMzTXDKtwF0MJI7En6IKDa/iG 5bzNNCF6omU2DdTkuU8VglrZ1rGSwHocp0HcOT0Aw0Of9pY74mcRJDZOsw9xQtMsqn ILhs2sKyTSIkvu3tNQT07PpjL8DTIk3UcywMEtbjFYTfzx0Py3MuuFPvKBIsWMh2C+ 3nlgwmTuYcXhles+FlAkQvNPib2mDqhHasnzKuPzJCTOcHkxu3/huFF2H0bjNn8Rez BTqPXLiYWCE5x8NzAqVzS4YPvsCY3cBjZE8FmXdHpbcHe0YwgubDzLqRZP1Zb3q0UU ZJlHpWejMrp2A==
Archived-At: http://mailarchive.ietf.org/arch/msg/salud/lb_dKNcN60XnjhYftZjXahCSmbE
Subject: Re: [salud] 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: Fri, 25 Apr 2014 20:09:32 -0000

Dale,

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.

	Thanks,
	Paul

On 4/25/14 3:59 PM, Dale R. Worley wrote:
> [as an author]
>
> I have reformatted and somewhat revised my proposed response to IANA.
> The authors generally seem to agree with my response; I want to
> provide the final draft of the message to verify our agreement and
> solicit any improvements you have.  If I don't hear otherwise, I will
> send this on Wednesday morning.
>
> Dale
> ----------------------------------------------------------------------
> From: worley@ariadne.com (Dale R. Worley)
> Sender: worley@ariadne.com (Dale R. Worley)
> To: drafts-lastcall@iana.org
> Subject: [IANA #755327] Last Call: <draft-ietf-salud-alert-info-urns-12.txt> (URNs for the Alert-Info Header Field of the Session Initiation Protocol (SIP)) to Proposed Standard
> CC: salud-chairs@tools.ietf.org,
>          draft-ietf-salud-alert-info-urns@tools.ietf.org
> --text follows this line--
>> IANA understands that, upon approval of this document, there are two
>> actions which IANA must complete.
>
> This is correct.
>
>> First, in the Formal URN Namespaces subregistry of the Uniform
>> Resource Names (URN) Namespaces registry located at:
>>
>> http://www.iana.org/assignments/urn-namespaces/
>>
>> a new URN will be registered as follows:
>>
>> URN Namespace: alert
>> Reference: [ RFC-to-be ]
>
> This is correct.
>
>> Second, a new registry called the Alert URN Identifiers registry is
>> to be created.
>
> This is correct.
>
>> New URNs in the Alert URN Identifiers Registry are created through
>> Standards Action as defined by RFC 5226.
>
> The process is more complex than that; the details are in section 9.1
> of the RFC:
>
>     The policy for adding a new standard <alert-category> is 'Standards
>     Action'.  The policy for adding <alert-identifiers>s or patterns of
>     <alert-identifiers>s within a particular <alert-category> may differ
>     for each <alert-category>and MUST be defined by the document defining
>     the corresponding <alert-category>.
>
> That is:  New "alert-categories" (items that do not contain a colon)
> are created by Standards Action.  The policy for new
> "alert-identifiers" (items containing a colon) is set by the
> alert-category that it starts with.  All existing alert-categories
> specify the policy Standards Action for adding alert-identifiers.  The
> update policy for any alert-category will be stated in the RFC that
> defines it, so the "Reference" column implicitly specifies the update
> policy for that alert-category.
>
> Perhaps it would help to add a column "update policy" to this
> registry, which for each alert-category will contain the updating
> policy for alert-identifiers in that alert-category.  (This column
> would be empty for alert-identifiers.)
>
> Or perhaps this registry should be divided into two registries, one
> for alert-categories (listing an update policy for the related
> alert-identifiers) and a second registry for the alert-identifiers
> (without an update policy column).
>
> What does IANA recommend for organizing this information?
>
>> QUESTIONs:
>> Should this new registry a sub-registry of the registry
>> 'Service URN Labels' located at
>> http://www.iana.org/assignments/urn-serviceid-labels?  Or is this new
>> registry 'Alert URN Identifiers' a stand-alone with a brand new URL?
>>
>> Then, if the latter, what should be the name of the master "Parameter"
>> registry?  Is Uniform Resource Names (URN)?  See iana.org/protocols for
>> a list of main registry pages and the registries they include.
>
> The new registry will be a new registry named "Alert URN Identifiers"
> under the protocol name "Uniform Resource Names (URN)", and thus will
> be alongside "URN Service Labels", not a sub-registry of it.
>
>> IANA understands that the initial registrations in this new registry
>> are to be collected from section 9.2.1 through 9.2.6 of the current
>> document. IANA understands that the initial registry will look like
>> this:
>>
>> <alert-category>/ Reference Description
>> <alert-identifier>
>> --------------------------------------------------------------------------
>> service [ RFC-to-be ] Specific telephony
>> service used in this
>> call
>> service:normal [ RFC-to-be ] Normal ring/ringback
>> rendering (default value)
>> service:call-waiting [ RFC-to-be ] Call waiting was
>> initiated at the other side
>> of the call
>> service:forward [ RFC-to-be ] Call has been forwarded
>> service:recall:callback [ RFC-to-be ] Recall due to callback
>> service:recall:hold [ RFC-to-be ] Recall due to call hold
>> service:recall:transfer [ RFC-to-be ] Recall due to transfer
>> source [ RFC-to-be ] Classification
>> of the other party
>> to the call
>> source:unclassified [ RFC-to-be ] Unclassified ring/ringback
>> rendering (default value)
>> source:internal [ RFC-to-be ] User at the other side of
>> the call is internal to the
>> enterprise or PBX system
>> source:external [ RFC-to-be ] User at the other side of
>> the call is external to the
>> enterprise or PBX system
>> source:friend [ RFC-to-be ] User at the other side of
>> the call is a friend
>> source:family [ RFC-to-be ] User at the other side of
>> the call is a family member
>> priority [ RFC-to-be ] Priority of the
>> call
>> priority:normal [ RFC-to-be ] Normal ring/ringback
>> rendering (default value)
>> priority:low [ RFC-to-be ] Low priority call.
>> priority:high [ RFC-to-be ] High priority call
>> duration [ RFC-to-be ] Duration of alerting signal
>> alerting signal
>> duration:normal [ RFC-to-be ] Normal ring/ringback
>> rendering (default value)
>> duration:short [ RFC-to-be ] Shorter than normal
>> duration:long [ RFC-to-be ] Longer than normal
>> delay [ RFC-to-be ] Delay of rendering of alerting
>> of alerting signal
>> delay:none [ RFC-to-be ] Immediate alerting
>> (default value)
>> delay:yes [ RFC-to-be ] Delayed alerting
>> locale [ RFC-to-be ] Location-specific
>> alerting signals
>> locale:default [ RFC-to-be ] Alerting not location
>> specific
>> (default value)
>> locale:country:<ISO 3166-1 country code>
>> [ RFC-to-be ] Alerting according to the
>> conventions of the specified
>> country
>>
>> IANA understands that these two actions are the only ones that need
>> to be completed upon approval of this document.
>
> The list of initial registrations in your e-mail is correct (allowing
> for the irregular use of line breaks in the original e-mail).  That
> is, it is correct in regard to the data items to be recorded; the
> proposed registry may be organized differently if IANA recommends
> doing so (as discussed above).
>
> Dale, for the authors of ietf-salud-alert-info-urns
> ----------------------------------------------------------------------
> [EOF]
>
> _______________________________________________
> salud mailing list
> salud@ietf.org
> https://www.ietf.org/mailman/listinfo/salud
>