Subject: Re: IPP> ADM - Goals of the IPP Working Group

From: JK Martin <[email-masked]>
Date: Fri, 6 Jun 1997 21:56:07 -0400 (EDT)

I read your message three times, but still come away confused
about exactly what disturbs you regarding recent discussions.

Can you be a bit more explicit, please?

	...jay

----- Begin Included Message -----

>From [email-masked] Fri Jun  6 19:53 EDT 1997
Date: Fri, 6 Jun 1997 16:37:55 PDT
To: [email-masked]
From: Carl-Uno Manros <[email-masked]>
Subject: IPP> ADM - Goals of the IPP Working Group

All,

I know it is a long time back (6 - 8 months) since we discussed the scope
of the project, but I would encourage everybody who want to debate the SWP
vs. full IPP issue to go back and read what the charter for this group states.
It is referenced from the IPP web page, if you do not know where to find it.

In particular, I would like to call your attention to this piece of text
from our IETF charter:

"The goal of this working group is to develop requirements for Internet
Printing and to describe a model and semantics for Internet Printing. 

The further goal is to define a new application level Internet Printing
Protocol for the following core functions: 

- for a user to find out about a printer's capabilities 
- for a user to submit print jobs to a printer 
- for a user to find out the status of a printer or a print job 
- for a user to cancel a previously submitted job" 

This is what we promised to deliver at the beginning of the project, and
this what we have been working to provide so far. Some of the discussion on
the DL lately seem to question the scope of the whole project, which I find
very disturbing.

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]

----- End Included Message -----

---

From: Randy Turner <[email-masked]>
Date: Fri, 06 Jun 1997 23:14:03 -0700

I think Carl-Uno was talking about that some recent mail messages
have tended towards possibly scaling back IPP to be just SWP. And
since the original SWP document (not the latest doc from Paul
Moore) only met one of several requirements in the charter, that
discussing scaling back was potentially damaging and counter-
productive to the original intent of the working group. 

At this point, I don't think we have any business wasting 
precious (i.e., market-driven) time by stepping back to the
10000, 25000, 50000, or pick your favorite altitude and
looking at too abstract a big picture. I think what is
solidifying at the moment (meaning what we have agreed to
so far) with the set of documents we have is very close to
meeting the original requirements. And given that this
working group has only been chartered for 4 months, I think
the progress is very good (independent of what the trade rags
might have us believe). 

I suggest we go ahead with what we have decided on so far and
proceed from there. I think we're too close to start 
reconsidering major components of IPP that we have already
decided on. 

We should stay focused and finish the remainder of our work,
including but not limited to the following:

1. A recommendation for secure IPP transactions from the
   security sub-group in the form of an internet-draft. 

2. Finalize a language and encoding for IPP attributes using
   HTTP. We need to reach closure on this very quickly so we
   can start prototyping to make sure we have experimental
   verification that we've "done the right thing". 

3. A short internet draft (possibly informational) on 
   potential directory schemas for IPP services.

4. Cleaning up any model issues and possibly moving the
   attributes section of the model document into a separate
   draft, just to make the model document easier to "swallow".

The last few weeks on my schedule have been quite hectic, with
alot of document generation on top of my usual job. I would
have liked to have had more prototyping experience by now but I
appreciate Scott and his colleagues for publishing their
initial experience with encodings for attribute information.
This is just the kind of feedback and analysis we need to 
justify our decisions (and to possibly defend our decisions
before the IETF).

Randy

---

From: Carl-Uno Manros <[email-masked]>
Date: Mon, 9 Jun 1997 10:59:26 PDT

>Can you be a bit more explicit, please?
Jay,

I think that Randy has already given the answer, but here I go again to

>- for a user to cancel a previously submitted job" 

The above passage from the charter describes 4 sets of functions as "core
functionality" for IPP.
  
Let us examine these in relation to the SWP aka Level 1 functionality:

1) for a user to find out about a printer's capabilities

This is supplied by the Get Attributes operation. The Validate operation,
with a stretch of imagination, could be seen as delivering a subset, but
you would have to go through a number of trial-and-error attempts using
Validate in order to find out the total capabilities of a Printer.

2) for a user to submit print jobs to a printer

The simple Print-Job operation does deliver this, the combination of
Create-Job and Send-Document offers additional optional features.

3) for a user to find out the status of a printer or a print job 

This is supplied by the Get-Attributes and Get-Jobs operations.

4) for a user to cancel a previously submitted job

This is supplied by the Cancel-Job operation.

If Conformance Level 1 was to support only the Validate and the Print-Job
operations, it is obvious that we would not deliver all of the "core
functionality" required in the charter.  

Hence: 

First, we definately cannot limit the standard to only require the Validate
and Print-Job operations.

Secondly, I am sure that the IETF management would look unfavourably on a
solution that includes less than what is describes as "core" in the
charter. We can leave out some of the goodies, like multi-document jobs and
print-by-reference, from the
subset that MUST be supported by a conformant implementation, but I see
some definate problems with leaving out the Get-Attributes and Cancel-Job
operations.

Thirdly, the IETF is not likely to by happy over a printing standard that
has several conformance levels in general.

I may be playing the devil's advocate on this, but I think this is better
than for us to have a rude awakening later, when we try to get the
documents through the IETF standardization process.

Carl-Uno
Carl-Uno Manros