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

[Paul Kyzivat <[e-mail]>]

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

On 2/13/13 4:05 PM, Dale R. Worley wrote:
> (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
>