Subject: [salud] New version of the ABNF-syntax

From: Laura Liess <[email-masked]>
Date: Wed, 13 Feb 2013 15:46:42 +0100

Hi,

Because we had several changes and discussions which affect the
syntax,  I send a new version to the list, including the rules for
<date>.  I used the <provider-id>,  <MM> and <DD> definitions from the
RFC 4198.
Please let me know what you think of it.

       alert-URN         = "urn:alert:" alert-identifier
       alert-identifier    = alert-category ":" alert-indication
       alert-category    = name/private-name
       alert-indication   = alert-name *(":" alert-name)
       alert-name         = name/private-name
       name                = label
       private-name      = label"@"provider-id["(" date ")"]
       provider-id          = 1*(label ".") toplabel
       date                  = [CC] YY ["-" MM ["-" DD] ]
       label                  = let-dig [ *let-dig-hyp let-dig ]
       let-dig-hyp          = let-dig / "-"
       let-dig                = ALPHA / DIGIT
       YY                    = CC
       CC                    = DIGIT DIGIT
      MM                    = ("0" %x31-39) / ("1" %x30-32)
      DD                     = ("0" %x31-39) / (%x31-32 DIGIT) / "30" / "31"
      ALPHA               = %x41-5A / %x61-7A   ; A-Z / a-z
      DIGIT                  = %x30-39 ; 0-9
      DIGIT-1-9             = %x31-39 ; 1-9
      DIGIT-2-9             = %x32-39 ; 2-9

    Following rules apply to the <date> usage:
       a) A provider is permitted to use any <date> within its domain
name ownership time period.
       b) If the <date> is absent, it defaults to 2013-01-01.
       c) If <DD> or <MM> are absent each defaults to 01.
       d)  If <CC> is absent it defaults to 20.
       e)  Comparison is based on the full <CCYY-MM-DD> after defaults
have been filled in.
       f)   A provider is allowed to use a domain name without a date
if he owns the domain at the default year 2013 or if he is able to
verify that he is the first owner of the domain, e.g. by checking
reliable domain history tools.   Note: We assume that the domain
ownership does not change during the same year.

Thank you
Laura

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 13 Feb 2013 16:13:40 +0100

Not clear from this extract what associated normative references you have. 

They need to at least cover which calendar is in use, and how sequences of digits or letter digits are converted into days or months (for example is January "01" or "10" and indeed is January the 1st month.

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Laura Liess
> Sent: 13 February 2013 14:47
> To: [email-masked]
> Subject: [salud] New version of the ABNF-syntax
> 
> Hi,
> 
> _______________________________________________
> salud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/salud

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 Feb 2013 13:03:36 -0500

>         alert-name         = name/private-name

Since private-name is now allowed as a category as well as an 
alert-name, the above can be simplified further:

        alert-URN         = "urn:alert:" alert-identifier
        alert-identifier  = alert-category ":" alert-indication
        alert-category    = alert-name
        alert-indication  = alert-name *(":" alert-name)
        alert-name        = label/private-name

>         provider-id          = 1*(label ".") toplabel

Definition of toplabel is missing.

> ownership does not change during the same year.

I'd like to propose a major change to (f):

"The meaning of a private-name with a particular domain name and date is 
specified by the owner of the domain at that date. The first owner of a 
domain may specify the meaning of private-names with dates prior to 
first ownership. As a consequence, the first owner of a domain may 
specify the meaning of a private-name that contains no date."

(My point is that anybody can *use* a private name with any date they 
want. The only issue is what (if anything) it *means*. Since there is no 
registration for private-names, we can just talk about it in a general way.)

I'm not entirely satisfied with the above. A private-name out of context 
doesn't really have a meaning. It is the whole alert-identifier that has 
a meaning. But I don't know how to say this in a comprehensible way.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 13 Feb 2013 14:56:54 -0500 (EST)

> From: "DRAGE, Keith (Keith)" <[email-masked]>
> 

Yeah, we need to put in a reference to RFC 3339 in somewhere.  But for
discussion purposes, you can safely assume that's what we mean.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 13 Feb 2013 16:05:11 -0500 (EST)

(as an individual)

OK, we can see that this is going well because the ABNF is quite
simple and clear.  I've made the following adjustments in the version
below:

- aligned the columns and normalized the spacing between elements
- put blank lines to break the rules in to sections, and reordered the rules
- applied Paul's simplification
- changed the rule "YY=CC" to "YY=DIGIT DIGIT", because YY is
    semantically different from CC
- removed DIGIT-1-9 and DIGIT-2-9, because they are not used
- added a rule for "toplabel"
- broken private-name into two parts, because one of the rules needs
  to refer to the provider-id-and-date part

      alert-URN         = "urn:alert:" alert-identifier
      alert-identifier  = alert-category ":" alert-indication
      alert-category    = alert-name
      alert-indication  = alert-name *(":" alert-name)
      alert-name        = label / private-name
      name              = label
      private-name      = label "@" provider
      provider          = provider-id ["(" date ")"]
      provider-id       = 1*(label ".") toplabel
[I'm not sure I like the names of the two preceding rules.]

      toplabel          = ALPHA [ *let-dig-hyp let-dig ]
      label             = let-dig [ *let-dig-hyp let-dig ]
      let-dig-hyp       = let-dig / "-"
      let-dig           = ALPHA / DIGIT

      date              = [CC] YY [ "-" MM ["-" DD] ]
      CC                = DIGIT DIGIT
      YY                = DIGIT DIGIT
      MM                = ( "0" %x31-39 ) / ( "1" %x30-32 )
      DD                = ( "0" %x31-39 ) / ( %x31-32 DIGIT ) / "30" / "31"
      ALPHA             = %x41-5A / %x61-7A   ; A-Z / a-z
      DIGIT             = %x30-39 ; 0-9

I want to make two modifications so that the ABNF symbols can be used
to describe the semantics more easily:

1. I want to have a symbol that refers to the component of the URN that
can be removed during the resolution algorithm.  Currently, alert-name
is used for both alert-category and as a component of
alert-indication.

2. I want to have a syntactic distinction between alert-names which have
standard meanings and alert-names which are privately defined.

However, both of these changes are messy and unclear when written in
ABNF.  So I will see if I can use semantic specifications to achieve
the same result.

The semantic rules are:

1) provider-id:  This is intended to match the allowed ABNF for domain
names.  (What is the correct normative reference?  With
internationalization, is our syntax still correct?)

2) date:  <date> syntax is a subset of ??? in RFC 3339.

2a) If <date> is absent from <private-name>, it defaults to 2013-01-01.
2b) If <DD> or <MM> are absent, each defaults to 01.
2c) If <CC> is absent, it defaults to 20.

In all situations, including comparison of URNs and determining which
entity defines the meanings of <alert-name>s, <provider>s are
interpreted as if they contain <date> values with a full "CCYY-MM-DD"
value, which is determined according to the above rules.

3) Comparison of URNs:

   Comparison is case-insensitive, considering the URNs as character
   strings (but with respect to rule (2)).

4) Removing components when interpreting URNs:
   (section 8.1 step (b))

   The <alert-name>s of the URN are removed sequentially from back to
   front, until the first <alert-name> in the <alert-indication> is
   removed, at which point the URN is discarded from consideration.

5) Definition of meaning of <label>s:

5a) A <provider> has an "owner", which is the entity that was the
    registered owner of the domain name <provider-id> on the date
    <date> (with respect to rule (2)).

5b) If an entity is the first registrant of a domain name
    <provider-id>, it owns all <provider>s with that <provider-id> and
    all <date>s preceding when it registered the domain name.

5c) The entity owning <provider> defines the meaning of a
    <private-name>, whether it is used as an <alert-category> or an
    <alert-indication>.

5d) The entity owning <provider> within a <private-name> (in either an
    <alert-category> or an <alert-indication>) defines the meaning of
    each <alert-indication> which is a <label> following that
    <private-name> and preceding the next <alert-indication> which is
    a <private-name>.

5e) Entities SHOULD use only one <provider> value for all <private-name>s
    that they define.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 Feb 2013 22:23:59 -0500

Thanks Dale! That cleans things up well, and resolves the problem I had.

One thing: the rule defining 'name' is never used, so it can be omitted.

	Thanks,
	Paul

---

From: Laura Liess <[email-masked]>
Date: Mon, 18 Feb 2013 15:24:40 +0100

Dale,

Thank you for adding the rules. I like them :-). I have following
proposals on the two open items.

> 2) date:  <date> syntax is a subset of ??? in RFC 3339.

I would propose following text, which is a modification of the
corresponding text in the rfc 4198:

"<date> is a date in ISO 8601 Extended Format ([CC]YY["-"MM["-"DD]]),
and MUST correspond to a specific day on which the organization
allocating the URN owned the domain name specified in the provider-id.
 If not included, the default value for MM and DD is "01". "

> internationalization, is our syntax still correct?)

This reminds me of Alfred's comment #1 and the discussion
http://www.ietf.org/mail-archive/web/salud/current/msg00260.html and
previous threads.

By then, we (also Alfred) agreed on the following text, based on the RFC 5890:

"The <alert-indication>s are hierarchical identifiers.  The set of
allowable characters is the same as that for domain names [RFC1123].
Labels used in <standard-name> MUST comply with the syntax for Non
Reserved LDH-labels [RFC5890].  Labels used in <private-name> MUST
comply with the syntax for Non Reserved LDH-labels or for A-labels
[RFC5890]. Comparisons MUST follow the comparison rules for the
corresponding type of label.  Registered URNs MUST be transmitted as
registered. A new name MUST NOT be registered if it is equal by the
comparison rules above to an already registered name."

However, we changed the syntax since then. IMO, with Dale's the syntax
after "name" is deleted,  the second and third sentences in the above
text should be modified as follows:

" <Label>s used in && <alert-name>s excepting <label>s used in
<provider-id>s && MUST comply with the syntax for Non Reserved
LDH-labels [RFC5890].  Labels used in &&<provider-id>s&& MUST
comply with the syntax for Non Reserved LDH-labels or for A-labels
[RFC5890]. " (I put the modified text  between  &&..&&.)

We also could used different names for the two types of labels, e.g.
"label" and ""provider-id-label", but I am niot sure we want this.

Thank you
Laura

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Feb 2013 11:52:48 -0500

>   If not included, the default value for MM and DD is "01". "

I've been trying to explain why this sort of wording doesn't work for 
me, several times.

The problem is that the URN is a *reference*. Typically it won't be 
written by the owner of the domain. Rather it will be written by someone 
who wants to take some special alerting action. So it isn't the 
allocation of the URN that is restricted - it is the *meaning* of that 
URN. For example, it may be that example.com was owned by a startup in 
2013, but then they go bankrupt and cease owning the domain. Then in 
2014 example.com is bought by a different company. I may have a business 
relationship with this second company, and so define some special 
alerting for calls from them, tagging my alert with "[email-masked](2014)".

Of course somebody needs to insert the alert-info header with the URN in 
the call. It *could* be the caller (example.com) in which case the 
language you have above would apply. But it could also be a server on my 
receiving side, that authorizes incoming calls and assigns alert URNs. 
This server is free to use whatever URN it wants, but the meaning will 
vary. IMO this usage is much more likely - I am not likely to trust 
Alert-Info URNs assigned by the caller. Or if I do I will most likely 
screen/filter them.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 18 Feb 2013 13:54:23 -0500 (EST)

(as an individual)

> From: Laura Liess <[email-masked]>
> 

Thanks!

>  If not included, the default value for MM and DD is "01". "

This looks good to me.  RFC 3339 Appendix A contains the BNF from ISO
8061 for comparison.  It might be helpful to include a reference to
RFC 3339, since it seems to be the RFC people use as a reference for
date syntax and semantics.

However, there are two parts to this issue.  One is the syntax, which
you write as:

> [...]

We want to add the default for the century as well.  This encompasses
what I wrote as (2b) and (2c).

And the other is the semantics:

> MUST correspond to a specific day on which the organization

But the semantics is more complicated than that, it includes what I

> "label" and ""provider-id-label", but I am niot sure we want this.

Ah, yes, I'm starting to remember that discussion.

> allowable characters is the same as that for domain names [RFC1123].

I just looked at RFC 1123, and it doesn't seem to have any BNF.  So
it's a background reference for domain names, but not really
normative.  We may want to remove the reference, as the references to
RFC 5890 below tell the real syntax.

> <Label>s used in <alert-name>s excepting <label>s used in
> <provider-id>s MUST comply with the syntax for Non Reserved
> LDH-labels [RFC5890].  Labels used in <provider-id>s MUST
> [RFC5890].

(I use RFC 5890 figure 1 on page 10 as a reference for terms like
"A-label".)

There are three sorts of strings that we may want to treat separately:

One sort are domain names.  These are called <provider-id> in the
current BNF.  As far as I can tell from RFC 5890, valid domain names
(when represented on the wire) must be composed of:

- NR-LDH labels (ordinary ASCII labels that meet certain validity
  rules, especially not starting with "xn--", which indicates an
  A-label), and
- A-labels (non-ASCII labels encoded with Punycode).

The second sort are "privately-defined labels", that is, the <label>
part of a <private-name> and the <alert-indication>s that are <label>s
that follow it before the next <private-name>.  These are the ones
covered by:

We probably want to allow these to be internationalized as well.  If
so, we would define these as "NR-LDH / A-label".

The third sort are the "standardized labels", the <labels> that aren't
covered by the preceding two categories.  We probably want to
restrict these to traditional ASCII labels, so their syntax is
"NR-LDH".

OK, now that I've thought that through, I can compare it with your
text.  I make the following observations:

- In my listing of rules 1, 2, 3, etc. in
  http://www.ietf.org/mail-archive/web/salud/current/msg00341.html,
  though I specify when a <label> *is* defined by a private entity, I
  don't state when a <label> *is not*, that is, when its definition
  must be standard.  That would be accomplished by:  "(5x) The meaning
  of a <label> whose meaning is not defined by an entity according to
  the rules (5c) and (5d) is defined by standardization."  (That
  wording is not quite correct.)

- It would make discussion easier if the <label>s within a
  <provider-id> were a different nonterminal symbol.  Then we could
  say (taking an example from your text above), "<Label>s MUST comply
  with the syntax for Non Reserved LDH-labels [RFC5890]." rather than
  "<Label>s used in <alert-name>s excepting <label>s used in
  <provider-id>s MUST comply with the syntax for Non Reserved
  LDH-labels [RFC5890]."

- Your wording "<Label>s ... MUST comply with the syntax for Non
  Reserved LDH-labels [RFC5890]" means that only "ASCII labels" can be
  used for privately-defined alert-names.  Do we want this
  restriction?  Or do we want to allow entities to define
  "internationalized" alert-names?  To allow internationalization, we
  would say, "<labels> MUST comply with the syntax for Non Reserved
  LDH-labels or for A-labels [RFC5890]."

- I'm sure we want to restrict the standardized <label>s to be NR-LDH
  labels, i.e., ASCII.  We can state such a restriction in the RFC, or
  we can just assume that we will never define non-ASCII standardized
  labels.

> Comparisons MUST follow the comparison rules for the
> corresponding type of label.

I'm taking the comparison rule for internationalized domain names from
RFC 3490 section 2:

   In IDNA, equivalence of labels is defined in terms of the ToASCII
   operation, which constructs an ASCII form for a given label, whether
   or not the label was already an ASCII label.  Labels are defined to
   be equivalent if and only if their ASCII forms produced by ToASCII
   match using a case-insensitive ASCII comparison.  ASCII labels
   already have a notion of equivalence: upper case and lower case are
   considered equivalent.  The IDNA notion of equivalence is an
   extension of that older notion.  Equivalent labels in IDNA are
   treated as alternate forms of the same label, just as "foo" and "Foo"
   are treated as alternate forms of the same label.

That seems to mean that internationalized labels are compared by first
converting them into ASCII strings and then comparing the ASCII
strings case-insensitively.  Since Alert-Info URN domain names are
already in their ASCII form, this means that the URN domain names can
just be compared case-insensitively.

And the <label>s that are not part of domain names are also to be
compared case-insensitively.

So I think we can safely reduce all that to the statement that all
comparisons are to be done case-insensitively.  It would certainly
make life easier for implementers if we state that directly.  (I
suppose we need a reference to RFC 3490 in regard to comparing
internationalized domain names.)

> Registered URNs MUST be transmitted as

We probably want to make it clear what we are concerned about:

    > Registered URNs MUST be transmitted with the case in which they are
    > registered. A new name MUST NOT be registered if it is
    > case-insensitively equal to an already registered name."

(I see that I am using "standardized" where the draft uses
"registered".)

Dale

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 18 Feb 2013 21:20:16 +0100

Aside from the rest of this discussion, I believe we need the ISO 8601 reference to at least express:

1)	Gregorian calendar
2)	"31" represents the 31st rather than 13th

Keith

> Dale R. Worley
> Sent: 18 February 2013 18:54
> To: Laura Liess
> Cc: [email-masked]
> Subject: Re: [salud] New version of the ABNF-syntax
> 
> (as an individual)
>

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 18 Feb 2013 16:05:28 -0500 (EST)

> From: Paul Kyzivat <[email-masked]>
> 
> me, several times.  [...]

I tried to avoid this problem by describing which <provider>s a given
entity "owns", and thus has the right to define the meaning of
<label>s that are governed by that <provider>:

   http://www.ietf.org/mail-archive/web/salud/current/msg00341.html

Does that approach work for you?

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 18 Feb 2013 16:05:09 -0500 (EST)

> 2)	"31" represents the 31st rather than 13th

RFC 3339 references ISO 8601, so I don't think we *need* to reference
ISO 8601 as long as we reference RFC 3339.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Feb 2013 16:11:49 -0500

> 2)	"31" represents the 31st rather than 13th

No. I think we should specify that we are using the Mayan calendar and 
Mayan base-20 arithmetic.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Feb 2013 16:39:01 -0500

> Does that approach work for you?

The issue isn't who is the "owner" of the label, but rather what rights 
are restricted to owners.

It is possible that the "owner" of a label neither inserts the URN into 
an Alert-Info nor defines the actual alert data structures in an 
endpoint that are selected by the Alert-Info URN. It may just strike 
some agreements with others about these things.

For instance, example.com may make it known that Bob and Carol work for 
the foo department with label [email-masked], while Ted and Alice work 
for the bar department with label [email-masked]. Then I may configure 
my incoming proxy to identify calls from Bob, Carol, Ted, and Alice, and 
insert a corresponding Alert-Info for them. And I may configure my 
devices to map [email-masked] and [email-masked] to the alerts I want 
to hear when getting calls from people in those departments.

I guess an alternative to the above is that I use my own private labels 
for those cases. But in any case, somebody other than the owner may be 
inserting the alert-info.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 18 Feb 2013 18:05:14 -0500 (EST)

> some agreements with others about these things.

Well, yes, that's why I phrase it, "The entity owning <provider>
... defines the meaning of ...".  The right that is restricted to
owners is to declare what that part of the URN means.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Feb 2013 18:12:49 -0500

> owners is to declare what that part of the URN means.

OK. WFM.

	Thanks,
	Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 19 Feb 2013 00:53:10 +0100

I am not sure I understand fully the issue here, but surely what matters is that the URN that is inserted has the semantics that are defined by the owner at the time given for the URN, not that they inserted it themselves, or that they owned the domain name at the time.

Thus the owner defines the semantics of the URN, but anyone can use it.

Regards

Keith

> Paul Kyzivat
> Sent: 18 February 2013 21:39
> To: Dale R. Worley
> Cc: [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Feb 2013 19:02:49 -0500

> Thus the owner defines the semantics of the URN, but anyone can use it.

Yes. The thing is that this does not define any normative behavior.

The person that inserts the URN can put in anything they like, and then 
it means what it means. If you inserted a URN without a date, then it 
has some meaning, even if it is not the meaning that you intended.

E.g. when you insert a URN you may omit the date, thinking that the 
current owner is the first owner. Its meaning is then defined by the 
first owner. If the current owner is not the first owner, then the only 
error is that you referred to a different meaning than you intended.

And if the person that defines the actual alert that this URN maps to 
makes the same mistake, then all is well.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 20 Feb 2013 10:42:19 -0500 (EST)

> makes the same mistake, then all is well.

That is, I think, an unavoidable problem here.  We can set up a
framework that defines who is permitted to "define the meaning" of a
URN, but "defining the meaning" of a URN has no conseqences at the
level of the operation of the protocol.  All we are doing is providing
guidance to the implementers who they should ask to learn the social
content of a particular URN.  (And we define a bunch of rules
regarding how certain URNs relate to other URNs, which URN is the most
important when processing a set of URNs, etc.)

This is somewhat like priority levels.  We define "emergency",
"urgent", etc., but there are no protocol consequences of those words,
their meaning has an effect only at higher levels of processing.

Dale

---

From: Laura Liess <[email-masked]>
Date: Thu, 21 Feb 2013 11:40:57 +0100

Dale,

a) Let me try to find out if I understood you correctly:

-  We want to allow internationalized <label>s for the <provider-id>,
this means Non Reserved LDH-labels or A-labels

-  We want to allow internationalized <label>s for "private alert
labels" (labels within the <private-name> preceding the "@" or lables
following a <private-name>).  This means Non Reserved LDH-labels or
A-labels.

- We want to allow only ASCII-labels for "standardised/registred alert
labels".  This means Non Reserved LDH-labels.

Is this correct or did I get something wrong?

b)

 > <private-name> and preceding the next <alert-indication> which is

Maybe I got something wrong, but it seems to me that the text above is
not completely consistent to the definitions in the draft:
 -  It seems to me that in your text the term "<alert-indication>" is
used for a string between two ":" which is a  single label  or a
<private-name>). In the draft, an <alert-indication> is a chain of
<lables>.

  - In your talk about the "meaning"  for <private-name>s and <label>s
(<alert-indication>s), while according to the draft only an
<alert-category> or an <alert-identifier> as a whole has a "meaning"
or a "description".

Thank you
Laura

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 21 Feb 2013 15:27:30 -0500 (EST)

(as an individual)

> Is this correct or did I get something wrong?

Yes, that is what I suggest.

The second point assumes that we want to allow private alert labels to
be internationalized.  I don't know if we have discussed that point,
but it seems like a good idea to me; it allows private labels in
users' own languages, and it won't cause any operational problems
(since A-labels are processed essentially the same way as
NR-LDH-labels).

> <private-name>). In the draft, an <alert-indication> is a chain of

(Based on the original version of "New version of the ABNF-syntax":)
Yes, you are correct.  I should have said <alert-name> rather than
<alert-indication>.  That changes (5d) to:

     5d) The entity owning <provider> within a <private-name> (in either an
     <alert-category> or an <ALERT-NAME>) defines the meaning of
     each <ALERT-NAME> which is a <label> following that
     <private-name> and preceding the next <ALERT-NAME> which is
     a <private-name>.

> <alert-category> or an <alert-identifier> as a whole has a "meaning"

You are correct.  Let me try to describe what I mean...  There is a
standard URN:

    urn:alert:source:internal

Suppose example.com wants to define a URN to describe an internal
source that is "secure" in some way:

    urn:alert:source:internal:[email-masked]

Now let us suppose that the UA army decides to augment a PBX purchased
from example.com to include a "top-secret" subcategory:

    urn:alert:source:internal:[email-masked]:[email-masked]

I want to express:

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

2) The additional meaning when "[email-masked]" is added to
"urn:alert:source:internal" is defined by example.com.

3) The additional meaning when "[email-masked]" is added to
"urn:alert:source:internal:[email-masked]" is defined by army.mil.

Of course, meaning 2 is dependent on meaning 1, and meaning 3 is
dependent on meaning 2.

I don't quite know how to express this, because, as you point out,
"[email-masked]" and "[email-masked]" have no meaning in
isolation.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 21 Feb 2013 17:22:57 -0500

> (since A-labels are processed essentially the same way as

I'm slightly concerned about this, for perhaps poor reasons.

1) allowing internationalized private labels but not for standard labels 
might bias some against defining a new standard label because they want 
to use internationalized names. I would rather not give that incentive 
for non-standard behavior.

2) allowing internationalized names will open Pandora's box for all 
sorts of issues about comparison of labels. Not permitting them will 
avoid the need to go down that rat hole.

	Thanks,
	Paul

---

From: Laura Liess <[email-masked]>
Date: Fri, 22 Feb 2013 16:13:34 +0100

Dale,

> (since A-labels are processed essentially the same way as

This was also my opinion. But after reading Paul's e-mail I have
doubts if we should do this. I would think we should keep it simpe if
we can.

Note:
Maybe the "prosa" could also become more simple if we have the same
syntactic rules for the  <label>s which do not apear in the
<provider-id>. We could then just distinguish in the syntax between
"alert-labels" and "domain-labels", like:

      alert-name        = alert-label / private-name
      private-name     = alert-label "@" provider
      provider            = provider-id ["(" date ")"]
      provider-id         = 1*(domain-label ".") toplabel

<Alert-label>s  MUST comply with the syntax for Non
Reserved LDH-labels [RFC5890]. <Domain-label>s MUST
comply with the syntax for Non Reserved LDH-labels or for A-labels
[RFC5890].
Comparisons MUST follow the comparison rules for the
corresponding type of label.  Registered URNs MUST be transmitted as
registered. A new name MUST NOT be registered if it is equal by the
comparison rules above to an already registered name.

What do you think?
I don't have any strong opinion about splitting the <label>s in
<alert-label> and  <domain-label> or not.

> "[email-masked]" and "[email-masked]" have no meaning in

This is exactly my point.  And I don't have any idea,  either.  I
don't have any problems with the text myself, I just suspect we have
to be very accurate with our text to pass through the URNBIS and IESG
review.

Thank you
Laura

5d) The entity owning <provider> within an <ALERT-CATEGORY> or
<ALERT-IDENTIFIER> ntifierCATEGORY>which is a <label> following that

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 22 Feb 2013 13:24:51 -0500 (EST)

(as an individual)

> doubts if we should do this. I would think we should keep it simpe if

I agree with you and Paul now.

Let me propose this:  We restrict private alert labels to be NR-LDH
labels (ordinary ASCII labels) at this time.  Later, we can amend the
standard to allow A-labels (internationalized labels).  Processing
software should not be confused if it sees an A-label as a private
alert label, because their syntax is very similar to NR-LDH labels.

Better, let us add a requirement that processing software MUST be able
to cope with internationalized <alert-label>s, even though we do not
now allow them:

After the text where we state the restrictions on the labels, such as:

Add:

    However, processes that interpret these URNs MUST correctly
    process URNs even if they contain arbitrary LDH labels as
    <alert-label>s.  (Of necessity, the process will not understand a
    URN containing an <alert-label> that is not a Non Reserved
    LDH-label, and so that <alert-label> and any following
    <alert-label>s will be ignored per the rules of Section 8.1.)

(Note:  An "LDH label" is what is normally called "an ordinary ASCII
label".  From RFC 5890:

   2.3.1.  LDH Label

   This is the classical label form used, albeit with some additional
   restrictions, in hostnames [RFC0952].  Its syntax is identical to
   that described as the "preferred name syntax" in Section 3.5 of RFC
   1034 [RFC1034] as modified by RFC 1123 [RFC1123].  Briefly, it is a
   string consisting of ASCII letters, digits, and the hyphen with the
   further restriction that the hyphen cannot appear at the beginning or
   end of the string.  Like all DNS labels, its total length must not
   exceed 63 octets.

)

> <alert-label> and  <domain-label> or not.

Yes, I think that split would make describing the semantic
restrictions simpler.

We might want to replace <toplabel> with <domain-label>.  It is true
that the final label in a domain name is much more restricted, but we
do not need to define or enforce that restriction in our document.

> to be very accurate with our text to pass through the URNBIS and IESG

I am sure you are right that we have to be very accurate.

Let me try with this:

In section 4, the namespace registration template, there is this
paragraph:

      The<alert-indication>s are hierarchical identifiers.  The set of
      allowable characters is the same as that for domain names
      [RFC1123].  Labels used in <standard-name> MUST comply with the
      syntax for Non Reserved LDH-labels [RFC5890].  Labels used in
      <private-name> MUST comply with the syntax for Non Reserved LDH-
      labels or for A-labels [RFC5890].  Comparisons MUST follow the
      comparison rules for the corresponding type of label.  Registered
      URNs MUST be transmitted as registered.  A new name MUST NOT be
      registered if it is equal by the comparison rules above to an
      already registered name.

This is the only place where we mention the fact that alert-info URNs
are hierarchical -- and we do not explain exactly what "hierarchical"
means.

Let us separate the first sentence into a separate paragraph, and add
this text to describe what "hierarchical" means:

      The <alert-indication>s are hierarchical identifiers.  An
      <alert-URN> asserts some fact or feature of the offered SIP
      dialog, or some fact or feature of how it should be presented to
      a user, or of how it is being presented to a user.  Removing an
      <alert-identifier> from a URN creates shorter a URN with a less
      specific meaning; the set of dialogs to which the longer URN
      applies is necessarily a subset of the set of dialogs to which
      the shorter URN applies.  (If first URN contains only one
      <alert-indication>, then the larger set is considered to be the
      set of all dialogs.)

      The specific criteria defining the subset to which the longer
      URN applies, within the larger set of dialogs, is considered to
      be the meaning of the <alert-indication>.  This meaning is
      relative to and depends upon the preceding <alert-category> and
      <alert-indication>s (if any).  The meanings of two
      <alert-indication>s that are textually the same but are
      preceded by different <alert-category>s or <alert-indication>s
      have no necessary connection.  (An <alert-category> considered
      alone has no meaning.)

      The entity owning <provider> defines the meaning of a <private-name>
      that is used as an <alert-indication>.

      The entity owning the <provider> within a <private-name> (in
      either an <alert-category> or an <alert-indication>) defines the
      meaning of each <alert-indication> which is a <label> that
      follows that <private-name> and that precedes the next
      <alert-indication> which is a <private-name> (if any).

      The meaning of all other <alert-indication>s is defined by
      standardization.

Dale