Re: SACRED Protocol (long!)

At 10:44 AM 12/11/2001 -0600, Dale Gustafson wrote:
>Agree, althought it's not as clear that SASL needs to be tightly coupled 
>with BEEP.

Indeed.  SASL was developed independently.  The point was (and is) that 
choosing BEEP solves a set of issues.  So you do ONE adoption/integration, 
rather than a series.  SASL comes WITH beep.  Skip beep and you need to 
integrate SASL separately, along with doing your own framing, error codes, 
etc., etc.


>Also, many SASL mechanisms won't work for SACRED.  Ideally, we need a 
>proper subset
>of SASL.

SASL is a negotiation mechanism.  I would venture to say that no protocol 
that uses it requires (or even expects) participants to support ALL of the 
mechanisms it defines.  In other words, all you have done is to highlight 
the benefit of SASL, rather than a problem (or extra work).


> > Perspective on "highly constrained" changes over the years.  From an
> > historical perspective, the idea that anything that is considered highly
> > constrained would use HTTP is, in fact, downright amusing.
>
>Highly constrained means

yes, of course.  I understand.  my point was missed, so I'll just say it 
directly:  From a practical standpoing, BEEP does not introduce overhead 
that you won't incur without beep.


>... We
>will, no doubt, need the flexibility that allows us to take a free ride on 
>well
>known capabilities whenever necessary.

Like BEEP.  Yes.  Excellent perspective.


>However, using an extra 2 or 4 K of a client device's storage space might be a
>non-trivial problem (seems strange, I know).

For functionality in the modern Internet, that level of optimization will 
typically require using totally non-standard mechanisms.


> > It always seems better to create a fully self-contained facility.  For
> > Internet design, the history is that it is not only NOT better, but in fact
> > it is just plain wrong.
>
>We're after the most flexible standardization structure that fits a very 
>wide range
>of needs.

Hmmm.  That suggests two very different responses:

1.  Excellent.  That's another good reason for using BEEP, or

2.  You probably want to do your work outside the IETF, such as perhaps ISO...

d/

----------
Dave Crocker  <mailto:[email protected]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464