Subject: Re: IPP> application/ipp vs. application/print-job

From: JK Martin <[email-masked]>
Date: Wed, 21 May 1997 19:06:07 -0400 (EDT)

Larry,

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:   [email-masked]          --
--  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 -----

>From [email-masked] Wed May 21 18:43 EDT 1997
Date: Wed, 21 May 1997 15:35:13 PDT
From: Larry Masinter <[email-masked]>
To: [email-masked]
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 -----

---

From: Larry Masinter <[email-masked]>
Date: Wed, 21 May 1997 17:21:01 PDT

> only one of its kind in the internet.

Some people say "the only good thing about standards is there
are so many of them to choose from". However, the outcome
of the IPP working group is supposed to be _the_ proposed
standard for printing in the Internet. If you just want
to do something without making it the standard, then you
don't need a standards group where you're forced to listen
to fools like me.

> Assuming that "print-job" is reasonable for other print-like
> mechanisms (such as fax) is not really clear, is it?

I would assume that "print-job" was a good name for
what it is that you're sending in submitting a job.
Maybe you want some more general way to marshall and
unmarshall an attribute value list, but then there
are lots of those, including application/directory
and multipart/form-data. Then you just need a schema
and a version of the scheme. Right?

Larry

---

From: Carl-Uno Manros <[email-masked]>
Date: Thu, 22 May 1997 09:42:55 PDT

Larry,

I think we are discussing past each other in this conversation.

One of the parameters for application/ipp is intended to be the actual
operation that you want the IPP server to execute. Only one (or possibly
two) of these are actually the "print-job" operation. The other operations
have to do with getting printer capabilities, finding out status of a job
etc.  So I think we are looking for for something more generic than
"application/print-job".

I see the "application/ipp" as a top level label for a number of related
operation requests and responses, each describing what the ISO and ITU
folks call a "Protocol Data Unit", which can be mapped to several different
underlying transfer protocols.

Any problems with that?

Carl-Uno

Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: [email-masked]

---

From: "Scott Lawrence" <[email-masked]>
Date: Thu, 22 May 1997 14:21:13 -0400

LM> I would assume that "print-job" was a good name for
LM> what it is that you're sending in submitting a job.

>>>>> "CM" == Carl-Uno Manros <[email-masked]> writes:

CM> One of the parameters for application/ipp is intended to be the actual
CM> operation that you want the IPP server to execute. [...] So I
CM> think we are looking for for something more generic than
CM> "application/print-job".

CM> I see the "application/ipp" as a top level label for a number of related
CM> operation requests and responses [...]

  I agree with Larrys original comment that 'application/ipp' is both
  redundant and not very descriptive.  From your response, I would
  agree that 'application/print-operation' would be much better.

--
Scott Lawrence           EmWeb Embedded Server       <[email-masked]>
Agranat Systems, Inc.        Engineering            http://www.agranat.com/