Subject: Encoding SDPng messages using UMF

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

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
=============================================

---

From: "Dr. Carsten Bormann" <[email-masked]>
Date: Tue, 5 Jun 2001 14:18:42 +0200

Pete,

I don't want to offend you, but Syntax discussions are fun because

-- everybody can contribute (if they can write characters on paper)

-- the supply of different variants and new ideas is infinite

-- there is no clear win for anything, so you can continue discussing
forever

Having been part of this since the early 80s (CLPT, anyone?), I (literally)
desperately don't care.

If the world out there wants XML, let them have it.  XML is good enough.
More precisely:
It is neither significantly better nor significantly worse that anything I'd
come up with.
Maybe by a factor of two or three or so, but the time to market lost by
restarting the discussion outweighs this easily.

Let's stick to XML.

Gruesse, Carsten

(PS.: In a back room somewhere, you can tell me about UMF.  I'm interested.
Maybe we can derail the XML bandwagon.
Let's just try to not have SDPng or anything else that matters be part of
the trainwreck.)

---

From: "Pete Cordell" <[email-masked]>
Date: Tue, 5 Jun 2001 18:43:06 +0100

Carsten,

No offence taken, as I think what you say can be said about most protocol
development work as well!!!  And while it is easy to do something simple in
this area, to get something useful actually requires quite a deep
understanding of trade offs before the best option becomes clear.  I
certainly don't see that we are falling over good message definition
solutions here.

In terms of time to market, as far as I can see, SDPng has no defined
syntax.  SDPng can easily switch to UMF without any loss in time (and
probably some gain) by defining UMF in the SDPng document in much the same
way that SMTP defines EBNF.  That gives the world a chance to see whether it
has any merit before putting a whole load of procedure behind its
development.

Pete.

----- Original Message -----
From: Dr. Carsten Bormann <[email-masked]>
To: Pete Cordell <[email-masked]>; Dirk Kutscher
<[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: 05 June 2001 13:18
Subject: RE: Encoding SDPng messages using UMF

---

From: Jeff Ayars <[email-masked]>
Date: Tue, 05 Jun 2001 12:47:18 -0700

XML may not be the most efficient syntax from a bytes used perspective but 
it is regular and WIDELY understood.  Compression a-la zlib in RFC 2974 for 
SDP compression in SAP or WAP Binary XML representation should be 
considered for byte efficiency.

XSL solves the data type problem in another existing standard way.

I already have an XML parser in my product.  YAPS (Yet Another Protocol 
Syntax) == YAPP (Yet another protocol parser).  I don't want to bloat my 
product with YAPP.

JEff

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 06 Jun 2001 05:04:55 -0700

> XSL solves the data type problem in another existing standard way.

I assume you mean (at least also) XML schemas, as XSL is a
transformation language (*). (But XSL is a good example of the power of
using a widely used mechanism rather than inventing your own. For
example, we were able to create XSL which automatically renders CPL
scripts as a tree in HTML. I suspect that something similar would be
useful for SDPng.)

(*) "XML Schemas express shared vocabularies and allow machines to carry
out rules made by people. They provide a means for defining the
structure, content and semantics of XML documents."

> Syntax) == YAPP (Yet another protocol parser).  I don't want to bloat my

Particularly since other pieces of a multimedia component already need
XML, such as event descriptions.

---

From: "Pete Cordell" <[email-masked]>
Date: Wed, 6 Jun 2001 10:13:07 +0100

Jeff,

I'm afraid I don't really buy the compression argument.  If size is
important to you than you are prepared to use compression, then you can
compress any protocol, including UMF.  I would rather start off with a
smaller encoding and avoid the extra step.  Indeed, compression seems to
defeat one of the advantages of text encoding, and that's easy sniffing and
viewing of messages on the wire.  After all, a compressed encoding is
effectively a binary encoding.

As for XSL, I think we should try and get some practical experience with it
as a sort of feasibility study ASAP.  I don't think it is going to be as
easy to use as it might first appear.  If Dirk has then, it would be good to
see them so that I can attempt to do a UMF equivalent.  It would be good to
know what the tools status is for it also.

Also, an XSL parser is likely to be something in addition to an XML parser.
Therefore having an XSL parser extension plus an XML parser is likely to be
no better than having an XML parser plus a UMF parser.  After all, XSL =
YAPS also.

Pete.

----- Original Message -----
From: Jeff Ayars <[email-masked]>
To: Pete Cordell <[email-masked]>; Dr. Carsten Bormann
<[email-masked]>; Dirk Kutscher <[email-masked]>;
<[email-masked]>
Cc: <[email-masked]>
Sent: 05 June 2001 20:47
Subject: Re: Encoding SDPng messages using UMF

---

From: "Pete Cordell" <[email-masked]>
Date: Thu, 7 Jun 2001 17:24:58 +0100

Henning,

Are those CPL event descriptors you are talking about?  If not, which ones
do you mean?

Pete.

P.S.  I've chopped off sdp-ng and a number of personal e-mails in this reply
to try and cut down the number of messages that end up on the various lists.
Please let me know if this was a bad move.

----- Original Message -----
From: Henning Schulzrinne <[email-masked]>
To: Jeff Ayars <[email-masked]>
Cc: Pete Cordell <[email-masked]>; Dr. Carsten Bormann
<[email-masked]>; Dirk Kutscher <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: 06 June 2001 13:04
Subject: Re: Encoding SDPng messages using UMF

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 07 Jun 2001 12:35:13 -0700

> Are those CPL event descriptors you are talking about?  If not, which ones

I'm talking about the Call Processing Language, the iptel work item for
IP telephony call handling, which is an XML DTD. A student here
developed a nice XSL script (or whatever you call them) that renders any
valid CPL script as an HTML page, showing the tree structure of the
nodes and various other features.

---

From: "Pete Cordell" <[email-masked]>
Date: Sat, 9 Jun 2001 11:59:40 +0100

Henning,

While this is a neat trick, do you think that it is anything more than a
techie gizmo?  i.e. do you think it will actually be useful as a commercial
tool accessed by Joe - oh dear my mouse has reached the end of the mouse
pad* - Public?  I would imagine that SDPng is going to be of even less
interest to Joe Public than CPL.  If tech support did want to see it, they
could just put it in an HTML <pre></pre> section, or just output it as
text/plain.

Pete.

* Dogbert computer support recommends re-booting if this happens!!!