Subject: Re: Extension of commands / parameters (was Re: MEGACO reserved n ames)

From: Nancy-M Greene <[email-masked]>
Date: Thu, 4 Nov 1999 15:42:20 -0500

First, let's be clear what X- is to be used for. It is for experimental
extensions and for proprietary use (although the protocol document actually
says nothing on them...). Abdallah pointed out to me that the current ABNF
does not allow X- to extend commands, so my statement below is wrong... X-
is ONLY used to extend parameters to certain descriptors:

mediaDescriptor has no extension mechanism
modemDescriptor has,
muxDescriptor has,
eventsDescriptor has,
signalsDescriptor does not have,
digitMapDescriptor is extendable by virtue
auditDescriptor is not.
packagesDescriptor is not,
observedEventsDescriptor is not.

But perhaps the descriptors that are not extendable do not need to be - any
opinions?

X- is NOT currently allowed to mark a packageName as experimental ("-" is
currently not allowed in PackageName), 

X- is NOT allowed to to be used to add a new experimental command to the
protocol, and 

X-  is NOT allowed to be used to add a new experimental descriptor to the
protocol. 

Do we have a need for any of these? I would say we do have a need to allow
expermental descriptors to be added - for example, a script descriptor...,
until it gets folded into v2 of the protocol.

Just to put things in perspective....: a quote from our requirements
document:

Section 8. General Protocol requirements:
i.   Specify commands as optional (they can be ignored) or mandatory
     (the command must be rejected), and within a command, to specify
     parameters as optional (they can be ignored) or mandatory (the com-
     mand must be rejected).

- Megaco/H.248 does have a way to mark a command as optional (O-)

- through the use of Packages, certain properties, all signals and events,
and all statistics are all optional, depending on whether you support a
package or not

- we may have a problem with descriptors - we do NOT have a way to mark a
descriptor as optional or mandatory. We could do this by allowing X- to
qualify an experimental/proprietary descriptor that can be ignored, and
using X+ to qualify one that cannot be ignored. 

And to cover the case when experimental descriptors are folded into a new
version, we probably need text in THIS version of the protocol that says
what an older version is to do with descriptors it does not recognize -
ignore them or flag them as an error/not understood.

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

> ----------
> From:         Harpreet Singh Anand[SMTP:[email-masked]]
> Sent:         Thursday, November 04, 1999 3:44 AM
> To:   [email-masked]
> Subject:      Extension of commands / parameters (was Re: MEGACO reserved
> names)
> 
>   
> Nancy, 
> 
>       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-".
> 
> In v12, there is no mention of extension of commands. The text encoding
> allows extension of only the following: 
> 
> - muxType 
> - requestedAction 
> - modemType 
> - ServiceChangeParam 
> - ServiceChangeMethod 
> - StatisticsParameter 
> 
> Is there any other paramter / command that can be extended ? 
> 
> Thanks and Regards, 
> Harpreet 
>

---

From: Harpreet Singh Anand <[email-masked]>
Date: Fri, 5 Nov 1999 14:57:25 +0530

> X- is ONLY used to extend parameters to certain descriptors:
>

adding to this list, ServiceChangeDescriptor is also extensible.

> But perhaps the descriptors that are not extendable do not need to be - any

If we allow experimental descriptors to be added, then we should also have
methods for extending auditDescriptor.

> until it gets folded into v2 of the protocol.

Agreed, we should allow support for experimental descriptors and experimental
commands also. And we should put this in v1 of the protocol.

Regards,
Harpreet

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

---

From: Abdallah Rayhan <[email-masked]>
Date: Fri, 5 Nov 1999 09:10:21 -0500

This is an interesting issue. But before we get carried away and start
shooting
in the dark, we need to envision what V2 would look like and therefore
allow
for a window of change in V1. Further more, we need to understand
what compatibility between the two versions means !

The issues that could carry change between the two would be,

1- Header format: the message header
2- Syntax : things like x=y{z,z,z}, and x{z,z,z}, digitmap, etc...
3- Protocol structure: new commands
4- New Descriptors: context descriptors, script descriptors, templates,
etc...
5- Extra parameters: related to various packages, signals and events

Now, the questions become which of those would most probably witness
change ? and how should an older version deal with such change ? for
example,
ignore what you can not understand and try to make sense of what you
understand, or plain reject the whole if something is out of line.

Because we still dont know what V2 is, whatever we come up with serve
as guidelines and when worst comes to worse, the message/transaction
would be reject due to incompatible supported version.

Abdallah Rayhan

Harpreet Singh Anand wrote:

> Agreed, we should allow support for experimental descriptors and
> experimental commands also. And we should put this in v1 of the
> protocol.