Subject: Re: Nits on the ABNF

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

> yes I think we should allow parameters on the Modem descriptor.

Allowing for some future definition is fine, but they
are not defined yet, so there are no ABNF rules that permit
them.  What we did by using bracket instead of brace
is to allow definition in the future.

> > 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"}.
> >
> 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....
>
Okay, I argued this with Abdallah, so here is my view.

The syntax does not have termination IDs that are fully
specified (no wild card, no choose) returned.  When
you say Add=Circuit1{..., you get a reply of Add{...,
not Add=Circuit1{...

If you use a wildcard, or specify choose, then you get
the reply repeated, once per match, and you get the
terminationID with the reply, as in Add=Circuit*{..,
and you get Add=Circuit1{...},Add=Circuit2{...}}.

If you were to say Modify=Circuit*{..}, Modify=Circuit2{..
you would get the following as a reply:
        Modify=Circuit1{...}, Modify=Circuit2{...},
        Modify{...}

What we are talking about is, should a fully specified
terminationID be returned in the case of an error.

I say no.  If the MGC can figure out all the cases when
there is no error, then it can figure out the case when
there is an error, and returning the terminationID is
more rules and more work without any benefit.

If there are any cases where the MGC can't figure out what
is happening without an error, we have a problem which
must be fixed.  There is nothing in between.

> >         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
> >
> 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.
I'm not worried about out of order if that is what you
mean by this

> If the reply matches NO transaction request, that is an error
That is the only case I'm worried about.  I don't think
that is distinguishable from an ALF error.
> - MGC/MG sends
> a top level message with error descriptor = "protocol error", or
> "transaction id error".
Is this a top level request, or a top level reply?
I said reply.  Either case is weird, because it's the "wrong" direction.

> 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".
Can't fail it, it's the reply, not the request!
Need to send a reply (or a request, as above) with
the real error (missing action in transaction reply)

> - Missing command reply in an action: fail the transaction,
> and MGC/MG sends
> a message with error descriptor = "protocol error".
Same as above, can't fail, and can give a meaningful error
message.

> 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.
yep

> - 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.
Agree

Brian

---

From: Abdallah Rayhan <[email-masked]>
Date: Mon, 13 Sep 1999 16:56:40 -0400

See comments below,

> must be fixed.  There is nothing in between.

Let is say that MG has these terminations, AAA, ABA, BAA,
BBA, BBB, BAB,  and the MGC is only aware of ABA, AAA ,BBB, BAB,
The MGC issues the following commands,
Add B*  --> Add BBB, Add BBA, Add BAB, Add BAA, and
Add *A  --> Add BBA, Add BAA Add ABA Add AAA.

and it happens that Add BBA and Add BAA fail in each command.
Unless you explicit say what has failed how the MGC can tell
what had happened ???

> the real error (missing action in transaction reply)

First, you reply to the reply. I dont think we have this yet
in MEGACO. Second, you have not described how the MGC
should handle that case ! What Nancy meant by fail is the
MGC considers the transaction as being failed, right Nancy ?
Third, we dont have error with in a request but we have that
with a top level error message. and that is what should be
used because this a serious protocol violation and you need to
be able to report that to the MG/MGC.

> Same as above, can't fail, and can give a meaningful error

Same as above note.

Abdallah