Subject: RE: [BXXPwg] Updated strawman for BEEP protocol URIs

From: "Bob Wyman" <[email-masked]>
Date: Tue, 19 Jun 2001 11:17:39 -0400

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
[email-masked]
http://lists.invisible.net/mailman/listinfo/bxxpwg

---

From: "Dan Kohn" <[email-masked]>
Date: Tue, 19 Jun 2001 09:28:03 -0700

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:[email-masked]>
<http://www.dankohn.com/>  <tel:+1-650-327-2600>

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Bob Wyman
Sent: Tuesday, June 19, 2001 08:18
To: [email-masked]
Subject: RE: [BXXPwg] Updated strawman for BEEP protocol URIs

=============

---

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