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

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 16 January 2014 23:24 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796151AD8DC for <salud@ietfa.amsl.com>; Thu, 16 Jan 2014 15:24:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 421xNoA5kgcx for <salud@ietfa.amsl.com>; Thu, 16 Jan 2014 15:24:58 -0800 (PST)
Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id E42A71AD8EE for <salud@ietf.org>; Thu, 16 Jan 2014 15:24:57 -0800 (PST)
Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta06.westchester.pa.mail.comcast.net with comcast id EnJn1n00227AodY56nQlyC; Thu, 16 Jan 2014 23:24:45 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id EnQl1n00H3ZTu2S3fnQltj; Thu, 16 Jan 2014 23:24:45 +0000
Message-ID: <52D86A3D.4040102@alum.mit.edu>
Date: Thu, 16 Jan 2014 18:24:45 -0500
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
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
To: salud@ietf.org
References: <7594FB04B1934943A5C02806D1A2204B1C5EF0E7@ESESSMB209.ericsson.se> <201401072131.s07LVQZs2347719@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C5F00D5@ESESSMB209.ericsson.se> <201401162107.s0GL7AKI2944531@shell01.TheWorld.com>
In-Reply-To: <201401162107.s0GL7AKI2944531@shell01.TheWorld.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; 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-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list <salud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/salud>, <mailto:salud-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/salud/>
List-Post: <mailto:salud@ietf.org>
List-Help: <mailto:salud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/salud>, <mailto:salud-request@ietf.org?subject=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.

	Thanks,
	Paul

On 1/16/14 4:07 PM, Dale R. Worley wrote:
> [as an individual]
>
>> From: Christer Holmberg <christer.holmberg@ericsson.com>
>
>> 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
> salud@ietf.org
> https://www.ietf.org/mailman/listinfo/salud
>