Subject: Washington Issue 21 - Version Incompatibilities

From: Brian Rosen <[email-masked]>
Date: Mon, 15 Nov 1999 16:32:43 -0500

A number of issues were raised in the Washington meeting that
were "send to the list".  This is one of these issues, with the
problem and my suggested fix.

Most of this text comes from a message from Nancy Greene

Problem:

What do you do when the MG and MGC differ in their versions?

We reference RFC2145 as the place that defines the meaning of
the major and minor version numbers. But we do not state
anywhere in the protocol what happens when an MG/MGC receives
a message with a higher version number than it supports.

Our options:
1) the entity receiving the msg returns an error "version not
supported". The other side must then resend the message with a
lower version number (how does it know how low to go?). Probably
need a way for the version to be negotiated or preprovisioned.

2) the entity notes the higher version number, but still tries to
parse the transactions in the message - when it encounters a
descriptor it does not support, it either a) ignores it or b)
sends an error msg with the actual descriptor it could not
understand in it.

Proposed Solution
2)b)

Brian

---

From: Harpreet Singh Anand <[email-masked]>
Date: Tue, 16 Nov 1999 15:59:36 +0530

Hello Brian,

> sends an error msg with the actual descriptor it could not

We should have a mix of both 1) and 2b), where the version gets negotiated at
the start of the association establishment. There were some discussions on this
topic earlier also and I am attaching the mail in which I had proposed the full
solution.

Please comment.

-------- Original Message --------
Subject: RE: versioning - was RE: MEGACO reserved names
   Date: Fri, 5 Nov 1999 09:50:52 -0500
   From: "Tom-PT Taylor" <[email-masked]>
     To: [email-masked], "Nancy-M Greene" <[email-masked]>
     CC: "'Pete Cordell'" <[email-masked]>,"[email-masked]'"
         <[email-masked]>,"[email-masked]'"
         <[email-masked]>,"Abdallah Rayhan" <[email-masked]>

I agree with this approach.  Trying to cope with different versions throughout
the duration of an established association doesn't feel like it is a very robust
solution.

     -----Original Message-----
     From:  Harpreet Singh Anand [SMTP:[email-masked]]
     Sent:  Friday, November 05, 1999 4:02 AM
     To:    Greene, Nancy-M [CAR:5N10:EXCH]
     Cc:    'Pete Cordell'; [email-masked]'; [email-masked]'; Rayhan,
     Abdallah [CAR:5N00:EXCH]; Taylor, Tom-PT [CAR:B904-I:EXCH]

     Subject:       Re: versioning - was RE: MEGACO reserved names
          Pete, I think this is a big issue. We reference RFC2145 as the place
          that defines the meaning of the major and minor version numbers. But
          we do not state anywhere in the protocol what happens when an MG/MGC
          receives a message with a higher version number than it supports.

          Our options:
          1) the entity receiving the msg returns an error "version not
          supported". The other side must then resend the message with a lower
          version number (how does it know how low to go?). Probably need a way
          for the version to be negotiated or preprovisioned.

     I have tried to outline a method which uses the existing protocol
     mechanisms to negotiate the version. Please comment.

     - The MG-MGC association is initiated by MG.

     - The first ServiceChange command from MG would contain the version number
     as supported by MG. On receiving such a message two scenarios can be there:

     A. MGC supports a higher version of protocol as compared to MG

     - If MGC has a support for the lower version, then
             - it sends the ServiceChangeReply with the lower version
             - thereafter, all the messages between MG and MGC would
               contain the lower version and would only use the IE as
               specified in the lower version of the protocol.

     - else
             - it rejects the association request giving reason as version not
     supported.

     B. MG supports higher version of protocol.

     - MGC on receiving a ServiceChange having a higher version would send back
     a ServiceChange indicating its own version. (here it is being assumed that
     MGC is able to parse the ServiceChange method as defined in the newer
     version, If while parsing ServiceChange command, MGC encounters some
     descriptors that it does not recognize, then it will ignore those
     descriptors).

     MGC after sending the reply can proceed assuming that MG would switch to a
     lower version. if MG can not then MG anyway initiates the clearingof the
     association (see below)

     - MG on receiving ServiceChange reply with the lower version can do the
     following:

     a) If it supports the lower version, then from that point it will work on
     the lower version, that is it will send messages with version id as the
     lower version and use only those IE that are defined in that lower version.

     b) If MG does not support the lower version, then it will clear the
     association by sending another ServiceChange to the MGC with
     ServiceChangeMethod as Forced and reason as "version not supported"

     To summarise:

     1.  In this way, an association gets established ONLY when both MG and MGC
     can talk the same version and the messages that flow then on will have the
     common denominator version no.

     2. An association is not established if the entity supporting higher
     version can not support the lower version indicated by the other entity. An
     alternative to this can be that the association gets established and the
     entity supporting the higher version keeps sending messages with the higher
     version id. The other entity behaves according to the option 2(b) as
     specified by Nancy.

          2) the entity notes the higher version number, but still tries to
          parse the transactions in the message - when it encounters a
          descriptor it does not support, it either a) ignores it or b) sends an
          error msg with the actual descriptor it could not understand in it.

          2)b) is probably what we want - any other opinions?

          Do we need a way to mark descriptors as mandatory or optional? I.E.
          mandatory for an entity to understand it? Our requirements document
          says this is necessary. This leads to this question: Do we need to
          cover the proxy/firewall case - where the firewall may not need to
          understand all packages/descriptors that are being passed through it?

          Nancy
          --------------------------------------------------------------------------

          Nancy M. Greene
          Internet & Service Provider Networks, Nortel Networks
          T:514-271-7221 (internal:ESN853-1077) E:[email-masked]

                  ----------
          From:Pete Cordell[SMTP:[email-masked]]
          Sent:Thursday, November 04, 1999 12:47 PM
          To: Greene, Nancy-M [CAR:5N10:EXCH]
          Subject:  Re: MEGACO reserved names

                  Nancy,

                  The usual is to ignore all new unknown parameters if not
          understood.  If this is not appropriate then support for the feature
          needs to be negotiated, or has to be marked as comprehension required
          in some way. You can have a higher version number indicating that
          certain new parameters need to be understood, but this seems to be
          less favoured.  For example an HTTP 1.1 request should be handled by
          an HTTP 1.0 server successfully without knowing about any fields added
          to 1.1.  Text in (at least one of) the HTTP specs describes what the
          significance of major and minor version numbers is in this respect.
          The SIP Require and Proxy-Require headers are quite a good way of
          specifying what support is required (although I think the inverted
          hierarchy they use is actually not helpful, and the standard additions
          should not have to be pre-pended with org.ietf - but that would be
          appended with ietf.org if the hierarchy was reversed).  Perhaps such a
          concept could be included in the service change message.  If you want
          such a feature, then V1 is really the time to include it as it is very
          necessary for a thing to understand what it means and it can't be
          ignored if not understood.  Unfortunately H.323 is a bit weak in this
          respect.

                  Pete

                  =============================================
          Pete Cordell
          [email-masked]
          =============================================
                       -----Original Message-----
               From: Nancy-M Greene < [email-masked]>
               To: [email-masked]' < [email-masked]>
               Date: 04 November 1999 15:44
               Subject: RE: MEGACO reserved names

                       Pete, you are right, that was the intention of X- - it is
               not well explained in the protocol document (a subject for
               another email coming up....). From what I understand, you extend
               the protocol in a standard way by creating version 2 of it, i.e.
               once an experimental parameter is agreed to be necessary, you
               create version 2. Each message in the ABNF has the protocol
               version on it, if your parser does not understand that version,
               it would say so, and the other side would resend the msg using a
               previous version of the protocol. Does the ASN.1 extension
               mechanism prevent this problem? It allows a parser to parse any
               version of the protocol, but the actual application still needs
               to know what to do with new fields.

                       Nancy
               --------------------------------------------------------------------------

               Nancy M. Greene
               Internet & Service Provider Networks, Nortel Networks
               T:514-271-7221 (internal:ESN853-1077)
               E:[email-masked]

                              ----------
               From:Pete Cordell[SMTP:[email-masked]]
               Sent:Tuesday, November 02, 1999 6:18 PM
               To:Greene, Nancy-M [CAR:5N10:EXCH]
               Subject:  Re: MEGACO reserved names

                              Ah, I assumed this was only for proprietary and
               experimental extensions as per other IETF protocols.

                       Pete

                              =============================================
               Pete Cordell
               [email-masked]
               =============================================
                                   -----Original Message-----
                    From: Nancy-M Greene < [email-masked]>
                    To: [email-masked] <
                    [email-masked]>
                    Date: 02 November 1999 19:53
                    Subject: Re: MEGACO reserved names

                                   The protocol is extendable. In the text
                    encoding of the protocol, you can extend the commands and
                    parameters by prefixing the new commands/parameters with
                    "X-".

                                   On the issue of Megaco reserved names - I
                    think we need to state in section 12 on Packages,  that the
                    PackageName part of the pkgdName MUST be present to qualify
                    the ItemID. If we do this then I think we are ok. We only
                    need to ensure that PackageName/ItemID (=pkgdName) is not a
                    Megaco reserved word, and since PackageName/ItemIDalways has
                    a "/" in it, and no Megaco reserved word has a slash, there
                    is no problem.

                                   Nancy
                    --------------------------------------------------------------------------

                    Nancy M. Greene
                    Internet & Service Provider Networks, Nortel Networks
                    T:514-271-7221 (internal:ESN853-1077)
                    E:[email-masked]

                                      ----------
                    From:Pete Cordell[SMTP:[email-masked]]
                    Sent:Tuesday, November 02, 1999 6:25 AM
                    To:[email-masked]
                    Subject:  Re: MEGACO reserved names

                                      A question...

                                      If the parsing of the protocol is
                    predicated on knowing what are reserved
                    words, surely that means that new reserved words can not be
                    added and hence
                    the protocol becomes un-extendable.  This sounds rather
                    dangerous to me.
                    But maybe I've missed something.

                                      Pete

                    =============================================
                    Pete Cordell
                    [email-masked]
                    =============================================

     --

     Regards,
     Harpreet

     _________________________________
     Harpreet Singh Anand
     Ficon Technology
     E-mail :  <mailto:[email-masked]>
     Web    :  <http://www.ficon-tech.com>

Regards,
Harpreet

_________________________________
Harpreet Singh Anand
Ficon Technology
E-mail :  mailto:[email-masked]
Web    :  http://www.ficon-tech.com

---

From: Abdallah Rayhan <[email-masked]>
Date: Tue, 16 Nov 1999 09:18:11 -0500

The fact that we still dont know how the lower and higher versions would

differ makes all solutions acceptable for the time being. Once we have
version 2, we can make a statement on how compatible should the higher
version should be in regard with the lower. Since this is an
implementation
issue, we could say that these are recommendations and we dont need to
negotiate it but preprovision it at the time of deployment.

Abdallah Rayhan

---

From: Christian Groves <[email-masked]>
Date: Wed, 17 Nov 1999 16:34:12 +0100

G'Day all,

I like Harpeet version handling method (as included below).

I also think some text like we have for the packages versioning should
be added as well describing principles for extending the protocol. ie.
backwards compatible changes.

Cheers, Christian

Harpeet's text---------------------------------------------------------

- The first ServiceChange command from MG would contain the version
number as supported by MG. On receiving such a message two scenarios can
be there:

     - MGC on receiving a ServiceChange having a higher version would
send back a ServiceChange indicating its own version.
     (here it is being assumed that MGC is able to parse the
ServiceChange method as defined in the newer version, If while parsing
     ServiceChange command, MGC encounters some descriptors that it does
not recognize, then it will ignore those descriptors).

     MGC after sending the reply can proceed assuming that MG would
switch to a lower version. if MG can not then MG anyway
     initiates the clearingof the association (see below)

     - MG on receiving ServiceChange reply with the lower version can do
the following:

     a) If it supports the lower version, then from that point it will
work on the lower version, that is it will send messages with version
     id as the lower version and use only those IE that are defined in
that lower version.

     b) If MG does not support the lower version, then it will clear the
association by sending another ServiceChange to the MGC with
     ServiceChangeMethod as Forced and reason as "version not supported"
------------------------------------------------------------------------

---

From: Abdallah Rayhan <[email-masked]>
Date: Fri, 19 Nov 1999 10:46:27 -0500

Should this be in the main document or in a separate I-D ?
If it is ought to happen, a separate I-D might be the way to go
since this seems to be an important issue that will be addressed for
all old and future releases of MEGACO.

Abdallah Rayhan