Subject: Re: IPP>PRO: sorry, binary is better (?)

From: "Sylvan Butler" <[email-masked]>
Date: Thu, 26 Jun 1997 10:49:51 -0700

>From:           Larry Masinter <[email-masked]>

>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 | [email-masked] | AreaCode 208 Phone/TelNet 396-2282 |

---

From: Larry Masinter <[email-masked]>
Date: Sat, 28 Jun 1997 23:40:46 PDT

> public, it is moved to the normal range.

a) it isn't a stretch, it's the real world. There is no
 single fixed point in time when 'the extension is formalized',
 extensions go through several stages of formalization, and
 there's no easy way to deploy code that can be replaced
 instantaneously even if it could.

b) MIME types originally had the theory that they could map to
   x- and then move, but in fact, it's never worked that way.
   Either people started out without the x- prefix, or else
   they wound up keeping it (application/x-url-encoded) because
   changing would be too painful or just not worth it.

   The latest MIME registration draft, instead, recommends
   registering 'vnd....' as soon as possible, but of course,
   you can use it before the registration's been accepted, etc.

> vendor to determine if it is there extension.

Yes, this is similar to the proposal just to use OIDs, and is
workable, but four bytes is not enough. (Witness the Macintosh
four byte file type & creator fields, which wind up with some
duplicates for file creators.)

> extension, and does not have to worry about such.

They may have originally been written that way, but that's not
how they work in practice or in the most recent revisions.

> few more binary bytes prepended to that binary stream?

If all you were doing was print job submission (which you're not)
and if all of the PDLs you were submitting were binary (which they're
not), then you'd have an argument.

Larry