Re: [salud] Christer's review of draft-ietf-salud-alert-info-urns-09 (Dale R. Worley) Thu, 16 January 2014 21:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 32F391ACD00 for <>; Thu, 16 Jan 2014 13:10:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rI1W4Mixgjfs for <>; Thu, 16 Jan 2014 13:10:29 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id DF9611ACCEA for <>; Thu, 16 Jan 2014 13:10:28 -0800 (PST)
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s0GLABb3023158; Thu, 16 Jan 2014 16:10:13 -0500
Received: from ( []) by (8.13.6/8.12.8) with ESMTP id s0GL7B8q2941025; Thu, 16 Jan 2014 16:07:11 -0500 (EST)
Received: (from worley@localhost) by (8.13.6/8.13.6/Submit) id s0GL7AKI2944531; Thu, 16 Jan 2014 16:07:10 -0500 (EST)
Date: Thu, 16 Jan 2014 16:07:10 -0500 (EST)
Message-Id: <>
From: (Dale R. Worley)
Sender: (Dale R. Worley)
To: Christer Holmberg <>
In-reply-to: <> (
References: <> <> <>
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 21:10:31 -0000

[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

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