[BXXPwg] SOAP over BEEP

Gabe Wachob gwachob@wachob.com
Thu, 14 Jun 2001 18:13:30 -0700 (PDT)


what about

beep:hostname:port:<profile uri>?

e.g.

beep:beephost.wiredobjects.com:10087:http://www.resource.org/SOAP

ew, thats long.

	-Gabe


On Thu, 14 Jun 2001, Bill Mills wrote:

> >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.
>
> 	beep:<scheme-specific-part>
>
> 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
> been taken.
>
> 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
> so that:
>
> 	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
>
> 	beep:soap://example.com/
>
> 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.
>
> regards,
>
> -bill
>
> -----Original Message-----
> From: Marshall T. Rose [mailto:mrose+mtr.netnews@dbc.mtview.ca.us]
> Sent: Thursday, June 14, 2001 3:59 PM
> To: Roy T. Fielding
> Cc: Gabe Wachob; bxxpwg@invisible.net; 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
> protocol-specific
> > 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,
>
>     http://example.com/
>
> 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...
>
>     beep://example.com/
>
>     soap.beep://example.com/
>
>     soap://example.com/?proto=beep
>
>     beep://example.com?profile=http://iana.org/beep/soap
>
> ideally, i would prefer to avoid having to use a new scheme everytime
> someone moves yet another service on top of beep.
>
> thanks,
>
> /mtr
>
>
>
> _______________________________________________
> BXXPwg mailing list
> BXXPwg@lists.invisible.net
> http://lists.invisible.net/mailman/listinfo/bxxpwg
>