[rfc-i] URL Issue, was Re: draft-iab-streams-headers-boilerplates-07.txt

Joe Touch touch at ISI.EDU
Thu Apr 9 20:49:41 PDT 2009

Hash: SHA1

Martin J. Dürst wrote:
> On 2009/04/10 2:53, Joe Touch wrote:
>> Lars Eggert wrote:
>>> On 2009-4-9, at 19:30, Joe Touch wrote:
>>>>      http://www.rfc-editor.org/info?rfc=2468
>>> This exposes implementation details that I'd rather see hidden for a
>>> permanent URL.
> I agree that for a permanent one, / is more appropriate.
>> Both / and ? expose implementation details. It's not easy to implement
>> either with the other.
> On an average server (e.g. Apache), it's dead easy. Probably about three
> lines with mod_rewrite, a few more if you do it as a CGI, depending on
> what language (Perl, PHP, Python, Ruby,...) you use.
> In general, I'm against prescribing too much implementation detail.
> But URIs aren't an implementation detail, URIs are *public interfaces*.
> Being able to say "You can always find the latest status of an RFC at
> http://foo.bar/baz/rfcXXXX." is very strongly different from saying
> "There's an URI where you can figure out the latest status of RFCXXXX,
> go figure."

I agree. The boilerplate should require a specific URL, but shouldn't
itself specify what that is IMO.

> That's why I would prefer to just tell them "that's it", but if we
> really cannot go there, then at least tell them: Decide once, keep it
> "forever". 

Like all boilerplate, this is "forever" until it's changed, then it's
not. With the rate at which boilerplate changes, IMO we should specify
it as Java code that morphs in sync with the whims of the ISOC.

Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the rfc-interest mailing list