OK, I agree.
Eric Burger wrote:
The nightmare is the proliferation of X-mumble (e-mail), P-mumble (SIP),
g.mumble, etc., especially when the experiment becomes standard.
I'd much rather have a registration that looks like:
Package Name Contact Reference
keypress SIP Work Group <[email protected] <mailto:[email protected]>>
RFCYYYY
coolpackage Proprietary Co <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> none
(where RFCYYYY is some standards track RFC)
And then, someday we get
coolpackage Proprietary Co <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> RFCZZZZ
(where RFCZZZZ is some Informational RFC or link to a stable document)
The multiple tree way gives us X-coolpackage at best and
com.example.coolpackage at worst, which might make foobar.com not want
to advertise example.com. Plus the package name give us a hint to what
it does...
On Nov 19, 2008, at 7:16 PM, Paul Kyzivat wrote:
Eric Burger wrote:
We can also have two trees, one Specification Required and one
Private. This has been proven to be an interoperability and marketing
nightmare, but I will put it out there for completeness.
Can you say more? Why would it be more of a nightmare than FCFS?
I would offer we go with First Come First Served. We can have a
field for a reference, giving us the best of the specification
required (you can look up what a published specification is) and
Private (if you are creating a private Info Package, you do not have
to specify anything other than the package name).
Please Vote:
[ ] First Come First Served with pointer to optional specification
[ ] First Come First Served
[ ] Specification Required
[ ] Expert Review
[X] Two trees: Specification Required and Private
IMO this is better than FCFS with pointer because it gives a higher
degree of legitimacy to those with specifications, which provides an
incentive to get that.
But I will make FCFS w/opt spec my 2nd choice.
Thanks,
Paul
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
