Subject: Re: IPP> ADM - Minutes from PWG IPP Phone Conference - 980114

From: Scott Isaacson <[email-masked]>
Date: Fri, 16 Jan 1998 13:17:05 -0700

I forgot that I was supposed to write up the Model and Semantics dicsussion
and post the results.  As Carl-Uno has pointed out, I already posted the
actual document and the changes can be read following the revision marks,
however to summarize on the DL:

1.  The "containing-printer-uri" name was changed to "job-printer-uri" 
There was a discussion about making it hard (always one value and only one
value) or soft (any one of the possibly many URIs for the Printer object
depending on the URI used in the query to get the attribute).  It was
decided to make it "hard".  

In other words:  It is popultated by the Printer object that creates the Job
and t is the URI of the printer object that created the job. If the Printer
object that creates the Job has more than one URI, it is the one URI that
was used by the client when issuing the create request.   The client always
uses the creating Printer URI along with the "job-id" when targeting a Job
object via the Job ID.  If the client (or any other client) queries the
Printer objec with a different URI, the "job-printer-uri" is still (hard not
soft) the URI that was used for creation, not the URI that is being used for
the query.  It is possible that some implementations might allow a client to
query the job using the Job ID and any one of the URIs for the Printer
object that created the Job, however the spec is silent on such a feature
(left up to the implementation).  

It was noted that the Job ID is only in the IPP model for existing system
API and model constraints, it is not an elegant part of the new IPP model. 
In those existing systems, there is really no concept of a  "soft" printer
associated with the Job.  The job was createad with a Printer in mind and it
always stays associated with that Printer, not some other more or less
secure access channel to that printer.

2. "orientation-requested" stays a J.T. attribute.  The model already notes
that any JT attribute may or may not be supported based on the context of
the document format.  Language was added to "orientation-requested" to make
very clear that it is "what is wanted" not "a description of what is" and
that it is expected the Printer objects support "orientation-requested" for
some document formats (text/plain) and not others (application/postscript).

As Carl-Uno stated, the -09 version just delivered to the IETF resolves ALL
issues and problems raised during the final call period and it is expected
that the -09 document will be the document sent to the IESG.

As soon as it is announced, are you, Carl-Uno, going to notify the IESG?  We
have 100% consensus that any of the latest mess about XML will have NO
impact on the model. 

Scott

>>> Carl-Uno Manros <[email-masked]> 01/16 11:59 AM >>>
Minutes from PWG IPP Phone Conference - 980114

Attending:

 Carl-Uno Manros
 Don Wright
 Scott Isaacson
 Bob Herriot
 Tom Hastings
 Paul Moore
 Peter Zehler
 Ron Bergman
 Keith Carter
 Swen Johnson
 Carl Kugler
 Steve Gebert
 Jim Walker
 Harry Lewis
 Randy Turner
 Ira Mcdonald
 Xavier Riley
 One more gentleman from Novell (who's name I couldn't read afterwards!)

The main agenda point was to discuss Paul Moore's suggestion to examine the
use of XML to carry the protocol information which is currently in the
application/ipp MIME type.

Paul explained that the Microsoft Web Architecture team wanted to examine
the potential use of XML in IPP in order to align our protocol solution
with other standardization projects such as WEBDAV, which have already
jumped onto the XML bandwagon. He offered to have a strawman proposal ready
for presentation at the PWG IPP meeting in Maui on January 28th. Paul would
show up for the meeting and also bring along a Microsoft Web/XML expert.

It was agreed that this was a reasonable way to proceed for now, but it was
also clear that the group had not yet bought into this approach.

A number of comments were offered:

Tom Hastings has written up a small document listing the requirements for a
new protocol mapping, which has been distrubuted to the DL. Paul Moore
promissed to make sure that that list was studied in writing up the new
proposal.

Bob Herriot said that he had already stated his own analysis to try to
determine if a mapping to XML was feasible. Some initial ideas have already
been sent to the DL. He had identified a couple of issues, the most
important one seems to be how we get the document data in - can they form
part of the XML structure or do they have to be in a separate file? Bob
will try to verify any XML issues that come up with Sun experts that are
active in the XML project.

Peter Zehler wanted to get better information about the extra footprint
that an XML parser would take up in a small printer, compared to our
current solution.

It was also pointed out that the W3C has not yet ratified XML as an
official Recommendation; voting closes on January 20th.

Scott Isaacson pointed out that the Microsoft idea about also introducing
new HTTP methods was a separate subject that should be discussed
independently from the XML discussion. It seemed to be little or no
interest in the group to go over that subject again, which has been
extensively discussed during last year.

Paul More undertook to not only provide the new draft solution, but also to
come up with some convincing rationale for why we should consider the
change.

It was also requested to set up a phone conference into the Maui meeting
for people who are unable to attend. Carl-Uno will organize that in
collaboration with Larry Stein who is making the conference arrangements
for Maui. The phone conference will be held on January 28th, 1 - 3 pm local
time (which is 3 - 5 pm PST and 6 - 8 pm EST), mark your calendars. So far,
20 people had signed up to be present in Maui on January 28th. I few more
might come due to this agenda change. Paul Moore will make sure that the
Microsoft input is available on the IPP DL on the day before the meeting.

On the IPP meeting agenda we will now reserve the time from 10:30 am to at
most 5 pm on the 28th for discussion of the prosed new protocol mapping,
which means that we will shorten the time previously planned to discuss
possible future extensions to IPP. Some, or all, of that discussion will be
moved to the following day, during which we will also discuss
interoperability testing. 

The rest of the phone conference was devoted to some detailed comments
about the Model & Semantics document. Scott Isaacson will document the
final results of those discussions in the latest draft, which has actually
already been distributed to the DL carrying the date January 16th. This
draft is NOT expected to change further.

Next week's phone conference will review any new information that has come
up on the DL in the meantime.
---

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: Carl-Uno Manros <[email-masked]>
Date: Fri, 16 Jan 1998 13:07:25 PST

---snip, snip ----

>have 100% consensus that any of the latest mess about XML will have NO

Scott,

As much as I would like to, I don't think it makes a lot of sense to send
the Model document to the IESG before we also have full agreement around
the Protocol document - after all the IETF is in the business of
standardizing protocols.

I am copying Harald and Keith Moore on this message to get their
clarification on that. BTW, please note that Harald has a new email
address, see above.

Carl-Uno
Carl-Uno Manros

---

From: Paul Moore <[email-masked]>
Date: Mon, 19 Jan 1998 09:38:07 -0800

we had come to the same conclusion

> -----Original Message-----
> From:	Larry Masinter [SMTP:[email-masked]]
> Sent:	Saturday, January 17, 1998 8:40 AM
> To:	Carl-Uno Manros
> Cc:	[email-masked]; Paul Moore; [email-masked]
> Subject:	Re: IPP> ADM - Minutes from PWG IPP Phone Conference -
> 980114
> 
> If you use XML for the protocol mapping and yet want to get
> file data in, you might consider a protocol mapping which separates
> the print data stream from the print protocol using MIME
> multipart, e.g., "multipart/related" where the print protocol
> elements are in an XML data structure, and the binary data streams
> are encoded appropriately just with their MIME media designations
> (application/postscript, etc.).
> 
> Larry
> -- 
> http://www.parc.xerox.com/masinter