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

[Paul Kyzivat <[e-mail]>]

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

OK - that makes sense.

	Thanks,
	Paul

> Thank you
> Laura
>
>
> 2013/3/7 Paul Kyzivat <[e-mail] <mailto:[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]
>         <mailto:[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] <mailto:[e-mail]>" and
>                     "[e-mail] <mailto:[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] <mailto:[e-mail]>
>             https://www.ietf.org/mailman/__listinfo/salud
>             <https://www.ietf.org/mailman/listinfo/salud>
>
>         _________________________________________________
>         salud mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/__listinfo/salud
>         <https://www.ietf.org/mailman/listinfo/salud>
>
>
>     _________________________________________________
>     salud mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/__listinfo/salud
>     <https://www.ietf.org/mailman/listinfo/salud>
>
>