Subject: [Megaco] Megaco Text Encoding Question

From: "Kamitses, Jerry" <[email-masked]>
Date: Thu, 2 Mar 2006 07:44:12 -0500

A question has arisen during interop testing regarding the valid 
options for representing an integer using the text encoding defined 
by H.248.  

Briefly put, for those productions which include a terminal symbol 
representing an integer, such as UINT32 or UINT16, the ABNF seems to 
pretty clearly indicate the integer must be coded using radix 10:
   UINT16               = 1*5(DIGIT)  ; %x0-FFFF
   UINT32               = 1*10(DIGIT) ; %x0-FFFFFFFF
   DIGIT                = %x30-39         ; 0-9

So, is it correct to assume that in all packages, any  
parameter value that is defined to be an "integer" must 
be coded radix 10 unless clearly specified as otherwise?

For example, in the Shared Risk Package, the specification for 
the Shared risk group Identity Request (shrisk/srgi), states 
	Type:	Sub-list of type Integer

Is it correct to conclude that the integers in the list be coded 
radix 10, or could radix 16 be used (if the value is preceded by "0x")?

Secondly, regarding the rules for coding integers using radix 16, 
the ABNF in H.248 says the following: 

B.2   ABNF specification
...
   ; Integer, Double, and Unsigned Integer:  Decimal values can be
   ; encoded using characters 0-9.  Hexadecimal values must be prefixed
   ; with '0x' and can use characters 0-9,a-f,A-F.  An octal format is
   ; not supported.  Negative integers start with '-' and MUST be
   ; Decimal.  The SafeChar form of VALUE MUST be used.

Some productions clearly require that radix 16 is required with 
leading "0x", e.g. 
   SecurityParmIndex    = "0x" 8(HEXDIG)
   SequenceNum          = "0x" 8(HEXDIG)
   AuthData             = "0x" 24*64(HEXDIG)

other places the use of the "0x" appears to be implied (?)
   hex4                 = 1*4HEXDIG
   mtpAddress           = MTPToken LBRKT 4*8 (HEXDIG) RBRKT
   HEXDIG               = ( DIGIT / "A" / "B" / "C" / "D" / "E" / "F" )

or maybe not?  When hex4 is encoded as a text string should (must;may) it 
start with "0x"?; does this production intend to allow a naked radix 16 
value to be coded?

Cherry Cheers,
Gerald

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

---

From: Sudhanshu Garg <[email-masked]>
Date: Thu, 2 Mar 2006 19:16:12 +0530

Hi Jerry,

Find my response inline.

Regards,

Sudhanshu.

Technical Leader

Flextronics Software Systems

Phone: +91-124-4176301 extn 5109

Fax: +91-124-4300247

web: www.flextronicssoftware.com

"Kamitses, Jerry" <[email-masked]>

"Kamitses, Jerry" <[email-masked]>

03/02/2006 06:14 PM

To

<[email-masked]>

cc

Subject

[Megaco] Megaco Text Encoding Question

by H.248.

DIGIT                = %x30-39         ; 0-9

[SG]

IMO, the integers should not be represented in hexadecimal format if it is not specifically mentioned in the standard documents.

For specific package related query, the section 5.5.1.3 of H.248.22 specifies follows:

"That is,

the shrisk/srgi decimal integer is treated as a four byte binary number within the MG and MGC.

This way different bytes or groups of bits may be used to address different types of resources in the

MG. For example: the first two bytes could be used to identify DSP resources while the last two

bytes could identify interface boards on the MG. When sent over the GCP link, the binary number

is, however, expressed as a decimal number integer."

So the value must be represented in decimal integer format.

[/SG]

B.2   ABNF specification

...

leading "0x", e.g.

hex4                 = 1*4HEXDIG

value to be coded?

[SG]

The ABNF provides the "0x" prefix where it is required.

The 0x must be used in SecurityParmIndex, SequenceNum, AuthData but in the MID part (IPv6 address and MTP address), the 0x must not be used.

MID part should be treated as the text string which is printable format of IPv6 or MTP address.

Printable format of IPV6 addresses does not contain "0x".

[/SG]

Cherry Cheers,

Gerald

Megaco mailing list

[email-masked]

*********************** FSS-Restricted ***********************

"DISCLAIMER: This message is proprietary to Flextronics Software

Systems Limited (FSS) and is intended solely for the use of the

individual to whom it is addressed. It may contain privileged or

confidential information and should not be circulated or used for

any purpose other than for what it is intended. If you have received

this message in error, please notify the originator immediately.

If you are not the intended recipient, you are notified that you are

strictly prohibited from using, copying, altering, or disclosing

the contents of this message. FSS accepts no responsibility for

loss or damage arising from the use of the information transmitted

by this email including damage from virus."