Subject: IPP> Common concerns regarding the SWP proposal

From: Harry Lewis <[email-masked]>
Date: Fri, 6 Jun 1997 13:46:58 -0400

Jay - thank you for providing the framework that will enable us to FOCUS
discussion of SWP as it relates to the IPP goals. I am one, as you mentioned,
who encourages this, not because I want a "battle" to ensue, but because I
think a *short* concise list of issues will help us visualize, prioritize and
respond to the existing proposals.

>We need to resolve the issue of whether:
>
>  - The SWP proposal should represent THE final IPP specification, or
>
>  - The SWP proposal represents "Level 1" conformance to an IPP spec
>    having two conformance levels, or
>
>  - The SWP proposal is inadequate and should be abandoned in favor
>    of a single conformance level represented by the existing documents

This is a good way to represent the choices regarding SWP and IPP. I,
personally, recall Microsoft repeatedly saying they do not intend SWP
as the "end all" IPP protocol. Rather, my interpretation was that
Microsoft was putting some "meat" behind the revolving discussions in
IPP regarding use of HTTP, number of URLs, submission methods etc. so,
I would favor your middle choice or perhaps a slightly different
phrasing ... "Treat SWP as the Simple IPP Submission protocol and
document separate methods for query and cancel." Of course, this
implies that concerns such as multi-doc and print-by-reference have
been adequately resolved.

As so frequently occurs, "Simple" is a keyword in the Microsoft proposal,
so we should not expect it to solve every possible problem or scenario
we can imagine for internet printing. My impression, in SanDiego, was
that Microsoft appeared willing to address some of the concerns
(endian-ness, compatible proposals for multi-doc etc.) but, like anyone
who feels they have a sufficient architecture, were protective of the
fundamental design decisions which have allowed them to keep it Simple
and make it real.

Let's not forget that, in SanDiego, Microsoft presented SWP as an initial,
*timely* step toward print job submission via the interent, *not* as
the total solution to a complete, robust IPP protocol.

>The concerns I have heard from multiple IPP participants include the
>following (in no particular order):
>
>  1. Does not support multiple documents
>
>  2. Does not support Print-by-Reference
>
>  3. Does not support job status queries
>
>  4. Does not support job cancellation by the requesting user
>
>  5. Uses binary-encoded data for simple information normally encoded
>     in text for HTTP-related transactions

If this list *does* represent the entire scope of *key* issues, then,
at least, we know our points of interest, and IPP can decide whether to
build the roadmap starting with SWP or take a separate route.

Thanks, again, Jay, for setting this "Common Concerns" thread in motion.

>>> Harry Lewis <<<

---

From: Tom Hastings <[email-masked]>
Date: Fri, 6 Jun 1997 11:25:13 PDT

Jay,

Thanks for raising the issues about SWP.  Here are my comments.

Tom

At 17:47 06/05/97 PDT, JK Martin wrote:
>After many private phone calls and email messages with several IPP
>participants--including a 1.5 hour phone call with Evan Schuman
>regarding his "Internet Printing Deal Unravels" article--it was
>suggested that I be the sacrificial lamb and ask the $64K question:
>
>   "So what's wrong with the SWP proposal from Microsoft and HP?"
>

No problem with not having any of the above in the lowest level (or in SWP).
You don't get any of the above with current Windows printing and it hasn't
cause customers to not use Windows.  As Babak and Keith said, SWP is
only the first step which takes the current Windows printing paradigm
and puts it on the Internet.

>     in text for HTTP-related transactions

This decision is perhaps not the best, but its not a show stopper.
Lets not use it as a "wedge" issue to abandon the agreements in San Diego.

>
>There may be more concerns floating around, but these appear to be the
>Top 5 that consistently arise in conversations.
>
>The purpose of this message is to get these concerns out on the table
>NOW so that we can resolve them as quickly as possible.  (Please don't
>flame at me for this message...wait until I state my opinions... ;-)
>
>There has been considerable traffic on the list regarding the concern
>for the lack of Print-by-Reference.  Let's get discussion started on
>the other concerns.
>
>Incidentally, more than one participant made a statement to this effect:
>
>  "If two conformance levels are specified--yet Microsoft only implements
>   the low-end Level 1 spec--then it is pointless for us to work on a
>   Level 2 implementation given current and past market dynamics.
>
>   "Therefore, we should stop further IPP development and simply bless
>    the SWP proposal and run with it, since it will be the only pervasive
>    implementation in the marketplace, anyway."

Maybe I'm naive, but I think that Microsoft will support full IPP in their
follow on release.  Its just a matter of timing.  Had we had IPP all done
and the NT 5.0 development group had the resources, they would have put
full IPP into NT 5.0.  Basically, the NT strategy is to keep adding 
functionality.  Why do you think that Microsoft would stop with SWP?

Any system that can't cancel a job is not going to be viable in the market
place very long.  So Microsoft will be forced into doing more in the
future by their customer base (and IPP).

I look at SWP as being half full, not half empty.  SWP makes IPP more real,
rather than detracting from IPP.

Carl-Uno made the suggestion that maybe SWP could be a separate informational
RFC (from Microsoft or from the PWG, TBD), which is a subset of IPP.
Then IPP could avoid having two conformance levels, if we cannot agree
to have two conformance levels.

>
>Your comments to this statement are also encouraged, whether pro or con.
>
>	...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   --
>----------------------------------------------------------------------
>
>

---

From: Scott Isaacson <[email-masked]>
Date: Fri, 06 Jun 1997 13:43:05 -0600

Good summary Jay..

************************************************************
Scott A. Isaacson
Print Services Consulting Engineer
Novell Inc., 122 E 1700 S, Provo, UT 84606
V: (801) 861-7366, (800) 453-1267 x17366
F: (801) 861-4025, E: [email-masked]
W: http://www.novell.com
************************************************************

>>> JK Martin <[email-masked]> 06/05 6:47 PM >>>

>  1. Does not support multiple documents

No mandatory support for all implementations.  Add a simple attribute to the
printer that is a boolean "multiple-documents-supported" = True or False. 
If False, expect an error code back on Create-Job or Send-Document.  Maybe
even put this in the directroy schema.  Do end users want to find printers
that can print multiple documents per job?  I don't know.

>   2. Does not support Print-by-Reference

Add s simple attribute to the printer that says
"print-by-reference-supported" = True or False.  If False, don't expect a
URL as document content to work.  If True, what gets printed is what gets
printed no guarantee and if you send
in an FTP URL and the given instance of a Printer does not support it, you
get
an error message.  

>  3. Does not support job status queries
Has always sounded to me like a basic query to a Printer or a Job is
essential.  I believe this is fundamental.   Sure, you could always do a GET
on a url with an
accept header of text/html and get back a browser view, but this need not be
a requirement.  SWP does not mandate that this be a requirement.  However, a
requirement would be to support an POST with an application/ipp  PDU in 
it.  The number of MANDATORY requirements is SO small here, I don't see a
problem with supporting the operation for all implemntations given that you
have a web server already (doing the GET accepting text/html that is).

>  4. Does not support job cancellation by the requesting user
Seems fundamental to me.  If you support an HTML form version of this, it
would be like litterally 10 lines of code to add the POST application/IPP
version.

>     in text for HTTP-related transactions

In our prototype, we just finished up a Java application that tried to
process
attributes encoded as:

<lenght>name<length>value         (case 2)

rather than as

name ":" value CRLF        (case 1)

We ran both versions on 3 attributes, 30 attributes, and 300 attributes.
The goal was to measure the actuall difference in processing time for a
dumb, interpreted java application to do one or the other.   The times seem
slow (we just did a quick an dirty hack with no optimizations, kept the
buffering I/O the same, just modified the algorithm)

Encoding 
30 attributes (varying name lengths, varying value lenghts), 50 runs, avg.

Case 1:   .1375 seconds
Case 2:   .1525 seconds

Decoding 
30 attributes (varying name lengths, varying value lenghts), 50 runs, avg.

Case 1:  .0975 seconds
Case 2:  .0825 seconds

Sure enough, case 2 was "quicker" but as been said many times before:
"This is printing we are talking about, and at MOST 30 attributes we are
talking about"  Ease of use and extensibility and portability etc are so
much easier with a non-binary encoding of lengths.  It just doesn't buy you
very much.

Interesting node, encoding actually took longer with case 2?  You actually
have to compute the length in order to encode the length!  Looking
at both sides (encoder/decoder), it seems to come out a wash with
binary encoding or not.

The point in posting this data is not to get into a war about "we'll I could
do it
faster ..."  but just to look at the RELATIVELY MINOR overhead of 30
attributes
compared to a 4 meg color RIP process!!!

Please, let's not have two conformance levels.  Let's NOT force everyone
to do do everything, but let's not fragement the standard.   We have
all failed if we do.

Scott Isaacson

---

From: Brian Grimshaw <[email-masked]>
Date: Fri, 6 Jun 97 14:30:31 -0700

I believe the features (intentionally) missing in SWP are essential to 
IPP if it is to become widely adopted.

Scott did an excellent job explaining how simple it is to address the 
concerns that have been voiced over these features.  I encourage the IPP 
WG to work out the final details and keep IPP on track as a robust and 
single conformance level protocol.

Brian

> Add a simple attribute to the printer that is a boolean
> "multiple-documents-supported" = True or False.
...
> "print-by-reference-supported" = True or False.
...
> essential.  I believe this is fundamental.
...
> Seems fundamental to me.
...
> to do do everything, but let's not fragement the standard.   We have

Brian Grimshaw
Apple Computer, Inc.
[email-masked]

---

From: JK Martin <[email-masked]>
Date: Fri, 6 Jun 1997 22:28:44 -0400 (EDT)

Tom,

> and puts it on the Internet.

This is fine for Windows.  (I guess.)  But what about other environments?
(I can just hear Don Wright's all-too-frequent exclamation now...
     "Unix is a niche market, so don't bother with it!")

IPP is not just for Windows.  However some folks seem to contend that
Windows is the only environment worth satisfying in the IPP effort.

By the way, are you saying that a Windows user has no way to observe
the current status of his/her submitted job?  Nor that the user is able
to cancel a previously submitted job?  I find this a bit hard to believe.

> Lets not use it as a "wedge" issue to abandon the agreements in San Diego.

And let's not say these kinds to put the wrong spin on stated concerns.

There are those in the IPP group who believe the group did not have
sufficient time to fully evaluate SWP in San Diego, given the document
was not published until a couple of days before the meeting.

It's should come as no surprise, then, that once we started comparing
the SWP proposal against the IPP charter, it fell quite a bit short.

> functionality.  Why do you think that Microsoft would stop with SWP?

Ummm... Because they don't want to expose anymore of their printing
system for external augmentation by other vendors?  (Sorry, but was
that a trick question?)

If Microsoft and HP had taken the time to discuss their ideas and
objections on the IPP list all along, we--and they--would have had more
time to develop a singular conformance level to the betterment of all.

Why didn't Microsoft and HP participate in the open forum for this
standards effort, anyway?  In most working groups, the people who
make a particular proposal are usually the ones to defend it, yet
we have heard nothing from either the Microsoft nor HP camp.

> future by their customer base (and IPP).

Hmmm...  I thought you said Windows users can't cancel print jobs today?

> rather than detracting from IPP.

SWP makes IPP more real???  (Sorry, a rhetorical question, at best)

> to have two conformance levels.

Anyone can publish an I-D at anytime (with some constraints now, I guess).

But calling SWP an "I-D" so as to avoid a two-level conformance situation
is just a thinly disguised veneer of a second conformance level, IMHO.

	...jay

---

From: [email-masked] (Bill Wagner)
Date: Mon, 9 Jun 1997 13:15:13 -0400

Carl-Unos and Scott appear to suggest the that IPP standard should 
     include all the features the group feels are desirable; and that 
     specific implementations may have "null" implementations of these 
     features. Aside from the time necessary to properly define this 
     complete set of features, and the time necessary to get approval, the 
     following message on the IETF-FAX list (in response to perhaps a 
     similar situation in internet fax) points out a potential problem to 
     this approach which sould be addressed. It might be appropriate for 
     the IPP's IETF guides to comment on this.
     
     Bill Wagner, Osicom/DPI

______________________________ Forward Header _____________________________
Subject: Re: JWK and Wordcraft support for legacy fax machines - UniB
Author:  Ned Freed <[email-masked]> at Internet
Date:    6/9/97 9:13 AM

>Confusion of standards and implementations again. Standards define the set
>of functions, implementations may opt for a sub-set.The key is to define a
>full set to start with and then let people do their own thing in terms of
>the sub-set they select.

I agree that this is how the ISO and ITU standards process works.It is not,
however, how the IETF standards process works. IETF standards attempt to
standardize the minimum amount of stuff needed to get the job done and no 
more.
And if subsequent implementation experience shows that some features end up
being unimplemented and hence don't interoperate they will be removed from 
the standard as it proceeds down the standards path.

At the heart of all this is the IETF requirement that each feature of a
standard has to be shown to

(1) interoperate between multiple implementations and
(2) not have any known interoperability problems 

before the standard can advance in grade.

Fine,you say,but why does this rule preclude me from writing a standard 
with
lots of stuff in it and then trimming the stuff that sees insufficient
implementation later on? The answer is that while the process may formally
allow this, the long-time participants in the process have a strong bias
against it, and you will have the devil's own job getting rough consensus 
on
documents that are written this way. The "rough consensus and running code"
line often sounds silly to people who hail from the ISO or ITU communities 
(I used to be such a person, BTW) but here these are words to live by.

When MIME was first designed there were no less than three separate
implementations of every feature in the standard (one by me, one by 
Marshall Rose, and one by Nathaniel Borenstein) that were done as the 
standard was being written and were kept up to date as the standard 
changed. And even though we effectively met the implementation requirements 
for a move to full standard status before RFC1341 even came out, we've 
still have to trim any number of features out of MIME, and I suspect that 
several more will have to go before we
are allowed to move it to full standard.

                                Ned

______________________________ Reply Separator _________________________________
Subject: Re: IPP> Common concerns regarding the SWP proposal
Author:  Scott Isaacson <[email-masked]> at Internet
Date:    6/6/97 1:43 PM

Good summary Jay..

rather than as

Encoding 

Case 1:   .1375 seconds
Case 2:   .1525 seconds

Decoding 

Case 1:  .0975 seconds
Case 2:  .0825 seconds

Scott Isaacson

---

From: Roger K Debry <[email-masked]>
Date: Mon, 9 Jun 1997 16:10:12 -0400

Isn't this what our Mandatory and conditionally mandatory attributes are all
about?

Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: [email-masked]
phone: 1-303-924-4080

---------------------- Forwarded by Roger K Debry/Boulder/IBM on 06/09/97 02:04
PM ---------------------------

        ipp-owner @ pwg.org
        06/09/97 11:19 AM
Please respond to [email-masked] @ internet

To: ipp @ pwg.org @ internet
cc:
Subject: Re[2]: IPP> Common concerns regarding the SWP proposal

     Bill Wagner, Osicom/DPI

                                Ned

Good summary Jay..

rather than as

Encoding

Case 1:   .1375 seconds
Case 2:   .1525 seconds

Decoding

Case 1:  .0975 seconds
Case 2:  .0825 seconds

Scott Isaacson