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

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

Larry Masinter (masinter@parc.xerox.com)
Sat, 28 Jun 1997 23:40:46 PDT

> 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.

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.

> 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.

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.)

> 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.

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

> >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

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