[rfc-i] Data point [Re: Fwd: I-D ACTION:draft-hoffman-utf8-rfcs-03.txt]

Dave CROCKER dhc2 at dcrocker.net
Tue Oct 7 10:32:53 PDT 2008



Paul Hoffman wrote:
> places where it did not render correctly. The fact that the one place that
> would have destroyed the bits asked him if he wanted to is a very positive

Well, certainly better than destroying data silently, I suppose.


> sign. To me, no loss of bits on the wire is "robust".

In a localized view of robustness, yes it is.  Much like saying that the patient 
died but the surgery was a success. Also much like saying that fat pipes 
eliminate the need for queuing mechanisms, in spite of having other components 
in the sequence that still experience congestion...

I intended "robust" as and end-to-end construct, meaning that documents are 
usable to the humans trying to read them, to the same extent they currently are 
usable (and have been since... forever.)

Anything that disrupts that utility for the human reader constitutes fragility.


>>> We explicitly did not put any requirements in our document because no
>>> such requirements appear in RFC 2223. Our document proposes a change in
>>> the encoding, *not* a change in the requirements for the RFC series.
>> Sure it does.  The long-standing requirement has been robustness in
>> surviving varied handling and retaining readability.
> 
> We agree on the first part but disagree on the second.

You think it's ok to break existing practices that produce readability?


>> Concern for that requirement has been at the core of every rejection for
>> proposed encoding/format enhancement made in at least the last 15 years.
> 
> And we fully agree on that, unfortunately.

It's difficult to define enhancements that preserve an installed base. 
Proposals need to navigate carefully.

Of course, that's a very different stance than being so afraid of change that 
all proposals are automatically rejected...


>> Brian's test scenario demonstrates a substantial change in survivability.
>> In other words, the document becomes much more fragile than it ever has
>> been.
> 
> It sounds like you have conflated your two types of robustness. Nothing in
> Brian's message indicates lack of robustness in "surviving varied handling".

You mean I misread his saying that document data was presented incorrectly as 
meaning that data did not survive handling?  Please explain my error, because 
I'm still not seeing it.  (And I'll point out that that phrasing is an 
accidental bit of irony...)

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net


More information about the rfc-interest mailing list