Subject: MEGACOHGCP10: Clarifications + Editorial corrections/comments

From: Harpreet Singh Anand <[email-masked]>
Date: Wed, 15 Sep 1999 17:55:46 +0530

Hello Brian,

I have a few questions on MEGACO/HGCP10 :

1. Topology Descriptor: The position of topology descriptor is not clear in the
document - is it a parameter to a command or is it a context property (which is
not a part of a message) ? In section 7.1.16, it has been mentioned that the
Topology descriptor can be a part of Add or Modify command message, but the ABNF
specification puts it at the level of command list, in fact the way ABNF defines
a topology descriptor can be specified without specifying the command message.

actionRequest = CtxToken EQUAL ContextID LBRKT ((contextProperties COMMA
commandList) | contextProperties | commandList ) RBRKT

contextProperties = contextProperty *(COMMA contextProperty)
; at-most-once

contextProperty = topologyDescriptor ; | bridgeDescriptor

Please comment ?

2. Since the Subtract command always returns Statistics in the response message,
the StatisticsDescriptor should be marked as mandatory in the response to
Subtract command (sec 7.2.3).

3. What is the need of sending StatisticsDescriptor and ObservedEventsDescriptor
in AuditCapabilities Response message ? These descriptors describe activity
rather than a capability.

4. What does the profile parameter in ServiceChange Descriptor represent ? How
is to be used by MG / MGC ?

Editorial corrections/comments:

1. The text in section 6.2.4 says that the table lists *all* of the possible
descriptors, but the table is not complete. The missing descriptors being -
Topology, TerminalState, Stream, Local Control, Local, Remote.

2. Package Descriptor is missing from the list of descriptors that can be sent
in RequestedInfo Descriptor (sec 7.1.12)

3. There is no description for 'Packages', 'Observed Events' and 'Extension'
descriptor.

4. In the package definition (section 12) description, bullet 3 and 4.
PropertyID to be replaced by ParameterId.

Regards,
Harpreet

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

---

From: Brian Rosen <[email-masked]>
Date: Thu, 16 Sep 1999 15:33:01 -0400

I'm not in favor of making this change.  I think the one
character tokens for the common cases makes a lot of sense.
The code that does table lookup including length is really
trivial, so I don't think it is any kind of burden that
a match must be the right length as well as the right characters.  In my
experience symbol table lookups that
check length first are significantly faster than those that start with
character by character matching.

I especially would not want to see tokens like local and
localControl have to change to meet the no-substrings rule.

Brian

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Thursday, September 16, 1999 3:11 PM
> To: Brian Rosen; [email-masked]
> Subject: Re: MEGACOHGCP10: Clarifications + Editorial
> corrections/comments
>
>
> Brian,
>
> We might want to rethink this "Modem" "Mode" thing: for
> lexical analyzers is it nice not to
> have one token being a literal substring of another.  This is
> also true for several `short'
> names where a single letter is used from one of the tokens
> and then multiple letters used for
> others.  Again, one token should not be a literal substring
> of another, particularly where one
> is a prefix of another.
>
> "Brian F. G. Bidulock" wrote:
> [snip]
> >
> > Add the MediaToken, MethodToken, ModemToken, and Modem
> productions: there were
> > not defined.
> >
> >     ***************
> >     ---------------
> >     + MediaToken =
> >     +     ( "Media" /
> >     +     "MA" )
> >     +
> >     + MethodToken =
> >     +     ( "Method" /
> >     +     "MT" )
> >     +
> >     + ModemToken =
> >     +     ( "Modem" /
> >     +     "MD" )
> >     +
> >     + ModeToken =
> >     +     ( "Mode" /
> >     +     "MO" )
> >     +
> >     ***************
> >
> [snip]
>
> --
> Brian F. G. Bidulock
> Associate Director - New Products
> Inet Technologies Inc.
>