Subject: Re: [apps-discuss] [websec] AppsDir review of draft-ietf-websec-strict-transport-sec

From: Julian Reschke <[email-masked]>
Date: Tue, 01 May 2012 10:10:53 +0200

On 2012-05-01 04:55, Murray S. Kucherawy wrote:
>> -----Original Message-----
>> From: Julian Reschke [mailto:[email-masked]]
>> Sent: Monday, April 30, 2012 10:03 AM
>> To: Murray S. Kucherawy
>> Cc: [email-masked]; [email-masked]; [email-masked]
>> Subject: Re: [websec] AppsDir review of draft-ietf-websec-strict-transport-sec
>>
>> On 2012-04-29 09:11, Murray S. Kucherawy wrote:
>>   >  ...
>>> Section 6.1.1: I think the "delta-seconds" should be:
>>>
>>> delta-seconds = 1*DIGIT
>>>
>>> ; defined in Section 3.3.2 of [RFC2616] ...
>>
>> That would copy the rule from RFC 2616 "by value".
>
> Why not just say "delta-seconds is defined in Section 3.3.2 of [RFC2616]" and leave out the restatement of the ABNF?  Then it's truly only specified in one place.

That's *exactly* what the prose ABNF rule is doing; except that it makes 
the in-spec ABNF complete.

> ...

Best regards, Julian

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 1 May 2012 13:43:36 +0000

> Sent: Tuesday, May 01, 2012 1:11 AM
> To: Murray S. Kucherawy
> > Why not just say "delta-seconds is defined in Section 3.3.2 of
> > [RFC2616]" and leave out the restatement of the ABNF?  Then it's truly
> > only specified in one place.
> 
> That's *exactly* what the prose ABNF rule is doing; except that it
> makes the in-spec ABNF complete.

Yes, and I'm saying I think that's a risky thing to do.  Granted, in this particular case it's pretty hard to copy and get wrong, but in general it's safer to point to an authoritative definition of something rather than copy it just so it's all local.

-MSK

---

From: Julian Reschke <[email-masked]>
Date: Tue, 01 May 2012 21:53:49 +0200

> Yes, and I'm saying I think that's a risky thing to do.  Granted, in this particular case it's pretty hard to copy and get wrong, but in general it's safer to point to an authoritative definition o…

Technically it *does* point to the authoritative definition.

Best regards, Julian

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 2 May 2012 17:48:02 +0000

> Sent: Tuesday, May 01, 2012 12:54 PM
> To: Murray S. Kucherawy

The real issue here is that we don't have a (ahem) standard way to import ABNF definitions from other documents.  The specific problem in this case to me is twofold:

1) Section 4 of RFC5234 specifies that the prose-val construction is a mechanism of "last resort", which I take to mean one uses it only when the thing you need to describe is sufficiently complicated that it's easier to describe in English than in ABNF.  I don't think "1*DIGIT" qualifies, nor does an import from another document because we do it all the time with a non-ABNF sentence.  (Now, if that admonition in RFC5234 needs clarification, then let's do that.)

2) There's a common axiom that says it's safer to refer to a definition rather than to copy it.  I understand that we're up against reader convenience here, which can suffer when a copy isn't used, especially when the definitions being recycled are scattered throughout many documents.  Although I'm infinitely confident the string "1*DIGIT" was copied correctly from RFC2616 to this draft, I'm concerned that approval of this use will eventually lead to a case where some author uses prose-val to copy something more complex in the name of reader convenience, and get it wrong, and now we have two documents that don't agree on the definition of something.  That may or may not have serious side effects.

What I would prefer in this case is to say one of these:

	"delta-seconds" in defined in Section 3.3.2 of RFC2616.

	delta-seconds = <defined in Section 3.3.2 of RFC2616>

I strongly prefer the former.  I still think the latter is an improper use of prose-val, but at least the ABNF itself isn't copied there.

To address the larger question, we definitely have to have some conversation about the right way to do this in general.  Perhaps another draft that updates RFC5234 which presents a consensus view of the right, safe, convenient way to do so would be useful.  Perhaps further we just say that what you're doing here is the new official way to do so, where the ABNF inside the prose-val is a convenience copy with the understanding that the referenced definition is authoritative if somehow they diverged.
 
For example, we could standardize on a prose-val whose contents are of the form:

	name = < [ABNF] "from " [ "Section " 1*DIGIT *( "." 1*DIGIT) " of " ] "RFC" 1*DIGIT >

This would be interpreted as: "name" is defined in the specified RFC, possibly down to the specified Section.  If ABNF is there, it is a convenience copy; the referenced document contains the official definition of "name".  And people would just discourage the convenience copy in cases where it's non-trivial.  (We'd have to bang on this a bit to allow importing from documents that aren't RFCs, but you get the idea.)

I'd be happy to write that up as something that updates 5234 if people think that's a good idea.

-MSK

---

From: Julian Reschke <[email-masked]>
Date: Wed, 02 May 2012 20:33:55 +0200

> The real issue here is that we don't have a (ahem) standard way to import ABNF definitions from other documents.  The specific problem in this case to me is twofold:

Exactly. It would be good to have that.

> 1) Section 4 of RFC5234 specifies that the prose-val construction is a mechanism of "last resort", which I take to mean one uses it only when the thing you need to describe is sufficiently complica…

The choices we have are:

a) import "by value" (copy the ABNF rule)

b) import "by reference"

For b), I see two options:

b1) have a prose rule for the imported ABNF rule, or

b2) just say it in prose.

The advantage of b1 over b2 is that an ABNF checker can check whether 
the ABNF is complete (for some value of "complete").

I believe that using the prose rule for that is strictly better than 
having an incomplete ABNF, but it would certainly be cool to have 
something better than that.

> 	delta-seconds =<defined in Section 3.3.2 of RFC2616>
>
> 	name =<  [ABNF] "from " [ "Section " 1*DIGIT *( "." 1*DIGIT) " of " ] "RFC" 1*DIGIT>

Something like that, yes. It would help automated checkers a lot.

Best regards, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 2 May 2012 12:32:03 -0700

On May 2, 2012, at 10:48 AM, Murray S. Kucherawy wrote:
> 2) There's a common axiom that says it's safer to refer to a definition rather than to copy it.

I think we should recognize that as a false axiom and move on.

We should refer to orthogonal definitions that are subject to
independent change control -- e.g., protocol elements that are
defined in another spec because they change at a different
rate than the referring spec or are used by multiple specs.

We should copy a definition by value if the referring spec
depends on the definition (does not allow the parser to change
even if some other spec were to define it and later extend it).

My preference is to not use prose definitions at all -- I used
them as a crutch when I first started writing IETF specs in 1994,
and they burned me every time.

And if we go down the slippery slope, I would love to have a
formal definition of set reduction, as in

   ALPHA = ALPHANUM - DIGIT

since I very commonly need rules that only differ by one or two
characters being removed from the allowed set.

....Roy

---

From: Julian Reschke <[email-masked]>
Date: Wed, 02 May 2012 23:13:57 +0200

> formal definition of set reduction, as in

+1000

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 03 May 2012 07:39:16 +0100

Roy,

> even if some other spec were to define it and later extend it).

But that is contrary to the general principle in the IETF of
using normative references and *not* replicating normative material,
to avoid mistakes.

Both approaches have their advantages and disadvantages, but making
ABNF an exception seems problematic, or at least a decision that can't
be taken at Area level.

> characters being removed from the allowed set.

Would you call that "disinheritance" ?

    Brian