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

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

(as an individual)

> From: Laura Liess <[e-mail]>
> 
> Thank you for adding the rules. I like them :-). I have following
> proposals on the two open items.

Thanks!

> > 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". "

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:

> "<date> is a date in ISO 8601 Extended Format ([CC]YY["-"MM["-"DD]]),
> [...]
>  If not included, the default value for MM and DD is "01". "

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
> allocating the URN owned the domain name specified in the provider-id.

But the semantics is more complicated than that, it includes what I
wrote as (5a) and (5b):

> > 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.

> > 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?)
> 
> 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.

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

I examine this text (as you have edited it) in detail:

> "The <alert-indication>s are hierarchical identifiers.  The set of
> 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
> comply with the syntax for Non Reserved LDH-labels or for A-labels
> [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:

    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>.

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
> registered. A new name MUST NOT be registered if it is equal by the
> comparison rules above to an already registered name."

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