Re: #282: Recommend minimum sizes for protocol elements

In message <A2439359-80C0-466D-9E1A-7A9316F9FBD0@mnot.net>, Mark Nottingham wri
tes:

>1.4.x Delta Seconds
>
>The delta-seconds rule specifies a non-negative integer, representing =
>time in seconds.

Some high volume sites cache content for only a couple of seconds,
but derive 20-30% cache hit ratios from it.  For these sites the
1 second granularity of age related values are a serious limitation
on caching policy.

Does anybody know of anything that would break if we allowed real
numbers for these fields ?

ie:
	delta-seconds = 1*DIGIT [ '.' *DIGIT]

Specifying truncation rather than rounding for implementations that
do not support real numbers, would ensure compliance for existing
implementations.  The 2^31 should remain unaltered.


>For other situations, add section to p1 Security Considerations:

Do we need to caution against dropping headers selectively due
to size ?

I know of at least one filtering device which can be circumvented
by making a particular header longer than a certain length.  This
causes the device to drop just this one header, which in turn
bypasses filter features.  (The vendor has been notified, but
emits few if any clue-o-trons)

I'm not quite sure how to express this, something like "don't drop
headers unless you know what they mean".


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Sunday, 26 June 2011 08:19:54 UTC