Subject: Re: ABNF Question: digit maps embedded in events

From: Troy Cauble <[email-masked]>
Date: Fri, 01 Jun 2001 11:21:38 -0400

Just curious, but why doesn't this get squashed for
being an unnecessary change?  Nothing's broken except
the symmetry.

More useful changes have been delayed to v2.

Please treat this as a question, not a complaint!
Christian, Tom, Brian, et. al. are doing a great job.

-troy

Christian Groves wrote:
> 
> Just in time. I'll add it to the implementors' guide.
> 
> Christian
> 
> Tom-PT Taylor wrote:
> >
> > Yes, and I suspect I'm the guilty typist.
> >
> > > -----Original Message-----
> > > From: Rosen, Brian [mailto:[email-masked]]
> > > Sent: Wednesday, May 30, 2001 3:44 PM
> > > To: 'Steven Weisz'; Megaco Mailing List (E-mail)
> > > Cc: Taylor, Tom-PT [NORSE:B881:EXCH]
> > > Subject: RE: ABNF Question: digit maps embedded in events
> > >
> > >
> > > I usually defer to Tom on any digitMap questions.
> > > I can't tell you how many hours I (and several others
> > > including Abdullah Rayhan) spent pouring over the
> > > ABNF to ferret out such problems.
> > >
> > > Yes, I agree, it should be
> > > digitMap={...
> > > and not
> > > digitMap{...
> > >
> > > I think this qualifies as a typo and deserves an IG entry.
> > > Tom, do you agree?
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Steven Weisz [mailto:[email-masked]]
> > > > Sent: Wednesday, May 30, 2001 3:08 PM
> > > > To: Megaco Mailing List (E-mail)
> > > > Subject: ABNF Question: digit maps embedded in events
> > > >
> > > >
> > > > Hi List,
> > > >
> > > > I asked this question a few weeks ago and still have not
> > > > found an answer.
> > > > Does anyone have an opinion?
> > > >
> > > > It is a quick question concerning a digit map embedded in a
> > > > requested event.
> > > > Specifically, if you look at the ABNF the embedded digit map
> > > > is defined as
> > > >
> > > > eventDM = DigitMapToken (( EQUAL digitMapName ) / (LBRKT
> > > digitMapValue
> > > > RBRKT))
> > > >
> > > > and a digit map descriptor is defined as:
> > > >
> > > > digitMapDescriptor = DigitMapToken EQUAL (( LBRKT
> > > > digitMapValue RBRKT ) /
> > > >                      ( digitMapName [LBRKT digitMapValue RBRKT] ))
> >
> > > >
> > > > It obvious that they are very similar, as I believe was
> > > > intended but there
> > > > is one thing that is bothering me in eventDM. That is it
> > > > seems to me that
> > > > the EQUAL should be right after DigitMapToken as is the case in
> > > > digitMapDescriptor. So we would instead have:
> > > >
> > > > eventDM = DigitMapToken EQUAL (( digitMapName ) / (LBRKT
> > > digitMapValue
> > > > RBRKT))
> > > >
> > > > Does this make sense?
> > > >
> > > > Thanks,
> > > >
> > > > Steve
> > > >
> > >

---

From: "Paul Long" <[email-masked]>
Date: Fri, 1 Jun 2001 10:49:14 -0500

Yeah, what are the criteria for what gets changed in v1 and what gets put
off to v2? Also, when is v1 officially "done" and can no longer be changed?
Like Troy, I'm not complaining--I really want to know. As you can tell from
my earlier response to Steve's query, I thought it was already too late to
change v1.

Paul Long
ipDialog, Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Troy Cauble
Sent: Friday, June 01, 2001 10:22 AM
To: Megaco Mailing List (E-mail)
Subject: Re: ABNF Question: digit maps embedded in events

-troy

---

From: Christian Groves <[email-masked]>
Date: Sat, 02 Jun 2001 07:01:41 +1000

G'Day Paul and Troy,

If the change is new functionality then it goes to v2.
If its to fix an error then it goes to the implementors' guide (IG)
If its to align between ABNF and ASN1 it goes in the IG
If its to fix inconsistencies between procedures and syntax it goes in
the IG

This is broadly how I interpret things. There aren't really any solid
rules
except for the first one.

With regards to the EQUALS change I believe it was a syntax
irregularity. I assume the intention when the syntax was written it was
meant to be the way that it was fixed to.

Cheers, Christian

---

From: "Paul Long" <[email-masked]>
Date: Wed, 6 Jun 2001 14:37:22 -0500

Christian,

That's not going to work. Your use of "an error" is too vague. You can only
put something in the IG if it clarifies an issue or fixes an otherwise
broken aspect of the standard which prevents interoperability (not that
simply brings the syntax into some kind of aesthetic harmony at the risk of
breaking interoperability). Otherwise, as is the case with the proposed
digit-map modification, you have created a conflict that opens us up to
interoperability problems.

Let's say I have shipped product, it's out the door, and it's compliant.
According to H.248/RFC3015, another entity could send this embedded digit
map to my product, and it would not encounter a parse error.
	DigitMap { x }
However, now you are proposing that we change the standard so that the
syntax is now this:
	DigitMap = { x }
My product receives this and flags it as a syntax error--you broke it by
changing the standard.

IMO, interoperability is sacrosanct and trumps aesthetics any day.

But nobody has answered my second question. When can a version of the
standard no longer be changed? With H.323, both the standard and its IG must
be Decided. Is it the same way with H.248? How about RFC3015?

Paul Long
ipDialog, Inc.

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Friday, June 01, 2001 4:02 PM
To: Paul Long
Cc: Megaco Mailing List (E-mail)
Subject: Re: ABNF Question: digit maps embedded in events

G'Day Paul and Troy,

Cheers, Christian

---

From: Christian Groves <[email-masked]>
Date: Fri, 08 Jun 2001 13:58:06 +1000

G'Day Paul,

I'm sorry if I haven't given an encyclopedic definition of "an error". I
don't believe there's any hard and fast definition. Really its the rough
consensus that decides. I appreciate your concern about
interoperability. Any change to syntax or procedure creates an
interoperability problem, we have about 80 of them. I believe that its
worthwhile in H248v1 fixing all these errors/bugs/clarification/etc so
that we don't have any problem when we approve H.248v2. When v2 comes
out we also have the issue of backwards compatibility and thus any
changes are very serious.

H.248 works in the same way as H.323. IGs never get "decided". I'm not
sure what happens to RFC3015. With the schedule of getting H248v2
approved in Feb 2002 I believe that we have the chance on getting a very
robust stable protocol then.

Christian