Carl-Uno, I agree with most of your comments. We should take HTTP mapping out
of the charter. That just seems to be the politically correct thing to do. I
am concerned about security though -- do we really want to build it into the
mime-encoding?
---------------------- Forwarded by Roger K Debry/Boulder/IBM on 12/19/96 07:12
AM ---------------------------
ipp-owner @ pwg.org
12/17/96 06:18 PM
To: ipp @ pwg.org@internet, Roger K Debry/Boulder/IBM
cc:
Subject: Re: IPP> Some observations from the IPP BOF in the IETF
Some further comments on Roger's comments (I have deleted some of the
earlier text).
Carl-Uno
At 07:37 AM 12/17/96 PST, rdebry@us.ibm.com wrote:
>To: ipp @ pwg.org@internet
>cc:
>Subject: IPP> Some observations from the IPP BOF in the IETF
>
><<RKD>> Getting the RFCs approved and on the standards track may
><<RKD>> take longer as the IETF takes on more formality. However,
><<RKD>> I disagree that it will take longer to generate the RFCs
><<RKD>> for initial submission to the IESG. Let's keep our focus
><<RKD>> and momentum!
>
As I wrote further down in my original posting, we should not let the
administration in IETF slow us down! However, the additional requirements
for security, management, and I18N, means that we might need to do more
work then we anticipated earlier.
><<RKD>> I wouldn't say that the Area directors would not accept an HTTP
><<RKD>> mapping. In fact, I think Keith Moore's suggestion to look at a
><<RKD>> "lightweight" HTTP was a very positive comment. However, I agree
><<RKD>> that splitting out the HTTP mapping as a separate document is
><<RKD>> a smart thing for us to do .. and Yes, I do think we ought to
><<RKD>> proceed with the mapping.
>
I agree that "we in the PWG" should continue our work on the HTTP mapping.
Whether that is palatable to the IETF is still a serious question. We do
not want the project stoppeed in the IETF by insisting that this mapping
has to be part of the official IETF project.
Keith's idea about a "lightweight" HTTP might be interesting, but will most
likely take far to long to fit in our current schedule. For possible future
use perhaps, but do we want to spend our time on doing that right now?
I think not.
><<RKD>> As long as we carefully think through how we want to mime-encode!
>
This will require some thinking. We can go either of several different
ways about this:
1) Define a generic MIME "container" type that is application independent,
and allows for things like operations and attributes, which needs to
be filled with actual types and values for use in a particular application.
Larry Masinter expressed some interest in this idea, as the WEB DAV group
has similar needs.
2) We can define IPP specific MIME-types, perhaps one each for say:
Print-request (to server)
Print-request-response (from server)
Print-request-error (from server)
Print-request-notification (from server)
.... and so on.
3) As a compromise between 1) and 2), we could specify ONE format that can
be used for all the IPP interchanges, but does not aim to be as generic as
case 1). We would in effect try to model a client-server style of operation
onto MIME-types, that in themselves has no concept of state or
interdependence.
Another comment about the MIME-type approach, is that we will need to define
security on the MIME level, that is independent of the transport method.
This implies using some form of end-to-end security that also work over
e-mail
etc. I believe this requires a rethinking of our ideas about IPP security.
><<RKD>> I disagree! We ought to proceed with what we believe is the best
><<RKD>> course for us and do it in parallel. Once we do the mime-encoding,
><<RKD>> I think that the HTTP mapping is dead simple anyway. With the
><<RKD>> standard split into several pieces, the worst that can happen is
><<RKD>> that the IETF not approve the HTTP mapping, or choose to address
><<RKD>> approval in a serial fashion. However, that decision should not
><<RKD>> affect approval of the other pieces.
>
As already stated, I agree that the PWG should keep up the work on the HTTP
mapping, the question is still whether it is smart to try to insist on
keeping
it in the IETF charter....
><<RKD>> We definately should not slow down prototyping! We have made some
><<RKD>> substantial progress and I think sharing implementation experience
><<RKD>> will help us assure ourselves that we have made the right decisions.
><<RKD>> I'd really like Microsoft's and Netscape's input before we make any
><<RKD>> substantial shifts away from HTTP.
>
Obviously, if we create de-facto realizations of IPP over HTTP that gets
implemented by Microsoft and Netscape, it does not matter what IETF thinks
about it.
><<RKD>> Also as stated in my previous comment, I think that we should
><<RKD>> proceed full speed ahead as planned - not only in the PWG, but
><<RKD>> with the IETF. Let them make the decision to put pieces on hold
><<RKD>> that they are concerned with, let's not try to second guess them.
><<RKD>> Splitting up the standard into multiple RFCs and working in
><<RKD>> parallel allows us to think about and write down how all of these
><<RKD>> bits work together, which I think is critical to success.
>
I agree that our prototyping should continue as planned. I believe that
some IETF folks believe that it is feasible to test the IPP MIME types over
SMTP. I totally disagree - email is definately not the right transfer for
IPP and we would just waste our time. If we were to look into some other
transport, evaluating Alex's proposal to do something directly on top of
TCP (which might have the advantage of improved performance) could be an
alternative.
>
I repeat: We had 80 people attending our BOF session and I counted about
2/3 of
those being actively interested in getting IPP off the ground. Whatever we
do, we should not let the IETF bureaucracy slow us down in doing real work.
The IETF claims to believe in rough consensus and running code. I believe
that we
can deliver both.
Carl-Uno