Subject: RE: [newtrk] Re:

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 10 May 2005 16:04:51 -0700

> [mailto:[email-masked]] On Behalf Of Bruce Lilly

> > Why? What is the utility in deciding which are the five or 
> six draft 
> > standards that are obsolete out of sixty that have been in 
> that state 
> > for four years or more?
> 
> Huh?  The 2026 section 6.2 process (q.v.) provides for 
> review, decisions, and notification to the IETF at large.  A 
> valid decision is movement to Historic.

Sure if people can be bothered to do that.

But what I am saying is that rather than waiting for someone to have the
time to decide which of the draft standards are really standards the
best thing to do short term is simply approve everything in the queue.

I am not that worried about a document marked 'standard' that is
arguably historic, they cause little harm. But 821 and 822 which have
been obsolete for years and are causing a real problem as is the
obsolete TCP document discussed earlier.

> > Neither of which was on standards track. Gopher (1436) is 
> > informational, Archie is not even an RFC, it is described in 1580 
> > which is also informational.
> 
> But both were sufficiently well defined to produce multiple 
> client implementations, both are stable (unlikely to change). 
>  So I disagree with your dismissal of utility as a criterion.

If they had become draft standards I don't think it would cause harm to
promote them. Since they were never standards in any degree the question
is irrelevant.

> <much elided>
> You're not helping the case for the "runs on Proposed 
> Standards" claim by changing the subject every time it's challenged...

I never made that claim, what I claimed is that the current STD
designations are an actual menace. Several STD series documents are
obsolete because they have been superceeded by other RFCs. 

> > If anyone thinks that I or anyone else who worked on 
> HTTP/1.1 has any 
> > intention of doing any more work on that draft to get it 
> advanced in 
> > IETF process they are mad. If you think what reopening the process 
> > would mean it becomes clear that it is impossible. People 
> would start 
> > re-opening old debates that are long closed and irrelevant.
> 
> Not with a suitably-defined charter and an active chair.

I don't care who you got to chair such an exercise, without the original
design team it would be a farce. 

> > Moreover the
> > group of individuals who would work on the project would be self
> > selecting and probably have no relationship at all to the 
> original group
> > who created the protocol. 
> 
> Perhaps they would do a better job on the Security 
> Considerations -- I 
> note that 2616 makes no mention of "web bugs".

Probably because they are an artifact of Marc Andressens broken HTML IMG
tag specification and are not an issue with the HTTP transport. The TCP
spec probably does not mention Web Bugs either, nor should it, it is an
HTML layer issue.

> > I certainly do not see any logic in continuing to publish a 
> list that 
> > describes RFC 821 and RFC 822 as 'standards' when they are long 
> > obsoleted by 2822 and 2821
> 
> If and when 2821/2822 successors reach Standard status, 
> 821/822 will be obsolete and presumably moved to Historic.  
> The fact is that now much of the infrastructure and deployed 
> UAs use 821/822.

But if you read 2821 it says it already replaces 821.

.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html