Subject: [Tools-discuss] Re: I-D ACTION:draft-ietf-tools-draft-info-03.txt

From: Brian E Carpenter <[email-masked]>
Date: Thu, 17 Nov 2005 14:40:46 +0100

Hadn't had a chance to look at the earlier drafts, so these are basic comments.

> 3.  Scope
...
>    The interfaces required to locate a draft or correlate information
>    about multiple drafts are out of scope.

That's a problem, because is this very fundamental to draft tracking.
I believe these three items must be in scope:

Replaces: <draft identifier>
Replaced by: <draft identifier>
Grouped with: <draft identifier>

All of these are currently supported by the I-D tracker.

> 6.2.1.  Status
> 6.5.  Draft events

I don't see the point of separating these. I think it's
necessary and sufficient that each status/state is timestamped
with entry/exit timestamps (and BTW, a draft can enter the same
state many times, so you could have

AD Follow-up:
in:  2005-10-25 21:50
out: 2005-10-26 00:51
in:  2005-10-26 21:52
out: 2005-11-14 21:53
in:  2005-11-17 00:49

for a draft currently in state AD Follow-up

Also in

> 6.2.1.  Status
...
>    An active or expired draft can be in one or more states related to
>    IESG review activity.  These states are not documented here, but
>    implementations must provide this information using the current state
>    list and state definitions maintained by IESG.

States can have sub-states, so the model needs to be recursive.

Not only the IESG generates states, so the framework should allow
for states generated by the Author(s), Editor(s), WG Chair(s),
WG Secretary, PROTO Shepherd, IESG Shepherd, Secretariat, RFC Editor,
and IANA. These can't all be defined in advance but must be possible
to add.

Incidentally, all of the above actors may need to be associated with
the draft, so the framework needs to allow for that too.

<actor role="author" email="[email-masked]">Alex Rousskov</actor>

> Appendix A.  Comparison with current procedures
...
>    o  Currently, IETF provides only the latest draft version.  This
>       document requires providing all unexpired versions.  This change
>       allows to maintain a change history useful for draft review and
>       discussion.  The change does not seem to contradict written IETF
>       rules and principles.

Actually that depends on how you choose to read the text of RFC 2026
section 2.2. Also, a meaningful history needs access to expired drafts.
RFC 2026 requires us to remove expired drafts, so that *is* a rule.
Some draft authors really care about this and in some cases have forced
all the unofficial archives to remove superseded drafts. It's rare, but
it can happen. So I would suggest rethinking this - let's be up front
and ask the community to get rid of the rule that expired I-Ds are
invisible, with an opt-out clause.

     Brian

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

---

From: Larry Masinter <[email-masked]>
Date: Thu, 17 Nov 2005 10:38:41 -0800

> .... So I would suggest rethinking this - let's be up front

Perhaps there is some middle ground, between "removing" and "keeping"
that could be an option.

For example, change it so that trying to access an expired I-D
through the web will give you something with a note at the beginning
explaining the draft is expired, whether it's been replaced,
a pointer to the latest draft or replacement or RFC. After this
information (which could always be available), then the text
of the (older) draft could be either there or not, depending on
IPR rights and opt-out choice.

Larry

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 Nov 2005 13:21:46 +0100

> IPR rights and opt-out choice.

I like that. If I wasn't worried about Henrik's workload, I'd mention
that at least part of this would look like an easy fix to
http://tools.ietf.org/id/

     Brian

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 18 Nov 2005 15:32:43 +0100

Brian E Carpenter wrote:

> at least part of this would look like an easy fix to

Nice tool, I didn't know it.  At the moment it wants
the file name draft-...-NN.

It won't tell me if NN is really the latest version, I
tried it with "procdoc":  -00 up to -02 are all still
available.  For -03 I get an error with a link to -02.

For a quick hack I could ask for -99 to get a link to
the last available -02.  But what I really want would
be to arrive directly at the last available -02.

For that the tool could support the file name without
a version, draft-... instead of draft-...-99, to get
into some "do what I mean" mode:

http://tools.ietf.org/id/draft-carpenter-procdoc-roadmap

And actually it does this already, my browser is only
too stupid to interpret the relative URL in the 303:

~~~ cut ~~~
HTTP/1.1 303 See Other
Date: Fri, 18 Nov 2005 14:24:05 GMT
Server: Apache/2.0.54 (Debian GNU/Linux) mod_python/3.1.3 Python/2.3.5
PHP/4.4.0-4 mod_perl/2.0.1 Perl/v5.8.7
Docname: draft-carpenter-procdoc-roadmap
Docbase: draft-carpenter-procdoc-roadmap
Location: draft-carpenter-procdoc-roadmap-02.txt
Connection: close
Content-Type: text/html; charset=iso-8859-1

~~~ end ~~~

With an absolute URL it should work, and probably a
Content-Length: 0 is also important for old browsers
getting an empty reply.
                        Bye, Frank

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 18 Nov 2005 19:16:12 +0100

Hi Frank,

> be to arrive directly at the last available -02.

Omitting the -NN should give you the latest draft already.

This is the third example you'll be shown if you go to
simply http://tools.ietf.org/id/ .  

It works for me; if it doesn't work for you, something's
broken; but I try to check all the examples every time I
tweak the script a little bit.

> And actually it does this already,

Ahh - you found that :-) ...

> my browser is only

... but there's some trouble...

> Content-Length: 0 is also important for old browsers

Oho.  Ok.  Absolute URL fixed.  I added the Content-Length: 0 header
too, but Apache has it's own ideas, and strips that out again.  Sorry.
Let me know if it works with the absolute URL.

	Henrik

---

From: Bill Fenner <[email-masked]>
Date: Fri, 18 Nov 2005 11:05:24 -0800

>Oho.  Ok.  Absolute URL fixed.

A little-known fact is that Location: headers are not permitted
to be relative.  It's little-known because nearly every browser
works when presented with a relative Location: header.

  Bill

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 18 Nov 2005 20:38:57 +0100

> works when presented with a relative Location: header.

Hah.  That also explains why the apache Redirect directive requires
an absolute target URL, rather than a relative one - something I've
found to be a slight pain when deploying the same page with multiple
URLs, and then needing to move it...

Thanks for the info :-)

	Henrik

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 19 Nov 2005 19:20:02 +0100

Henrik Levkowetz wrote:

> Absolute URL fixed.  I added the Content-Length: 0 header

Testing again, I still get only "document contains no data",
the absolute URL plus "Content-Length: 0" doesn't help, sigh.

How about just sending the same or a similar non-empty content
as for version -99 ?  And / or if you can "see" that the query
is HTTP/1.0 just try 302 as proposed in 2616:

| Note: Many pre-HTTP/1.1 user agents do not understand the 303
| status. When interoperability with such clients is a concern,
| the 302 status code may be used instead, since most user
| agents react to a 302 response as described here for 303.

For "Many" read "Some of my".  Lynx gets it right (as always),
but Netscape 3.x and 4.x fail.  
                               Bye, Frank

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 19 Nov 2005 20:08:25 +0100

> is HTTP/1.0 just try 302 as proposed in 2616:

Actually, since the output of the request shouldn't change for the
same input, 302 might be a better response than 303 overall.

> but Netscape 3.x and 4.x fail.  

Ok, I've changed to 302, and also added a little snippet providing
a hypertext link to the new location, as recommended.  Please
see if this works better.

Regards,

	Henrik

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 19 Nov 2005 23:41:44 +0100

Henrik Levkowetz wrote:

>> Netscape 3.x and 4.x fail.
> Ok, I've changed to 302

Some hours of test failures later, `rxhost tools.ietf.org`
| 192.36.157.99    cabernet.verkstad.net
| 81.224.201.50    81-224-201-50-no45.tbcn.telia.com

Okay, that makes testing certainly interesting ;-)  Yes, with
one of these two servers it now apparently works.  Bye, Frank

---

From: Henrik Levkowetz <[email-masked]>
Date: Sun, 20 Nov 2005 00:28:13 +0100

Hi Frank,

> one of these two servers it now apparently works.  Bye, Frank

Oh, dear.  First time around, I remembered to push the changes out
to the secondary server.

This time, I forgot :-((((

I'm really sorry, Frank.

One of the cron jobs would have taken care of it in about 3 hours,
but I've pushed the scripts over to the secondary anyway, now.

You can always test against the primary (where I try out changes)
by explicitly going to http://www1.tools.ietf.org/

Anyway, it's good that it works now.  My apologies for your
wasted time.

	Henrik

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 20 Nov 2005 01:07:15 +0100

Henrik Levkowetz wrote:

> I'm really sorry

No problem - I learned a lot of things that won't cause a
problem, and I didn't know that my browers apparently stick
to whatever IP they got, unfortunately it was the "wrong"
IP for this test ;-)  www1.tools.ietf.org noted, bye, Frank