Re: When can we provide stable references to other standards bodies

[Cullen Jennings <[e-mail]>]

On 9/28/05 12:17 PM, "Dean Willis" <[e-mail]> wrote:

> 
> On Sep 26, 2005, at 12:48 PM, Cullen Jennings wrote:
>> 
>> We already have enough of "you can't change that non working group
>> draft,
>> 3GPP is using it" - lets not make it worse. Don't take this as I
>> don't care
>> that 3GPP documents depend on IETF ones, I do care and I want to
>> make that
>> easier and work better but I want to point out the problem is not
>> that they
>> need an RFC number but that they need a pointer (or RFC number) to
>> something
>> that is not changing in ways that will mess up their documents.
> 
> I think the need for a "non-changing pointer" outweighs the need for
> a pointer to a "non-changing specification".
> 
> The usual case is that an external document will refer to a proto-RFC
> in a general way: "The request must be encoded as a tel: URI as
> specified in POINTER".  They don't really CARE if the specification
> of tel: URI changes slightly because the RFC defining the ABNF got
> revved. They're committing to use whatever we put in that POINTER
> placeholder, with the general understanding that if it changes
> HUGELY, then we'll publish the newly-obsoleted spec as historical
> (preserving the POINTER) and work on a new document that will someday
> have a new POINTER.
> 
> 
> Their world just works differently from ours -- a few months ago, I
> sat in an OMA board meeting where we essntially approved release of
> three different versions of one enabler specification with a single
> vote. Why not just approve the latest version and drop the others?
> Because stuff pointed at the old versions by their version number.
> 
> --
> Dean

I hear you but not sure I buy it. We already provide non-changing pointers
very early in the process. A draft name, draft-willis-sip-answeralert-01, is
a non changing pointer. If a 3g spec references a tel URL draft, no one can
finalize an implementation until the details of the TEL ABNF are final.

If what they need is a placeholder for the RFC when it is finalized, then
seems like the draft name should work. Feel free to whack me in the head
here and tell me why a changing document reference by a 4 digit number is
better than a draft name but it's not obvious to me.

Every time I hear about a specific example of the problem, it sounds like
what 3G (and others) need is for us to finalize our RFCs sooner. Right now
the SIPish folks choose to spread very thin effort over many drafts instead
of trying to concentrate effort on a few key ones and quickly move to next.
I don't know if that is changeable but it is the best way I can imagine to
get key RFCs finalized sooner. It's probably a fairly good discussion for
the wgchairs list to discuss overall strategies for prioritization of an
overwhelming amount of work.

Cullen