Subject: RE: Inter-version compatibility

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 12 Mar 2001 10:58:30 -0500

First off, there is some advice in the document on rules to follow when
extending the protocol, courtesy Alf Heidemark.  That may help some.  Beyond
that, our version negotiation rules require the more advanced device to drop
back to the version used by the less advanced device, if possible.  ABNF has
no built in mechanism for extensibility, but people usually try to design
extensions such that the parser can isolate them and the application can
work with what it does understand. 

> -----Original Message-----
> From: Paul Long [mailto:[email-masked]]
> Sent: Monday, February 26, 2001 3:50 PM
> To: megaco
> Subject: Inter-version compatibility
> 
> 
> I come from the H.323 world where the ASN.1 message syntax is 
> inherently
> extensible, thus providing a valuable mechanism for 
> compatibility between
> different versions of the protocol. This same mechanism is 
> also available in
> the Megaco binary encoding, but how is this handled in the 
> Megaco ABNF text
> encoding? Specifically, what should I do as an implementor to 
> assure that my
> v1 MG will be forward compatible with, for example, a v2 MGC? 
> Or is version
> compatibility even a goal in Megaco (MG/MGC deployment will 
> be homogeneous
> with repect to version)? IOW, will the ABNF syntax ever 
> change? If so, how
> can my ABNF parser distinguish between an extension to the 
> syntax and a true
> encoding error?
> 
> Paul Long
> ipDialog, Inc.
> 
>

---

From: "Paul Long" <[email-masked]>
Date: Mon, 12 Mar 2001 13:35:16 -0600

RE: Inter-version compatibilityTom,

Thanks for your reply.

So what shall, should, or may a Megaco/H.248 entity do upon encountering an
encoding that does not follow the published ABNF? We currently treat it as a
syntax error (as opposed to a semantic error), discard the message, and
respond with an appropriate error descriptor. If we are not required to do
this, under what circumstances shall or should an entity "forgive" the
transgression and attempt to continue processing the message? At what point
in the syntax shall it resynch? On the transmitter side, if I have
"extended" the syntax, won't this cause non-deterministic behavior in the
receiving entity? IOW, how can I predict what the receiving entity will do
with my extensions?

Paul Long
ipDialog, Inc.