Subject: [Megaco] Ambiguities, Errors and forgotten things in Packages Description

From: Contardi Angelo <[email-masked]>
Date: Thu, 9 Jun 2005 15:12:40 +0200

Hello,

During the reading of H.248.1 packages description i have encountered 
many difficulties i try to explain in this mail.

I hope someone can clarify my doubts. Furthermore, if any of my
considerations
is valid, i hope will be taken in count in the new "incoming" H.248.1 V3 ITU
specification. The V2 specification probably is "too stable" to be modified
:-)

REFERENCE SPECIFICATION:
------------------------

ITU H.248.1 V2 Corrigendum 1 (i think the last one approved by ITU).

PREFACE:
--------

The Textual (ABNF) coding of VALUEs allows ONE of the following forms:

* A sequence of ONE or MORE SafeChar (let me say SafeChar form).

* A quotedString form that is a DOUBLE QUOTED string of ZERO or MORE ASCII
chars,
  with some exceptions (DOUBLE QUOTES, non printable chars, C language
string
  terminator '\0' (0x00), etc.).

Of the two forms, the quotedString form is the more general one.

Errors (?):
-----------

1) In the textual coding i think it's impossible to code ANY UTF-8 char
   (RFC 3629) because of the FIRST byte of an UTF-8 char may be ANY ASCII
   char in the range 0x00-0x7E and, for instance, the ASCII 0x01-0x07, that
   are not allowed in ABNF form of VALUE.
   Furthermore, UTF-8 chars "greater than 0x7E", need ASCII chars in the
   range 0x80-0xFF (not ALL), not allowed in the ABNF form of VALUE.
   If my assertion is true, in the packages description (paragraphs 12.x.x
of
   H.248.1 V2 Corrigendum 1), the TYPEs of VALUEs (i suppose they should be
valid
   for BOTH ASN.1 and ABNF coding):
   
   - String:    can't be ANY UTF-8 string but JUST an ASCII string with the
                limitation of the quotedString !!! So it can't include '"',
                '\0', etc.

   - Character: can't be ANY UTF-8 for the same above reasons and with the
                same limitation.
                
   In other words, String and Character types may be JUST quotedString.
   Otherwise, to code UTF-8 chars with an ASCII string it's necessary to
extend
   the quotedString definition allowing ANY ASCII, except '\0' and '"'.

2) Due probably to a "copy & paste" operation of the "Octet String"
references,
   the references o Sub-List type in paragraphs 12.1.2, 12.1.5 and 12.2 are
   probably wrong and should be:

    "The encoding of Sub-lists is specified in Annex A and B.2
(alternativeValue
     description)."

3) The Integer and Double types of Properties and Parameters are BOTH
   SIGNED (paragraphs 12.x.x of Corrigendum), while in ABNF description of
   VALUEs ("top" ANNEX B.2 comment) there is the possibility of Unsigned
Integer
   TOO. Why ? Note that from the "implementor" point of view, Integer and
Unsigned
   Integer (on 32 Bits) aren't the same thing (different range: the sign
"eat"
   on bit).

Ambiguities:
------------

1) About the Sub-List type of a package Property/Parameter:

   - Sub-List is not "strictly speaking" a type but a Sub-set of Items, ALL
     of a specified Type (Integer, Double, etc.).

   - The term Sub-List appears just in the descriptive paragraphs of
Packages
     (12.x.x) but NOT in packages definitions (ANNEX E) in witch appears
JUST
     List (see tonedet ad tonegen base packages).
   
   - Paragraph 12.3 is titled "Lists", but describe how to register
enumerated
     types to IANA.
   
   - A Sub-List may assume 3 forms (in BOTH ASN.1 and ABNF implementations):

     * An OR    sublist of elements
     * An AND   sublist of elements
     * A  RANGE sublist of elements (AND or OR ?)
     
     So, to specify COMPLETELY a VALUE of a Parameter/Property of "type"
Sub-list,
     somewhere in the package one should write which relation, AND or OR,
"ties"
     the Sub-list VALUEs.
     
     Furthermore, if it is reasonable to allow packages that MAY admit BOTH
     AND or OR relations, the syntax of the "RANGE" is not suited to carry
     the AND or OR "relation attribute".
     I think in some applications the AND or OR attribute may have, in
different
     times, sense. For instance, a modem tone detector (when i was jung i
work
     with modems :-), can be programmed as a DTMF tone detector (so it
detects
     a COUPLE of SINGLE tones at the same time (relation AND)) or as a
"multy"
     (single) tone detector, capable to detect toneA OR toneB ...(relation
OR)).

   My proposal:
   
   * In a package description, specify the type of the values as usual and
do
     not include Sub-List as a type but ADD a the new descriptive "item":
   
            Sub-Set: None/AND/OR or BOTH
      
   * Reference the Sub-Set with the string "Sub-Set" everywhere in the
specification,
     both in the Packages definitions and in the syntax description (ASN.1
and
     ABNF notation comments, to indicate how the Sub-Set is implemented).

2) About Octet String ABNF representation:

   - The octet string ABNF representation is described in ANNEX B.3 in a way
     i think is not so clear:
     
     "...This octet encoding SHOULD be used when encoding octet strings in
the
      text version of the protocol..."
      
     I think it means, more explicitly: 
     
     "The ASCII character string corresponding to this octet encoding SHOULD
      be used when encoding octet strings in the text version of the
protocol."

     So, for instance, the Hex Coding "0x90" correspond to the string "90".

   - Furthermore i think ANNEX B.4 may be deleted because it just contribute
     to confuse ideas. It seems it says "text coding of octet string must be
     terminated with a CARRIAGE RETURN", not allowed in the ABNF form of
VALUE.

Things left out (forgotten):
----------------------------

1) The ASN.1 implementation of VALUE allow a NULL list of VALUEs that means
   CHOOSE: the VALUE may be choosen by MG. How CHOOSE is implemented in ABNF
syntax ?
   
   My Proposal:
   
   * Non conservative: Change the syntax of alternativeValue:
   
          VALUE *(COMMA VALUE)      become     [VALUE *(COMMA VALUE)] 
   
     It may introduce "parser ambiguities". 
   
   * Conservative (as i have already implemented :-):
   
     If parmValue is EQUAL to an EMPTY QUOTED STRING, the parameter VALUE
may
     be choose by MG. Note that THIS is done at PARSER level so the TYPE of
     the VALE (semantic level) doesn't affect the way an EMPTY VALUE of ANY
TYPE
     is represented ("").
     I think the "semantic" distinction made in paragraph 7.2.6:
     
     "For property and parameter values of type string, character or octet
string,
      the MG shall return an empty value.
      For the text encoding, strings and characters return an empty
quotedString
      construct, while octet strings return NUL (0x00)."
   
     is NOT necessary at ALL and NOT applicable to ALL allowed values types.
     Furthermore i don't understand what it means with:
     
         "... while octet strings return NUL (0x00)"
         
     Does it means the text Octect Coding of 0x00, thus the string "00" (not
quoted)?
     The ASCII '\0' (0x00) is NOT allowed in ABNF VALUEs forms.

2) When describing the fact that a package may be an extension of an other
it
   should be stated that the "added Items Ids can't assume ANY of the
(already
   existing) base package Items Ids values". This to ensure the the fact
that
   any Item of "extended package" (UNION of the base and added ones), must
be
   identified in an unambiguous mode.

Best Regards

        o o o o o o o . . .   ___________________________________
        o      _____           ||        Angelo Contardi         |
      .][__n_n_|DD[  ====_____  |   [email-masked]   |
     >(________|__|_[_________]_|________________________________|
     _/oo OOOOO oo`  ooo   ooo  'o!o!o                      o!o!o`
_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: Christian Groves <[email-masked]>
Date: Thu, 16 Jun 2005 17:14:01 +1000

Contardi Angelo wrote:

> specification. The V2 specification probably is "too stable" to be
> modified :-) 
> 
> REFERENCE SPECIFICATION: 
> ------------------------ 
> 
> * A quotedString form that is a DOUBLE QUOTED string of ZERO or MORE
> ASCII chars, 
>    If my assertion is true, in the packages description (paragraphs
> 12.x.x of 
>    H.248.1 V2 Corrigendum 1), the TYPEs of VALUEs (i suppose they should
> be valid 

[CHG] Yes I agree with many of your assertions. I thought this is already 
covered at the start of the ABNF in H.248.1 section B.2.

>     "The encoding of Sub-lists is specified in Annex A and B.2

[CHG] Yes this should reference B.2 not B.3.

>    TOO. Why ? Note that from the "implementor" point of view, Integer
> and Unsigned 

[CHG] The paragraphs of 12.x.x are the overriding descriptions. The ABNF itself 
does not enforce all the H.248.1 syntax and procedures. As you've pointed out 
VALUE is very flexible but it is the type defined in the packages (and sect 12.) 
that say how it is used.

> Ambiguities: 
[CHG] Yes.

>      List (see tonedet ad tonegen base packages). 
[CHG] This has been fixed in H.248.1v3 to say sub-list

>    - Paragraph 12.3 is titled "Lists", but describe how to register

[CHG] I don't believe anybody has made use of this facility. I actually would 
propose to remove this.
>      somewhere in the package one should write which relation, AND or
> OR, "ties" 
>      the Sub-list VALUEs. 
>      
>      times, sense. For instance, a modem tone detector (when i was jung
> i work 
>      (single) tone detector, capable to detect toneA OR toneB
> ...(relation OR)). 
> 
>    My proposal: 
>    
>    * In a package description, specify the type of the values as usual
> and do 
>      both in the Packages definitions and in the syntax description
> (ASN.1 and 

[CHG] I don't think we need to formalise this. I think it is up to the package 
writers to address this. It is also largely dependent on the individual 
capabilities of the Media gateways.

>      "...This octet encoding SHOULD be used when encoding octet strings
> in the 

[CHG] This is probably clearer but the example clarifies exactly what is required.

>    CHOOSE: the VALUE may be choosen by MG. How CHOOSE is implemented in
> ABNF syntax ?

[CHG] Choose is implemented in the ABNF by sending down "?" It does not need to 
be equivalent to the ASN.1. So long as both encodings can alway to choose.

>      If parmValue is EQUAL to an EMPTY QUOTED STRING, the parameter
> VALUE may 
>      the VALE (semantic level) doesn't affect the way an EMPTY VALUE of
> ANY TYPE 
>      is represented (""). 
>      "For property and parameter values of type string, character or
> octet string, 
>      Does it means the text Octect Coding of 0x00, thus the string "00"
> (not quoted)? 
> 2) When describing the fact that a package may be an extension of an
> other it 
>    any Item of "extended package" (UNION of the base and added ones),
> must be 

[CHG] It already states this in H.248.1 section 12.1.1 "An extended package 
shall not redefine or overload an identifier defined in the original package and 
packages it may have extended (multiple levels of extension). "

> ------------------------------------------------------------------------
>