Subject: [salud] AD review of draft-ietf-salud-alert-info-urns-12

From: Richard Barnes <[email-masked]>
Date: Fri, 11 Apr 2014 13:33:12 -0400

I have reviewed this document in preparation for IETF LC.  Thanks for a
clearly written document!  I especially liked the style of the Terminology
section.  I've requested LC, and a few comments to address along with any
LC comments are below.

Thanks,
--Richard

Some of the values in Section 8.2 have internal colons, which seems like
you're actually defining two things.  But it's not meaningful to remove the
final label.  Should these use a different separator?

In 8.2.6, do you want a language tag instead of a country?

It seems like the tables in 9.2.* could be collapsed into one.

It's not clear to me why you need all the date machinery in provider IDs.
 This things are ephemeral -- why not just use the org that has the domain
now?

Section 13 says that the UA MUST provide a "reasonable rendering".   How do
I tell if a UA meets that criterion?  Might be better to add in Section 11
a requirement of the form, "if a UA cannot process the set of Alert URNs in
a message, then it MUST still provide some alert (chosen by local policy).
 Failure to parse Alert URNs MUST NOT cause a UA not to alert at a all."

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 11 Apr 2014 15:20:40 -0400

> From: Richard Barnes <[email-masked]>
> 

[as chair]

Many thanks!  

[as an author]

We will review your comments carefully.

> This things are ephemeral -- why not just use the org that has the domain

The problem is that these are URNs and so their meanings, once set,
have to be fixed for all time.  That point was raised vividly by the
URN people.  Adding the date to a domain name gives it a
time-invariant meaning.

And though the "visible" use of an alert-info URN is transient, from
the caller to the callee, both the caller and the callee keep a list
of the alert-info URNs that they understand and the meanings that they
attach to them.  And this is telephony equipment, which can have a
lifetime of over a decade.  So you don't want the expiration of some
company's domain registration to require that all the phones that know
of their private extension URNs to have to be reprogrammed.

Dale

---

From: Richard Barnes <[email-masked]>
Date: Fri, 11 Apr 2014 15:35:44 -0400

> of their private extension URNs to have to be reprogrammed.

Fair enough.  Just wondering if we could simplify things, but it sounds
like not.  Thanks!

--Richard

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Apr 2014 16:12:00 -0400

Richard,

Following up on what Dale said - we originally didn't have any of the 
date stuff. We were "forced" to add it, for reasons Dale explained, by 
the URN "police". There was quite a lot of thought and effort put into 
the details of how the semantics are specified, and on the syntax, to 
make it as convenient as possible to use. (E.g., what the defaults are.)

	Thanks,
	Paul

On 4/11/14 3:35 PM, Richard Barnes wrote:
> On Fri, Apr 11, 2014 at 3:20 PM, Dale R. Worley <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> _______________________________________________
> salud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/salud
>

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 14 Apr 2014 20:45:52 -0400

> > > It's not clear to me why you need all the date machinery in
> > > provider IDs.  This things are ephemeral -- why not just use the
> > > org that has the domain now?
> 

> From: Paul Kyzivat <[email-masked]>

> There was quite a lot of thought and effort put into 

More explicitly:  If the date for a domain name is omitted, it
defaults to 2013-01-01, and that date is usable by any organization
which possessed its domain name on that date, or any organization
which acquires a new domain name in the future which was never owned
before.  The intention is to allow all existing telecomm equipment
vendors to be able to avoid using dates, and probably most vendors
that will be created in the future (if they're careful about choosing
a domain name).

Also, if a vendor's ownership of its domain name extends across Jan 1
of any year (and we expect that will be universal), they can use the
date 20xx-01-01, and that date can be abbreviated to just "xx".  That
shortens the date specifier to four characters, "(xx)", which we
consider is a reasonable overhead to trade for adhering to strict
time-invariance for URNs.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 14 Apr 2014 21:04:01 -0400

[as an author]

> final label.  Should these use a different separator?

The idea is that a UA could define a rendering corresponding to
service:recall, and it would cover all three of the defined recall
categories.

> In 8.2.6, do you want a language tag instead of a country?

Oddly, you actually want a country code.  The idea is that ring and
ringback signals will tend to vary depending on the PTT
administration, and those are more organized on national boundries
than on languages.

> It seems like the tables in 9.2.* could be collapsed into one.

The tables could be combined, but each table has different explanatory
material, and combining the tables would make it harder to connect the
explanations with the entries.  We do expect the IANA registration to
use a single table (because the explanations will only be connected
through the RFC reference).

>  Failure to parse Alert URNs MUST NOT cause a UA not to alert at a all."

Yes, the meaning of "reasonable rendering" is difficult to define.  On
the other hand, the behaviors of the UA that we want to forbid seem
like they would be obvious when one observed it but difficult to
specify.

I'm not even sure that we want to go as far as requiring a noticable
alerting signal was *always* produced -- what if there was a
<urn:alert:priority:silent>?

I think the requirement that the UA must produce an alert unless
specifically requested not to falls under what we have written in
section 13, but maybe it's worth specifying explicitly.  And note that
section 13 is broader than the rule you wrote, since it covers all
combinations of URIs regardless of their scheme.

Dale