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

From: "Mark Watson" <[email-masked]>
Date: Wed, 6 Jun 2001 18:14:21 +0100

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

But this is not a good thing. Strictly speaking, if you can send things in
any order, it dramatically increases the number of test cases that you have
to run. Surely it's better to have a canonical encoding.

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

The ASN.1 Value Notation is effectively an ASCII Encoding Rules.

> 
> -----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]
> 
> 
> 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: Thu, 7 Jun 2001 11:39:33 +0100

RE: [sdp-ng] Encoding SDPng messages using UMFI think for small messages a canonical representation is probably better than a tagged version in which the parameters can be in any order.  However, as the complexity of the message set grows, after a point, (which is going to be a very fussy and personal point), errors introduced due to not getting exactly the right canonical order are more of a threat to your code than having parameters in any order.  And it's not really that big a problem because HTTP and in the most part SIP allow headers in any order, and they seem to work OK.  Also, having a fixed canonical order can be a problem for extensibility.  This is probably one reason that SDP has had such bad growing pains.

As for the ASN.1 value notation, I think there has to be some tweaks made to it before it can be used as an unambiguous text encoding.  I can't remember precisely where they are, but I think it might have something to do with the encoding of CHOICE, although they might have fixed that ambiguity.  I think ASN.1 has some merit, but I also think that there are other problems with it which point to making a fresh start, in much the same way that SDPng is looking again at SDP, SIP is looking again at H.323 etc.

Pete.

  ----- Original Message ----- 
  From: Mark Watson 
  To: [email-masked]' ; [email-masked] 
  Sent: 06 June 2001 18:14
  Subject: RE: [sdp-ng] Encoding SDPng messages using UMF

  > didn't see that in UMF.  Did I miss it? 

  But this is not a good thing. Strictly speaking, if you can send things in any order, it dramatically increases the number of test cases that you have to run. Surely it's better to have a canonical encoding.