[salud] Section 7 update

[[e-mail] (Dale R. Worley)]

[as an individual]

I've revised section 7 ("extension rules") to make the terminology
match what we are using in the ABNF, and to provide a lot more
explanation and examples.

Comments?

Dale
----------------------------------------------------------------------
[[
Here, I am using "organization" rather than "entity".  "organization"
is more common in RFCs and much more common in ordinary speech.
It is also has a more specific meaning.

"organization" is much more common in RFCs than "organisation".

I am using "private" rather than "proprietary", because we have
usually used the term "private" in our discussions.

There are a number of additional notes below, marked with "***".
]]

7.  Extension Rules

7.1.  General Extension Rules

   The set of 'alert' URNs is extensible.  An extension "at the top
   level" creates an new <alert-category> (which represents a new
   alerting characteristic), an extension "at the second level"
   creates a new <alert-indication> value for an existing
   <alert-category>, an extension "at the third level" creates a
   subdivision of an existing <alert-indication> (that has one
   <alert-ind-part>), etc.  URNs allow (in principle) indefinite
   subdivision of existing <alert-indication> values, although most of
   the standard 'alert' URNs have only one level of subdivision and
   a few have two levels of subdivision.

   Designers of extensions should take care to derive the new URN from
   the most specific base URN which has the correct meaning; a new URN
   should have no semantic overlap with any sibling URN, i.e., there
   can be no calls to which both URNs could apply.

   The process for defining new standard 'alert' URNs is described in
   Section 6.1.  Adding new <alert-category>s and adding
   <alert-identifier> values other than via the "private" mechanism
   described in Section 7.2 is standards action.

*** The previous sentence implies that registering any standad alert
    URN is a standards action.  And now that I read that sentence, I
    remember that we've discussed the issue, and we decided that any
    new alert URN in the standard categories should be a standards
    action.  That should be put into section 6 (and removed from the
    paragraph above).

7.2.  Private Extension Rules

   The "<private-name>" syntax is used to create private extensions,
   extensions that are not registered with IANA.  The
   <private-name> has the form of an <alert-label> (which is an "ordinary
   ASCII DNS label"), followed by "@" and then a <provider> that
   designates the organization defining the extension.  A private
   extension URN is created by using a <private-name> as either an
   <alert-category> or an <alert-ind-part>.

   If the <private-name> is used as an <alert-category>, the
   characteristic of the alerting signal that the <alert-category>
   describes is defined by the organization.  If the <private-name> is
   used as the first <alert-ind-part>, the organization defines an
   alternative value for the standardized <alert-category> of the URN.  If the
   <private-name> is used as the second or later <alert-ind-part>, the
   organization defines the meaning of the URN as a subset of the
   meaning of the shorter URN resulting when the <private-name> (and
   any subsequent <alert-ind-part>s) are removed.
   
   Within a URN, all <alert-label> components that follow a
   <private-name> but are before any following <private-name>s are
   additional private extensions whose meaning is defined by the
   organization defining the <private-name>.

   A URN that contains a private extension can be further subdivided
   by the private extension of a different organization:  the second
   organization adds a <private-name> component containing a
   <provider> that is valid for the second organiztiion.

*** In the next paragraph, I use <alert-label>, but we really need a
    syntax term for "an <alert-ind-part> that is an <alert-label>.
    We need to look into that.

   The meaning of a <private-name> or an <alert-label> that is defined
   privately (because of a preceding <private-name>) is only fixed within
   the context provided by preceding <alert-name>s; these components
   have no meaning in isolation and there is no necessary relationship
   between the meaning of textually identical <alert-name>s in
   different contexts.

   Creating private extension 'alert' URNs is not a standards action
   and they are not registered with IANA.

7.3.  Interpreting <provider>

   The organization that defines a particular <private-name> is
   determined by the <provider> within the <private-name>.  An
   <alert-label> that follows a <private-name> is defined by the
   organization determined by the <provider> within the
   <private-name>.

   The organization determined by a <provider> is the organization
   that was the registered owner of the contained <provider-id> (which
   is a fully-qualified domain name) on the given date <date>
   (interpreted according to the following default rules).  If the
   <date> is omitted, it defaults to "2013-01-01".  If the century
   part <CC> is omitted, it defaults to "20".  If the month part <MM>
   or the day part <DD> is omitted, it defaults to "01".  In addition,
   if an organization is the first registrant of a domain name (over
   all time), it may use any <date> preceding when it registered the
   domain name.

   More specifically:  On every date on which an organization is the
   registered owner of a domain name, the organization acquires an
   intellectual property right to define the meaning of
   <private-name>s and <alert-label>s that are governed by a
   <provider> value specifying that domain name and that date
   (directly or by defaults).  If an organization is the first
   registrant of a domain name, on the date it obtains the
   registration, it also acquires those rights for all <provider>
   values specifying that domain name and any date before the date of
   registration.  Unless otherwise arranged, these intellectual
   property rights transfer if the organization transfers the right to
   use the domain name.  However, if the organization's registration
   expires and another organization acquires registration of the
   domain name de novo, the first organization retains the <provider>
   rights that it possessed regarding that domain name.

7.4.  Examples

7.4.1.  Subsetting an existing URN

   A company owning the domain name somecompany.example.com can
   define distinctive versions of <urn:alert:service:call-waiting>:

   urn:alert:service:call-waiting:[e-mail]
   urn:alert:service:call-waiting:[e-mail]

   It can create a more specialized URN that applies to a subset of
   the situations to which the first URN above applies:

   urn:alert:service:call-waiting:[e-mail]:xyz

   Because "xyz" follows "[e-mail]" (and there is
   no intervening <private-name>, its meaning is defined by the owner
   of the <provider> "somecompany.example.com" (whose implicit date is
   "2013-01-01").

7.4.2.  A new value within an <alert-category>

   A company owning the domain name somecompany.example.com can
   define URNs in the "service" category to express a new service that
   is not covered by any of the standardized URNs:

   urn:alert:service:[e-mail]

   However, before defining such a URN, the organization should verify
   that the set of calls to which the URN applies is not a subset of
   the set of calls for some existing URN.  If it is a subset, the
   extension URN should be a subdivision of the existing URN.

7.4.3.  A new <alert-category>

   A company owning the domain name somecompany.example.com can define
   an extension <alert-category> named "[e-mail]"
   with two values "a1" and "a2":

   urn:alert:[e-mail]:a1
   urn:alert:[e-mail]:a2

7.4.4.  Subsetting a private extension URN

   There is a standard URN:

       urn:alert:source:internal

   The company designed by "example.com(2013)" can define a URN to
   describe an internal source that is "secure" in some way:

       urn:alert:source:internal:[e-mail]

   The United States Army (army.mil) can to augment a PBX purchased
   from the company to be able to specify a "top-secret" subcategory
   of the "secure" category:

       urn:alert:source:internal:[e-mail]:[e-mail]
 
   The Army can further subset the "top-secret" category by defining
   the meaning of an additional <alert-label>:

       urn:alert:source:internal:[e-mail]:[e-mail]:sci

   Within this set of URNs:

   1) The meaning of <urn:alert:source:internal> is defined by the standard.

   2) The additional meaning when "[e-mail]" is added to
   <urn:alert:source:internal> is defined by the company designated by
   example.com.

   3) The additional meaning when "[e-mail]" is added to
   <urn:alert:source:internal:[e-mail]> is defined by the
   Army.

   4) The additional meaning when "sci" is added to
   <urn:alert:source:internal:[e-mail]:[e-mail]>
   is defined by the Army, because it is designated by the <provider>
   in the nearest preceding <private-name>.

7.4.5  Default <date>s

   The United States Army has had possession of the domain name
   "army.mil" since at least 1990.  Thus, it can use the following
   <provider> values (among many others):

       army.mil(1990)
       army.mil(2013-03)
       army.mil(2013-03-29)

   It can also use the following <provider> values, which all have the
   same meaning:

       army.mil
       army.mil(13)
       army.mil(13-01)
       army.mil(13-01-01)
       army.mil(2013)
       army.mil(2013-01)
       army.mil(2013-01-01)

   (Note that per Section 4, an organization SHOULD use only one
   <provider> value for all of the <private-name>s it defines.)

*** This reminds me that we have not incorporated the date defaults into
    the description of how we compare URNs.
----------------------------------------------------------------------