Subject: [Tools-discuss] ietf-ftpext-mlst

From: Frank Ellermann <[email-masked]>
Date: Sat, 02 Dec 2006 12:08:00 +0100

Hi, trying <http://tools.ietf.org/id/ietf-ftpext-mlst> and variants
adding -16 or -16.txt I got a 404 "not found".  But it exists as
<http://www.ietf.org/internet-drafts/draft-ietf-ftpext-mlst-16.txt>.

I stumbled over RFC.ietf-ftpext-mlst-16.txt on the IANA matrix page,
apparently it's for more than three years in the RFC editor queue:

<http://rtg.ietf.org/~fenner/ietf/rfc/hist.cgi?draft=draft-ietf-ftpext-mlst>

Could http://tools.ietf.org/id be modified to find such documents ?

Frank

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

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 02 Dec 2006 12:53:47 +0100

Hi Frank,

> <http://www.ietf.org/internet-drafts/draft-ietf-ftpext-mlst-16.txt>.

If you try
  http://tools.ietf.org/id/draft-ietf-ftpext-mlst
instead of
  http://tools.ietf.org/id/ietf-ftpext-mlst

you find it just fine.

> Could http://tools.ietf.org/id be modified to find such documents ?

So, was the "not found" above just the result of mistakenly leaving "draft-"
off the beginning of the string, or is the request to actually make the
/id/ tool try to fix this kind of mistake by testing with a draft- prefix
if the first search didn't succeed?  I could do that, I just want to be
sure what the request is ,;-)

	Henrik

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 02 Dec 2006 16:24:31 +0100

>   http://tools.ietf.org/id/ietf-ftpext-mlst

Ouch, and I can't claim that it's lack of coffee...

> I just want to be sure what the request is ,;-)

...the request was bogus, I forgot to replace the
"RFC" in RFC.ietf-ftpext-mlst by "draft-".  With
"I-D" it's more obvious.

In theory your tool could try to "do what I mean":

draft-xxx      try draft-xxx-*.txt
I-D.xxx        try draft-xxx-*.txt
RFC.xxx        try draft-xxx-*.txt
RFCnnnn        as is, ditto BCP, FYI, STD
nnnn           try RFCnnnn.txt
xxx            try draft-xxx-*.txt

But probably that's overkill, only IANA uses the
RFC.xxx convention, and only I messed it up... ;-)

Frank

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 02 Dec 2006 17:03:47 +0100

Hi Frank,

on 2006-12-02 16:24 Frank Ellermann said the following:
...
> "RFC" in RFC.ietf-ftpext-mlst by "draft-".  With

Ah, Ok.  Nevertheless, I added the ability to handle
/id/ietf-ftpext-mlst .  With that in place, /id/ now
handles the cases

/id/draft-xxx	tries draft-xxx*.txt
/id/xxx		tries draft-*xxx*.txt

> RFC.xxx convention, and only I messed it up... ;-)

Yes.  The intention was to have /id/ look up I-Ds, only, and
the I-D. and RFC. notations are fairly unusual (I haven't seen
them used in a link, anywhere), and for manual usage the two
cases which are now handled should suffice.

The /html/ tree is closer to the do-what-I-mean philosophy, and
handles the following:

/html/draft-xxx		(if unique)
/html/RFCnnnn		
/html/nnnn		
/html/BCPnn		
/html/FYInn
/html/STDnn

For some reason, this does not work, even if it should:

/html/ietf-xxx		(if unique)

I'll have a closer look at that.

Regards,

	Henrik

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 02 Dec 2006 18:04:57 +0100

Henrik Levkowetz wrote:
 
> Nevertheless, I added the ability to handle
> /id/ietf-ftpext-mlst

Nice, thanks, I always love shorter URLs :-)

> The intention was to have /id/ look up I-Ds, only

Okay, makes sense, I didn't know that /html/ added
the "rfc" etc. features, and thought that they were
a part of /id/.   

> the I-D. and RFC. notations are fairly unusual
> (I haven't seen them used in a link, anywhere)

RFC.xxx is unusual, but I-D.xxx is what you get with
xml2rfc for a bare <xref target="I-D.xxx" />, e.g.
   <xref target="I-D.ietf-usefor-usefor" />
is shown as
   [I-D.ietf-usefor-usefor]
for a "normal" (= imported from xml.resource.org)
   bibxml3/reference.I-D.ietf-usefor-usefor.xml

> the two cases which are now handled should suffice.

ACK, it also preserves the dot for the ".txt" magic -
if that's how you handle extensions, but this would
break for other dots in a document name.

> this does not work, even if it should:

Probably the /html/ magic never tries /id/ietf-xxx
if it doesn't see a "draft-" at the begin (?)  

Frank

---

From: Julian Reschke <[email-masked]>
Date: Sat, 02 Dec 2006 18:10:37 +0100

> Nice, thanks, I always love shorter URLs :-)

Just make sure that there is *one* preferred URI for RFCs and IDs (in 
HTML), and make sure those do not break :-)

Best regards, Julian

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 02 Dec 2006 18:21:13 +0100

Hi Frank,

on 2006-12-02 18:04 Frank Ellermann said the following:
...
> if it doesn't see a "draft-" at the begin (?)  

Right, it just did a redirect to /id/.  Fixed now.

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 02 Dec 2006 18:24:06 +0100

Hi Julian,

> HTML), and make sure those do not break :-)

Right.  For RFCs it's /html/rfcNNNN, and for drafts it's the exact
full draft name without revision and extension in order to get the
latest revision, and full draft name with revision, without extension,
to get an explicit revision.  This has been the invariants for quite
some time, now, and I'll keep in mind not to change that.

	Henrik

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 02 Dec 2006 21:40:58 +0100

> Just make sure that there is *one* preferred URI for RFCs
> and IDs (in HTML), and make sure those do not break :-)

ACK, I won't use the "omit draft-" or "omit rfc" tricks in
any public URLs.  Has <link rel="bookmark" href="pref-URI" />
an effect with modern browsers ?  

The "show last I-D" feature could use this, the location is
the complete URL .../html/draft-xxx-nn.txt, the bookmark is
.../html/draft-xxx, unless the query was explicitly for -nn.

Frank

---

From: Julian Reschke <[email-masked]>
Date: Sat, 02 Dec 2006 22:03:22 +0100

> .../html/draft-xxx, unless the query was explicitly for -nn.

It does has an effect in some browsers (such as Seamonkey I think), and 
will also have an effect in Firefox with the right extension installed 
(see 
<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#html.link>). 
I'm using this to add back/forward links to the HTML versions of my IDs.

Best regards, Julian

---

From: Henrik Levkowetz <[email-masked]>
Date: Sun, 03 Dec 2006 02:51:45 +0100

Hi Frank

> an effect with modern browsers ?  

I believe so, although I haven't used it.

> .../html/draft-xxx, unless the query was explicitly for -nn.

Yes.  Except that means I'd have to re-write cached pages to
insert or change the <link/> element depending on what the
original request was for.  I'd prefer not to do this (at least
at this time) - the request counts for /html/ pages have been
rising steadily over the last 8 weeks or so, and if I hadn't
changed to caching I would probably have been in occasional
trouble for one of the servers now (not enough processing power).

For plain page fetches the load isn't troublesome.  It's now a
bit more than 4000 pages average non-Googlebot requests per day
per server, and a bit more than that from the Googlebots.  But
the number was about half of that about 2 months ago.  I expect
it to continue climbing.  Peak numbers are ~20000 /html/ requests
per server per day.

	Henrik

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 03 Dec 2006 07:48:51 +0100

Henrik Levkowetz wrote:
 
> I'd have to re-write cached pages to insert or change the <link/>
> element depending on what the original request was for.  I'd
> prefer not to do this

Understandable, and caching both variants would be clumsy.

> the request counts for /html/ pages have been rising steadily
> over the last 8 weeks or so

Odd, why only in the last 8 weeks, the wikipedia change was
months ago...  Checking Google with two RFCs, no, you're under
the top ten with /html/, but not (yet) under the top three...

> Peak numbers are ~20000 /html/ requests per server per day.

...I swear it's not only me, there must be another fan :-)

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 03 Dec 2006 09:22:00 +0100

> apparently it's for more than three years in the RFC editor queue:

Remember that a draft in the queue does not expire from the regular
directory:
http://www.ietf.org/internet-drafts/draft-ietf-ftpext-mlst-16.txt

You can also find such cases through the RFC Editor queue or through
various Bill tools including
http://rtg.ietf.org:8080/Test/parking

(This particular case is an unfortunate one but there is work in
progress to get it resolved.)

     Brian