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

[Laura Liess <[e-mail]>]

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



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


Thank you
Laura


2013/2/13 Dale R. Worley <[e-mail]>:
> (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
> _______________________________________________
> salud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/salud