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