Subject: RE: [Megaco] Conflicting parameterID and ABNF token

From: "Syed Mohd Mujahid" <[email-masked]>
Date: Mon, 23 Jul 2007 17:29:28 +0530

Hi,

The conflict that is observer in this case is at the same hierarchy
level. As you can see from the grammar specification quoted below:

sigParameter = sigStream / sigSignalType / sigDuration / sigOther /

notifyCompletion / KeepActiveToken /

sigDirection / sigRequestID / sigIntsigDelay

sigStream = StreamToken EQUAL StreamID

sigOther = sigParameterName parmValue

The "aastts" package has a signal parameter named Segment Type whose
parameter ID is "st".  i.e StreamToken and sigParameterName matches.

But at this same hierarchy level, stream token(st) is also valid. If
suppose the value types of both these conflicting tokens match, ( i.e
EQUAL StreamID and  parmValue matches ) then the resultant grammar will
thus be ambiguous. Hence, don't you think the token IDs should be
globally unique?

________________________________

From: Schwarz Albrecht [mailto:[email-masked]] 
Sent: Monday, July 23, 2007 4:41 PM
To: Syed Mohd Mujahid; [email-masked]
Subject: RE: [Megaco] Conflicting parameterID and ABNF token

This is allowed as far as I know.

An overlapping name space is also technically no issue, due to the
"local" scope of such protocol codepoints in H.248.

There isn't any need for a globally unique name space due to the
hierachicaly concepts (like e.g. descriptors, packages) in the H.248
protocol architecture.

________________________________

	From: Syed Mohd Mujahid [mailto:[email-masked]] 
	Sent: Freitag, 20. Juli 2007 16:59
	To: [email-masked]
	Subject: [Megaco] Conflicting parameterID and ABNF token

	Hi,

	     Could any body clear my following concern

	     Can the parameter ID specified for a package be same as the
ABNF token?

	     For example for the package "aastts 0x00a8" the parameter
ID for Segment type is "st",  which conflicts with the stream token
"st".   Is this allowed?

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: "Schwarz Albrecht" <[email-masked]>
Date: Tue, 24 Jul 2007 14:23:43 +0200

Syed, right, you are correct in my understanding!
I did overlook the possiblity of optional StreamID parameter in a Signals Descriptor.
 
The general framework is: the Descriptor is somehow orthogonal to the Stream Descriptors (because different Signals in the Signals Descriptor may have a Stream-individual scope).
 
This indicates a general design rule for packages: e.g. "token names of possible sigParameter codepoints shall not be re-used for signals/parameters definitions by package definitions".
 
=> if my conclusion is correct, then we should include this as an explicit statement in § 12.1.4/H.248.1.
 
Concerning the aastts package:
 
There are two parameter names (with 'st') in aastts:
aastts/playsid/st    (segment type)
aastts/playscript/st (script type)
 
Both must be changed.
 
Yangbo &Christian,
guess this issue must be corrected, e.g. during the LC phase of H.248.9 Amd. 1.
http://www.itu.int/ITU-T/aap/aapid/1467/show.aspx 
Albrecht

	From: Syed Mohd Mujahid [mailto:[email-masked]] 
	Sent: Montag, 23. Juli 2007 13:59
	To: Schwarz Albrecht; [email-masked]
	Subject: RE: [Megaco] Conflicting parameterID and ABNF token

	Hi,

	The conflict that is observer in this case is at the same hierarchy level. As you can see from the grammar specification quoted below:

	 

	The "aastts" package has a signal parameter named Segment Type whose parameter ID is "st".  i.e StreamToken and sigParameterName matches.

	But at this same hierarchy level, stream token(st) is also valid. If suppose the value types of both these conflicting tokens match, ( i.e EQUAL StreamID and  parmValue matches ) then the resultant grammar will thus be ambiguous. Hence, don't you think the token IDs should be globally unique?

	An overlapping name space is also technically no issue, due to the "local" scope of such protocol codepoints in H.248.

	There isn't any need for a globally unique name space due to the hierachicaly concepts (like e.g. descriptors, packages) in the H.248 protocol architecture.

		Hi,

		     Can the parameter ID specified for a package be same as the ABNF token?

		     For example for the package "aastts 0x00a8" the parameter ID for Segment type is "st",  which conflicts with the stream token "st".   Is this allowed?

---

From: Christian Groves <[email-masked]>
Date: Tue, 31 Jul 2007 16:39:12 +1000

Hello Albrecht amd Syed,

The use of "st" is not forbidden but as has been pointed out it 
complicates the parsing of messages. Thus I think it would be worthwhile 
updating H.248.9 Amendment 1 to use a different parameter name. I'll 
make sure this is updated during the last call process.

Regards, Christian

Schwarz Albrecht wrote:
> The general framework is: the Descriptor is somehow orthogonal to the 
> Stream Descriptors (because different Signals in the Signals 
> Descriptor may have a Stream-individual scope).
> This indicates a general design rule for packages: e.g. "token names 
> of possible sigParameter codepoints shall not be re-used for 
> signals/parameters definitions by package definitions".
>     ------------------------------------------------------------------------
>     *From:* Syed Mohd Mujahid [mailto:[email-masked]]
>     *Sent:* Montag, 23. Juli 2007 13:59
>     *To:* Schwarz Albrecht; [email-masked]
>     *Subject:* RE: [Megaco] Conflicting parameterID and ABNF token
>
>     Hi,
>
>     The conflict that is observer in this case is at the same
>     hierarchy level. As you can see from the grammar specification
>     quoted below:
>
>     sigStream = *StreamToken EQUAL StreamID*
>
>     sigOther = *sigParameterName parmValue*
>
>     The “aastts” package has a signal parameter named Segment Type
>     whose parameter ID is “st”. i.e *StreamToken* and
>     *sigParameterName* matches.
>
>     But at this same hierarchy level, stream token(st) is also valid.
>     If suppose the value types of both these conflicting tokens match,
>     ( i.e *EQUAL StreamID* and *parmValue* matches ) then the
>     resultant grammar will thus be ambiguous. Hence, don’t you think
>     the token IDs should be globally unique?
>
>     ------------------------------------------------------------------------
>
>     *From:* Schwarz Albrecht [mailto:[email-masked]]
>     *Sent:* Monday, July 23, 2007 4:41 PM
>     *To:* Syed Mohd Mujahid; [email-masked]
>     *Subject:* RE: [Megaco] Conflicting parameterID and ABNF token
>
>     hierachicaly concepts (like e.g. descriptors, packages) in the
>     H.248 protocol architecture.
>
>         ------------------------------------------------------------------------
>
>         *From:* Syed Mohd Mujahid [mailto:[email-masked]]
>         *Sent:* Freitag, 20. Juli 2007 16:59
>         *To:* [email-masked]
>         *Subject:* [Megaco] Conflicting parameterID and ABNF token
>
>         Hi,
>
>         For example for the package “aastts 0x00a8” the parameter ID
>         for Segment type is “st”, which conflicts with the stream
>         token “st”. Is this allowed?
>