Re: [salud] Christer's review of draft-ietf-salud-alert-info-urns-09

Christer Holmberg <> Mon, 20 January 2014 07:19 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3D0F81A0042 for <>; Sun, 19 Jan 2014 23:19:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.799
X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kv7fud9FD6jN for <>; Sun, 19 Jan 2014 23:19:57 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C109C1A0058 for <>; Sun, 19 Jan 2014 23:19:56 -0800 (PST)
X-AuditID: c1b4fb38-b7f2c8e000006d25-43-52dcce1c3a11
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id F3.69.27941.C1ECCD25; Mon, 20 Jan 2014 08:19:56 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.02.0387.000; Mon, 20 Jan 2014 08:19:56 +0100
From: Christer Holmberg <>
To: "Dale R. Worley" <>
Thread-Topic: [salud] Christer's review of draft-ietf-salud-alert-info-urns-09
Thread-Index: Ac8LoI2GwVZiq6LbSqq5Xri0pXR59AATzaeXABbZ38ABrQwL2wCr/kcg
Date: Mon, 20 Jan 2014 07:19:55 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: fi-FI
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+Jvja7MuTtBBmtvK1jc7TjAaPHyRJkD k8fk/V+ZPZYs+ckUwBTFZZOSmpNZllqkb5fAlXF42QaWgj7hisefP7E2ME7m72Lk5JAQMJG4 NW8yO4QtJnHh3no2EFtI4AijxJRT3l2MXED2EkaJT2ueAhVxcLAJWEh0/9MGMUUENCU6FuSA lDMLqErsvb2ECcQWFvCVWHe5jwmiJEBiVn8MSFhEwE3iw98esE0sQOV7fi9lBbF5gcpfvtrE CrHpL6PEjaVbmEESnAIOErsutIIVMQKd9v3UGiaIXeISHw5eZ4Y4WUBiyZ7zULaoxMvH/1gh bCWJFdsvMULU60gs2P2JDcLWlli28DUzxGJBiZMzn7BMYBSbhWTsLCQts5C0zELSsoCRZRUj R3FqcVJuupHBJkZgfBzc8ttiB+PlvzaHGKU5WJTEeT++dQ4SEkhPLEnNTk0tSC2KLyrNSS0+ xMjEwSnVwLj+TO7Gny2JGbf8OH0e38q+Jmv5KPKeSuXrmD37QmbaHi3+sFGEoXj/5ODMSQ+z s5J7F635Fc3jJbPkDefSop/W3bw77X1SVOdu9g579P1+ivnRXSE3Z340Y7nnNZvvy+oz6i+c Nwmb/V6wV+/K1sT4M3Xve2z9TJ8cD3nX8mIrzyHd+wpdC0WVWIozEg21mIuKEwHc/3DHXQIA AA==
Cc: "" <>
Subject: Re: [salud] Christer's review of draft-ietf-salud-alert-info-urns-09
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: Mon, 20 Jan 2014 07:19:59 -0000


>> BTW, the following sentence is unclear to me:
>>    "In practice, this specification extends Alert-Info in that it will
>>    cause the use of a new class of URIs and the use of multiple URIs."
>> What does it mean? 
> The idea is that, while 3261 syntactically and semantically *allows* non-HTTP URIs in Alert-Info, nobody ever used non-HTTP URIs in Alert-Info, and nobody implemented an interpretation of those URIs.
> Thus, even though we are not changing what is officially permitted, implementers will have to change their code because the new *practice* will be an extension of the old practice.  (And both the new practice and the old practice are a small subset of what is permitted by 3261.)

Well, then you should use different wording. Because, the draft does not extend Alert-Info, it simply describes the usage of a new URN in the header field.

>>>> Q9:
>>>> -----
>>>> Section 4 defines the ABNF for the URN, but [there] is no text on 
>>>> how to "map" it into the Alert-Info header field ABNF:
>>>> For example, I assume that the URN is encoded using the opaque-part 
>>>> format of the absoluteURI, and that the scheme value is "urn". I 
>>>> think it would be good to indicate that.
>>> Actually, we're depending on the fact (unstated in RFC 3261) that 
>>> any "absolute" URI (per RFC 3986) is allowed as a header field value 
>>> in Alert-Info, and that the URNs we are defining conform to the 
>>> absolute URI syntax.  If the syntax for <absoluteURI> in RFC 3261 
>>> didn't allow all absolute URIs, we'd have to amend RFC 3261.
>> There are two different "structures" for absolute URI, and the URNs 
>> only fit into the opaque-part structure.
>> In addition, as the URI requires a scheme value, I think we should 
>> explicitly say what it is.
> I guess my point is that the 3261 ABNF already allows all alert URNs to appear in Alert-Info, and there is no need to specify exactly how alert URNs are compatible with the 3261 ABNF.  Anyone who cares exactly how this draft is directly compatible with the ABNF can see that by looking at the ABNF.
> Have there been other situations where this sort of syntax explication has been provided?

I don't know - I am just commenting on how I think the draft could from my perspective be improved :)