Re: sasl in beep or payload

Considering all the (mostly valid, even if sometimes contradicting)
technical and pragmatic arguments on the list, I can see why it is
difficult to determine where the consensus lies. 
 
My vote is with BEEP and sasl-in-beep. 
 
SACRED is setting an example for others Apps WGs that are coming in
future. Many of the worries with using HTTP as a transport revolve
around security, and other WGs might consider the SACRED WG, with its
heavy security emphasis, and follow its lead. The wider Internet
infrastructure also needs to be considered. Taking the "use http as an
application substrate" argument to a logical conclusion, we could get
everything flowing over port 80. What is the poor firewall administrator
to do then?
 
If Stephen is prepared to spend his Christmas hols writing up a new
version of the spec, surely the "beep vs. http" and "what to do about
sasl" questions has to be conclusively answered before that. 
 
Why not simply ask the Apps ADs or the IESG about whether they are
satisfied with using HTTP as an application substrate? Marshall reckons
the http route will require an extra "15-20 pages of spec to deal with
administriva" - does anyone have a counter-guesstimate to that. Will it
really be that much? A number of technical questions about using HTTP as
the substrate have been raised on the list -  the pro-http faction have
yet to answer them. 
 
Stephen wrote:
> In fact, I'd be quite happy with sasl-in-beep, but am following 
> what I see as the consensus.
 
If it is decided to go with BEEP, I demand a re-count!
If BEEP is the substrate, it only seems logical to use its capabilities
to the fullest, including sasl-in-beep. 
 
There was a mention a while back about concerns over BEEP on mobile
devices - this is a valid worry for implementors who have the practical
problem of delivering solutions. Most mobile devices  will support
mobile versions of Java, Microsoft .NET or Linux. There is a java
implementation on beepcore.org - would it really be that much of a
effort to get it running on J2ME? Clipcode will have its BEEP for .NET
ready for beta on pocket PC and similar devices early next month (using
the .NET Compact Framework). There is a BEEP C implementation on
beepcore.org - and that should be portable to platforms where there is a
Berkeley sockets API available - albeit with some work to be done. 
 
 
Eamon O'Tuathail
Clipcode.com