Interoperability and Extensibility

[Pete Cordell]

Tom,

If you haven't had a chance to read it yet, I think my internet-draft covers
off a lot of the syntactic issues on messaging.
(Accessible at:
http://www.tech-know-ware.com/draft-cordell-messaging-00.txt)

On the semantics side, I like the SIP "Require:" construct.  This indicates
packages or parameters that must be understood.  Anything else is optional.
The transaction is cancelled if the server doesn't understand something that
is required.  It's essentially equivalent to 'comprehension required' in
Q.931 although its more expressive in what needs to be understood.  This is
a simple technique, but is actually very powerful.

Regards,

Pete

=============================================
Pete Cordell
pete at tech-know-ware.com
=============================================

-----Original Message-----
From: Tom-PT Taylor <taylor at NORTELNETWORKS.COM>
To: ITU-SG16 at MAILBAG.INTEL.COM <ITU-SG16 at MAILBAG.INTEL.COM>
Date: 24 June 1999 19:59
Subject: Interoperability and Extensibility


>We face a continuing tension between the requirement to ensure
>interoperability and the desirability of minimizing the size of the core
>protocol, particularly at the MG.  We also have to make sure our protocol
>has well-defined procedures for adding both ad hoc (i.e. proprietary or
>experimental) and formal extensions.   This note suggests some principles
>which we should follow in response to these considerations.
>
>There are really two levels of interoperability to deal with: syntactic
(can
>the message be parsed?) and semantic (can the message recipient perform the
>actions which the sender is requesting?).
>
>At the syntactic level, I believe that we can agree on these principles:
>
>I-1: Every message must be fully parsable down to a certain level of
detail,
>even if it contains extensions unsupported by the recipient.
>
>I-2: Our protocol document must specify the syntax by means of which
>extensions are identified.
>
>I-3: The protocol must provide the means for the recipient to identify in
>its response to any message all unsupported extensions it encountered in
>that message.
>
>There is an open issue here: what is the minimal parsability level we want
>to specify?  Suggestion: all messages are parsable down to the command and
>parameter level at a minimum.  Here I use the term "parameter" to imply
>either a simple data value or a potentially complex data structure
>identified as a syntactic element in our API definitions.  The implication
>of this suggestion is that extensions can add no new commands, no new
>command parameters, only new possible values for command parameters and new
>event packages.  I'm sure others will have comments on this.
>
>Now we get to the interesting part: semantic interoperability.  I'll start
>with what I hope are a couple of obvious statements.
>
>I-4: Not all implementations will support all event packages, all possible
>parameter values, or whatever else we allow to be extended.
>
>I-5: The protocol definition must include a specification of what the
>receiver does if a message contains an unsupported extension.
>
>On this latter point, do we enforce the transaction concept at all levels
>and fail the transaction, requiring the sender to reissue the command
>without the offending value?  This is definitely a workable solution.  We
>could go further and introduce the ability to say in a message whether a
>given field is a transaction-stopper, but I'm not sure that capability
would
>be used in practice  -- it wasn't when we had it in IPDC.
>
>Now for the crucial question: if I-4 is true, what criteria do we use to
say
>what features MUST be supported by any given implementation?  Can we
>distinguish between required support in MGC implementations, versus
required
>support in MG implementations?  How does each side of the Megaco interface
>determine what the other side supports, other than by parsing transaction
>rejections?  Here are some propositions to use as a basis for discussion:
>
>I-6: The Megaco/H.GCP specification should be organized into a basic
>protocol specification which must be satisfied by all implementations, plus
>annexes which are conditionally mandatory.  The conditions under which an
>annex is mandatory will be stated within the annex itself, to make it
>self-contained.
>
>Some annexes will constitute extensions of the protocol (e.g. event package
>specifications) and must therefore be identifiable as such at the syntactic
>level.  Other annexes may be more like profiles, stating, for example, what
>extensions must be supported by an MG or MGC which supports a given
>application.  An extension identifier for the complete profile is a
>"nice-to-have", but would be used only as shorthand in Audit responses, not
>in other commands.
>
>Looking to the future, extensions could be created:
>-- by joint Megaco/ITU action, added as new annexes to H.GCP
>-- by action of the ITU on its own, added as new annexes to H.GCP or as new
>Recommendations.
>-- by the IETF on its own, added as new RFCs
>In all cases, I suggest that the extensions be registered with IANA in
>accordance with procedures and criteria defined in the base protocol
>document.
>
>I-7: As a general principle in deciding what each implementation must
>support, MGs should be assumed to be more specialized than MGCs.  For
>example, we may decide (though I doubt it) that all MGCs must support all
>applications documented in the initial Megaco/H.GCP specification, but MGs
>may support an arbitrary subset of them.
>
>This is a debatable principle -- some vendors probably have a different
view
>of the architecture.  I suspect it is the consensus view, however.
>
>I-8: If at all possible, MGs should hide the details of national and
>regional variations in channel-associated signalling from the MGC.
>
>This is more debatable than I-7.  I propose it as a principle on the
grounds
>that MGs are more likely to be serving customers in only one country or
>region than are MGCs, so they will be the more logical point of
>specialization.  I have a concrete suggestion for our event packages which
>may help to support this principle: event descriptor syntax should include
>both the abstract event names and specialization identifiers which
indicate,
>for instance, that the MG should provide busy tone for Country A rather
than
>Country B to this particular termination.  That way the MGC can pass down
>information it has received from signalling, while the physical details are
>known only to the MG.
>
>
>
>
>
>
>Tom Taylor
>Advisor -- IPConnect Standards
>E-mail: taylor at nortelnetworks.com (internally, Tom-PT Taylor)
>Phone and FAX: +1 613 736 0961
>