Subject: IPP> Some observations from the IPP BOF in the IETF

From: [email-masked]
Date: Tue, 17 Dec 1996 10:37:47 -0500

Classification:
Prologue:
Epilogue:

My comments follow .....
---------------------- Forwarded by Roger K Debry/Boulder/IBM on 12/17/96 08:12
AM ---------------------------

        ipp-owner @ pwg.org
        12/16/96 08:55 PM

To: ipp @ pwg.org@internet
cc:
Subject: IPP> Some observations from the IPP BOF in the IETF

Hi,

here follows some of my impressions from last week's BOF meeting:

1) The IETF is becoming more structured and formal in its approach to
making standards. This has both pro's and con's. It will increase the
quality of the standards, but it will also slow down the process
considerably.  Making a complete set of RFCs for IPP in 6 months seems to
be rather futile, following the latest IETF rules.

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

2) It seems that the IETF Application Area Directors are rather negatively
oriented towards both HTTP and LDAP, things that we planned to include in
our solution. Is this a case of "not invented here" (both originated
outside the IETF), or is it a question of quality control for new standards?

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

3) On the other hand, the Area Directors and everybody else, seem to be in
love with MIME (even if it means stretching the use of MIME into areas for
which it was not originally designed).  We cannot go wrong if we use MIME.

<<RKD>> As long as we carefully think through how we want to mime-encode!

4) The route to get approval for our IPP project seems to be concentrating
on describing our application specific data (such as operations and
attributes) in MIME format and describe generic use and attributes for
directory services, but to forget about mapping it to HTTP and LDAP for
now.  It was suggested that doing things in sequence would be better than
trying to do mappings to "transports" at the same time.

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

5) If we were to accept all the proposals made, it seems that our objective
of having working prototypes out within 6 months are doomed.  However, we
have several alternatives on how to proceed.  We could accept the reduced
scope from IETF, but could keep up the work on the other subjects in the
PWG, for later introduction in the IETF.  Or we could consider getting the
W3C organization interested in working on the HTTP mapping.  We could also
consider the proposal to design a new dedicated protocol to run directly on
top of TCP (which would take us out of the discussion about whether HTTP is
good or bad).  Let us try to get quick agreements on which way to go, so
that we do not slow down the progress of our project in particular in our
prototype teams.

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

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

6) 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.

7) Our concept of using HTTP to avoid Firewalls seem to be flawed.  I spoke
to several security specialists about it and they called us naive. They
pointed out that any firewall provider worth its salt would use IPP as a
good excuse to sell their customers a new version of their firewall -
whichever way we do it.

my 2 cents...

Carl-Uno

---

From: Carl-Uno Manros <[email-masked]>
Date: Tue, 17 Dec 1996 17:05:26 PST

Some further comments on Roger's comments (I have deleted some of the
earlier text).

Carl-Uno

><<RKD>> for initial submission to the IESG. Let's keep our focus

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

---

From: [email-masked]
Date: Thu, 19 Dec 1996 09:15:06 -0500

Classification:
Prologue:
Epilogue:

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

Carl-Uno

Carl-Uno

---

From: [email-masked] (Robert Herriot)
Date: Thu, 19 Dec 1996 16:24:53 -0800

> From [email-masked] Thu Dec 19 06:16:42 1996

> ... I

You might want to look at RFC 1847:  'Security Multiparts for MIME:
Multipart/Signed and Multipart/Encrypted'. It may solve our problem
with authentication and security.

The brief summary is that there are two new subtypes of multipart:
signed and encrypted. An example from this rfc of a signed document is:

    Content-Type: multipart/signed; protocol="TYPE/STYPE";
            micalg="MICALG"; boundary="Signed Boundary"
 
    --Signed Boundary
    Content-Type: text/plain; charset="us-ascii"
 
    This is some text to be signed although it could be
    any type of data, labeled accordingly, of course.
 
    --Signed Boundary
    Content-Type: TYPE/STYPE
 
    CONTROL INFORMATION for protocol "TYPE/STYPE" would be here
 
    --Signed Boundary--

The signature part is always the second of two parts.