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

[Paul Kyzivat <[e-mail]>]

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 <[e-mail]>
>
>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/salud
>