Subject: RE: [BXXPwg] SOAP over BEEP

From: Bill Mills <[email-masked]>
Date: Mon, 18 Jun 2001 14:20:35 -0700

I don't know if I like it as much but what about 

	beep://foo.com:<profile>:<port>:<proto>/

This would allow us to stay near the current usages for URL's.  It has
the disadvantage of significantly overloading the current usage for port
specification in HTTP.

Again I think the ugliest thing here is if we end up needing a full 
URL to identify the profile.

-bil

-----Original Message-----
From: Eamon O'Tuathail [mailto:[email-masked]]
Sent: Monday, June 18, 2001 2:03 PM
To: Bill Mills; [email-masked]
Subject: RE: [BXXPwg] SOAP over BEEP

The idea of a superhandler would be neat, but ...

from a practical viewpoint, having multiple ':' could well trip up
many generic implementations, and

>From a standards perspective, RFC 2396, states:
   "Many URI include components consisting of or delimited by, certain
   special characters.  These characters are called "reserved", since
   their usage within the URI component is limited to their reserved
   purpose.  If the data for a URI component would conflict with the
   reserved purpose, then the conflicting data must be escaped before
   forming the URI."

      reserved    = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
                    "$" | ","

and later:
   "Within the authority component, the characters ";", ":",
   "@", "?", and "/" are reserved."

You don't have to follow the "scheme>://<authority><path>?<query>"
approach - but the vast majority of implementations do.

   "The URI syntax does not require that the scheme-specific-part have
   any general structure or set of semantics which is common among all
   URI."

The BNF in RFC 2396, appendix A does permit use of ':' in the opaque_part.

The more you stray from what people expect, the more likely things will be
broken.

Eamon

_______________________________________________
BXXPwg mailing list
[email-masked]
http://lists.invisible.net/mailman/listinfo/bxxpwg

---

From: "Marshall T. Rose" <[email-masked]>
Date: Mon, 18 Jun 2001 14:29:28 -0700

> URL to identify the profile.

i'll pass. this is abstracting the wrong thing. beep isn't a protocol or a
service. it doesn't make sense to specify a url scheme for it.

/mtr

---

From: Gabe Wachob <[email-masked]>
Date: Mon, 18 Jun 2001 16:48:23 -0700 (PDT)

> service. it doesn't make sense to specify a url scheme for it.

I think I started this thread, so let me say thats its become clear that
what I was really asking about (though in my fuzzy thinking I may not have
actually stated such) was how to pass around an endpoint descriptor - for
example, to configure an application to talk to a particular BEEP
listener.

Its become clear from this discussion, at least to me, that in almost any
use case I can come up with, all that is really needed is a hostname/ip &
port number (for TCP binding). The application consuming this endpoint
descriptor will presumably know whats there; if it didn't know what
profile to use there, how could it be doing anything useful.

In other words, for a given endpoint, I don't see a situation where the
profile to be used (or profiles) isn't implied by the context in which the
endpoint is being used.

Thus, no real need for URLs except something very basic like
beep:<hostname>:<port>

Counterexamples?

	-Gabe

---

From: "Marshall T. Rose" <[email-masked]>
Date: Mon, 18 Jun 2001 16:58:11 -0700

> Thus, no real need for URLs except something very basic like

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

---

From: Gabe Wachob <[email-masked]>
Date: 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?

	-Gabe

---

From: "Dan Kohn" <[email-masked]>
Date: Mon, 18 Jun 2001 21:10:39 -0700

The counterexample for Gabe is a beep listener that, for whatever
reason, supports profiles for two or more services on the same port.
Which is why I'd like to suggest the following (updated) proposal:

Any protocol built over beep is welcome to define it's own URL scheme.
This registration must include what profile is supported and the default
port number and transport layer.  Since URL schemes will map one-to-one
to BEEP profiles, the profile should not be separately specified in the
URL.  Thus, for a "web over beep" service, the following scheme would be
registered using RFC 2396 notation:

web_URL = "web:" "//" host [ ":" transport ] [ ":" port ] [ abs_path [
"?" query ]]

transport = "tcp" / "sctp" / "udp" / "tls"

And where lack of specified transport defaults to TCP (for this scheme
name, although not necessarily for others).  The listener and/or
initiator can still cause the transport to be negotiated (e.g., from tcp
to tls), but the transport in the URI specifies what to start with.

web is used instead of web.beep because web is not previously defined
over other session layers.  Similarly, imxp, syslog.raw, and
syslog.cooked are all good URL scheme names, where if soap is registered
as a scheme name using HTTP transport semantics, then SOAP over BEEP
should use "soap.beep".

A default beep URL scheme should not be registered, since invocation of
a beep URL would have no default semantics and no default application to
call.

		- dan
--
Dan Kohn <mailto:[email-masked]>
<http://www.dankohn.com/>  <tel:+1-650-327-2600>

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Gabe Wachob
Sent: Monday, June 18, 2001 17:07
To: Marshall T. Rose
Cc: [email-masked]
Subject: Re: [BXXPwg] SOAP over BEEP

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?

	-Gabe

---

From: Gabe Wachob <[email-masked]>
Date: Mon, 18 Jun 2001 21:48:26 -0700 (PDT)

> Which is why I'd like to suggest the following (updated) proposal:

Wait, why would a listener need a URL format? Only initiators are going to
need this URL containing a profile.. Only an initiator is going to have to
make a decision about *why* they are entering into a BEEP connection ..

In other words, in BEEP, a "location" is not visible within the protocol -
if you talk to a BEEP endpoint (listener), that listener basically only
cares really that you connected, and the negotiation for what profile to
"execute" is part of the greeting and channel creation - no URL
neccesary.

	-Gabe

---

From: "Dan Kohn" <[email-masked]>
Date: Mon, 18 Jun 2001 21:54:02 -0700

The initiator needs the URL, but the unique scheme names per profile are
required if the listener is offering multiple profiles on the same port.

A BEEP initiator is told by a URL to begin a session.  The listener
supports two profiles on the same port, IMXP and raw syslog.  A
hypothetical "beep" URL would not be able to specify which profile
should be selected.  But, an imxp or syslog.raw URL scheme name is by
definition bound to a single BEEP profile, so there is no confusion over
which profile to select.

		- dan

-----Original Message-----
From: Gabe Wachob [mailto:[email-masked]] 
Sent: Monday, June 18, 2001 21:48
To: Dan Kohn
Cc: [email-masked]; Roy Fielding
Subject: Re: [BXXPwg] Updated strawman for BEEP protocol URIs

> Which is why I'd like to suggest the following (updated) proposal:

Wait, why would a listener need a URL format? Only initiators are going
to
need this URL containing a profile.. Only an initiator is going to have
to
make a decision about *why* they are entering into a BEEP connection ..

In other words, in BEEP, a "location" is not visible within the protocol
-
if you talk to a BEEP endpoint (listener), that listener basically only
cares really that you connected, and the negotiation for what profile to
"execute" is part of the greeting and channel creation - no URL
neccesary.

	-Gabe

---

From: Gabe Wachob <[email-masked]>
Date: Mon, 18 Jun 2001 21:59:34 -0700 (PDT)

I'm having a hard time understaning in what situation an application would
think "hmm, I have this endpoint, should I do IMXP or syslog-raw?" I mean,
even if it did both of those functions, wouldn't it know by context (eg
different fill-in fields in some config screen) that the particular
endpoint can be used for either profile?

The application is not making the decision - "here's an endpoint, whats
something interesting I can do with it". Rather, the logic is "I want to
do profile X, do I have an endpoint with which to do profile X"...

	-Gabe

---

From: "Dan Kohn" <[email-masked]>
Date: Mon, 18 Jun 2001 22:09:34 -0700

If the URL scheme were just "beep", the application would connect and
see, I can do IMXP or syslog-raw.  This would be fixed if there were a
profile field in the beep URL scheme name, but that's very ugly because:

A) who wants a URL in a URL, and
B) it incorrectly assumes that there is a single BEEP client to be
invoked, when in fact that are probably multiple applications, each of
which speaks a certain BEEP profile.

My proposal addresses this by mapping one-to-one between BEEP profiles
and URL scheme names so that the right application is launched for any
given profile.  This additionally enables a listener to support multiple
profiles on the same port without confusion, since the initiator knows
which profile it should use from the scheme name.

I don't know how to more clearly answer your question.  Could I suggest
you go back to my proposal from a few messages ago and, if you have an
issue with it, suggest an alternative?

		- dan

-----Original Message-----
From: Gabe Wachob [mailto:[email-masked]] 
Sent: Monday, June 18, 2001 22:00
To: Dan Kohn
Cc: [email-masked]; 'Roy Fielding'
Subject: RE: [BXXPwg] Updated strawman for BEEP protocol URIs

I'm having a hard time understaning in what situation an application
would
think "hmm, I have this endpoint, should I do IMXP or syslog-raw?" I
mean,
even if it did both of those functions, wouldn't it know by context (eg
different fill-in fields in some config screen) that the particular
endpoint can be used for either profile?

	-Gabe

---

From: Gabe Wachob <[email-masked]>
Date: Mon, 18 Jun 2001 22:17:36 -0700 (PDT)

Ah, ok, I get it now - you are talking about the "click on this URL" mode
of application. I had not considered that - I had not considered that
there would be some way to launch an beep application from within (say) an
HTML page. (I could embed a IMXP URL for example).

Fair enough. Good counterexample. The initiator is still going to drive
the decision of which profile to use (I was confused when you talked about
the *listener* making a decision - that threw me off).

	-Gabe

---

From: Gabe Wachob <[email-masked]>
Date: Mon, 18 Jun 2001 22:25:12 -0700 (PDT)

OK, now that I buy your counterexample (a useful excercise IMHO)..

I guess my only concern is the negotiation of transport - see my note
below.

> transport = "tcp" / "sctp" / "udp" / "tls"

Little nit - "port" may not have meaning in some transports.. i.e. a
serial connection or bluetooth serial profile (if one were to go there,
its been suggested not to).

> to tls), but the transport in the URI specifies what to start with.

Outside of TCP->TLS, this negotiation isn't part of BEEP, is it? If I
understand this proposal (you are not the first to make it), a listener
can make an initial TCP connection, and then somehow negotiate that it
wants to use a different transport (say sctp) and so the two magically
make this new connection. OK, its not magic - probably a relatively simple
profile for transport negotiatoin.

Is that what you are suggesting?

> a beep URL would have no default semantics and no default application to

Right, we all agree thats clear now. BEEP endpoints don't need URLs,
application endpoints do.

	-Gabe

---

From: "Dan Kohn" <[email-masked]>
Date: Mon, 18 Jun 2001 22:40:50 -0700

Yep, that's what I'm suggesting.

TCP to SCTP seems like it could become common in addition to TCP to TLS.
My original strawman suggested not to bother with a transport token in
the URL, since you can always negotiate it later.  But, one can imagine
circumstances (say IMXP) where the listener supports both secure and
insecure modes, but the webpage embedding the IMXP URL wants the
initiator to start off secure.  Without the tls token in the URL,
there's no way to be sure that the initiator will bother to upgrade.
This is analogous to the situation with http vs. https today.

Although one could do different URL schemes for each transport, there's
no obvious benefit to doing so, and it's a pain in terms of requiring
multiple registrations.  Also, URL schemes for all BEEP profiles are
upward compatible with new transport mappings (e.g., BEEP over DNS)
simply by having the transport mapping RFC specify an additional
transport token.

Finally, the fact that port may not be meaningful in certain transports
is already handled by the fact that it's optional.

		- dan

-----Original Message-----
From: Gabe Wachob [mailto:[email-masked]] 
Sent: Monday, June 18, 2001 22:25
To: Dan Kohn
Cc: [email-masked]; Roy Fielding
Subject: Re: [BXXPwg] Updated strawman for BEEP protocol URIs

make this new connection. OK, its not magic - probably a relatively
simple

	-Gabe