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

Ok - we've got 6 options. Magnus and I plan to run a strawpoll on these
six, starting jan 7th, running to Friday 11th. So if you've a 7th option, 
or comments on this list, please post to the list before the 7th.

Stephen.

David Chizmadia wrote:
> 
> Stephen,
> 
> > 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?
> 
>  6) in a distinct RFC, define the normative SACred
>     PDU content and format, as well as a set of
>     mandatory requirements for the substrate that
>     carries those PDUs. Define additional RFCs for
>     beep and http. Let other SDUs (like OMG) reuse
>     the PDU RFC with our substrate (GIOP/IIOP).
> 
> > Stephen.
> 
> -DMC

-- 
____________________________________________________________
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