[BXXPwg] Updated strawman for BEEP protocol URIs

Gabe Wachob gwachob@wachob.com
Tue, 19 Jun 2001 09:39:27 -0700 (PDT)


Specifically, here's the most pertinent snippet:

(a Perlish regular expression for parsing URI's):

      ^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?
       12            3  4          5       6  7        8 9

   The numbers in the second line above are only to assist readability;
   they indicate the reference points for each subexpression (i.e., each
   paired parenthesis).  We refer to the value matched for subexpression
   <n> as $<n>.  For example, matching the above expression to

   http://www.ics.uci.edu/pub/ietf/uri/#Related

   results in the following  subexpression matches:

      $1 = http:
      $2 = http
      $3 = //www.ics.uci.edu
      $4 = www.ics.uci.edu
      $5 = /pub/ietf/uri/
      $6 = <undefined>
      $7 = <undefined>
      $8 = #Related
      $9 = Related

   where <undefined> indicates that the component is not present, as is
   the case for the query component in the above example.  Therefore, we
   can determine the value of the four components and fragment as

      scheme    = $2
      authority = $4
      path      = $5
      query     = $7
      fragment  = $9


	-Gabe

On Tue, 19 Jun 2001, Dan Kohn wrote:

> The Elvin scheme breaks all of the relative URL parsing code that is in
> wide use today (see RFC 2396 sections 5.2 & Appendices B & C) but gives
> no advantages.  It does not seem like a model.
>
> 		- dan
> --
> Dan Kohn <mailto:dan@dankohn.com>
> <http://www.dankohn.com/>  <tel:+1-650-327-2600>
>
> -----Original Message-----
> From: bxxpwg-admin@lists.invisibleworlds.com
> [mailto:bxxpwg-admin@lists.invisibleworlds.com] On Behalf Of Bob Wyman
> Sent: Tuesday, June 19, 2001 08:18
> To: bxxpwg@lists.invisibleworlds.com
> Subject: RE: [BXXPwg] Updated strawman for BEEP protocol URIs
>
>
> I thought it might be useful to provide an example of how another system
> (Elvin) has addressed the issues being discussed here. Elvin produces
> URL's that follow the pattern:
>     elvin:/protocol/endpoint-specification
> An example Elvin URL might look like:
>     elvin:/tcp,ssl,xdr/machine.domain.com:1234;property=value
> The "protocol" element distinguishs between transport, security and
> marshalling bindings.
>
> Note: I'm providing this for information. I don't explicitly endorse
> what they are doing...
>
> The following more detailed discussion of the Elvin URL scheme is taken
> from:
>     http://elvin.dstc.edu.au/doc/guides/elvin-admin.html#SEC8
>
> =============
> The Elvin router (@command{elvind}) accepts connections from client
> programs using one or more offered protocol stacks. A protocol stack is
> constructed from the available network transport, security and data
> marshalling modules, and exported by the @command{elvind} process.
>
> Elvin clients identify the server and protocol with which they connect
> using a uniform resource locator (URL). The URLs contain the information
> needs by the client libraries to contact the @command{elvind} process.
>
> An example of such an URL follows:
>
>    elvin:/tcp,none,xdr/server.example.com:2917
>
> Breaking that example URL into its components, we have
>
>    elvin:/protocol/endpoint-specification
>
> The elvin is the scheme name, which distinguishes Elvin URLs from those
> of other schemes, like http, for example.
>
> Next is the protocol, which describes the protocol stack to be used. In
> the example, we are using a TCP transport, no security, and an XDR
> (External Data Representation) marshalling layer. The protocol field may
> be empty which implies the default elvin protocol of tcp,none,xdr.
>
> Next is the endpoint specification, which provides protocol-level
> connection information. This field is specific to the protocol stack. In
> this example, the server.example.com identifies a particular host
> machine, and the 2917 specifies a TCP port number.
>
> When used in the server configuration file, the special host field
> 0.0.0.0 can be used in an endpoint specification to mean all interfaces
> on the machine.
>
> Note that this is the standard Elvin protocol and uses Elvin's IANA
> allocated port for Elvin client to server communication.
>
> An example using a different protocol is:
>
>    elvin:/unix,none,xdr/server.example.com/tmp/elvin
>
> Here the protocol used is unix, for Unix domain sockets which are useful
> for clients connected on the same machine. The endpoint specification
> specifies the machine and the path of the Unix domain socket,
> /tmp/elvin.
>
> _______________________________________________
> BXXPwg mailing list
> BXXPwg@lists.invisible.net
> http://lists.invisible.net/mailman/listinfo/bxxpwg
>
>
> _______________________________________________
> BXXPwg mailing list
> BXXPwg@lists.invisible.net
> http://lists.invisible.net/mailman/listinfo/bxxpwg
>