[AFS3-std] draft-brashear-afs3-pts-extended-names to Experimental

[Simon Wilkinson]

On 11 Mar 2011, at 23:27, Tom Keiser wrote:
> So, what are we going to do about the GetCapabilities issue?  A
> compliant implementation could cache this data forever, which
> is.....preposterous.  Can we can handle this via the RFC errata
> process?

It's not an RFC, and we're not the IETF, so no.=20

We've never really codified what happens next, beyond that being =
declared "experimental" is the point that people can go away and get =
identifiers, and release products containing the code. It's really =
important that this mean something, which is why I don't think we should =
accept late challenges or modifications to the document. People should =
be free to go away and write, and release, code based on this groups =
consensus without worrying that weeks later someone will go "hang on", =
and rewrite the standard under them.

Sure, we may get it wrong. When we do, we have to accept that code may =
be deployed containing our mistakes, and we have to consider how to fix =
those mistakes without breaking the deployed base.

In this case, there are two separate issues. The first is a document =
clarification (GetCapabilities responses should only be cached for a =
certain number of hours). I think that one is acceptable to bring back =
as a clarfication when the document is next advanced (which is the point =
it will, hopefully, become an RFC).

The second, however, is harder. I don't think that we can add fields to =
RPCs that have reached experimental. So, we have to decide whether the =
possible race is sufficiently serious to warrant creating a new RPC, =
with a new code point, to implement this behaviour. In any event, it's =
perfectly acceptable for people to release code and/or ship products =
that contain the RFC as described within the current document - all we =
can do is propose a better successor.

Sorry, but the last call on this document closed in December of last =
year - the time for tinkering with this version is long past.

Simon.