Subject: IPP> Consensus on sending our drafts to the IESG

From: [email-masked]
Date: Fri, 30 Jan 1998 11:58:27 -0500

I reaffirm my position that we send the existing documents to
the IESG as is for last call.  The XML proposal while technically
interesting does not provide additional functionality.  Because
the current state of XML does not provide all the structured
data types we need adoption could therefore lead to a divergence
between an IPP XML implementation and the main XML efforts.

**********************************************
* Don Wright                 [email-masked] *
* Product Manager, Strategic Alliances       *
* Lexmark International                      *
* 740 New Circle Rd                          *
* Lexington, Ky 40550                        *
* 606-232-4808 (phone) 606-232-6740 (fax)    *
**********************************************
---------------------- Forwarded by Don Wright on 01/30/98 11:55 AM
---------------------------

From: [email-masked] on 01/29/98 06:40 PM
      PST

To:   [email-masked]
cc:    (bcc: Don Wright)
bcc:  Don Wright
Subject:  IPP> Consensus on sending our drafts to the IESG

The PWG has just held a meeting on IPP. In that meeting which also had a
phone conference, which together covered most of the active IPP
participants, the subject of Paul Moore's and Josh Cohen's proposal to
evaluate new alternatives for the protocol specification was discussed.
Although the proposal found some support and to have some technical merit,
it was clear that a considerable majority were not convinced that the
solutions proposed would offer a better alternative to our current solution
and preferred to go ahead with our current drafts without further delays.
I therefore believe that we have enough consensus to proceed with our
earlier plans to send the IPP Model & Semantics and the Protocol
Specification drafts to the IESG with the recommendation as Proposed
Standards, and our remaining three drafts as Informational RFCs.
I wish to see your reconfirmation of this consensus expressed on the IPP
DL.
I plan to send the drafts to the IESG next Friday on February 6th, 1998.
Regards,
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: [email-masked]
Date: Fri, 30 Jan 1998 14:37:26 -0500

After reviewing the XML proposal and reading the e-mail
discussion, my belief is that the best route for the IPP
working group is to submit the current internet drafts
to the IESG for consideration as Proposed Standard.
Lloyd

------------------------------------------------------------
Lloyd Young                       Lexmark International, Inc.
Senior Program Manager            Dept. C14L/Bldg. 035-3
Strategic Alliances               740 New Circle Road NW
internet: [email-masked]     Lexington, KY 40550
Phone: (606) 232-5150             Fax: (606) 232-6740

---

From: [email-masked] (Robert McComiskie)
Date: Fri, 30 Jan 1998 16:10:57 -0500

Please submit the drafts to the IESG. The world is waiting.
     
     Bob.
     
*********************************************************************
** Bob McComiskie                              Voice: 781-229-7021 **
** Product Line Manager                          Fax: 781-229-7119 **
** Xionics Document Technologies, Inc                              **
** 70 Blanchard Road                       [email-masked] **
** Burlington, MA 01803 USA                http://www.xionics.com  **
*********************************************************************

---

From: [email-masked]
Date: Mon, 2 Feb 1998 09:55:19 +0100

As requested, I reafirm my decision, as expressed during the meeting in
Maui, to send the IPP Model & Semantics and the Protocol Specification
drafts to the IESG with the recommendation as Proposed Standards and the
remaining three drafts as Informational RFCs without further delay.

Henrik Holst

______________________________________________
Henrik Holst	       i-data International
[email-masked]	www.i-data.com

---

From: "Zehler, Peter " <[email-masked]>
Date: Mon, 2 Feb 1998 10:37:56 PST

All,
I reaffirm my position that we send the existing documents to the IESG
last call.  
The XML overview by Microsoft, while technically interesting, was not
compelling enough to cause me to abandon a specification that satisfies
the IPP requirements.  I urge Microsoft to come back with a detailed
proposal equal to the level of the existing protocol document.  The
current document is  26 pages.  Eleven of those pages layout the
protocol mapping.   The XML protocol mapping document will clarify the
magnitude of the change that is being requested.  I am also concerned
with the lack of structured data types in XML that are required by IPP.
I am not convinced that the time for XML is at hand.

Pete

Email: [email-masked]
US Mail: Peter Zehler
	Xerox Corp.
	800 Phillips Rd.
	M/S 111-02J
	Webster NY, 14580-9701
Voice:   (716) 265-8755
FAX:     (716)265-8792

---

From: Bob Pentecost <[email-masked]>
Date: Wed, 4 Feb 1998 15:18:01 -0700

As stated in the IPP meeting, I am in favor of delaying the submittal of the 
IPP documents to the IESG for the purpose of further investigation of the XML 
alternative.

Bob Pentecost
HP

---

From: [email-masked]
Date: Wed, 4 Feb 1998 20:18:19 -0800 (PST)

I agree with Scott.  Please forward the draft.

Patrick Powell                 Astart Technologies,
[email-masked]            9475 Chesapeake Drive, Suite D,
Network and System             San Diego, CA 92123
  Consulting                   619-874-6543 FAX 619-279-8424 
LPRng - Print Spooler (http://www.astart.com)

> I believe that we have strong consensus.  Period.  
>
> I have been involved in this WG since late 1996.  I am the editor
> and principal author of the Model and Semantics document.  I have
> contributed to all of the other IPP I-Ds.  I have seen proprosals
> raised, debated, modified, reworked, reviewed, analyzed, and finally
> embraced.  I have seen a lot of give and take.   I have seen WG
> meetings at the IETF where IETF attendees outside the WG have come
> and participated and provided feedback and opinion.  I have seen
> the process work.  In this latest case of "vehement opposition" I
> have not seen a lot of cooperation and give and take.
>
>
> Scott Isaacson
> ************************************************************
> Scott A. Isaacson
> Corporate Architect
> Novell Inc., M/S PRV-C-121 
> 122 E 1700 S, Provo, UT 84606
> voice: (801) 861-7366, (800) 453-1267 x17366
> fax: (801) 861-2517
> email: [email-masked]
> web: http://www.novell.com
> ************************************************************

---

From: Rick Yardumian <[email-masked]>
Date: Thu, 5 Feb 1998 13:45:12 PST

I vote to send the IPP Model & Semantics and the Protocol 
Specification drafts to the IESG without further delay.

I'm involved in an IPP prototyping effort and based on the results I feel the current specification is a usable solution.
______________________________________________________________________
Rick Yardumian
Xerox Corporation				Voice: (310) 333-8303 / 8*823-8303
Corporate Research & Technology	Fax: (310) 333-6342 / 8*823-6342
701 S. Aviation Blvd, ESAE-242	Email: [email-masked]
El Segundo, CA 90245
______________________________________________________________________

---

From: Tom Hastings <[email-masked]>
Date: Thu, 5 Feb 1998 16:09:09 PST

After having heard and been involved in the discussions on using XML, 
instead of our binary encoding, I'm convinced that we should forward the IPP
Model and Protocol documents as they are.

I was willing to consider XML, but the following persuades me that
we would be ill-advised at this time:

1. XML 1.0 was designed for representing documents, not attributes.
While there are some in the W3C XML group that want to extend XML
for representing attributes, subsetting the parts of XML not needed and
adding data types, it is not clear whether they will prevail on the
part of the W3C XML group that considers XML fine as it is for representing 
documents.

2. If the IPP WG were to use XML 1.0 now, we would make decisions about
using XML for representing attributes that would likely be different
than the XML group will do, if they do at all.  For example, the
representation of dates, ranges, multi-valued attributes, data types,
data type names, etc.  (I had hoped that a draft of IPP in XML would
have been forth coming during our review that just used basic XML, but 
that doesn't seem possible, now that we understand the current capabilities
of XML a little better).

3. If the IPP WG were to wait for the W3C XML to support attributes
in an approved XML version, IPP would be delayed at least six to nine 
months, if not longer.  The prototyping work of the last year 
would need to be largely repeated.  Printer, network, and OS vendors would 
likely deploy their own proprietary versions in the meantime, making IPP
largely irrelevant.

4. One of the concerns that the IESG has had about IPP using HTTP is that
HTTP has lots of other requirements that pull it in directions that might
not suit IPP.  The same is likely to be true for XML (e.g., representing
documents vs. representing attributes).

5. The prototyping work that we have done during the past year shows that
the current protocol is workable.  

6. IPP has had a lot of significant involvement and contributions from
printer vendors, NOS vendors, and OS vendors.  This is a historic
achievement!  I have never seen a standard in this area in which all the 
major players have been involved.  Lets not lose this "window of opportunity"
in the name of waiting for something better.  When that comes, if ever,
there will be something coming down the pike after it, that is even better.  
That is the nature of our business.  Lets ship what we have now, since
we have shown that it meets our requirements and has been designed to
be extensible to meet our future requirements.

Tom Hastings

---

From: "Wagner, William" <[email-masked]>
Date: Fri, 6 Feb 1998 17:12:45 -0500

The questions voiced by Jim Walker, and Jay's addition are most
disheartening. It is not because these are new concerns but because
these things have been gone over and over during the course of this
working group's life. Yes, to some people compromise is a dirty word;
and the current specification represents very much compromise on
everyone's part. In the last analysis however, the deciding factor
should not be whether one or another favorite approach is used, but:
does what is specified work? does it do what it was intended to do? is
it producable and deployable?

Jay's very practical concern about  can a printing specification not
implemented by Microsoft and HP ever succeed must be considered.
Microsoft and HP have a history of pushing through their "alternate"
solutions just as a specification nears completion. I would have thought
that their extensive participation and the previous round of compromises
intended to incorporate the ideas of these two giants would have may
unnecessary this "end-play". Apparently, it has not.

The group can continue, and can put into effect a working protocol for
inter/intra net printing. It can do this with or without IESG sanction
and with or without Microsoft/HP participation. The question of whether
this is a viable action is one for marketeers, not engineers.

W. A. Wagner (Bill Wagner)
OSICOM/DPI

> -----Original Message-----
> From:	Jay Martin [SMTP:[email-masked]]
> Sent:	Friday, February 06, 1998 2:53 PM
> To:	[email-masked]
> Cc:	[email-masked]
> Subject:	Re: IPP> Consensus on sending our drafts to the IESG
> 
> I would like to go on record as sharing many (if not most) of
> the views and comments Jim Walker has posted.
> 
> Given the current "culture" that has seemingly developed within
> the IPP group, Jim should be commended on being so brave as to
> suggest some of the views that some may describe as "nay-saying".
> 
> I must admit that I am a member of the group Jim refers to in:
> 
> >         "We know that this draft will get rejected anyways, so
> >         why don't we send it in, collect all of the comments at
> >         one time, and in the meantime we can think some more
> >         about XML".
> 
> While I had strongly proposed that the current drafts be submitted
> as-is for IETF review, the fact is, I really don't like the
> IPP protocol as it is currently defined.  (Wow, I said it.
> Now I feel better... ;-)
> 
> One final note: whether IPP (as currently defined) is better or
> worse than XML is really a useless discussion, IMHO.
> 
> Without Microsoft's aggressive support, any *pervasive* deployment
> of an Internet-like printing protocol will likely fail within the
> general domain.  If Microsoft balks at IPP v1.0 (and they surely
> have made this comment, repeatedly!), then does anyone actually
> believe they will deploy it?
> 
> I have longed for the day in which the Printer Industry as a whole
> would stand up, band together, and produce something in concert
> with the sum of the industry's players.  But, after waiting some
> five years for this act to occur, I now find that this belief is
> but a pipe dream.
> 
> Let's face it.  As long as the printer industry continues to gate
> itself on the progress and initiative of Microsoft and HP, then
> true innovation deployed on a global scale--in which the efforts
> are conducted on an honestly "level playing field"--is likely
> to NEVER happen, at least not in our lifetime.  (Of course, the
> Department of Justice could change all of that... ;-)
> 
> I would like to publicly challenge Microsoft to put forth an
> "Internet printing" proposal in which it can demonstrate true
> openness for allowing the printer industry to participate in
> it's development and deployment.
> 
> I, for one, have no problem in working within an environment
> that has a "benevolent dictator".  After all, my company exists
> to make products and profit from that effort.  Having a single
> "Master" of a given effort is fine...so long as the Master is
> open and honest with its "serfs".
> 
> Thanks for letting me get this off my chest.
> 
> 	...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   --
> ----------------------------------------------------------------------
> 
> 
> James Walker wrote:
> > 
> > Roger K Debry wrote:
> > >
> > > Not having been in Maui, I'd be interested in what
> > > you believe the "many other" issues are.
> > 
> > Sorry about the delay in the response...
> > 
> > There were several other issues that were discussed, some of which
> > I thought came up during the phone conference (alas, we all know
> > how well that technology worked :-).
> > 
> > At any rate here are some that I remember (not meant to be an
> > exhaustive list)...
> > 
> > o   Using a new HTTP method rather than overloading POST.
> >         Nuff said.
> > 
> > o   Concern over using HTTP at all... there was a rumor going
> >         around that the IESG was poised to reject the current
> >         IPP drafts because HTTP was being used as the protocol.
> >         In fact, part of the discussion was along the lines of
> >         "We know that this draft will get rejected anyways, so
> >         why don't we send it in, collect all of the comments at
> >         one time, and in the meantime we can think some more
> >         about XML".
> > 
> >         There also seemed to be some underriding current of
> >         uneasiness from some of the group regarding HTTP.
> >         This is just a subjective opinion of mine, but there
> >         were comments made like "now, if we had just used a
> >         simple socket-level protocol..."
> > 
> > o   IPP as an embedded printer protocol versus a print server
> >         protocol.  There was a lot of discussion about whether
> >         we are trying to accomplish too much by having one
> >         protocol for both the embedded printer and the print
> >         server.  For example, there is a natural tension between
> >         the space requirements that the embedded printer crowd
> >         (rightfully) defends, and the "elegance" and
> >         "extensibility" arguments that the print server crowd
> >         espouses.  I think that the XML discussion, as well as
> >         the original text versus binary protocol discussion from
> >         over a year ago, are valid examples of this tension.
> > 
> > o   IPP versus SNMP.  Along the same lines of some of the issues
> >         above were discussions about overlap between IPP and SNMP.
> >         There was at least one suggestion that IPP should perhaps
> >         just be a job submission (and cancellation?) protocol,
> >         and use the existing Printer and Job Monitoring MIBs for
> >         determining printer and job status.
> > 
> >         I was also concerned about comments from at least one
> >         representative from a large printer vendor that indicated
> >         very little interest in IPP as a whole.  "If we already
> >         have a way to get jobs in the printer (using, say, a
> >         simple bi-directional TCP connection) and a way to monitor
> >         those jobs, as well as the printer (SNMP), what good does
> >         IPP do for us?"
> > 
> > These are just some random recollections.  I do not mean to be
> > a gloom-and-doom'er, but I did want to document some of the
> > observations that I made from my seat.
> > 
> > ...walker
> > 
> > --
> > Jim Walker <[email-masked]>
> > System Architect/DAZEL Wizard
> > DAZEL Corporation, Austin, TX

---

From: Paul Moore <[email-masked]>
Date: Fri, 6 Feb 1998 18:25:54 -0800

MS & HP will state to the IESG our concerns with the current design (just as
anybody in the Internet comunity can).

Having said that - we will implement what the IESG ratifies. It is our aim
to have maximum interoperability, not to divide the world into different
camps - that would be a war we can all do without.

Our intent is purely to do the right thing both for the short term and the
long term. We saw IPP as an opportunity for printing to 'do it right' from
day 1 as opposed to always having to compromise on other solutions (SNMP,
LPR/LPD, ...). Our view is that spending a little more time on it would
provide a more flexible, future-proof solution. This argument did not win
the day - instead we did a 'hey its good enough, lets ship it' - so be it
(although, as I stated before, we will raise our objection to the IESG
level).

> From:	Wagner, William [SMTP:[email-masked]]
> Sent:	Friday, February 06, 1998 2:13 PM
> To:	[email-masked]
> Subject:	RE: IPP> Consensus on sending our drafts to the IESG
>

---

From: Paul Moore <[email-masked]>
Date: Sun, 8 Feb 1998 12:48:42 -0800

The problem is that nobody wants to do the other thing!

I saw two problems with two , potentially different, soultions (hence my
double vote). I rolled with what I saw as the simple solution (HTTP -
interesting that you percieve them the opposite way round) and proposed
something called SIMPLE web printing based on what we were building - that
just did job submission. That eventually evolved into what we have today.

Now we move on to address the issues that were lurking in the background -
printer discovery, feature dicsovery , configuration discovery, managment,
notification, flow control, peer queuing,.... (things for s/w to printer
interface) and billing, quotas, access control, server managemnt, job
redirection, ... (things for client to print subsystem interface). 

The WG is DETERMINED that this will be done by one protocol - I have
expressed (with you and others) my opionion that this is not acheiveable
(its desirability is understandable) many times. We are not listened to and
I do not wish to continue to bash my forehead against that wall forever. So
I have changed tactics and am now thinking 'how can I make IPP into all the
things I need?'. Hence the current apparent change of stance, XML
suggestions, questions about notification, etc.

I just want to get down and build good stuff for users  - I am trying to
find the path of least resistance.

> Sent:	Saturday, February 07, 1998 10:16 AM
> To:	Paul Moore
> Cc:	[email-masked]
> Paul,
> > MS & HP will state to the IESG our concerns with the current
> > design (just as anybody in the Internet comunity can).
> 
> And rightly so.  We all look forward to seeing your concerns posted
> to the IESG, where a larger domain of reviewers may be able to shed
> additional light on this situation.
> 
> 
> > Having said that - we will implement what the IESG
> > ratifies. It is our aim to have maximum interoperability,
> > not to divide the world into different camps - that would
> > be a war we can all do without.
> 
> This is certainly good news.  We all needed to hear these "official"
> words from Microsoft.  Whether the protocol/model is good or bad is
> not nearly as important as solidarity, given the critical mass
> nature of our efforts.
> 
> Are you able to speak on behalf of HP, or should a similar statement
> be made from an HP representative?
> 
> 
> > Our intent is purely to do the right thing both for the
> > short term and the long term. We saw IPP as an opportunity
> > for printing to 'do it right' from day 1 as opposed to
> > always having to compromise on other solutions (SNMP,
> > LPR/LPD, ...).
> 
> Now this paragraph is totally confusing to me, Paul.  I vividly
> recall back at the May '97 IPP meeting (San Diego) the group
> explicitly discussed the notion of "something quick vs. something
> long term" in terms of whether to go "Web/HTTP" vs. a "simple,
> socket-based approach".
> 
> Recall that meeting?  It was the meeting in which I was supposed
> to get up and make "one last pitch" for a simple, socket-based
> approach" using the CPAP protocol as an example starting point.
> Having sensed the group's strong desire to leverage HTTP server
> technology (based on assumptions that have since proven to be
> totally *false* and unworkable), I decided to be "politically
> correct" and not give a CPAP presentation, so as not to appear
> as if I were "rocking the boat".  (I have since regretted that
> decision.)
> 
> The official minutes for this meeting, however, did not detail
> some of the critical statements made during this discussion.
> (ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-0597.txt)
> 
> What did happen was that Carl-Uno took a vote from the group
> as to the desired direction to proceed.  The vote was in
> favor of an HTTP approach (by quite a large margin).
> 
> Those who attended that meeting should recall that you
> surprised all those in attendance by voting for BOTH
> approaches!  To say the least, I was quite shocked and
> asked you why you voted both ways.
> 
> Your reply was something like this (not your exact words,
> but pretty close for all intents and purposes):
> 
>   If we wanted a real, long-term useful printing protocol,
>   then we would of course design a protocol using a simple
>   socket-based approach.  Such a protocol would allow us to
>   do much more than just job submission, but could also allow
>   us to effect critical management functions using the same
>   protocol.  However, since the world appears to strongly
>   desire some sort of Web-based interface, let's just develop
>   a simple HTTP-based submission protocol.  Afterwards, we
>   can then address a more suitable protocol usable in the
>   long-term.
> 
> I LOVED THIS STATEMENT.  It seemed so pragmatic and clearly
> thought out that I immediately jumped on the bandwagon to
> develop a *simple* HTTP-based protocol, hoping (of course)
> that the effort would not be long and drug out, and that
> we all could finish the effort in the originally intended
> schedule.
> 
> From what I could see, it was in my best interest to help
> complete the HTTP-based effort as quickly as possible so
> as to be able to more quickly move on to the development
> of a REAL, long-term protocol.
> 
> However, as time moved on, more and more people started
> to view IPP as both an INTERnet protocol *and* and INTRAnet
> protocol.  And this is where the real disaster strikes, IMHO.
> 
> So now, when you say:
> 
> > Our intent is purely to do the right thing both for the
> > short term and the long term. We saw IPP as an opportunity
> > for printing to 'do it right' from day 1 as opposed to
> > always having to compromise on other solutions (SNMP,
> > LPR/LPD, ...).
> 
> This appears to be a complete reversal of your great comments
> made to the group back in May in San Diego.  In San Diego,
> you implied that IPP would serve as an interim protocol, as
> anything HTTP-based would not easily allow for the kind of
> long-term printing protocol the world really needs, at least
> not within enterprise environments.
> 
> This is truly disappointing.  And I know for a fact I am not
> alone in this belief.
> 
> 	...jay
>

---

From: [email-masked]
Date: Tue, 10 Feb 1998 16:05:32 -0700

In response to Jay's query....
     
     Yes, Hewlett-Packard agrees with Paul Moore in that we will implement 
     what the IESG ratifies, and our aim, as well, is to promote 
     interoperability.  The intent of IPP is to enhance and standardize 
     internet printing, not to create a political battle between companies.

     Kris Schoff
     Hewlett-Packard

______________________________ Reply Separator _________________________________
Subject: Re: IPP> Consensus on sending our drafts to the IESG
Author:  Non-HP-jkm ([email-masked]) at HP-Boise,mimegw7
Date:    2/7/98 10:15 AM

Paul,

---

From: [email-masked]
Date: Thu, 12 Feb 1998 13:57:09 -0800 (PST)

> From [email-masked] Sun Feb  8 13:27:12 1998
> From: Paul Moore <[email-masked]>
> To: "'Jay Martin'" <[email-masked]>
> Cc: [email-masked]
> Date: Sun, 8 Feb 1998 12:48:42 -0800 
>

....  large section deleted for brevity - read the original posting please

I agree with almost all of these comments, from BOTH sides.  I also
went along with what I saw,  which after some careful analysis I
decided was a less than perfect methodology, in order to foster
group or general concensus.

I have reluctantly come to the position that the development of
this standard and protocol has been driven more by 'Corporate
Politics' and 'Having an Industry Concensus' than by 'Technical
Requirements'.

Now before you think that this is a NEGATIVE statement,  I want to clearly
indicate that I am ALL FOR 'Having an Industry Concensus' and that
if it takes 'Corporate Politics' to reach this,  I am all for it.

I may not like the fact that we have an elephant with the appearance
of a camel (apologies to PERL fans),  but at least we have something
that stands a chance of becoming an industry wide standard,  and appears
to be at least as functional as the old LPR (RFC1179) protocol,
and compatible with gatewaying to it.

Which is really all that I was interested in :-)

Patrick ("
   There is industry agreement, a standard, and a working prototype.
   Of course we don't use it, cause we didn't invent it and can't
   license it or patent it.
         ") Powell

P.S. - any resemblance to the above statement and proprietary
network protocols versus using TCP/IP is entirely coincidental, irrelevant,
immaterial,  and highly controversial. :-)