Gabe Wachob gwachob@wachob.com
Mon, 18 Jun 2001 17:07:15 -0700 (PDT)

In the example I give, I am giving the endpoint to an application, or
another person to stick in their application. I presume the application
will know what to do... e.g. the profile to start.

Are there going to be applications which can run arbitrary BEEP profiles?
In which case, yes, you'd have to include the profile with the endpoint...
I'm trying to figure out a real example of such...

I guess maybe there is increasingly a new class of applications where the
"physical transport" is not specified and that somehow that physical
transport (or something even above it like BEEP) must be specified along
with the protocol's logical endpoint naming scheme (a la soap.beep naming
below). I just don't have a feel for how that will actually play out -
will SOAP clients be frequently using HTTP transport along side BEEP
transport, or will this be a toggle/preference/configuration issue that is
not done on a per-interaction basis?


On Mon, 18 Jun 2001, Marshall T. Rose wrote:

> > Thus, no real need for URLs except something very basic like
> > beep:<hostname>:<port>
> >
> > Counterexamples?
> i think that it makes sense to define a URL scheme for a protocol that is
> based on beep, e.g.,
>     soap.beep://example.com?resource=stockTicker
> what makes no sense to me is defining a URL scheme for beep, per se.
> in the example that you give, how is one to know what profile to start?
> /mtr