Subject: RE: [Sip] WGLC for URI and Header Parameter Registries

From: [email-masked]
Date: Wed, 22 Oct 2003 09:06:21 +0300

I agree with that, but what would you call the parameters created by 3GPP? are they one-off? They are certainly not thrown away after being used once.

I'm not suggesting that every parameter needs an RFC. I'm suggesting that every parameter needs to be registered.

If the student's project starts to be widely used and adopted, then he needs to register his parameter. I don't know when you do and when you don't need and RFC. That's a separate issue.

/Hisham

> -----Original Message-----
> From: ext Dean Willis [mailto:[email-masked]]
> Sent: Tuesday, October 21, 2003 8:35 PM
> To: Khartabil Hisham (NMP-MSW/Helsinki)
> Cc: [email-masked]; Niemi Aki (NMP/Helsinki);
> [email-masked]; [email-masked]
> Subject: RE: [Sip] WGLC for URI and Header Parameter Registries
> 
> 
> On Tue, 2003-10-21 at 02:07, [email-masked] wrote:
> > Dean sai:
> > > We did NOT have consensus that every parameter that might 
> ever be used
> > > for a one-off application needed to be registered.
> > 
> > What does "one-off application" mean?
> 
> "One-off" is a colloquialism for a thing used one time and then
> discarded or obsoleted.
> 
> An example here might be a college student who is working on an
> application using SIP to invite his friends to play a game 
> that he just
> wrote as a class project. The invitation carries a new 
> parameter he made
> up, "Game=X78hj9p" that the SIP proxy uses to route players 
> to the right
> game session.
> 
> Since he hasn't written the RFC to register the parameter "Game" and
> define exactly what the value "X78hj9p" means, we'd have to 
> send out the
> protocol police to arrest him for violating the specification. Or even
> worse, perhaps his professor would force him to write the 
> RFC, and then
> "Game" could ONLY be used as he had previously specified it, and every
> other college student from then on out with have to come up with
> something else to call their new parameter. In short, 
> something that has
> no reason to be "standardized" would suddenly become an IANA 
> registered
> reality . . . (this is especially aggravating on an open-registration
> first-come-first-served registery).
> 
> Or we go with plan B -- since "Game" isn't a registered parameter, he
> can use it however he wants, and if it breaks something (like the
> different use of "Game" in his roommate's class project), that's his
> problem. Or his roomates. But if he tries to reuse "lr", which we DID
> register (and define in an RFC), his professor can slap him around and
> point out the documentation for what he did wrong.
> 
> --
> Dean
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Dean Willis <[email-masked]>
Date: Wed, 22 Oct 2003 10:40:33 -0500

On Wed, 2003-10-22 at 01:06, [email-masked] wrote:
> I agree with that, but what would you call the parameters created by
> 3GPP? are they one-off? They are certainly not thrown away after being
> used once.
> 

The 3GPP p-headers are documented by informational RFCs, as required by
RFC 3427. I'm not up to date on any parameters they've proposed, but I
would expect those to be properly documented, if there are any.

> I'm not suggesting that every parameter needs an RFC. I'm suggesting
> that every parameter needs to be registered.

You mean "every WIDELY USED parameter", right? That would make it
consistent with what you say next . . .

> If the student's project starts to be widely used and adopted, then he
> needs to register his parameter. I don't know when you do and when you
> don't need and RFC. That's a separate issue.

Well, under the policy we have proposed, if the parameter starts to be
widely used, then it needs an RFC.

One alternative that might make you happier is a policy of
"Specification Required", where that specification can be any publicly
acessible body of work recognized by the RFC Editor, including ITU and
3GPP specs.

--
Dean