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

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

My guess is people don't think of XDR because it's "old" and they don't think of ASN.1 because it's "from the ITU-T".

ASN.1 is extensible [good], but you have to specify where extensions can be before you do an extension [very bad].

One thing that ASN.1 and tagged protocols (e.g., keyword/value or XML tags) in general have is the ability to send and receive the information elements in any order.  I didn't see that in UMF.  Did I miss it?

BTW: I'm not advocating we use ASN.1 for SDPng.  This is because I would much prefer to use a tagged protocol.  However, if the consensus is that we want to go with an IDL/structured protocol, I would propose we consider adopting an existing specification language.

NOTE: I've never seen "AER" (ASCII Encoding Rules) for ASN.1.  However, it would be straight-forward to do.  I really, really DON'T want to use ASN.1 with BER or PER!

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

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.

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

---

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

Eric,

It wasn't clearly stated, but once you have got passed the untagged section
in a construct, you can put the parameters in any order you like.  As a
protocol designer you can decide whether you use untagged values, long tags,
short tags whatever.

In terms of ASN.1 encodings, some work was done about two years ago on XER -
XML encoding rules.  It's quite easy to do that for the basic stuff, but
might be trickier once you start working on Information Object Classes etc.
I don't know whether it ever got finished.

Pete.

----- Original Message -----
From: Eric Burger <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: 05 June 2001 14:33
Subject: RE: [sdp-ng] Encoding SDPng messages using UMF

> My guess is people don't think of XDR because it's "old" and they don't
think of ASN.1 because it's "from the ITU-T".
>
> ASN.1 is extensible [good], but you have to specify where extensions can
be before you do an extension [very bad].
>
> One thing that ASN.1 and tagged protocols (e.g., keyword/value or XML
tags) in general have is the ability to send and receive the information
elements in any order.  I didn't see that in UMF.  Did I miss it?
>
> BTW: I'm not advocating we use ASN.1 for SDPng.  This is because I would
much prefer to use a tagged protocol.  However, if the consensus is that we
want to go with an IDL/structured protocol, I would propose we consider
adopting an existing specification language.
>
> NOTE: I've never seen "AER" (ASCII Encoding Rules) for ASN.1.  However, it
would be straight-forward to do.  I really, really DON'T want to use ASN.1
with BER or PER!
> Subject: Re: [sdp-ng] Encoding SDPng messages using UMF
... cut ...