Subject: RE: [Ltru] status of RFC 3066 or RFC 3066bis in relation to HTTP Accept-Language

From: "McDonald, Ira" <[email-masked]>
Date: Fri, 24 Mar 2006 07:28:45 -0800

Hi Peter,

You may take this answer about "IETF versioning" with a grain
of salt, but...

When I complained awhile back to Roy Fielding that RFC 3986
renamed many ABNF productions from RFC 2396 and left others 
out entirely, Roy told me that it did no harm, because all those
pre-existing RFCs that already normatively referenced RFC 2396
still did so (in perpetuity), because the IETF does not follow
the ISO, ITU-T, and IEEE style that a newer version of a given
standard is automatically the normative reference intended.

I thought at the time that this was sophistry - I still do!

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked] 

-----Original Message-----
From: Peter Constable [mailto:[email-masked]]
Sent: Thursday, March 23, 2006 8:36 PM
To: [email-masked]; [email-masked]
Subject: [Ltru] status of RFC 3066 or RFC 3066bis in relation to HTTP
Accept-Language

RFC 2616 (HTTP 1.1) makes reference to RFC 1766 for use in Accept-Language.
Of course, 1766 was obsoleted by 3066; it was also obsoleted by RFC 3282
"Content Language Headers", which discussed both Content-language and
Accept-Language.
 
It's not clear to me how versioning is handled in IETF specs: since RFC 1766
is obsoleted by these other docs, is RFC 2616 effectively updated so that
every reference to RFC 1766 is now treated as a reference to RFCs 3066 and
3282 (or, rather, 3066bis in the former case)?

Thanks.
 
Peter Constable
GIFT | GPTS | MICROSOFT

--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.3.1/291 - Release Date: 3/24/2006

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.3.1/291 - Release Date: 3/24/2006

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: Ned Freed <[email-masked]>
Date: Fri, 24 Mar 2006 09:18:10 -0800 (PST)

> As a long-time IETFer:

> Typically, these matters are handled on an ad-hoc case-by-case basis in
> which common sense prevails.

> The razor in this case is "does something break?"  Most updates to IETF
> documents expand upon, or clarify, what was in the older document; they do
> not introduce an incompatibility.  If something is removed, that is
> generally because there is community concensus that it is bad juju.

> So, given RFC abcd that normatively references RFC efgh that has been
> obsoleted by RFC ijkl:
>   . can two RFC abcd implementations communicate with each other, and the
>     desired behavior happen, even though one uses RFC efgh and the other
>     uses RFC ijkl?

> If the answer is yes, then the question is effectively academic in nature.
> Sometime in the future, RFC abcd will have to be updated to reflect the
> change to RFC ijkl, but as it doesn't break interoperability it isn't
> urgent.  One might expect that old implementations will use RFC efgh and
> new implementations will use RFC ijkl.

> If the answer is no, then someone was not doing their job; RFC ijkl should
> not have been approved without that working group taking on the needed
> update to RFC abcd.  An important purpose of the IETF/IESG bureaucracy is
> to prevent something like this from happening.

> Hence the answer that since RFC abcd normatively refers to RFC efgh, it is
> RFC efgh that is used by an RFC abcd implementator.  It is, however,
> expected that people would tend to use RFC ijkl instead (if only because
> it has clearer wording and represents more modern understanding) -- and
> sooner or later, RFC abcd will be obsoleted by a RFC mnop that makes this
> change official.

> Equally important is that RFC ijkl should not have been approved for
> publication if it creates an incompatibility problem in RFC abcd, without
> also updating/obsoleting RFC abcd.

Full agreement on all points.

				Ned

---

From: "Peter Constable" <[email-masked]>
Date: Fri, 24 Mar 2006 09:56:57 -0800

> From: Ned Freed [mailto:[email-masked]]

MC> > Typically, these matters are handled on an ad-hoc case-by-case
basis in
> > The razor in this case is "does something break?"  

...

> Full agreement on all points.

This still leaves things somewhat vague wrt the specific question I
asked. You're saying that technically RFC 1766 is still the spec for
Accept-Language, but it's expected that people will actually use 3066bis
-- and as for "sooner or later", RFC 2616 was published in 1999, and RFC
3066 was published in 2001, so we've already had five years go by during
which 2616 could have been obsoleted by another doc that normatively
referenced 3066 but that hasn't happened.

If I needed to give a recommendation to a team that has to deal with
Accept-Language, it's really unclear to me which Language-Tag RFC I
should point them to.

Peter Constable

---

From: Ned Freed <[email-masked]>
Date: Fri, 24 Mar 2006 13:33:21 -0800 (PST)

> asked.

Indeed it does.

> You're saying that technically RFC 1766 is still the spec for
> Accept-Language,

Well, actually I was simply agreeing with something Mark said.

> but it's expected that people will actually use 3066bis

Yes, more or less.

> Accept-Language, it's really unclear to me which Language-Tag RFC I

My recommendation would be to refer them to the one that makes the most
sense for them to use. Sorry it doesn't get more precise than that, but that's
the eay it is.

				Ned

---

From: Mark Crispin <[email-masked]>
Date: Fri, 24 Mar 2006 09:11:58 -0800 (PST)

As a long-time IETFer:

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

---

From: Mark Crispin <[email-masked]>
Date: Fri, 24 Mar 2006 10:23:05 -0800 (PST)

The best answer to your question is "does it matter?"

Suppose there are three RFC 2616 implementations:
  . implementation A uses RFC 1766
  . implementation B uses RFC 3066
  . implementation C uses RFC 3066bis

Do these three implementation interoperate with each other?  Does the 
expected behavior happen?

If YES, then it doesn't matter.  Someday, an update to RFC 2616 will be 
published that uses RFC 3066bis (or whatever replaces it).

If NO, then RFC 1766 rules.  You have identified an urgent need for RFC 
2616 to be updated immediately.

If YES, then when you give a recommendation to a team, say "use RFC 
3066bis since that's the way of the future.  An RFC 1766 based version 
will work just fine against your code."

If NO, then say "don't implement RFC 2616.  It's broken."

Quite frankly, if 1766 -> 3066 -> 3066bis causes a NO, then the WG did not 
do its job.  Nor did the IESG.

-- Mark --

http://panda.com/mrc