[Json] Observations that might help the discussion

[Pete Resnick <[e-mail]>]

I've been trying to get this note together for a few days now and keep 
getting interrupted. Hopefully this is useful to move some of the 
discussion along. I will be posting some specific questions about open 
issues as well, but I thought these observations might be helpful.

This note expresses my personal views. There may be some things in here 
that WG members disagree with, or that the chairs disagree with, or 
other IESG members disagree with. Don't take this as scripture. But I am 
an increasingly old-timer in this community, so I hope these comments 
are taken as such.

Observation 1: We are chartered to "keep changes to a minimum", but we 
are also chartered to "correct significant errors and inconsistencies". 
Those two items do not seem in the least bit contradictory to me. If 
there is a significant error in the spec (and we all agree it is a 
significant error), then we need to do the minimum to correct the error. 
That doesn't necessarily mean that the change will be small; just the 
minimum we can do. Even if we have to write a long explanatory paragraph 
that describes what we all agree was intended, but has been implemented 
non-interoperably, I don't think we would have violated the charter. 
It's not the length of the change; it's whether it is changing the basic 
intention of the spec or not. Now, we might decide that a change to fix 
a particular error changes the spec so essentially that we'd no longer 
be fulfilling our mission of "essentially reclassifying in place" or it 
would have to be so extensive that it will cause other problems. But I 
haven't see anything to date that makes me worry about that. Yet.

Observation 2: Folks seem to be getting hung up on "declaring older 
implementations/documents non-conformant". I have a hard time getting 
too worked up about this issue. IETF specs have traditionally *not* been 
about conformance; they are supposed to be about interoperability. In 
particular, if you read over RFC 2119, you'll notice that MUST doesn't 
mean (as it does in other standards) "You MUST do this to conform to the 
spec". MUST means "You MUST do this in order to interoperate with 
someone else." Similarly, SHOULD is not simply a strong suggestion or 
recommendation. SHOULD means "There might be legitimate reasons not to 
do this in special circumstances, but if you don't do it, you run the 
risk of not interoperating with other implementations, so you'd better 
know what you're doing. Otherwise, you MUST do it."

So, if there are implementations out there that don't do X and are 
getting along just fine interoperating with everyone, then the spec 
can't legitimately say, "You MUST do X". Conversely, if there are 
implementations that don't do X and they crash, or screw up bunches of 
other implementations, or can't interoperate with bunches of 
implementations, then the spec really needs to say "You MUST do X". The 
spec isn't "making them non-conformant" (at least in any interesting way 
to me); the spec is simply being honest and saying that not doing X is 
demonstrably a bad idea. And if there are implementations that run in 
particular environments where doing X is really not necessary, but in 
general you'll be in trouble if you don't do X, then the spec should 
say, "You SHOULD do X".

Finally, if the spec says, "You MUST do X" and an implementation 
doesn't, an interoperating implementation can't simply crash. You've got 
to program defensively. And if the spec says, "You SHOULD do X", that 
doesn't mean that any implementation is perfectly welcome to not do X; 
if you're not in a particular environment where not doing X is known to 
be OK, you're not doing the right thing.

All in all, I don't think non-conformance is something we should get 
hung up about.

Observation 3: The IETF is often lousy about separating content from 
encoding. (And we are not alone.) Content is made up of theoretical 
entities. Maybe it's "characters" or "numeric values" or other things 
like that. Encoding is how we represent things "on the wire". So if you 
take a look at the ABNF spec, you will see that the terminals are simply 
non-negative integers. In particular, they are not characters in the 
sense of an abstract unit of a written language. ABNF terminals could be 
code points, but only if you declare when you use them that you are 
mapping them to a particular coded character set. So we can develop a 
spec that deals in simply numeric values and separately say whether and 
how it maps those numeric values into characters. How we encode things 
into 8-bit (or 7-bit or 16-bit or 32-bit) units is independent of what 
we are encoding, and is another step on top of mapping.

Like I said, I'll be posting some specific questions regarding how these 
observations apply to some of our current issues, but I wanted to get 
these out to see if it would center some thinking.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - [phone]