Subject: BEEP/SOAP (Was RE: SACRED Protocol (long!))

From: Mike Just <[email-masked]>
Date: Fri, 7 Dec 2001 09:51:27 -0500

Ok, so maybe the question should be "Why Beep?"  If we (meaning the company
I work for) implement XKMS and other web services using SOAP, I'd certainly
prefer that SACRED did the same. 

Mike 

> -----Original Message-----
> From: Dave Crocker [mailto:[email-masked]]
> Sent: Thursday, December 06, 2001 10:47 PM
> To: [email-masked]
> Subject: Re: SACRED Protocol (long!)
> 
> 
> 
> Folks,
> 
> >To: "Magnus Nystrom" <[email-masked]>, <[email-masked]>
> >Subject: Re: SACRED Protocol (long!)
> >From: "Marshall T. Rose" <[email-masked]>
> >
> > > Actually Marshall, I think it is a good thing to run 
> SACRED on top of
> > > BEEP. However, I also do believe that it should be possible to run
> > > SACRED on top of other protocols as well,
> >
> >everything has a cost. by mandating
> 
> 
> It is possible that the import of Marshall's response does 
> not adequately 
> register with some participants.  So it occurred to me that we should 
> consider this proposal for infinite portability, and apply it 
> to other venues.
> 
> For example, I have traveled to a few different countries and 
> I find all 
> those plug adapters and voltage differences to be quite irritating.
> 
> So I think we should mandate that every electrical device 
> must a) work on 
> all the different global voltages and b) have a plug that 
> works in all the 
> different global sockets.  Nevermind the increased cost.  
> Just the idea of 
> one of those bulbous plugs on every device is delightful to consider.
> 
> In fact, this seemed like such an appealing solution that it 
> occurred to me 
> we should go further.
> 
> We should mandate that every automobile be made legal for 
> every driving 
> situation in the world.  I have no idea what this will mean 
> under the hood, 
> but am most intrigued at the idea of having the driver's 
> steering wheel and 
> other driving controls able to move from one side of the car 
> to the other.
> 
> So,
> 
> I hope, like me, everyone is shaking their head by now, 
> because that really 
> is the nature of the proposal that has been put forward.  It is 
> well-intentioned, but it carries unacceptable costs, for the 
> specification 
> effort, for the development effort, and for the poor end-user.
> 
> d/
> 
> 
> ----------
> Dave Crocker  <mailto:[email-masked]>
> Brandenburg InternetWorking  <http://www.brandenburg.com>
> tel +1.408.246.8253;  fax +1.408.273.6464
>

---

From: "Marshall T. Rose" <[email-masked]>
Date: Fri, 7 Dec 2001 08:22:37 -0800

BEEP/SOAP (Was RE: SACRED Protocol (long!))why not go to
http://www.beepcore.org/beepcore/specsdocs.jsp, scroll down to where it says
"whitepapers" and then start reading.

or, go talk to the guys in the syslog or idxp working groups and ask why
they layered on top of beep instead of writing yet-another-protocol...

or ...

you get the picture...

/mtr

  ----- Original Message -----
  From: Mike Just
  To: 'Dave Crocker' ; [email-masked]
  Sent: Friday, December 07, 2001 06:51
  Subject: BEEP/SOAP (Was RE: SACRED Protocol (long!))

  Ok, so maybe the question should be "Why Beep?"  If we (meaning the
company I work for) implement XKMS and other web services using SOAP, I'd
certainly prefer that SACRED did the same.

  Mike

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 07 Dec 2001 16:36:37 +0000

Marshall, Mike,

(Just trying to eliminate or make specific one degree-of-freedom...)

In your opinion is there any point in sacred including sasl
elements in its payload, but still using beep as transport?

That is, this thread has mentioned the following options:

"sacred = payload + beep(sasl)"                [the current I-D]
"sacred = payload(sasl) + soap"                [mike's question]

does:

"sacred = payload(sasl) + beep" make sense or not? (To be clear:
this means using beep as transport, and not leveraging the sasl
support available in beep, but rather sending the sasl PDUs in
the sacred payload.)

If it did make sense, then one could imagine a way 'round this 
where we split into two drafts, one for payload(sasl) and one
(or more) for "sacred = draft1 + transport". However, I'm
not conviced that "sacred = payload(sasl) + beep" does
make that much sense, nor that we've sufficient bandwidth
and interest to progress multiple documents.

Stephen.

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

---

From: Magnus Nystrom <[email-masked]>
Date: Fri, 7 Dec 2001 12:04:50 -0500 (Eastern Standard Time)

Hi Stephen,

(Chipping in though the posting was directed to Marshall and Mike)

I think that BEEP has some nice characteristics that would make a
SACRED-on-top-of-BEEP architecture worthwhile. In particular, since
there is a BEEP profile for SOAP in the works, it seems as if the
people doing that profile felt that the binding was useful. As I
stated earlier, if we map SACRED to SOAP we will get these benefits
too, but with the added advantage of leveraging other SOAP bindings.

And, as I mentioned in an earlier posting, the task of doing the
mapping should not in itself require that much work, c.f. XKMS which
currently maps to SOAP in Appendix A.

-- Magnus

---

From: Sam Roberts <[email-masked]>
Date: Mon, 10 Dec 2001 11:14:12 -0500

I'd be interested in these whitepapers. Do they exist on another
web site? The URL you give points to a bunch of malfunctioning java
servlets.

Sam

Quoting "Marshall T. Rose" <[email-masked]>, who wrote:
> 
>    why not go to [1]http://www.beepcore.org/beepcore/specsdocs.jsp,
>    scroll down to where it says "whitepapers" and then start reading.
> 
>    or, go talk to the guys in the syslog or idxp working groups and ask
>    why they layered on top of beep instead of writing
>    yet-another-protocol...
> 
> 
> 
>    or ...
> 
> 
> 
>    you get the picture...
> 
> 
> 
>    /mtr
> 
> 
> 
>    From: [2]Mike Just
>    To: [3]'Dave Crocker' ; [4][email-masked]
> 
>      company I work for) implement XKMS and other web services using
>      SOAP, I'd certainly prefer that SACRED did the same.
> 
>      Mike
> 
> References
> 
>    1. http://www.beepcore.org/beepcore/specsdocs.jsp
>    2. mailto:[email-masked]
>    3. mailto:[email-masked]
>    4. mailto:[email-masked]

-- 
Sam Roberts <[email-masked]>