Subject: IPP> Delay of IPP ratification

From: Roger K Debry <[email-masked]>
Date: Fri, 9 Jan 1998 15:52:54 -0500

If XML has the promise of providing a better protocol format,
then I am willing to take a look at it. If we decide that XML does
make sense, will Microsoft have a reasonably complete mapping
to propose?  I would be hesitant to sign up for a completely new
approach without the promise of being able to quickly produce
a mapping document with the same level of function and detail
as the current one. If there's six months of effort required to figure
out how to use XML in IPP, then I'd most certainly vote against it!

I assume that this does not affect the model and semantics!

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

---------------------- Forwarded by Roger K Debry/Boulder/IBM on 01/09/98 01:44
PM ---------------------------

[email-masked] on 01/09/98 06:42:40 AM
Please respond to [email-masked] @ internet
To: [email-masked] @ internet
cc:
Subject: IPP> Delay of IPP ratification

This is a formal request that we delay the finalization of the IPP spec
until we have looked at the possibility of using XML as the protocol format.

I know this is revisiting an old issue but we need to make sure we do the
right thing. When the current format was proposed there was no good method
for representing structured data in an ASCII data stream. XML is now
available and seem to be the coming wave. I also know that most of the new
standards that will come out over the next year will be based around XML
(and protocol specific HTTP commands). By ensuring that we are in the centre
of these standards we will be able to leverage many common tools that will
emerge to support and manage these protocols.

There will definitely be down-sides so we need to debate this issue - not
least the investment that some of us have already made in building using the
current spec.

I think that somebody from MS will be in Hawaii.

Paul Moore

---

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

Paul,

There has to be some process in any standards body working group.   We had
final call for the working group close about a month ago and since then we
have been working issues raised during final call - not new issues. 
Granted, the IESG has not had final call and really any issues are still
open as long as we follow that process, it is just that this should have
come up ealier.  Keith has commented that he expected some comments during
the larger final call time frame.

Having said that, I am an technologist at heart and so I am always
interested in the best technical solution.  Best technologies to not always
a standard make.   The current protocol document is in the form that it is
in because of the valid Microsoft and HP proposals that were made 9 months
ago.  As I recall the problem wasn't structured data in an ascii protocol,
it was using a binary protocol rather than an ascii one for lower overhead
in processing and performance reasons.  I am convinced that the current
protocol spec is not broken and that what we have will work (since many of
us have already been doing prototyping).  There would have to be a
compelling reason to change now.  Just becuase there are other working
groups doing it, it not compelling to me.  Just becuase it is a "new wave"
is not compelling to me.

Here is my major point:  You do, however, raise vaild points about XML.  It
is a growing thing.  It is a valid candidate.  The WebDAV WG has found it be
useful.  But, one of our early goals for IPP was "speed to market" (so to
speak) so that we could come to consensus before some new technology came
over us an swallowed us up and we had to start over with the new technology.
 We are just on the verge here - we have a gold-master candidate and we are
about ready to ship product.  Do we "ship the product" with what we have
fought for a year over and finally come to consensus on (paying the price
with people's and company's time and resources) or to we hold up the product
and wait to integrate in the next new feature?  The classic question that we
all face every day.  

I personally feel is that it is too late in the process for infusion of new
things. This protocol mapping issue was discussed in Memphis (4/97) and
Munich(8/97) with full understanding and consensus on the mailing list
throughout the whole period.  There were NO issues raised about this on the
mailing list during final call.  There were NO issues raised in Washington. 
It is too late.  We need to ship.  We are not broken.  We do not NEED to
integrate with the up and coming wave of anything or we will never ship, we
will always be chasing.

Having said all that, I would be willing to consider the following:

Take the time to review a FULL proposal on an XML mapping for IPP on top of
HTTP POSTs as new encoding rules for version 1.0 of the new
"application/ipp" MIME media type if the following conditions are true:

1. That you (or someone) can contribute resources to deliver a full
proposal, distributed to the working group (via the DL) prior to the
face-to-face meeting on 1/21-22/98.

2. The proposal is limited to a data representation and encoding of the
current Model and Semantics.  We are not touching the model and semantics. 
There will be no revisiting the proposed use of new HTTP domain-specific
methods.  We SHALL NOT (can you tell I have been an editor too long!) not
revisit the issue of POST vs new HTTP methods.

3. The working group can reach consensus (at the meeting, via a toll free
phone call, on the DL)  that there is a way to proceed with the XML mapping
that will yield closure to all issues (given the limited scope of #2) in a
matter of weeks, not months.

4. The area directors comment and approve of the proposed direction before
the 1/21 meeting.

I hope that these assumptions were in the intent of your email in the first
place.  I am a little worried about the use of the parenthetical phrase you
added "(and protocol specific HTTP commands)".

Scott

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

>>> Paul Moore <[email-masked]> 01/09 11:21 AM >>>

Paul Moore

---

From: Carl-Uno Manros <[email-masked]>
Date: Fri, 9 Jan 1998 15:02:40 PST

Paul,

This kind of thing should not really happen. We have been through all our
formal steps to get agreements within the IPP WG and seemed to have full
agreement up to this message. 

Having said that, we certainly also do not want to end up with people
implementing different flavours of IPP that do not interoperate, or we have
missed our goal as a standards group.

If we were to even consider looking at an alternative proposal at this 12th
hour in the project, I expect to see some dedicated resource commitment
from MS experts to rapidly come up with a detailed proposal on how all the
current protocol functions could be expressed in the alternative proposal.
Are you prepared to make such a commitment, or else we close the discussion
right here? I think that a first draft from you within the next two weeks
would be expected.

I will wait a couple of days to allow people on the DL to respond to your
message and then take it from there. 

I urge the members of the DL to come back with your views on this subject
ASAP.

Regards,

Carl-Uno Manros

In my role as IPP Co-chair

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, 09 Jan 1998 18:01:41 -0800

--- snip , snip ---

Scott,

Thanks for your comments. 

One thing you got wrong were the dates for the next PWG IPP meeting.

The meeting is actually on Januari 28 and 29.

As I asked Paul in a previous message, can he have a draft for us by January 23,
which would give him two weeks to write it and a couple of days for us to
read it 
and get comments on the DL before the meeting.

Carl-Uno

---

From: [email-masked] (Robert Herriot)
Date: Fri, 9 Jan 1998 15:08:39 -0800

Jay,

I cannot give you any more details at this time because I haven't thought
about it enough.  At this time, I don't know whether XML is a great idea
or a terrible idea.  But XML is an important enough emerging standard
that we should not dismiss it without examining what the IPP protocol would
look like in XML and what its benefits would be.

Because the time is short, we need to make a decision quickly. We
also need enough details from XML experts, such as those at Microsoft,
to make an informed decision.

Bob Herriot

> From [email-masked] Fri Jan  9 14:06:25 1998
> 
> Bob and Paul,
> 
> Care to elucidate on the merits and applicability of XML to the IPP
> model?  Any known/expected problems in mapping?  Any particular
> benefits over alternative approaches?
> 
> Perhaps most importantly, exactly *why* should XML even be
> considered in the first place?
> 
> Bob says that "XML is becoming an important protocol."  We can all
> think of lots of emerging protocols that may be viewed as important,
> but are they applicable to network printing?  How and why is XML
> applicable to a network printing protocol?
> 
> Please understand that I am not casting any kind of early vote
> against XML here.  Just trying to figure out why XML has suddenly
> entered the fray.
> 
> 	...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   --
> ----------------------------------------------------------------------
> 
> 
> Robert Herriot wrote:
> > 
> > I agree with Paul that we should spend some time looking at XML before
> > we commit to the current protocol.  XML is becoming an important protocol.
> > 
> > Bob Herriot
> > 
> > > From [email-masked] Fri Jan  9 10:42:58 1998
> > > From: Paul Moore <[email-masked]>
> > > To: "[email-masked]'" <[email-masked]>
> > > Date: Fri, 9 Jan 1998 10:21:33 -0800
> > > X-Mailer: Internet Mail Service (5.5.1960.3)
> > > Sender: [email-masked]
> > > Content-Length: 942
> > > X-Lines: 19
> > >

---

From: Josh Cohen <[email-masked]>
Date: Fri, 9 Jan 1998 14:53:49 -0800

I think that the current IPP does not adequately address
security concerns, and that the landscape wrt XML has
changed such that it should be reconsidered.

At this point our efforts are not to conclusively move 
IPP to XML, but to open it for consideration.
XML is becoming a widely accepted way of expressing
arbitrary data types, schemas, or property attributes.

As it stands IPP is a new binary protocol specifically
for printing.  Any firewall or proxy that wishes to
securely support it will have to have IPP specific features 
coded into it.  In the future if other Internet protocols
continue this trend, proxies and firewalls will need
continual update for each protocol.

At first glance XML appears to offer a standard way of
expressing the functionality of IPP in a standard way.
While an administrator might need to configure his
firewall or proxy to specifically look for IPP
verbs or XML schemas, it doesnt require the proxy product
to be re-coded or altered.  It also shouldnt require
CGI, NSAPI, or ISAPI coding either.

Our point is that we should investigate this as a 
possibility.  You might respond by saying that
"we already looked at XML".  I would respond
to that by saying that the landscape has changed.
XML has progressed a lot, and it is gaining
widespread acceptance in many efforts as a
schema definition method.  Therefore it is worthy
to consider again with the new facts at hand.

In addition to the XML issue, I also beleive that
using POST is not optimal.  I think that printing
as a function is not something that firewalls and proxies
would want to allow just because they allow HTTP.
Rather then depending on HTTP to carry IPP through
the "problem" of firewalls and proxies, proceeding
on the current path is actually circumventing security
policies without the consent of the administrators.
Something that can work with existing proxies, but
only after being explicitly configured or allowed
(in most proxies) is more appropriate for the print
functionality.

As a firewall administrator it is up to me what
funtionality I permit through my firewall and as it
stands now IPP tricks me into thinking that Im
allowing HTTP when Im really exposing printers to
potentially unwanted load and resource consumption.

If we need to change IPP to fit future needs and
interoperability, we should do so.

If we hold off on IESG last call, we can have frank
technical discussions on how to improve IPP.

If IPP moves forward to IESG last call without 
considering these options, by which we mean working
group discussion for a period of time, I beleive
that IPP present a less than optimal solution.
Given the choice of spending extra time to get it
right and holding off on moving to IESG, or
standing up during IESG last call to oppose the 
IETF standardization of IPP, I would prefer the first.
(wait and fix it)

On the other hand, if IPP moves IESG last call as is,
I beleive that we will stand up in opposition.

--
Josh Cohen <[email-masked]>
Program Manager - Internet Technologies 

> -----Original Message-----
> From: Jay Martin [mailto:[email-masked]]
> Sent: Friday, January 09, 1998 2:06 PM
> To: Robert Herriot; Paul Moore
> Cc: [email-masked]
> Subject: Re: IPP> Delay of IPP ratification
> 
> 
> Bob and Paul,
>

---

From: [email-masked] (Robert Herriot)
Date: Fri, 9 Jan 1998 20:37:25 -0800

Try www.w3.org/TR

The following document describes XML:

    http://www.w3.org/TR/PR-xml (8 Dec 1997)

The following document describes XSL which are style sheets for XML.
I'm not sure if this is important for us.

    http://www.w3.org/TR/NOTE-XSL-970910

> From [email-masked] Fri Jan  9 20:25:25 1998
> Date: Fri, 9 Jan 1998 15:37:53 -0800 (Pacific Standard Time)
> From: Ron Bergman <[email-masked]>
> To: [email-masked]
> In-Reply-To: <[email-masked]>
> X-X-Sender: [email-masked]
> MIME-Version: 1.0
> X-Lines: 87
> I would like to echo some of the points presented by Jay.
> 
> I thought that XML was a presentation layer protocol developed as the next
> generation HTML.  Does XML include functionality beyond the presentation
> layer?
> 
> If not, why would XML be any different than PostScript, PCL or HTML?
> 
> Can anyone provide the URL to the current XML specification or tutorial
> for those persons (such as myself) who are not very knowledgeable
> regarding XML?  I would like to be somewhat prepared if this does become a
> discussion topic in Maui.
> 
> 	Ron Bergman
> 	Dataproducts Corp.
> 
> 
> 
> On Fri, 9 Jan 1998, Jay Martin wrote:
> 
> > Bob and Paul,
> >

---

From: "Turner, Randy" <[email-masked]>
Date: Sat, 10 Jan 1998 09:51:15 -0800

If a corporate entity wants to protect internal printing resources,
which I agree are valuable (consumables, time, etc...) then
the current IPP documents support the protection of these
resources via authentication. I would propose that this 
authentication be done with TLS, but HTTP-specific
autnentication might also be considered. What you have outlined
as the ability to open up something between "wide-open", and
"authenticated-access" I'm not sure would be used by entities
attempting to protect internal printing resources. If I open my
printing resources to the internet, then I want to know "who"
is using the resource. IPP has provided a transport-independent
protocol (TLS/SSL3) to accomplish this. And I believe most
current web servers support SSL3, which is configurable to
interoperate with TLS.

If there is a security concern with the use of SSL3/TLS, then
perhaps we should be discussing this, and not changing the
entire nature of the protocol encoding.

Randy

> From:	Josh Cohen [SMTP:[email-masked]]
> Sent:	Friday, January 09, 1998 2:54 PM
> To:	'Jay Martin'; Robert Herriot; Paul Moore; Yaron Goland;
> [email-masked]'
> Cc:	[email-masked]
> Subject:	RE: IPP> Delay of IPP ratification
> 
> > > > This is a formal request that we delay the finalization of the
> IPP
> spec
> > > > I know this is revisiting an old issue but we need to make sure
> we do
> the
> > > > right thing. When the current format was proposed there was no
> good
> method
> > > > available and seem to be the coming wave. I also know that most
> of the
> new
> > > > standards that will come out over the next year will be based
> around
> XML
> > > > (and protocol specific HTTP commands). By ensuring that we are
> in 
> > the centre
> > > > of these standards we will be able to leverage many common tools
> that
> will
> > > > There will definitely be down-sides so we need to debate this
> issue -
> not

---

From: Carl-Uno Manros <[email-masked]>
Date: Sat, 10 Jan 1998 09:47:04 -0800

>changed such that it should be reconsidered.

Josh,

You are basing all your reasoning around the firewall issue.
Are you aware that we actually also specifiy the use of
TLS for people who want to secure their printers? This is
REAL security compared to firewalls. 

Also, your reasoning seems to be based on the assumption that
everything runs over a common Web server that supports both
Web services and printing. I think that you will find that
IPP print servers and embedded IPP servers in printers
will more commonly have their own dedicated HTTP servers,
which makes it easy for a firewall to filter them. We have
been over these issues in detail for the past year. Don't 
think that you are coming along telling us something new.

Hence, I think you need to widen your horizons quite a lot,
rather than concentrating all your thinking around your
own favorite NT scenario.

Carl-Uno

---

From: [email-masked] (Ira Mcdonald x10962)
Date: Sat, 10 Jan 1998 15:55:12 PST

Hi folks,                                     Saturday (10 January 1998)

I'm not very sympathetic to this "12th hour" request for an XML rewrite
of the IPP Protocol spec...I'd like to comment on some hidden effects of
Paul Moore's request.

At present the IPP message ('application/ipp') is free-standing - while
a few attributes are mapped into HTTP/1.1 header fields, one is allowed
(by the IPP Model) to wrap all IPP attributes (including "operation-id")
in the IPP message.  So 'application/ipp' can be moved equally well via
interactive (HTTP/1.1) or store-and-forward (SMTP) protocols.

Josh and Paul are opposed to using HTTP Post to convey IPP messages, but
their rationale is faulty.  While firewalls shouldn't have to examine
the content of every incoming HTTP message, they now routinely examine
various HTTP header fields (for security and other site-policy reasons),
and 'Content-Type' of 'application/ipp' couldn't be plainer!

Adding new HTTP verbs for IPP will just make mappings of IPP to other
protocols harder in the future, which works against ubiquity.

My two cents,
- Ira McDonald (High North, outside consultant at Xerox)

---

From: Roger K Debry <[email-masked]>
Date: Mon, 12 Jan 1998 08:32:06 -0500

Josh, I suggest you need to substantiate your
claims on security! The group has worked very
hard to insure, through the use of TLS, that
an administrator can protect his or her print
resources. Frankly, I think Microsoft should be
terribly embarrased to veto the standards proposal
at the last minute, based on incorrect information.
After all, Microsoft has purported to be an active
participant in the development of IPP.

---

From: [email-masked] (Philip Thambidurai)
Date: Mon, 12 Jan 1998 11:16:16 -0500

______________________________ Reply Separator _________________________________
Subject: IPP> Delay of IPP ratification
Author:  Paul Moore <[email-masked]> at INTERNET
Date:    1/9/98 10:21 AM

Paul: 

Would you please enumerate the standards that you are referencing in your 
statement below? 

Philip Thambidurai

Paul Moore stated:

> ... ...
> I also know that most of the new
> ...