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

[Laura Liess <[e-mail]>]

Dale,

Thank you for doing this. The text looks realy good :-).

I agree with Paul, we should not remove the initial"alert-".

I also have only one remark:
The first paragraph in both "Namespace considerations" and "Comunity
considerations" states very clear that the "alert"  URN  is defined for
SIP.  If we state this, we probably will have to change to urn:ietf:params,
as Alfred required.
Alfred required us to either describe very clear why we can not use
urn:ietf:params or to switch to urn:ietf:params. In version 07, I to
changed the 06 text trying to express that the "alert" URN is not just for
SIP but is targeted to be used for signals or renderings in general.  The
text itself is not important to me, I don't even know if it would help, I
just want to remind you about Alfred's requirement.

Thank you
Laura





2013/3/13 Dale R. Worley <[e-mail]>

> I was looking at inserting the updated ABNF into -07, as well as
> adding the expanded explanation I gave of which organizations have the
> right to define the meaning of which components of a URN.  As far as I
> can tell, both of these go into the "Namespace registration template",
> which is in section 4.
>
> Looking at the template in -07, it seems to me that it did not relfect
> many of our recent decisions, and in some places information should be
> moved to other sections.  So I edited the template into what seems to
> me to be a better organization.  The revised text is below.
>
> In particular, I explained why we need such a complex scheme
> definition.  (We need to provide private extensions to accommodate the
> existing practice of equipment vendors.)
>
> During the editing, I listed some open questions regarding how we
> write the text:
>
> 1. Should we use the notation <xxx> for nonterminals?  We generally do
> now, but we don't do it completely consistently.
>
> 2. Should we remove the initial "alert-" from nonterminals other than
> "alert-URN"?  There does not seem to be much benefit from the prefix,
> and we already use (e.g.) "category" in some places.
>
> 3. The nonterminal name <indication-part> is a bit awkward, but I
> don't know of anything better.  <alert-indication-part> would be more
> consistent with current usage, but is very long.  Using
> <indicatin-part> makes more sense if we change <alert-indication> into
> <indication>.
>
> 4. In the template, we say '"alert" URN'.  This makes sense, but is it
>    the standard way to describe URNs which are of a particular scheme.
>
> My revision could probably use some additional editing.
>
> ----------------------------------------------------------------------
> 4.  Namespace Registration Template
>
>    This section provides the registration template for the 'alert' URN
>    namespace identifier (NID) according to [RFC2141] and [RFC3406]
>
>    Namespace ID:  alert
>
>    Registration Information:
>
>       Registration version:  1
>
>       Registration date:  TBD
>
>    Declared registrant of the namespace:
>
>       Registering organization:  IETF
>
>       Designated contact:  Laura Liess
>
>       Designated contact email:  [e-mail]
>
>    Declaration of syntactic structure:
>
>       The Namespace Specific String (NSS) for the "alert" URNs is called
>       an <alert-identifier> and has a hierarchical structure.  The
>       first colon-separated part after "alert" is called the
>       <alert-category>; the parts to the right of that are
>       the <alert-indication>.  The general form is
>       urn:alert:{alert-category}:{alert-indication}.
>
>       In this specification, the following <alert-category> identifiers are
>       described: "service" , "priority" , "source" , "duration", "delay"
>       and "locale".  The <alert-category> set can be extended in the
>       future, either by standardization or by private action.
>
>       The categories are orthogonal.  Any Alert-Info URN defined in this
>       specification is syntactically valid for ring and ringback tones
>       and can be used in INVITE requests or in provisional 1xx responses
>       excepting the 100 response.
>
>
>
>
> Liess, et al.             Expires April 5, 2013                [Page 12]
>
> Internet-Draft               Alert-Info URNs                October 2012
>
>
>       <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.
>
>       The ABNF [RFC5234] for the Alert -Info URNs is shown below:
>
>            alert-URN        = "urn:alert:" alert-identifier
>            alert-URN        = "urn:alert:" alert-identifier
>            alert-identifier = alert-category ":" alert-indication
>            alert-category   = alert-name
>            alert-indication = indication-part *(":" indication-part)
>            indication-part  = 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
>
>    Relevant ancillary documentation:  [this RFC]
>
>    Namespace considerations:
>
>       This specification proposes a new URN
>       namespace "alert" for URNs representing the semantics of
>       signals or renderings used for alerting of users when a call
>       arrives via the Session Initiation Protocol.  The particular
>       rendering of an "alert" URN
>       identifier depends on the context in which the rendering is done.
>
>       The initial scope of usage is in the SIP Alert-Info header,
>       in initial INVITE requests (to indicate how the called user
>       should be alerted regarding the call) and non-100 provisional
>       responses to those INVITE requests (to indicate the ringback,
>       how the calling user should be alerted regarding the progress of
>       the call).
>
>       The "alert" URN namespace is designed for more general usage.
>       The URN may appear in any protocols that allow general URIs (e.g.
>       also in ITU-T protocols), in web pages or in any end device's
>       software.
>
>       In order to assure widespread adoption of these URNs for
>       indicating ring tones and ringback tones, the scheme must allow
>       replication of the current diversity of these tones.  Currently,
>       these tones vary between the PSTNs of different nations and
>       between equipment supplied by different vendors.  Thus, the
>       scheme must accommodate national variations and proprietary
>       extensions in a way that minimizes the information that is lost
>       during interoperation between systems that follow different
>       national variations or that are supplied by different vendors.
>
>       The scheme allows definition of private extension URNs that refine
>       and extend the information provided by standard URNs.  Private
>       extension URNs can also refine and extend the information
>       provided by other private extension URNs.  Private extensions can
> also
>       define entirely new categories of information about calls.  We
>       expect these extensions to be used extensively when existing PBX
>       products are converted to support SIP operation.
>
>       The device that receives an Alert-Info header containing a
>       sequence of "alert" URNs provides to the user a rendering to
>       that represents the semantic content of the URNs.  The device is
>       given great leeway in choosing the rendering, but it is
>       constrained by rules that maximize interoperability
>       between systems that support different sets of private
>       extensions.  In particular, earlier URNs in the sequence
>       have priority of expression over later URNs in the sequence,
>       and URNs that are not usable in their entirety (because they
>       contain unknown extensions or are incompatible with previous
>       URNs) are successively truncated in attempt to construct a URN
>       that retains some information and is renderable in the context.
>
>       Due to the practical importance of private extensions for the
>       adoption of URNs for alerting calls and the very specific rules
>       for private extensions and the corresponding processing rules
>       that allow quality interoperation in the face of private
>       extensions, the requirements of the "alert" URN schems cannot be
>       met by a fixed enumeration of URNs and corresponding meanings.
>       In particular, the existing namespace "urn:ietf:params" does not
>       suffice (unless the private extension apparatus is applied to
>       that namespace).
>
>       [Note, to be deleted for the final version of this draft:]  Because
>       the work on this draft has lasted for about four years, the new
> "alert"
>       URN namespace is already used in already finalized specifications
>       of other SDOs (3GPP) and there are already existing
>       implementations in products and large carrier networks.
>       <urn:alert:service:normal> is also specified for use in
>       draft-ietf-bliss-shared-appearances.
>
>       Also, there do not appear to be other URN namespaces that
>       uniquely identify the semantic of a signal or rendering feature.
>       Unlike most other currently registered URN namespaces, the
>       "alert" URN does not identify documents and protocol objects
>       (e.g., [RFC3044], [RFC3120], [RFC3187], [RFC3188], [RFC4179],
>       [RFC4195], [RFC4198] ), types of telecommunications equipment
>       [RFC4152], people or organizations [RFC3043].
>
>       The <alert-URN>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 <indication-part>
>       from the end of an <alert-URN> (which has more than one
>       <indication-part>) creates a shorter <alert-URN> with a less specific
>       meaning; the set of dialogs to which the longer <alert-URN>
>       applies is necessarily a subset of the set of dialogs to which
>       the shorter <alert-URN> applies.  (If the starting <alert-URN>
>       contains only one <indication-part>, and thus the <indication-part>
> cannot
>       be removed to make a shorter <alert-URN>, we can consider the
>       set of dialogs to which the <alert-URN> applies to be a subset
>       of the set of all dialogs.)
>
>       The specific criteria defining the subset to which the longer
>       <alert-URN> applies, within the larger set of dialogs, is
>       considered to be the meaning of the final <indication-part>.  This
>       meaning is relative to and depends upon the preceding
>       <alert-category> and <indication-part>s (if any).  The meanings of
>       two <indication-part>s that are textually the same but are preceded
>       by different <alert-category>s or <indication-part>s have no
>       necessary connection.  (An <alert-category> considered alone
>       has no meaning.)
>
>       The entity owning the <provider> within a <private-name>
>       specifies the meaning of that <private-name> when it is used as
>       an <indication-part>.  (The entity owning a <provider> is
>       determined by the rules in Section 7.2 of [this RFC].)
>
>       The entity owning the <provider> within a <private-name> (in
>       either an <alert-category> or an <indication-part>) specifies the
>       meaning of each <indication-part> which is an <alert-label> that
>       follows that <private-name> and that precedes the next
>       <indication-part> which is a <private-name> (if any).
>
>       The meaning of all other <indication-part>s (i.e., those that are not
>       <private-name>s and do not follow a <private-name>) is defined
>       by standardization.
>
>    Community considerations:
>
>       The alert URN is believed to be relevant
>       to a large cross-section of Internet users, namely those that
>       initiate and receive communication connections via the Session
>       Initiation Protocol.
>       These users include both
>       technical and non-technical users, on a variety of devices and
>       with a variety of perception capabilities.  The 'alert' URN will
>       allow Internet users to receive more information and enable them
>       to better make decisions about accepting an offered call, or get
>       better feedback on the progress of a call they have made.  User
>       interfaces for perception-impaired users can better render the
>       ringback tone indication based on the Alert-Info URN.
>
>    Process of identifier assignment:
>
>       Assignment of standardized "alert" URNs is by insertion into the
>       IANA registry described in Section 6 of [this RFC].  This
>       process defines the meanings of <indication-part>s that have
>       standardized meanings, as described in "Namespace Considerations".
>
>       Private extensions are "alert" URNs that include
>       <indication-part>s that are <private-name>s and <alert-label>s
>       that appear after a <private-name>s (either as an
>       <alert-category> or an <alert-indication).  If such an
>       <indication-part> is a <private-name>, its meaning is defined by
>       the entity that owns the <provider> that appears in the
>       <private-name>.  If the <indication-part> is an <alert-label>,
>       its meaning is defined by the entity that owns the <provider>
>       that appears in the closest <private-name> preceeding the
>       <alert-label>.  The rules for determining the entity that owns a
>       <provider> are given in Section 7.2 of [this RFC].
>
>    Identifier uniqueness and persistence considerations:
>
>       An "alert" URN identifies a semantic feature of a
>       call or a sensory feature of how the call alerting should be a
>       rendered at the caller's or callee's end device.
>
>       For standardized <indication-parts> in URNs, uniqueness and
>       persistence of their meanings is guaranteed by the fact that
>       they are registered with IANA in accordance with the procedures
>       of Section 6 of [this RFC]; the feature identified by a
>       particular "alert" URN is distinct from the feature identified
>       by any other standardized "alert" URN.
>
>       Assuring uniqueness and persistence of the meanings of private
>       extensions is delegated to the entities that define private
>       extension <indication-parts>.  The entity responsible for a
>       particular <indication-part> in a particular "alert" URN is the
>       owner of a syntactically-determined <provider> part within the
>       URN.  Once an entity obtains ownership of a particular
>       <provider>, it retains ownership of it for all time, as
>       described in Section 7.2 of [this RFC].
>
>    Process for identifier resolution:
>
>       The process of identifier resolution is the process by which a
>       rendering device chooses a rendering to represent a sequence of
>       "alert" URNs.  The device is allowed great leeway in making this
>       choice, but the process must obey the rules of Section 8.1 of
>       [this RFC].  The device is expected to provide renderings that
>       users associate with the meanings assigned to the URNs within
>       their cultural context.  A non-normative example resolution
>       algorithm is given in Section 9.1 of [this RFC].
>
>    Rules for lexical equivalence:  Alert-Info URNs are compared
>       according to case-insensitive string equality, as described
>       under "Namespace Considerations".
>
>    Conformance with URN syntax:  All "alert" URNs must conform to the
>       BNF in the 'Declaration of syntactic structure', which is a
>       subset of the generic URN syntax.  Note that "internationalized"
>       DNS labels may appear in <provider-id>s, in which case they must
>       appear as A-labels, that is, as transformed by Punycode.
>       [insert reference to appropriate RFC]  <alert-label>s, that is,
>       components that are not DNS labels, are constrained to be Non
>       Reserved LDH-labels, that is, "ordinary ASCII labels".  Future
>       standardization may allow <alert-label>s that are A-labels, and
>       so interpreters of "alert" URNs must operate correctly when
>       given such URNs as input.
>
>    Validation mechanism:
>
>       An "alert" URN containing no private extensions can be validated
>       based on the IANA registry of standardized Alert-Info URNs.
>
>       Validating an "alert" URN containing private extensions requires
>       obtaining information regarding the private extensions defined
>       by the entity that owns the <provider> in the relevant
>       <private-name>.  The identity of the entity can be determined
>       from public registries of historical ownership of domain names,
>       in accordance with the procedures of Section 7.2 of [this RFC].
>
>       However, if an "alert" URN contains at least one
>       <alert-identifier> that precedes the first <private-name>, the
>       portion of the "alert" URN that precedes the first
>       <private-name> must itself be a valid standardized "alert" URN,
>       which may be validated as above.
>
>    Scope:  The scope for this URN is public and global.
> ----------------------------------------------------------------------
>
> Dale
>