I'd much rather have a registration that looks like:
Package Name Contact Reference keypress SIP Work Group <[email protected]> RFCYYYY coolpackage Proprietary Co <[EMAIL PROTECTED]> none (where RFCYYYY is some standards track RFC) And then, someday we get coolpackage Proprietary Co <[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 PrivateIMO 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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
