Subject: [Megaco] X+/X- extensionParameters in Megaco are not properly def ined

From: Nigel Williams <[email-masked]>
Date: Wed, 26 Jun 2002 08:17:57 +0100

Hello list,

This post concerns the absence of a full definition of the
extensionParameters X+/X- in Megaco.  My reading of RFC3015 is that there
are four places in a Megaco message where the X+/X- notation can appear.
These are as follows.

1. As a ServiceChangeDescriptor property, for example: ServiceChange = ROOT
{Services{Reason = 903, X-TEST = TESTVAL}}.

2. As a MuxDescriptor value, for example Mux = X+TEST{term1, term2, term3}.

3. As a ModemDescriptor value, for example Modem = X-MOD{<modem
parameters>}.

4. As a ServiceChangeMethod value, for example Method = X-SHUTOFF.

Although the X+/X- syntax is given in the ABNF and the ASN.1, RFC3015 does
not appear to specify the semantics of the X+/X- extension parameters.  Nor
is this rectified in the later corrections to RFC3015.  The closest the
specification comes to an explanation is in section 7.2.8, as follows.

- The value of the ServiceChangeMethod property may be "7) Another value
whose meaning is mutually understood between the MG and the MGC".

- In addition to the properties of the ServiceChangeDescriptor already
defined, "the optional Extension parameter may contain any value whose
meaning is mutually understood by the MG and MGC."

Taken at face value this suggests that unless the extension is mutually
understood, it should not be used at all.  However, the specification is
clearly incomplete, and this literal reading would leave no place for the X-
notation at all.  Therefore it would make sense to extend the specification
of X+/X- in the MGCP protocol to Megaco.

RFC2705, section 3.2.2 sets out the use of X+ and X- in the MGCP protocol.
The following is the relevant part of the text.

   If implementers need to experiment with new parameters, for example
   when developing a new application of MGCP, they should identify these
   parameters by names that start with the string "X-" or "X+", such as
   for example:

             X-FlowerOfTheDay: Daisy

   Parameter names that start with "X+" are critical parameter
   extensions.  An MGCP entity that receives a critical parameter
   extension that it cannot understand should refuse to execute the
   command.  It should respond with an error code 511 (Unrecognized
   extension).

   Parameter names that start with "X-" are non critical parameter
   extensions. An MGCP entity that receives a non critical parameter
   extension that it cannot understand can safely ignore that parameter.

I propose that this scheme be extended to Megaco as well, with the use of
the X+/X- restricted to the locations specified in RFC3015.  Does anyone
have any comments or suggestions on this issue or my proposed solution?

Thanks
Nigel

Nigel Williams
Voice Networking Group
Data Connection Ltd
Tel: +44 20 8366 1177
Fax: +44 20 8363 1039
Email: [email-masked]
Web: http://www.dataconnection.com

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 27 Jun 2002 11:29:20 -0400

Aah, I believe what we have here is a bug in the ABNF.
All extension parameters except ServiceChangeDescriptor
should have been flushed.  The reasons are:
	X-Parameters often turn into real parameters
		later on, and the early adopters don't
		want to change the name
	Two implementations who negotiate versions and
		profiles know what the other can do; any
		private extension can have any name they
		want.  Sort of by the definition of a profile,
		you can't have name collision
Most new protocols don't specify X- thingies any more,
for these and other reasons.  As I recall, we left
X- in ServiceChangeDescriptor because you haven't
negotiated profile when you need this.

Brian

> -----Original Message-----
> From: Nigel Williams [mailto:[email-masked]]
> Sent: Wednesday, June 26, 2002 3:18 AM
> To: [email-masked]'
> Subject: [Megaco] X+/X- extensionParameters in Megaco are not properly
> def ined
> 
> 
> Hello list,
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 27 Jun 2002 11:29:20 -0400

Brian