Re: [salud] AD review of draft-ietf-salud-alert-info-urns-12 (Dale R. Worley) Tue, 15 April 2014 01:04 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E689D1A0669 for <>; Mon, 14 Apr 2014 18:04:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ob4D6ET3ybJM for <>; Mon, 14 Apr 2014 18:04:06 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:43:76:96:62:16]) by (Postfix) with ESMTP id 5C6051A024C for <>; Mon, 14 Apr 2014 18:04:05 -0700 (PDT)
Received: from ([]) by with comcast id q0Bo1n0031ap0As51142TR; Tue, 15 Apr 2014 01:04:02 +0000
Received: from ([]) by with comcast id q1411n00b1KKtkw3i142f0; Tue, 15 Apr 2014 01:04:02 +0000
Received: from ( []) by (8.14.7/8.14.7) with ESMTP id s3F141Ts006748; Mon, 14 Apr 2014 21:04:01 -0400
Received: (from worley@localhost) by (8.14.7/8.14.7/Submit) id s3F141cI006746; Mon, 14 Apr 2014 21:04:01 -0400
Date: Mon, 14 Apr 2014 21:04:01 -0400
Message-Id: <>
From: (Dale R. Worley)
Sender: (Dale R. Worley)
To: Richard Barnes <>
In-reply-to: <> (
References: <>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20140121; t=1397523842; bh=Onr5fOqeu2kpH/EX0VaB5WGu0X4rqE41Sz6bIMKqN6s=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=mIqGSzqstzl4LmSw0dF8d+dcRMmORgTOBDoADjCd2/3DP+99orGl9yoGmHfo6V03M M2moCYx+jyK4wIONRYMbWfn5QmpwwgvutZfZvbKLjJA9LZbPlXI4qTo4vTCFsGO22T EKgh0kez/V3DMSaV9RfrTGqtOyesrW2LQlQE33l/KROdPN/K3iV3SS5IbRvZrP11An g6tGN6qmmG9PJ/KpwsE2xR34qLkcN5Bc5mOyY5yVU0mUbF+x05H/p1ec+7U834scKV DRIHge3mhqXCteDHqIc6UzJzuw9rkIxjHWcewoqko4Netfki5Sig5YuJKPem3npniQ 73Ct+mPpucv4g==
Subject: Re: [salud] AD review of draft-ietf-salud-alert-info-urns-12
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 15 Apr 2014 01:04:10 -0000

[as an author]

> From: Richard Barnes <>

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

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

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

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

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

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

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.