Subject: RE: [sdp-ng] Encoding SDPng messages using UMF

From: Eric Burger <[email-masked]>
Date: Tue, 5 Jun 2001 12:05:00 GMT

How is this different from ASN.1 with an ASCII, instead of binary, generator?

Why invent YAPS [Yet Another Protocol Specification language], when we've got three already?

-----Original Message-----
From: Pete Cordell [mailto:[email-masked]]
Sent: Tuesday, June 05, 2001 8:03 AM
To: Dirk Kutscher; [email-masked]
Cc: [email-masked]
Subject: [sdp-ng] Encoding SDPng messages using UMF

Dear Dirk, and other SDPng Developers,

Like many I have been concerned about the size of SDPng messages that might
result as a consequence of using XML.  My other concern about XML has been
that it is not clear on the data types that parameters have.  Although
schemas are an attempt to fix this, this seems to add yet more verbosity to
the message definition.  I feel that this verbosity is an issue because it
makes it time consuming to define parameters accurately,  which can lead to
people making silly mistakes, and all the key words hide the true content of
the messages.

I would therefore like to bring to your attention some work that I have been
doing for the last 3 or 4 years.  It defines messages using a modified C (or
if you prefer XDR) syntax, which is represented on the wire using text.
Some of this work has been guided by trying model the Megaco protocol, which
is really quite a compact protocol.  In particular, in a number of cases
parameters have no tags.  Surprisingly to people involved in the development
process this results in a clearer protocol than one that has tags all over
the place.

The scheme is designed from the outset to support extensibility, and allows
external profiles to be plugged, which sounds ideal for SDPng.

I've called the scheme UMF (for Universal Message Format - might as well
think big!).  It is (fairly) fully defined in the internet draft:

  http://www.ietf.org/internet-drafts/draft-cordell-mmusic-umf-00.txt

I have also developed a small tool kit that facilitates reading the
messages.  This is available at:

  http://www.tech-know-ware.com/umflib

Over time I hope to add a few more tools, including a syntax checker, and a
converter to ABNF (both of which are nearly there).

To save reading the draft(!), this is how it works in a nutshell.

Messages are defined in a C like way, except that types can have additional
constraints, and they can have a cardinality range rather than a fixed
cardinality as C effectively does.  You can also specify an explicit tag for
a parameter, including explicitly specifying that no tag is used.

A resultant definition might therefore look something like:

  module example
  struct example
  {
    unquoted-ascii<1..64>   protocol as ?;
    int <0..65535>          ports[0..*] as p;
    ipv4addr                proxies[0..*];
  };

This off the top of my head example specifies the ports and proxies that a
particular protocol should use.  The protocol is specified as unquoted ASCII
text that can be between 1 and 64 characters long.  The as ? indicates that
this parameter has no tag on the wire.

The second definition in the struct defines a ports parameter.  This is
represented by an integer in the range 0 to 65535, as indicated by
<0..65535>.  There may be zero or more instances of this parameter as
indicated by [0..*].  The parameter is tagged by 'p' on the wire.

The third parameter is the address of any proxies that should be used.
Again this can occur zero or more times.  As there is no explicitly defined
tag, the parameter is tagged by 'proxies' on the wire.

Valid encoding of this definition would be:

  HTTP

or:

  HTTP p=80, 8080

(or:

  HTTP p=80 p=8080
)

or:

  HTTP p=80 proxies=10.0.0.1, 10.0.0.2

For me this is a very practical solution for message definition, and I think
SDPng would benefit greatly from it.  I think that this is especially the
case with mobile devices becoming more main stream.  It may also be that
SCCP may benefit from it also.

I look forward to any comments you might have.

Regards,

Pete.

=============================================
Pete Cordell
Tech-Know-Ware
[email-masked]
+44 1473 635863
=============================================

To unsubscribe from this group, send an email to:
[email-masked]

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

---

From: "Pete Cordell" <[email-masked]>
Date: Tue, 5 Jun 2001 13:51:21 +0100

Eric,

That's a good question.

I think the main problem with ASN.1 is that the initial versions were
developed without taking enough of the extensibility issues into
consideration.  The addition of information object classes is so complex as
to defy comprehension in my opinion.  I really don't think that someone
should have to put that much effort into understanding something that only
features as a very small part in the development process.

UMF allows plugging in of additional syntax models with minimal complexity.
You could do:

  module my-addition
  extends example;
  plug
     bool      uses-tls;
  into example;

in a separate definition to extend what was described before.

As for other protocol specification languages, I can think of XDR, xBNF, XML
and there's probably a whole bunch of IDLs.

To me, the short answer is, the fact that people are looking to XML to solve
there problems indicates that this area isn't totally sown up.

The longer answer is:

XDR is quite low level, and not as expressive as it could be, although in
some respect UMF is an extension of XDR, minus some stuff that doesn't
really actually convey any more information in the definition than is
already defined elsewhere.

xBNF is too low level.  It's like working in machine code all the time.
It's also extremely time consuming and error prone to get a definition
correct.  The essence of a protocol can also get lost in the detail.
There's also quite a lot of handle turning to convert this into useable
code.

XML initially doesn't have any type information, which seems bad for a
message definition language.  Schemas are fixing that, but the verbosity of
specifying all that again mean the message of the message definition gets
lost in the syntax fluff.  (It would actually be better to define a message
in UMF and then automate the conversion to XML Schema using tools, as your
much more likely to get an error free definition that way.)

In summary, except for ASN.1 (and XDR) I don't think there are really any
protocol definition languages.  All the other examples have been high jacked
from the problem domains that they were originally developed for.  The
result is that they aren't particularly a good match for the problem space.
The fact that ASN.1 or XDR are not the first thing people rush to when
defining protocols suggests that there is room for improvement.

Pete.