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

From: Laura Liess <[email-masked]>
Date: Thu, 7 Mar 2013 21:20:01 +0100

Dale,

2013/2/22 Dale R. Worley <[email-masked]>
>
> (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,
> > > "[email-masked]" and "[email-masked]" 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/salud

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Mar 2013 06:07:27 +0800

This looks good. For reasons of non-redundancy, I would be inclined to 
make one tweak:

    alert-label = domain-label

(I just don't like the look of repeating the complex construction that 
is the definition of domain-label.)

But this is cosmetic, so I don't feel strongly about it.

	Thanks,
	Paul

---

From: Laura Liess <[email-masked]>
Date: Fri, 8 Mar 2013 09:50:42 +0100

Paul,

The reason for having different names is that we agreed to have different
rules for them:
<domain-label>s are internationalized labels and <alert- label>s are ASCII
labels.

The text we agreed upon is:

comparison rules above to an already registered name."

Alfred required something like this. I hope this text will satisfy him and
the URNBIS.

If we use the same name for both lables, I don't know how we can define
different rules for them.

Thank you
Laura

2013/3/7 Paul Kyzivat <[email-masked]>

> (I just don't like the look of repeating the complex construction that is
> the definition of domain-label.)
>
>>> ______________________________**_________________
>>> salud mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/**listinfo/salud<https://www.ietf.org/mailman/listinfo/salud>
>>>
>> ______________________________**_________________
>> salud mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/salud<https://www.ietf.org/mailman/listinfo/salud>
>>
>>
> ______________________________**_________________
> salud mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/salud<https://www.ietf.org/mailman/listinfo/salud>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Mar 2013 23:32:37 +0800

On 3/8/13 4:50 PM, Laura Liess wrote:
> Paul,
>
> The reason for having different names is that we agreed to have
> different rules for them:
> <domain-label>s are internationalized labels and <alert- label>s are
> ASCII labels.
>
> Alfred required something like this. I hope this text will satisfy him
> and the URNBIS.
>

OK - that makes sense.

	Thanks,
	Paul

> Thank you
> Laura
>
>
> 2013/3/7 Paul Kyzivat <[email-masked] <mailto:[email-masked]>>
>
>     This looks good. For reasons of non-redundancy, I would be inclined
>     to make one tweak:
>
>     (I just don't like the look of repeating the complex construction
>     that is the definition of domain-label.)
>
>         2013/2/22 Dale R. Worley <[email-masked]
>         <mailto:[email-masked]>>
>
>
>             (as an individual)
>
>                     "[email-masked] <mailto:[email-masked]>" and
>                     "[email-masked] <mailto:[email-masked]>"
>                     have no meaning in
>                     isolation.
>
>
>             _________________________________________________
>             salud mailing list
>             [email-masked] <mailto:[email-masked]>
>             https://www.ietf.org/mailman/__listinfo/salud
>             <https://www.ietf.org/mailman/listinfo/salud>
>
>         _________________________________________________
>         salud mailing list
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/__listinfo/salud
>         <https://www.ietf.org/mailman/listinfo/salud>
>
>
>     _________________________________________________
>     salud mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/salud
>     <https://www.ietf.org/mailman/listinfo/salud>
>
>

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 8 Mar 2013 11:30:28 -0500 (EST)

> Date: Fri, 08 Mar 2013 06:07:27 +0800
> From: Paul Kyzivat <[email-masked]>
> 

We might consider:

        alert-label       = label
        domain-label      = label
        label             = let-dig [ *let-dig-hyp let-dig ]

But the savings are small.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 8 Mar 2013 11:51:35 -0500 (EST)

[as an individual]

The current syntax is:

One source of difficulty I am having is that I would like a
nonterminal that means "an <alert-name> that is part of an
<alert-indication> (but not an <alert-category>".  I have been
incorrectly using the term <alert-indication> for this nonterminal.

There are alternative ways to provide this nonterminal.  We could
introduce a new nonterminal:

      alert-indication  = xxx *(":" xxx)
      xxx               = alert-name

Or we could change the meaning of alert-indication:

      alert-URN         = "urn:alert:" alert-identifier
      alert-identifier  = alert-category ":" alert-indication *(":" alert-indication)
      alert-category    = alert-name
      alert-indication  = alert-name
      alert-name        = alert-label / private-name

But I do not know what change would cause the fewest problems with the
rest of the draft text.

What do you recommend?

Dale

---

From: Laura Liess <[email-masked]>
Date: Fri, 8 Mar 2013 17:57:32 +0100

Dale,

2013/3/8 Dale R. Worley <[email-masked]>

> But the savings are small.

I would leave them as they are, for the reasons I gave in my previous mail
to Paul.

Additionally,  I found out that we use the word "label"  in the section 6.1
in a way which would not be consistent with the syntax above.

  " Alert URN identifiers are identified by <label>s managed by IANA,
   according to the processes outlined in [RFC5226] in a new registry
   called "Alert URN Labels".  Thus, creating a new Alert-Info URN
   identifier requires IANA action.  The policy for adding a new alert
   category is 'Standards Action'.  (This document defines the alert
   categories 'service', 'source', 'priority', 'duration', 'delay' and
   'locale'. ) The policy for assigning <label>s to <alert-indication>s
   and the rules to combine them may differ for each <alert-category>
   and MUST be defined by the document describing the corresponding
   alert category. "

Thank you
Laura

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 09 Mar 2013 01:22:15 +0800

> But I do not know what change would cause the fewest problems with the

If there is no need to reference the old meaning of alert-indication 
then I prefer the 2nd. Else the first is fine (but with something more 
mnemonic than xxx.)

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 09 Mar 2013 01:23:06 +0800

I'm ok with leaving as-is.

	Paul

On 3/9/13 12:57 AM, Laura Liess wrote:
> Dale,
>
>
> 2013/3/8 Dale R. Worley <[email-masked] <mailto:[email-masked]>>
>
>      > From: Paul Kyzivat <[email-masked]
>     <mailto:[email-masked]>>
>      >
> I would leave them as they are, for the reasons I gave in my previous
> mail to Paul.
>
> Additionally,  I found out that we use the word "label"  in the section
> 6.1 in a way which would not be consistent with the syntax above.
>
>    "Alert URN identifiers are identified by <label>s managed by IANA,

---

From: Laura Liess <[email-masked]>
Date: Fri, 8 Mar 2013 18:29:27 +0100

Dale,

I think there is the first proposal is OK. But the amount of changes depend
also on what you intend to do with the new identifier.

With the second proposal, we probably have to rewrite the draft. In this
case, I would give up.

But why do you need the components of an <alert-indication>?
Currently,  IMO they have no meaning and must be not managed as
individuals, only whole <alert-indicators> must be managed. This was a
decision of the WG at the beginning. If you want to change this we have to
throw avay what we have now an degin again were we were three or four years
ago.

And what is the open point you want to solve?  I thought with what we have
now we solved all issues. Or did I miss something here?

Thank you
Laura