Subject: [Ietf-not43] an IRIS over BEEP

From: [email-masked] (Andrew Newton)
Date: 23 Jul 2002 11:21:04 -0400

Though we are still hashing through the requirements and still
evaluating BOTH proposed approaches (and I guess others that might be
submitted), I have received private email concerning the use of HTTP
with IRIS and thought it proper to bring the issue up with the working
group.  In addition, I've had a few "senior" IETF'ers also mention the
over use of HTTP for such things.

The concern was over the following paragraph from
draft-newton-iris-http-00:

   Finally, precedents for using other transport mechanisms in layered
   applications do not seem to fit with the design goals of IRIS.
   BEEP[3], while a very complete application transport, offers many
   more features than would otherwise be used in the normal and
   expected uses of this application. Examples of such features are
   multiplexing connection behavior and peer-to-peer session
   negotiation. Conversely, the straight use of TCP such as that
   specified by [14] does not offer the client negotiation
   characteristics needed by a referral application where a single
   client, in the act of processing a query, may traverse multiple
   servers operating with different parameters.

The issue was specifically over the justification for not using BEEP. 
I'd like to know what others think about the HTTP vs. BEEP issue with
relation to IRIS and the work of this WG.  Perhaps a BEEP mapping would
be more justifiable?

Points to ponder:

1. As the private email pointed out, the multiplexing and peer-to-peer
mechanisms of BEEP can merely be turned off or refused by the
end-points.  Therefore, if they aren't desired, then they don't need to
be used.

2. As the private email also pointed out, BEEP gives you SASL, which is
worlds better than trying to shoe-horn something similar into HTTP.  Or
put more bluntly, clever attempts to rig HTTP with these features are
not viewed favorably.  This is a fairly valid point given the request
for the WG to consider draft-rescorla-auth-mech-00.txt while approaching
this problem.

3. Current port 43 operations are usually done in the very similar
stateless manner of HTTP. That is, the TCP session is established for
only a single query and response.  However, this doesn't mean it is
correct... many port 43 servers experience repeated connections that may
otherwise be conducted over a single session.  In addition, where
authorization is involved, the overhead of setup/teardown becomes more
expensive.

4. Looking at the EPP world, how many operators are using BEEP?  This
may be an indication that operators/implementers think it is too
complex.

Comments?

-andy