Multiple substrates (Was: Re: sasl in beep or payload)

Keith,

Keith Moore wrote:
> 
> > I have some sympathy for this myself, but judging by the raised
> > hands, the consensus amongst those who'd implement sacred was to
> > include the sasl pdus in the payload.
> 
> I think several people were assuming that there would need to be
> multiple substrates for sacred, and this was to some degree
> motivating the push toward putting sasl pdus in the payload.

Fair point (though it was at the end of a 30-40 minute discussion
where that specific issue was raised at least a few times). 

Any hand-raisers (or others, of course) care to comment/clarify? 

> I think that the assumption that there should be multiple substrates
> needs to be a separate discussion topic, because IMHO this will both
> degrade interoperability and make the sacred protocol more complex.

I tend to agree, though I think I'm less concerned with this for the 
credential server than I guess you are. I also don't think anyone's 
suggested that a sacred client would ever support more than one 
substrate.

So it seems that what's been suggested so far is along the lines of:

1) only define beep
2) only define http
3) define both in one rfc, client picks one, server MUST/SHOULD/MAY do 
   both (if not MUST do both, then one of beep or http has to be 
   mandatory-to-implement)
4) define both in one rfc, client and server pick what they like (yuk!)
5) first do 1) but then do 2) in a separate rfc, re-using as much as possible, 
   and making it as easy as possible for a single server to implement 
   both

Are there other combinations/substrates/ways-to-organise this that people 
would like to suggest before we get into the repsective (de-)merits of 
these? 

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email protected]
Ireland                             http://www.baltimore.com