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

Paul Kyzivat <> Thu, 16 January 2014 23:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 796151AD8DC for <>; Thu, 16 Jan 2014 15:24:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 421xNoA5kgcx for <>; Thu, 16 Jan 2014 15:24:58 -0800 (PST)
Received: from ( [IPv6:2001:558:fe14:43:76:96:62:56]) by (Postfix) with ESMTP id E42A71AD8EE for <>; Thu, 16 Jan 2014 15:24:57 -0800 (PST)
Received: from ([]) by with comcast id EnJn1n00227AodY56nQlyC; Thu, 16 Jan 2014 23:24:45 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id EnQl1n00H3ZTu2S3fnQltj; Thu, 16 Jan 2014 23:24:45 +0000
Message-ID: <>
Date: Thu, 16 Jan 2014 18:24:45 -0500
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20121106; t=1389914685; bh=WF3C4gPcKzUD6eK5nbctDItIsJEIJnPMT3eceL0omV4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=pona9fxMvMC0FV1p3Og5FVXcrjuCH7pK1eX2rdb7ebMnE8ZxVZwSe7xFP6xBWcxC5 0dC19w0R90GV0H9TNO4WYhSqWvNL4+mSQosFO0vx37DFnUZQPz3HNwNMr+JRMlhJWO 8tp4SLL5NWlKe0dOBq60cgYc54xqWMH0H2uuITZ612gmSLp+WIizN34h8noba7me6/ +jI2nKN5y3jXnhlKzrKwz/TIqovstH7YgI3DVKuwaK+zv8D9GnqaDeqvGCUKAwDdN0 olAS6fHPlJms/0XNuOvQlj7BqlZtW2Ha8m0t9xoCGsFRQnPPNmJ5dx4WQAmrDtYZoX mR5IXDYQYV0SA==
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: Thu, 16 Jan 2014 23:24:59 -0000

ISTM the main thing is that 3261 allows URNs in Alert-Info 
*syntactically*, but does not specify any semantics for them.
This draft defines semantics for a certain subset of URNs.


On 1/16/14 4:07 PM, Dale R. Worley wrote:
> [as an individual]
>> From: Christer Holmberg <>
>> But, in my opinion the draft [should] explicitly update the first
>> paragraph in section 20.4 of RFC 3261 (see below):
> Different people have different opinions.  I dislike the "textual
> edit" method of updating an RFC; I find it harder to understand the
> significance of change that is expressed textually than an update that
> states the update in "semantic" terms.
>> 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.)
>>> Roughly 463 RFCs have a "terminology" section.  Of them, about 144
>>> have a terminology section that is a subsection of section 1.
>>> Given how short our terminology section is, it seems OK to me.
>> If you are going to count RFCs, you should also look when they have
>> been published. We live and learn, and hopefully our RFC get more
>> clear and readable by time :)
>> Anyway, I will not spend time arguing about it. It was only an
>> editorial comment :)
> It's a valid point, and fortunately, I can revise my statistics
> easily:  In the RFCs 6001 (2010 Oct) to 6998 (2013 Aug), 114 RFCs have
> a "terminology" section, and of them, 42 have the section in section
> 1.  Of a randomly selected subset of 9 RFCs with a terminology section
> in section 1, in roughly half (4) the only terminology defined was the
> RFC 2119 keywords.  So we can crudely estimate that 18% of "recent"
> RFCs have non-trivial terminology sections as subsections of section
> 1.
>>>> 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?
> Dale
> _______________________________________________
> salud mailing list