Subject: Nits on the ABNF

From: Brian Rosen <[email-masked]>
Date: Mon, 13 Sep 1999 14:16:21 -0400

Abdallah Rayhan, Nancy Greene and I have been noodling with the ABNF.  There
are some issues that we have just
decided, but there are some that should at least be
brought up in case someone objects.

1. In Local/Remote, we currently allow two syntax descriptions, Tag/Value
(sometimes called "native"), and
SDP.  In the prior ABNF, we used an escaped Octet String
as the contents of the descriptor.  For example, we
may have allowed:
...Add=${Media{Local=SDP{"m=.........
The SDP string was in quotes, and you double quoted any
occurance of quote in the SDP string.

We observe that, as far as we know, the right brace can't
occur in SDP when used with MEGACO.  I know propose that
we eliminate the escapedOctetString productions, and
simply allow tag=value,tag=value....., or m=...
a=.... within the enclosing curly braces of the Local/Remote descriptors.

2.  We allow alternatives as values for properties.  We also allow ranges.
We have been discussing syntax for
these.  The current proposal is to flag non-simple values in square
brackets, allowing comma to denote alternative and .. to denote range.  Thus
we would have
        tag=[value1,value2,value3]
or
        tag=[value1..value2]
A question arises, should we allow:
        tag=[3,5..7,9]
At the moment, we say, no, we don't.
We started using curly brace as the bracketing.  In most
cases that works fine.  However, alternative and range
will be permitted in other cases of tag=value.  One such
case we considered is modem.  Modem=V90 is the basic
construction, but we think Modem=[V90,V34] should be
allowed.  We don't currently have parameters for Modem,
but imagine their might be some day.  We would not
want to see Modem={V90,V34}{maxSpeed=33400} if we
could make it Modem=[V90,V34]{maxSpeed=33400}.  That is
why we are suggesting square brackets.

3. Tom Taylor made the call that version is in every message and profile is
in ServiceChange.  I propose that
the syntax for profile be the same as syntax for the
Megaco message/version, so that
profile=NAME SLASH majorVersion DOT minorVersion

4. We decided to allow errorDescriptor to occur in 3 places:
a) As a parameter to a command, as in Add{Error=212{"Illegal
terminationID"}.
b) As the only parameter to a context.  This would occur when the contents
of the enclosing braces in an action was not decodeable, or if the contextID
was syntactically
correct, but had some other problem.
c) As the only parameter to a transaction.  This would occur when the
contents of the enclosing braces in a transaction was not decodeable, or the
transactionID
was in some way bogus.

A syntactically correct command with an improper termination ID will be
reported as in "a).
A syntactically correct action with an improper
contextID (or "out of contextIDs") would be reported
as in "b)"
A syntactically correct Transaction with a bogus TransactionID would be
reported as in "c)"

When you receive
        Something you can't decode as a transaction,
          you get a transaction reply with a null
          transaction ID and an appropriate error.
          Any other transactions in the message is discarded
        A message that has a recognizable transaction
          request, but has some other syntactic error, you
          get a "c)" response
        A reply that does not match a request, you get
          a transaction reply with whatever requestID was
          sent to you and an appropriate error message

Comments appreciated asap.

Brian

---

From: Nancy-M Greene <[email-masked]>
Date: Mon, 13 Sep 1999 14:26:17 -0500

Hi Brian, a couple of clarifications below....

> ----------
> From:         Brian Rosen[SMTP:[email-masked]]
> Sent:         Monday, September 13, 1999 2:16 PM
> To:   [email-masked]
> Subject:      Nits on the ABNF
>
yes I think we should allow parameters on the Modem descriptor.

> profile=NAME SLASH majorVersion DOT minorVersion
fine

> a) As a parameter to a command, as in Add{Error=212{"Illegal
Abdallah and I think that this error needs the terminationId, so it would
be:

Add=TID1{Error=212{"Illegal terminationID"}

When reporting errors, more information is always better than less....

>           Any other transactions in the message is discarded
ok
>           request, but has some other syntactic error, you
ok

>           sent to you and an appropriate error message
Let's reword this a bit. Do you mean a transaction Id in a reply that does
not match a transactionId in a request? If a reply does not match the
request, then no reply has come yet for that request. That's an ALF issue.
If the reply matches NO transaction request, that is an error - MGC/MG sends
a top level message with error descriptor = "protocol error", or
"transaction id error".

There are a few more cases:

- Missing action reply in a transaction reply: fail the whole transaction?
and MGC/MG sends message with error descriptor ="protocol error".

- Missing command reply in an action: fail the transaction, and MGC/MG sends
a message with error descriptor = "protocol error".

Note that when a wildcard is used in the terminationId in a command, you
will get back at least one command reply to that command. In fact, you will
get back a command reply for each terminationId the wildcard matched.

- Missing command reply for a terminationId that should have matched the
wildcard sent in the request: NOT an error - if the MGC knows the
terminationId that is missing, it can audit for the status of it.

> Comments appreciated asap.
Nancy and Abdallah

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