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

[[e-mail] (Dale R. Worley)]

(as an individual)

> From: Laura Liess <[e-mail]>
> 
> 2013/2/21 Dale R. Worley <[e-mail]>:
> > The second point assumes that we want to allow private alert labels to
> > be internationalized.  I don't know if we have discussed that point,
> > but it seems like a good idea to me; it allows private labels in
> > users' own languages, and it won't cause any operational problems
> > (since A-labels are processed essentially the same way as
> > NR-LDH-labels).
> 
> This was also my opinion. But after reading Paul's e-mail I have
> doubts if we should do this. I would think we should keep it simpe if
> we can.

I agree with you and Paul now.

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

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

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

Dale