I have posted "issues961204.(doc, pdf, ps, and txt) " in the ftp server. I
have included the txt inline in this message.
Carl-Uno, as chair do you want to track any of these as work items? Do
you want a process where someone can "raise and issue" and have it
formally recorded somewhere or just via e-mail discussions?
Scott
Issues
1. What is our relationship to Internet Fax? What is their
final charter? What is our final charter? Are there any
other groups that we need to liaison with?
2. Randy suggested looking at draft-ietf-asid-string-filter-
v2-00.txt. Did any one review this and have comments
about IPP use of LDAP?
3. On 11/14/96, Roger posted htppnew.ps. Has this been
reviewed and incorporated?
4. Have we resolved the issue of "Extending HTTP vs. Use
Existing HTTP Methods*
Larry Masinter:
What would help is to have a specific proposal of how to
extend
># HTTP to have the following DPA/LDPA operations:
># SubmitJob
># CancelJob
># ListJobAttributes
># ModifyJob
># ResubmitJob
>
>This is similar to the discussion we're having in the
"Distributed
>Authoring and Versioning" group, which is trying to
build a profile
>for doing document management at web sites (e.g., such
as FrontPage,
>MKS Source Integrity, Documentum, etc. are doing). In
that group, as
>here, the issue is: New methods, or POST with new
content?
> You might want to look at the home page for that
working group:
>
> http://www.ics.uci.edu/~ejw/versioning/
>
>SubmitJob could easily be a POST which returns a job
attributes and a
>Location: header that is the Job URL. CancelJob could be
done with a
>DELETE of the Job URL, ListJobAttributes might be GET of
the Job URL,
>ModifyJob could be a PUT of the Job URL with a new set
of Job
>Attributes (or Post). I don't know what ResubmitJob
might be, but
>perhaps it's a POST too.
Henning commnets:
The MMUSIC group is currently considering extending HTTP
for conference
control (see my RTSP draft and a yet-to-be-published
conference
initiation draft). We'll discuss this with the HTTP WG
chair, but our
impression is that extending HTTP does not necessarily
imply changing
the base draft. The advantage is conciseness and the
immediate ability
to extend web servers to do the job. Your method is then
a "first-class
citizen", with appropriate access control, query about
existing methods,
etc..
5. Are there any data transfer issues associated with
running IPP over HTTP/1.0? Can the contents of a POST be
arbitrarily large (several documents of many Mb each)?
6. On 11/15/96, Roger posted ipp-http-stuff.doc has this
been reviewed or incorporated?
7. Have we resolved all of the Attribute Syntax issues?
8. Do we need to add a fan in picture back into the
document?
9. Some directory entry attributes are set by the Printer.
Some are set by the Administrator? Do we know which are
which? Do we care?
Notes from Kieth: The original set of Printer object
attributes were hardware-oriented i.e. a Printer
object that is really a physical printer could specify
these attributes. Per our phone call, there are now
attributes (i.e. "speed", "quality" or "cost" = "high",
"medium", "low") that an administrator - not a physical
printer - must specify i.e. It seems that an
administrator must determine how to assign "high",
"medium" or "low" to "speed", "quality" and "cost"
while a printer can only return its actual speed and
resolution upon which the administrator determines the
appropriate attribute value. "Location" can be
specified and stored in some - but not all - printers
so in some cases the "location" attribute must also be
specified by an administrator. I believe the "speed",
"quality", "cost" and "location" attributes help the
user more easily locate Printer objects. The point is
there are now attributes for a Printer object directory
entry some of which are defined by the hardware and
others by the administrator. A Printer object that is
really a printer would only add/modify the hardware
attributes for its directory entry and not add/update
the administrator attributes for its entry.
10.Where are we on the proposal to establish, through IANA,
of a well known port (380 recommended) for printing via
IPP over HTTP?
Dons Comments: Dedicating a port to printing on the
surface sounds good. But, not
being an expert on firewalls, I ask is that a problem?
My understanding
is that some firewalls keep things under control by not
allowing
certains ports to be used (i.e. nothing can be used
unless explicitly
permitted.) Is this going to be a problem in an inter-
enterprise
environment? Could someone with a better understanding
of
firewalls comment on this?
Harry's comments:
I would like to propose we attempt to standardize a well
known port for
printing via http. The notion would be that whatever we
define as printing
via http will work over http well known port 80 (along
with everything else
that flows via http), but, if directed to well known port
(say 380 - assuming
this port is not already defined), then only PRINTING,
not any other form of
http, would be expected.
This proposal closely follows the motivation described in
the internet draft
<draft-mellquist-web-sys-00.txt> submitted June 1996,
which recommends
well known port 280 for SNMP over HTTP. Read (3) of this
draft for a more
thorough dissertation on the merits of this approach.
As for text to add to the IPP draft (tonight), I suggest
a new head level
created between 2 (Distributed Printing) and 3 (IPP
Objects) called
2 (Printing via HTTP). Probably, a lot could be lifted
from Roger's document
and put into this section, I'm not going to try and flesh
this out here.
Also, in this section, however, we should put some words
like...
"It will be suggested (in section 5) that Clients
identify Printer objects
using an HTTP type URL. One element of this proposal
will be to further
recommend the establishment, through IANA, of a well
known port (380
recommended) for printing via HTTP. The purpose of this
well known port
would be to distinguish printing from non-printing
content. While any
acceptable HTTP content could be inter-mixed over HTTP
well known port 80,
only HTTP printing would be acceptable on port 380.
The remainder of this draft will define the IPP content
for HTTP printing,
including IPP objects, operations, naming and
attributes."
Carl-Uno comments:
I brought up this subject with Larry Masinter (who is the
IETF HTTP Chair)
when I met him last week. He claims that the HTTP does
not really care about
the port number and that hence it would be no point in
using a different
number fore the printing protocol. Can somebody else, who
is supplying Web
servers, verify this?
Jay comments:
For the sake of global sanity, IANA also registers ports
above 1023, as
I recall. So, it's probably best we eventually
coordinate through them
if we are dealing on the Internet.
11.We still have issues about Subjective values versu
Objective values, especially in the Directory Entry.
What is the set of values for each attribute?
12.On 11/19/96, Roger posted some sample flows. Is this
what is in the current I-D? Have we reviewed the
encoding of content within an HTTP operation?
Roger comments:
Two things that I noted in doing this:
My http proposal puts the document in a separate
"container" rather than
shipping it as an attribute as proposed in the current
attribute write-up. I
think this is preferable as it allows more structure of
the data on the wire.
This will make it easier to provide real document objects
later on and add
additional document attributes.
As part of the above, I carry the document format in the
document-content
header. This is more consistent with http, which puts
mime-like content
identifiers in all of its headers.
I noted that we have no attribute which describes the
length of the queue.
One of the main things that I look at when i personally
submit print jobs is
how busy the printer is. If a printer is very busy, I
find one hat is not so
backed up. What about an attribute called <jobs-in-
queue>?
Bob comments:
After thinking about the protocol issue some more, it
seems like there
are two ways to organize the IPP Job Object in HTTP
Protocol, the
current proposal or my proposal described below.
1) current proposal: The way proposed in the current
document where the
job and all document data is a part of a HTTP single
entity-body.
2) my proposal: A job is an HTTP document whose top level
content type
is multipart/mixed (an existing type) or perhaps
multipart/ipp (a new
type and probably a bad idea). In either case, the first
entity has a
content type of application/ippjob and contains the job
attributes.
Each remaining entity contains a document and they are
all standard
MIME types, such as application/PostScript or text/plain.
Such a
document could in the future become a
multipart/ippdocument with a
document attribute entity and a document content entity
if a document
has attribute overrides. The document data entity could
also have a
content-type of multipart/alternative (an existing type)
if a client
wanted to have several representations of a document,
e.g. HTTP and PDF
and a printer supported such.
The advantage of my proposal is that the document parts
are
conventional MIME documents which any software could
read. Only the
application/ippjob and application/ippdocument require
special software
to process.
Roger comment:
Bob, I am not familiar enough with the real operation of
HTTP protocols to know
whether your idea is a good one or not. I had thought
that I could only send
one enitity at a time, which would require leaving the
connection open and
turning the line around several times to complete
transfer of the message when
sending the document along with the print request. How
would this affect
performance? Obviously this is not a concern when pulling
the document later.
What are the advantages of allowing "any" software to
read the document data?
Since I only apply the headers when sending the document
to be printed I'm not
sure what I gain? In my proposal, the document content
itself still has a
standard Mime type
13. What are we using for Device Id?
Jay's comments:
This issue/concept falls right into the same kind of
discussion we
recently conducted in the PWG regarding printer model
identification,
particularly with regard to supporting print job
submission and job
formatting (ie, PPD-like file support, etc).
Our experience tells us that users want to be able to
view "real world"
identification information, such as Make, Model and Type
(although I'm
not quite sure what "Type" would imply depending on the
context).
The previous related discussion pointed out that an OID
must be provided
to unambiguously and succinctly define the specific
printer model; within
the Printer MIB context, this value is defined as the
hrDeviceID object
in the HR MIB. During the discussion someone questioned
whether this was
a workable solution, since the application would have to
have knowledge of
the OID mappings to determine the model type. Those of
us who develop
such application software explained that the OID approach
was indeed a
reasonable solution, citing the need for a clean, simple
syntax that has
both hierarchical potential and distributed
administration within the name
space. All of this is achieved via the standard SNMP SMI
concept of the
"Enterprises" tree.
If we use a P1284 Device ID for the IPP, will these same
naming features
exist? Can someone brief the PWG on the name space
administration of
the P1284 Device ID? For example, how would an app
developer know which
vendors have which products registered for which IDs?
14. What is the status of overlap with WEBDAV?
15. What is the current write up on printer-name vs. URL and
job-identifier vs URL?
16. What is the current security story?
17. Have we resolved all of the number-up, embellishments
issues?
18. Are we cleared up on the Job Retention time issues
(cancel, etc.)?
19. What is the status of the shortest-job-first vs smallest-
job-fisrt issue?
20. Do we agree with the proposal to have no attributes that
have no values?
21. Was there a proposal to change the name of IPP due to
other IPPs being found?
22. Questions from reviewers:
- I don't see any references to fan-fold paper anywhere.
- It appears there is currently no suppurt fo accounting.
One can
certainly argue that this is a function of security
which you say
will be addressed later.
- How do you plan to support color calibration and other
features like
what is provided through PPD files?
- I suspect that PostScript printing control (like
spooling, status
queries, etc.) are not supported as part of the
PostScript
Content-Type, right? It probably should be spelled out.
HTTP methods are case-sensitive (HTTP/1.1, Section
5.1.1); thus, your
example needs updating
- Wouldn't it make more sense to define a content-type:
application/ipp
(or similar), so that the request would be a valid HTTP
request? (The
print request is then part of the entity).
- Have you considered the alternative of defining a new
method, say,
PRINT, with entity headers appropriate for the new task?
23. On 11/25/96 Roger posted an attribute summary. Has this
been reviewed?
24. We need to clarify Job Templates. Who wants to write up
a new summary? With examples?
25. Has anyone reviewed draft-mellquist-web-sys-01.txt? Tom
suggests that there is some overlap with Managment and
IPP/2.0?