Unidentified subject!

>From http-wg-request@cuckoo.hpl.hp.com  Sat Nov 29 19: 13:02 1997
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.1) id TAA28458 for ange@cuckoo.hpl.hp.com; Sat, 29 Nov 1997 19:13:01 GMT
Date: Sat, 29 Nov 1997 19:13:01 GMT
X-Envelope-From: hallam@ai.mit.edu  Sat Nov 29 19:13:00 1997
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.1) id TAA28444 for <http-wg@cuckoo.hpl.hp.com>; Sat, 29 Nov 1997 19:13:00 GMT
Received: from hplb.hpl.hp.com by otter.hpl.hp.com with ESMTP
	(1.37.109.16/15.6+ISC) id AA130520778; Sat, 29 Nov 1997 19:12:59 GMT
Received: from life.ai.mit.edu by hplb.hpl.hp.com; Sat, 29 Nov 1997 19:12:53 GMT
Received: from russell ([18.23.1.191])
	by life.ai.mit.edu (8.8.5/AI1.15/ai.master.life:1.18) with SMTP id OAA00126;
	Sat, 29 Nov 1997 14:11:13 -0500 (EST)
From: "Phillip M. Hallam-Baker" <hallam@ai.mit.edu>
To: "Larry Masinter" <masinter@parc.xerox.com>,
    http-wg@cuckoo.hpl.hp.com
Subject: Re: A common registry for MIME headers?
Old-Date: Sat, 29 Nov 1997 14:10:47 -0500
Message-Id: <01bcfcfa$7fa34000$06060606@russell>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1712.3
X-Mimeole: Produced By Microsoft MimeOLE V4.71.1712.3
X-Diagnostic: Not on the accept list
X-Envelope-To: http-wg
Resent-To: http-wg@cuckoo
Resent-Date: Tue, 02 Dec 1997 11:24:13 +0000
Resent-From: Andy Norman <ange@hplb>




>I personally think it would be better if there were a common
>registry for 'headers' that included the list of which
>were useful in HTTP, EMail, NetNews, within particular multipart
>types, etc.
>
>I think it would help in future coordination between extensions
>of mail, news, other kinds of 'push', etc.


I think that Larry's point is a good one but the problem is
somewhat deeper. The problem is that the RFC structure
does not really support the layered nature of the protocols,
nor is the need for continuing extensions handled at all well.

The area in which this is most apparent is NNTP where
almost half the 'de-facto' NNTP standard has been outside
the IETF process for a decade. The recent NNTP extensions
work has thus been preformed in a remedial rather than a
pro-active fashion.

Two models to bear in mind, the UK and US legislative
processes. The RFC process is basically that of the UK 
parliament. Bills correspond to Internet drafts. They can 
be introduced by any member at any time and have no 
weight. RFCs correspond to 'Acts' - i.e. fully processed
and approved bills that have made it thorugh the committee
cycle. Except that RFCs also include documents that would
in the UK system be considered 'orders in council' 'white
papers' and all the rest of parliamentary clutter.

The US legislative system is rather different in that the 
acts passed are essentially a set of editing instructions for
another document, a consolidated statement of the law.
This is essentially the French Revolutionary model, impose
a uniform code.

The advantage of this second model is that it allows much 
more scope for 'tweakage' of an extant spec. Additional
headers can be specified and added into the general mix
without having to re-issue every spec that is dependent on
them.

For example consider the Digest Authentication Spec,
should it dock or not? Ideally I would like to be able to
'dock' specifications of this type after the HTTP/1.1 
spec has been fully approved and without re-opening 
HTTP.

The case of specs that cross working group boundaries 
makes a mechanism of this type even more important.
For example the MIME group would never accept the
real and legitimate objections of the HTTP community 
that since HTTP is 8-bit clean it was imperative that
a content length engoding be allowed. What was actually
a transport issue (SMTP implementations are habitually
broken meaning that content-length is not stable) became
a structural imperative.

As much of the communications infrastructure becomes
embedded in the operating system it becomes even more
important to systematize the means by which facilities can
be added to the general infrastructure while taking account
of the specific limtations of particular protocols.

So a possible new structure for RFCs would be as a set of 
editing instructions. The protocol headers (or whatever)
would be specifie with a description for each. Then another
section would discuss the applicability of the headers to each 
of the MIME based transport protocols SMTP, NNTP and 
HTTP.

Some centralized document would be maintained with a
structure designed to allow component-wise editing (i.e. 
the addition of additional chunks). There might be cross
references in this document so that additional rationale
for a particular change might be found in an acompanying 
RFC..

In short this is not a simple 'registration' function but a 
fundamental change in the way the IETF operates. It would 
have many advantages, in particular avoiding the repetative
re-writing of introductory material which may or may not
contain substantive changes.

The problem is getting agreement to make such a change.
There are still folk that turn purple at the heretical suggestion
that RFCs should be issued in HTML. Their rationale being 
based on a bad experience with postscript. One ill fated 
experiment in the middle ages having proved that for all time
there can be no improvement on ASCII text. This is why
every single person down in Washington the week after next
will carry at least one RFC which has been misprinted.

And don't think for a moment that the response that everyone
will give to proposals for change is to agree with them but
lament at great length that they wont be changed.

Such things are the spark of revolutions.

            Phill

Received on Tuesday, 2 December 1997 03:30:52 UTC