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

[Laura Liess <[e-mail]>]

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:

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

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 <[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<https://www.ietf.org/mailman/listinfo/salud>
>>>
>> ______________________________**_________________
>> salud mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/**listinfo/salud<https://www.ietf.org/mailman/listinfo/salud>
>>
>>
> ______________________________**_________________
> salud mailing list
> [e-mail]
> https://www.ietf.org/mailman/**listinfo/salud<https://www.ietf.org/mailman/listinfo/salud>
>