|
Agreed
I do not see separate mileage in separate vendor trees.
They only work to me if we can grandfather some package off another
package.
Keith
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
(where RFCYYYY is some
standards track RFC)
And then,
someday we get
(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
|