Subject: RE: Error in H.248.9 Amd. 1; RE: [Megaco] Conflicting parameterID and ABNF token

From: "Schwarz Albrecht" <[email-masked]>
Date: Wed, 1 Aug 2007 15:08:52 +0200

Thanks!
Just saw that the Last Call is starting today:
http://www.itu.int/ITU-T/aap/AAPRecDetails.aspx?AAPSeqNo=1467

> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]] 
> Sent: Dienstag, 31. Juli 2007 08:39
> To: Schwarz Albrecht
> Cc: Syed Mohd Mujahid; [email-masked]; [email-masked]
> Subject: Re: Error in H.248.9 Amd. 1; RE: [Megaco] 
> Conflicting parameterID and ABNF token
> 
> 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:
> > 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:
> >
> >     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: Christian Groves <[email-masked]>
Date: Mon, 06 Aug 2007 15:36:56 +1000

Just as a follow up. I checked and there's already guidance in H.248.1 
section 12.2:

12.2 Guidelines to defining parameters to events and signals
Parameter Name: only descriptive
ParameterID: is an identifier. The textual ParameterID of parameters to 
events and signals shall not start with "EPA" and "SPA", respectively. 
The textual ParameterID shall also not be "ST", "Stream", "SY", 
"SignalType", "DR", "Duration", "NC", "NotifyCompletion", "KA", 
"KeepActive", "EB", "Embed", "DM", "DigitMap", "SPADI", "SPADirection", 
"SPARQ" or "SPARequestID".

Cheers, Christian

Schwarz Albrecht wrote:
> The general framework is: the Descriptor is somehow orthogonal to the 
> This indicates a general design rule for packages: e.g. "token names 
>     ------------------------------------------------------------------------
>     sigParameter = sigStream / sigSignalType / sigDuration / sigOther /
>
>     The “aastts” package has a signal parameter named Segment Type
>     whose parameter ID is “st”. i.e *StreamToken* and
>     But at this same hierarchy level, stream token(st) is also valid.
>     If suppose the value types of both these conflicting tokens match,
>     resultant grammar will thus be ambiguous. Hence, don’t you think
>     ------------------------------------------------------------------------
>
>     *From:* Schwarz Albrecht [mailto:[email-masked]]
>     An overlapping name space is also technically no issue, due to the
>         ------------------------------------------------------------------------
>
>         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?
>
> ------------------------------------------------------------------------
>