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 <<<