Subject: draft-hudson-spade-02

From: Greg Hudson <[email-masked]>
Date: Tue, 24 Aug 1999 17:31:05 -0400 (EDT)

In May, I submitted the first revision of an I-D on SPADE, which
describes a simple scheme for the wire-encoding of protocol data--in a
similar niche as XDR (SunRPC's data representation format) or
ASN.1/BER (the ISO's data representation format).  It is my view that
wire encoding is a fairly simple problem and should have a simple
solution.

Anyway, it's been a few months, and I've incorporated comments from a
number of people, so I think the draft is ready for publication as an
Experimental RFC.  Before I contact the RFC editor, though, I'd like
to solicit comments on this list.  The draft bears on essentially any
new application protocol where the wire encoding scheme is an open
question.

And at 13K, it's a pretty quick read.  For your convenience, the URL
is:

http://www.ietf.org/internet-drafts/draft-hudson-spade-02.txt

---

From: "Michael A. Dolan" <[email-masked]>
Date: Tue, 24 Aug 1999 15:32:29 -0700

Greg-

As long as you have a comparison section, it might be worthwhile 
noting CDR, due to its relatively widespread use.  It's very similar 
to XDR, so maybe you could easily cover them both in a single 
paragraph.

	Mike

>http://www.ietf.org/internet-drafts/draft-hudson-spade-02.txt

------------------------------------------------------
Michael A. Dolan, Representing DIRECTV,  (619)445-9070   
PO Box 1673 Alpine, CA 91903        FAX: (619)445-6122

---

From: "Michael A. Dolan" <[email-masked]>
Date: Tue, 24 Aug 1999 15:32:29 -0700

Greg-

	Mike

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 24 Aug 1999 19:02:01 -0400

A minor problem is that strings containing : won't work.

A more major, philosophical problem is that the major advantage of good
text protocols is that they are self-describing, in structure and field
names, and can be readily extended even without the syntax description.
For example, RFC 822/HTTP could be abstracted (save for some syntax
blunders such as WWW-Authenticate) as 

field ":" # ( value *(";" parname ["=" parvalue]))

Doesn't work well with more than two levels of "structure" nesting, but
handles the very common case of optional parameters and fields much more
gracefully.

The encoding also doesn't address what to do with very long lines.

At the very least, a Lisp-like grouping mechanism such as 

(par value) or (par (par value))

would allow additions of parameters and some human parsing, as well as
be tolerant of line folding. Once unions are introduced, this scheme
becomes basically unreadable and is very error-prone in terms of
skipping elements.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 24 Aug 1999 19:02:01 -0400

---

From: Greg Hudson <[email-masked]>
Date: Tue, 24 Aug 1999 20:52:41 EDT

An important theme here is that any choice of wire encoding involves a
lot of tradeoffs (compactness, readability, extensibility, generality,
etc.).  The designers of today's protocols have all made different
choices; for instance, SNMP has very little in common with SMTP, which
in turn has very little in common with DNS.  SPADE will definitely
look like a queer bird if you view it through the lens of one
particular kind of protocol, especially line-oriented protocols like
SMTP.  It is of course valid to say "I don't want to use SPADE because
I only want to develop line-oriented text protocols," just not, "my,
what an awful scheme for developing a line-oriented text protocol."

> A minor problem is that strings containing : won't work.

":" is the terminator for integers and symbols, not strings.  Symbols
are only intended for use when you're picking from a mostly-fixed set
of values, such as a protocol command set.  Strings (lists of bytes)
are counted, and are completely unrestricted in content.

> A more major, philosophical problem is that the major advantage of
> good text protocols

Certainly, a SPADE-based protocol doesn't qualify as a "text
protocol"; SPADE shares that property with XDR and ASN.1.  It's true
that the choice of integer encodings blurs the line a little bit, but
fundamentally a SPADE-based protocol shares more in common with binary
protocols than text protocols.

An underlying assumption behind SPADE is that a network protocol
should be a precise way of getting blobs of data from one side of the
wire to another.  You decide from the get-go where extensibility is
required, and you pick from various ways of getting it (header/value
lists or unions being two) depending on the situation.  The
"self-describing" nature of traditional text protocols has led to all
sorts of interoperability problems due to implementations not paying
careful attention to quoting and other corner-cases.

> The encoding also doesn't address what to do with very long lines.

It's not a line-oriented encoding.  There's nothing magical about the
newline character in a SPADE-based protocol.

> Once unions are introduced, this scheme becomes basically unreadable
> and is very error-prone in terms of skipping elements.

Error-prone in what way?

The integer encoding in SPADE is the one and only nod to readability;
it allows you to look at a network data dump for any SPADE protocol as
ASCII text, whereas an XDR-based protocol would really require a
presentation tool which knows the XDR types going over the wire.
Beyond that, I chose the compactness side of the tradeoff equation.

---

From: Greg Hudson <[email-masked]>
Date: Tue, 24 Aug 1999 20:52:41 EDT

Error-prone in what way?

---

From: Vijay Saraswat <[email-masked]>
Date: Wed, 25 Aug 1999 21:32:07 -0400

Greg ---

Apropos your comments about XML, check out Binary XML,

http://www1.wapforum.org/what/technical/SPEC-WBXML-19990616.pdf

Best,
Vijay

--
Try http://intercom.att.com!
Home-page: http://www.research.att.com/~vj

---

From: Vijay Saraswat <[email-masked]>
Date: Wed, 25 Aug 1999 21:32:07 -0400

Greg ---

Best,
Vijay

---

From: Greg Hudson <[email-masked]>
Date: Wed, 25 Aug 1999 23:47:44 EDT

> http://www1.wapforum.org/what/technical/SPEC-WBXML-19990616.pdf

Thanks for the pointer.  (Even if I never convince anybody to use
SPADE, I've certainly learned a lot about what other competing general
encoding schemes exist.)  Given that the referenced document still has
the status "this document is subject to change without notice," I
don't think it's currently appropriate to add a note about binary XML
in the SPADE draft.  But I will give a comparison here.

Binary XML makes essentially the same tradeoffs as regular XML with
one major difference: a binary-XML encoded document is much more
compact and much less readable than a regular XML document.  The
document naturally has the same structure as a regular XML document--a
tree of tagged strings with some embellishments--which I find
needlessly complicated.  (For example, why have "attributes" when
sub-elements can do the same job?)  And while a binary XML
implementation would seem to have fewer quoting issues to deal with
than a regular XML implementation, the encoding is not fully general
when it comes to strings; the character set is required to have a
termination value.  Yes, you can use an "opaque" if you have
deliberately decided that what you are encoding is binary 8-bit data,
but I don't see why the encoding should impose arbitrary restrictions
on "string," which is presumably intended for more common use.

I also find the amount of bit-hackery done in binary XML to be
distasteful.  It doesn't do as much bit-hacking as ASN.1/BER, but it
does a lot more than XDR or CDR or SPADE does, and it frequently does
bit-hacking just to save a byte here or there, not for some
overwhelming gain in efficiency.  But everyone has different
thresholds for bit-hackery, so I may not convince many people with
this argument.

Some minor nits:

	* The name mb_u_int32 is a little puzzling, since there is
	  nothing intrinsically 32 about it that I can tell.  I guess
	  it specifies a maximum range for those values, but if
	  there's an explicit statement to that effect, then I missed
	  it.

	* The WBXML version number is limited to 256 values (16 major
	  times 16 minor), for no particularly good reason.

---

From: Greg Hudson <[email-masked]>
Date: Wed, 25 Aug 1999 23:47:44 EDT

Some minor nits: