[BXXPwg] SOAP over BEEP
Thu, 14 Jun 2001 18:20:46 -0700
>ideally, i would prefer to avoid having to use a new scheme everytime
>someone moves yet another service on top of beep.
To satisfy the above seems reasonable and sane. Thus the URL for a
resource provisioned on BEEP to have the scheme "beep", i.e.
Are there major objections to this? Mostly what I have seen so far
is that there is yet a lot to think about and no firm path has yet
It makes sense to me that the URL should specify in some way that BEEP is
in use. Perhaps the scheme should encode the the transport mode as well
beep: beep over tcp
beeps: beep over ssl
beepsc: beep over sctp
We then have other vectors that need to be dealt with, host/port are
pretty easy. It's profile that gets ugly. Is it reasonable to adopt
well known abbreviations for specific profiles? The most painful thing
about profiles in the URL is that you need to encode a second URL within
the first one, I don't think anyone wants to go there...
To expand on MTR's 4 examples below we might end up with
It seems like there is enough thoguht in this that we might be
proceeding to a decision, or at least the start of the discussion which
will lead to one. As has been said there are many ways to do this,
and no one solution is necessarily preferred, but there are clearly some
with pitfalls to be avoided.
From: Marshall T. Rose [mailto:email@example.com]
Sent: Thursday, June 14, 2001 3:59 PM
To: Roy T. Fielding
Cc: Gabe Wachob; firstname.lastname@example.org; Eamon O'Tuathail
Subject: Re: [BXXPwg] SOAP over BEEP
roy - thanks.
> In general, if the service is available via multiple protocols and the
> naming syntax for those protocols will differ, then use a
> addition to the URI scheme (like the wcip.beep scheme above). That is the
> normal way of doing it because the authority syntax is often dependent on
> the transport used (e.g., TCP ports and defaults).
> OTOH, if the syntax for naming will be the same, but the naming authority
> will differ based on the lower-layer protocol, then I would include beep
> within the authority component. However, I have yet to see a good example
> of this in practice.
in most of the recent cases that i have seen, the only thing that differs is
how the data gets moved, e.g., going from soap/http to soap/beep, or
ice/http to ice/beep, etc. in both cases, you have a situation where the
path is going to be the same, and i have difficulty understanding whether
the "use beep" bit should be present in the scheme component or the
authority component. for example,
may very well be a valid thing for someone doing soap over http. so, what
should we be using for the soap over beep case? here are four possibilities,
i'm sure there are more...
ideally, i would prefer to avoid having to use a new scheme everytime
someone moves yet another service on top of beep.
BXXPwg mailing list