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

[Paul Kyzivat <[e-mail]>]

On 2/18/13 3:20 PM, DRAGE, Keith (Keith) wrote:
> 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

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

	Thanks,
	Paul

> 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
> _______________________________________________
> salud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/salud
>