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

[Paul Kyzivat <[e-mail]>]

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


On 3/8/13 4:20 AM, Laura Liess wrote:
> 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
> _______________________________________________
> salud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/salud
>