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

["DRAGE, Keith (Keith)" <[e-mail]>]

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

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Dale R. Worley
> Sent: 18 February 2013 18:54
> To: Laura Liess
> Cc: [e-mail]
> Subject: Re: [salud] New version of the ABNF-syntax
> 
> (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
> _______________________________________________
> salud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/salud