Subject: RE: Inter-version compatibility

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 15 Mar 2001 05:13:26 -0500

The general comment is that inter-version compatibility is essential at the
ServiceChange stage to allow version negotiation.  That said, we could have
trouble if new stuff is added to the ServiceChangeDescriptor.  It may be we
should have rules which say that if the ServiceChangeDescriptor can be
parsed to the point where a version difference is noted, then version
negotiation should proceed regardless of whether the descriptor contains
unrecognizable material.
 
Niggling point: an entity doesn't "discard a message" if there's something
not understood: it executes all it can up to the command which has the
strange stuff in it.  That strange stuff won't necessarily generate a syntax
error: if it can be parsed but not recognized there are a few other error
codes that cover the situation.

-----Original Message-----
From: Paul Long [mailto:[email-masked]]
Sent: Monday, March 12, 2001 2:35 PM
To: megaco
Subject: RE: Inter-version compatibility

Tom,
 
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.

-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]]
Sent: Monday, March 12, 2001 9:59 AM
To: 'plong'; megaco
Subject: RE: Inter-version compatibility

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.