Subject: RE: text suggested by ADs

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 29 Apr 2005 13:20:39 -0700

> From: Bob Braden [mailto:[email-masked]] 
 
>   *> If the STD series is going to be useful then the tool 
> that spits out the
>   *> current status of the RFCs should spit out HTML pages 
> with the RFCs
>   *> indexed by status. 
>   *> 
> 
> Presumably you mean:
> 
	http://www.rfc-editor.org/category.html

Which is linked from the rfc-editor's site, not from the home page of
the IETF whose documents they are.

If we go to www.ietf.org with the objective of finding current Internet
standards and follow the obvious navigation links we don't get there.

http://www.ietf.org/rfc.html is worse than useless, unless you know that
the RFC-Editor's pages is where the status is you cannot find what you
went to get. It is not logical to look on the RFC-Editor's site for
information that results from decisions of the IESG.

It would be much better to merge the two pages into one so that someone
who comes looking for the information on an RFC can find it.

Equally the RFC-Editor Queue information is really tracking the status
of internet drafts, not RFCs.

Basically the Web site design is from a much earlier era when people
accessed the web from 14K dial up and web site designers were taught to
only put five navigation options per web page. If you look at the OASIS
and W3C pages you will see that this particular guideline has been long
abandonded. Taxonomic navigation only works if people already understand
the categories being used, the categories used on the IETF site are
vague, confused and arbitrary.

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

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 30 Apr 2005 00:34:05 +0200

Hallam-Baker, Phillip wrote:

> the Web site design is from a much earlier era when people
> accessed the web from 14K dial up and web site designers were
> taught to only put five navigation options per web page.

My V.90 is not much better than 14K, and a Web design allowing
access with poor bandwidth is still perfection, also known as
"do as amazon does".  The rfc-editor pages are generally fine.

There are of course ways to improve things, e.g. if I see an
interesting I-D I'd like to know where to send public comments
without "subscription" hurdles, and I'd like a way to track
its way through the iETF independent of minor changes like a
new document name (i.e. something like a PURL), etc.

> the RFC-Editor Queue information is really tracking the
> status of internet drafts, not RFCs.

It's only the POV of the rfc-editor, the IESG has its own POV.
They are different, where's the problem with this ?  Merging
these state diagrams could be a dubious move, they are already
very convoluted.

I've never found out who or what "deadir" is, and I've no idea
who added a known to be harmful "RfC editor note" to a draft
I'm interested in.  Maybe it's a bug in this tracker business.

                          Bye, Frank