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

[Laura Liess <[e-mail]>]

Dale,

2013/2/22 Dale R. Worley <[e-mail]>
>
> (as an individual)
>
> Let me propose this:  We restrict private alert labels to be NR-LDH
> labels (ordinary ASCII labels) at this time.  Later, we can amend the
> standard to allow A-labels (internationalized labels).  Processing
> software should not be confused if it sees an A-label as a private
> alert label, because their syntax is very similar to NR-LDH labels.
>
> Better, let us add a requirement that processing software MUST be able
> to cope with internationalized <alert-label>s, even though we do not
> now allow them:
>
> After the text where we state the restrictions on the labels, such as:
>
>     <Alert-label>s  MUST comply with the syntax for Non
>     Reserved LDH-labels [RFC5890]. <Domain-label>s MUST
>     comply with the syntax for Non Reserved LDH-labels or for A-labels
>     [RFC5890].
>
> Add:
>
>     However, processes that interpret these URNs MUST correctly
>     process URNs even if they contain arbitrary LDH labels as
>     <alert-label>s.  (Of necessity, the process will not understand a
>     URN containing an <alert-label> that is not a Non Reserved
>     LDH-label, and so that <alert-label> and any following
>     <alert-label>s will be ignored per the rules of Section 8.1.)


I like this. Thank you, Dale!

>
>
> (Note:  An "LDH label" is what is normally called "an ordinary ASCII
> label".  From RFC 5890:
>
>    2.3.1.  LDH Label
>
>    This is the classical label form used, albeit with some additional
>    restrictions, in hostnames [RFC0952].  Its syntax is identical to
>    that described as the "preferred name syntax" in Section 3.5 of RFC
>    1034 [RFC1034] as modified by RFC 1123 [RFC1123].  Briefly, it is a
>    string consisting of ASCII letters, digits, and the hyphen with the
>    further restriction that the hyphen cannot appear at the beginning or
>    end of the string.  Like all DNS labels, its total length must not
>    exceed 63 octets.
>
> )
>
>
>
>
> > Maybe the "prosa" could also become more simple if we have the same
> > syntactic rules for the  <label>s which do not apear in the
> > <provider-id>. We could then just distinguish in the syntax between
> > "alert-labels" and "domain-labels", like:
> >
> >       alert-name        = alert-label / private-name
> >       private-name     = alert-label "@" provider
> >       provider            = provider-id ["(" date ")"]
> >       provider-id         = 1*(domain-label ".") toplabel
>
> >
> > <Alert-label>s  MUST comply with the syntax for Non
> > Reserved LDH-labels [RFC5890]. <Domain-label>s 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.
> >
> > What do you think?
> > I don't have any strong opinion about splitting the <label>s in
> > <alert-label> and  <domain-label> or not.
>
> Yes, I think that split would make describing the semantic
> restrictions simpler.
>
> We might want to replace <toplabel> with <domain-label>.  It is true
> that the final label in a domain name is much more restricted, but we
> do not need to define or enforce that restriction in our document.


Yes. This makes sense. The syntax we agreed upon is:

      alert-URN         = "urn:alert:" alert-identifier
      alert-identifier  = alert-category ":" alert-indication
      alert-category    = alert-name
      alert-indication  = alert-name *(":" alert-name)
     alert-name        = alert-label / private-name
     private-name     = alert-label "@" provider
      provider            = provider-id ["(" date ")"]
      provider-id         = 1*(domain-label ".") domain-label
      alert-label             = let-dig [ *let-dig-hyp let-dig ]
      domain-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 don't quite know how to express this, because, as you point out,
> > > "[e-mail]" and "[e-mail]" have no meaning in
> > > isolation.
> >
> > This is exactly my point.  And I don't have any idea,  either.  I
> > don't have any problems with the text myself, I just suspect we have
> > to be very accurate with our text to pass through the URNBIS and IESG
> > review.
>
> I am sure you are right that we have to be very accurate.
>
> Let me try with this:
>
> In section 4, the namespace registration template, there is this
> paragraph:
>
>       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.
>
> This is the only place where we mention the fact that alert-info URNs
> are hierarchical -- and we do not explain exactly what "hierarchical"
> means.
>
> Let us separate the first sentence into a separate paragraph, and add
> this text to describe what "hierarchical" means:
>
>       The <alert-indication>s are hierarchical identifiers.  An
>       <alert-URN> asserts some fact or feature of the offered SIP
>       dialog, or some fact or feature of how it should be presented to
>       a user, or of how it is being presented to a user.  Removing an
>       <alert-identifier> from a URN creates shorter a URN with a less
>       specific meaning; the set of dialogs to which the longer URN
>       applies is necessarily a subset of the set of dialogs to which
>       the shorter URN applies.  (If first URN contains only one
>       <alert-indication>, then the larger set is considered to be the
>       set of all dialogs.)
>
>       The specific criteria defining the subset to which the longer
>       URN applies, within the larger set of dialogs, is considered to
>       be the meaning of the <alert-indication>.  This meaning is
>       relative to and depends upon the preceding <alert-category> and
>       <alert-indication>s (if any).  The meanings of two
>       <alert-indication>s that are textually the same but are
>       preceded by different <alert-category>s or <alert-indication>s
>       have no necessary connection.  (An <alert-category> considered
>       alone has no meaning.)
>
>       The entity owning <provider> defines the meaning of a <private-name>
>       that is used as an <alert-indication>.
>
>       The entity owning the <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> that
>       follows that <private-name> and that precedes the next
>       <alert-indication> which is a <private-name> (if any).
>
>       The meaning of all other <alert-indication>s is defined by
>       standardization.



My problem here is with the usage of <alert-identifier> and
<alert-indication>  in the text above and in the rule 5 d).

According to the syntax the text refers to , a <lablel> is  label   =
let-dig [ *let-dig-hyp let-dig ] and    <alert-identifier> and
<alert-indication> are the full chains  including or after the
<alert-category>.
The text above and o the rule 5 d) talk about  <alert-identifier> and
<alert-indication> as <labels> or subchains.
"Removing an <alert-identifier> from a URN creates shorter a URN with
a less specific meaning; "  and "...the       meaning of each
<alert-indication> which is a <label>..."  and
 "... meaning of each <alert-indication> which is a <label> following
that  <private-name> and preceding the next <alert-indication> which
is  a <private-name>...".

Additionaly, the IANA registration defines the "meaning" for and
manages only <alert-category>s and <alert-identifier>s, not single
<label>s  or subchains within an <alert-identifier> or
<alert-indication>.  (We already decided in the past not to register
or define the meaning of single labels or subchains.)

I think we do not need a complicated explanation, just to modify your
rule 5 d) to comply to the syntax and with the registration process.
According to section 6, only <alert-category>s and <alert-identifier>s
(the whole chain) have a "meaning" and must be managed by someone.
What do you think of
5d)  The meaning of <alert-category>s and <alert-identifier>s  which
contain one or more <private-name>s is defined by the entity owning
<provider> within the last <private-name>.
  I am not sure this  is correct.  Are <alert-identifier>s with more
than one <private-name>s a problem?

Thank you
Laura



>
>
> Dale
> _______________________________________________
> salud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/salud