>One of the things that is affected by this choice is the extension
>mechanism. Suppose I want to try out a new feature. I'll do it
>privately, and then I want to register it and make it public. If
>I just pick a number, '43', I'm likely to hit someone else's number.
>So maybe I'll use a number out of the private extension space, e.g.,
>'123451'. But then when I change from 'private extension' to
>'public', I have to go back and recompile all my test code.
Being able to run the same code both with a private extension and
after the extension is formalized seems like a stretch. MIME types,
for example, map all extensions to x-* and if/when a type becomes
public, it is moved to the normal range.
For private testing you can pick any extension you want. You chance
of running into someone elses is minimal, because you are just
testing.
As I alluded in an earlier posting, I would propose extensibility for
an all-binary encoding by creating a "vendor extension" attribute
whose first at least four bytes of value must be checked by the
vendor to determine if it is there extension.
This won't help your code recompile issues, in fact, it is a little
bit more complicated than just picking a range of IDs for vendor
extensions. The advantage is that the range is virtually unlimited
and the chances of collision are reduced.
>This sounds pretty sloppy, but it's mainly what's done now for
>many protocols and it's much more robust than numbers.
Many (most?) protocols require all vendor extensions to start with a
particular prefix, such as X- (MIME, SMTP/NNTP, ???). This is to
ensure that the standardization process does not stomp on a vendor
extension, and does not have to worry about such.
>The protocol strings aren't human-language, they're just close enough to
>language to believe that they're extensible in a more distributed
>fashion.
Perhaps to mistakenly believe...
>In addition, the debugging and testing aspects shouldn't be ignored;
>it's useful to be able to write a test program in a scripting language
>or even to telnet to port 80 at a host and just type "GET url HTTP/1.0"
>without having to count bytes.
Which is quite unrealistic for what we are trying to accomplish, IMO.
We are, after all, trying to send binary print job data. What is a
few more binary bytes prepended to that binary stream?
sdb
| Sylvan Butler | sbutler@boi.hp.com | AreaCode 208 Phone/TelNet 396-2282 |