Subject: [salud] New version for draft-liess-dispatch-alert-info-urns

From: Laura Liess <[email-masked]>
Date: Fri, 9 Jul 2010 16:50:42 +0200

Hi,

A new version of  the alert-Info URN draft was submitted.
 http://tools.ietf.org/id/draft-liess-dispatch-alert-info-urns-02.txt

The main purpose of the submission is to provide a new basis for the
discussions, including the last ML-discussions for which we reached
(or almost reached) a consensus, mainly
- Paul’s syntax proposal (which was agreed on the ML at that time,
also Dale seems not to agree to this in his recent mail) and
- Dale’s proposals for how to define the purpose of the Alert-Info
URNand also for the terminology and requirements.
There are also some changes in the document structure and some other,
more minor changes.

The main changes:

- Semantc & non-semantic stuff replaced by a Dale’s definition (with
small modification): “….an indication which describes the semantics of
the signaling situation or the characteristics of the rendering“ (I
hope we can agree on this or something similar)
- “Terminology” section added.  Mainly Dale’s text as starting point,
needs more work in later versions.
- Requirements: Dale’s requirements added, some old requirements
replaced or modified (e.g. old REQ-7 and REQ-8 deleted to get rid of
the semantic/non semantic stuff, in principle replaced by REQ-1)
- New section “Use Cases”, mainly those from the old Section 4, but
independent from a particular syntax.
- Registration template:
- “URN scheme” changed to  “URN namespace identifier” (according to
Peter’s comment on the ML)
- The template does not longer contain the names of the alert-category
names defined in this document, the alert-category is just a string.
The alert-category names are registered with IANA in Section 9.  (But
no problem to switch back if people decide to.)
- Section 5 “Alert-Info URN values definitions”:  Alert-categories and
alert indications completely replaced with Paul’s proposal. Eventually
redundancy to the content of the Section 9.2 “Initial IANA
Registration”.
- Sections “New alert identifiers” and “Initial IANA registrations“
changed to register the new syntax.

Discussions which are not in this version of the draft:
- 180 vs. 18x responses
- Adam’s use cases and their syntax (3GPP2/TIA tones).
- Dale’s algorithm proposal

There are still many open issues which need clarification.

Thanks a lot
Laura

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 09 Jul 2010 13:41:02 -0400

Good job of incorporating some of Dale's excellent ideas into this.
Of course Dale wants to see a single URN rather than several being 
combined. Abstractly I agree with him. But when you get down to the 
nitty gritty of defining values for multiple categories and encoding 
that in a single URN, it seems pretty ugly. But I'd certainly be open to 
further discussion on how that might be achieved.

Here are a couple of small things:

Section 4:

In the following:

       The Namespace Specific String (NSS) for the "alert" URNs is called
       alert-identifier and has a hierarchical structure.  The left-most
       label is called "alert-category" and is separated from right-side
       of the alert-identifier, the alert-indication, by a semicolon.
       The general form is urn:alert:{alert-category}:{alert-indication}.

"semicolon" should be "colon".

Section 5.2.6:

In the example of private, it might be better to use a generic name 
rather than a real company name.

     I might suggest using "Acme" rather than "Cisco" :-)

Actually, urn:alert:source:private.com.example.customer would be my 
recommendation.

	Thanks,
	Paul

Laura Liess wrote:
> _______________________________________________
> salud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/salud
>

---

From: Laura Liess <[email-masked]>
Date: Tue, 13 Jul 2010 11:07:06 +0200

Paul,

thank you for the comments. I will incorporate them into the next version.

I hope we can get a time slot in Mastricht for discussion.

Laura

2010/7/9 Paul Kyzivat <[email-masked]>:
> Of course Dale wants to see a single URN rather than several being combined.
> Abstractly I agree with him. But when you get down to the nitty gritty of
> defining values for multiple categories and encoding that in a single URN,
> it seems pretty ugly. But I'd certainly be open to further discussion on how
> that might be achieved.

> In the example of private, it might be better to use a generic name rather
> than a real company name.
>