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
> -----Original Message-----
> From: Josh Cohen [SMTP:joshco@microsoft.com]
> Sent: Friday, January 09, 1998 2:54 PM
> To: 'Jay Martin'; Robert Herriot; Paul Moore; Yaron Goland;
> 'masinter@parc.xerox.com'
> Cc: ipp@pwg.org
> Subject: RE: IPP> Delay of IPP ratification
>
> 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 <joshco@microsoft.com>
> Program Manager - Internet Technologies
>
> > -----Original Message-----
> > From: Jay Martin [mailto:jkm@underscore.com]
> > Sent: Friday, January 09, 1998 2:06 PM
> > To: Robert Herriot; Paul Moore
> > Cc: ipp@pwg.org
> > Subject: Re: IPP> Delay of IPP ratification
> >
> >
> > 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: jkm@underscore.com
> --
> > -- 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 ipp-owner@pwg.org Fri Jan 9 10:42:58 1998
> > > > From: Paul Moore <paulmo@microsoft.com>
> > > > To: "'ipp@pwg.org'" <ipp@pwg.org>
> > > > Subject: IPP> Delay of IPP ratification
> > > > Date: Fri, 9 Jan 1998 10:21:33 -0800
> > > > X-Mailer: Internet Mail Service (5.5.1960.3)
> > > > Sender: ipp-owner@pwg.org
> > > > Content-Length: 942
> > > > X-Lines: 19
> > > >
> > > > 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
> > > >
> >