I see your point about the "purity" (or lack thereof) for using "ipp"
as the application name. Perhaps you're right, a better name should
be assigned for this encoding.
However, by the same token, assigning the name "print-job" is probably
too generic. It is unlikely that the IPP approach for printing over
HTTP (or any other quasi-MIME-encoded mechanism) will be (or is) the
only one of its kind in the internet.
Assuming that "print-job" is reasonable for other print-like mechanisms
(such as fax) is not really clear, is it?
Can we think of some other name that better serves to bind the implied
encoding with the specification defined by the IPP group? (Sorry, I
have no suggestions at this point.)
Regarding your comments on transaction indentifiers, sure, we can
always use a URI. We can actually use anything we want, so long as the
client can easily discern between assigned ID values. However, our
experience has shown that an integer value is far more useful within an
implementation, given the fact that the transaction ID is a processing
aid and not a UI component of some kind.
If we are going to have "transaction identifiers", then let's try to
keep them as simple as possible, and integers really work out the best.
...jay
----------------------------------------------------------------------
-- JK Martin | Email: jkm@underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------
----- Begin Included Message -----
Date: Wed, 21 May 1997 15:35:13 PDT
From: Larry Masinter <masinter@parc.xerox.com>
To: ipp@pwg.org
Subject: IPP> application/ipp vs. application/print-job
Content-Transfer-Encoding: 7bit
I'm dissatisfied with "application/ipp" as the name for the
Internet media type registration, because it's somewhat
redundant (i = internet in an internet protocol) and misdirected
(the content is not a 'protocol', it's a description of a
print job used in one protocol but useful possibly in others).
So I suggest renaming it: application/print-job. That is,
an 'application/print-job' is a description of a job that the
sender wants the recipient to print.
It might be possible to send one of these in an internet fax,
or in just regular email. You're designing it to work
in a particular kind of messaging (one in which the result
of the message is something that lets you query status and
modify the job later), but it's just a message.
As far as a 'transaction identifier' that Randy Turner was
proposing, I thought that the transaction was a resource, and
that you would identify it using a uniform resource identifier
(aka URI aka URL).
A 'raw IPP' shouldn't be so raw as to not allow interaction
with printer resources using ipp://host URLs instead of http://host
URLs, but for the most part, which protocol you were using
would just be determined by the name of the scheme.
Larry
-- http://www.parc.xerox.com/masinter
----- End Included Message -----