[elvin-discuss] Elvin URI spec questions

David Arnold davida at pobox.com
Wed Feb 21 03:04:18 CST 2007

-->"Matt" == Matthew Phillips <matt at mattp.name> writes:

hi Matt,

sorry about the delay in responding ... :-(

  Matt> just writing a parser for Elvin URI's and noticed what
  Matt> seems like an inconsistency in the protocol spec. The default
  Matt> protocol stack defined in 5.1.2 is:

  Matt>    tcp,none,xdr

  Matt> while the "secure" stack is:

  Matt>    ssl,none,xdr

  Matt> I'm assuming, if the (transport,security,marshalling) ordering
  Matt> matters, that this should be "tcp,ssl,xdr"?

you've just stumbled over the first of several problems with the Elvin
URL scheme as it is implemented today.

it's reasonable to implement SSL as a transparent encryption layer over
any underlying transport.  but ... in Mantara's implementation, the
'ssl' protocol is a transport that uses SSL over TCP.

there are no existing security modules.

  Matt> The spec doesn't actually nail down the
  Matt> (transport,security,marshalling) structure, so I'm just
  Matt> guessing, but this seems to be what all the client accept.

going forward, we tend to talk about the n-layer stack.

there are several types of modules:

- one that takes a packet structure/object, and converts it to an array
  of bytes and vice versa.  this is what the current Mantara 'xdr' and
  'xml' modules do, and could reasonably be called 'marshalling'.

- one that takes an array of bytes and gives an array of bytes.  for
  instance, doing encryption or compression.

- one that writes and reads arrays of bytes to and from the network.
  this is what the current 'tcp', 'udp', 'ssl', and 'unix' modules do,
  and we've always called 'transport'.

- a final possiblity is a module that takes a packet structure/object,
  modifies it, and passes it on.  i haven't yet come up with a good
  reason for doing this in the protocol stack, but it might be
  reasonable for something?

a protocol *stack* must put and get packet structure/objects onto the
network.  this could require a single combined module, or a stack like
/tcp,aes,gzip,xdr/ (for instance).

what's missing at elvin.org is the spec for what each of the module
names means.  eg. if a URL includes 'tcp', what exactly should be done
to interpret that data?  there's skeletons in CVS, but no useful

the URL spec should support stacks of 1..N of these modules, so long as
the interfaces between them match up.

it'd be totally reasonable to define an 'ssl2' or 'ssl-enc' or something
which means SSL over any underlying transport, but until now, it hasn't
been a priority.

hope this helps ...


More information about the elvin-discuss mailing list