Subject: [Sigtran] RE: Parameter Padding Question

From: "Kelly Mcdonald" <[email-masked]>
Date: Mon, 30 Jan 2006 14:14:32 -0500

SIGTRAN community

> 	I am hoping you can help me out with a matter of interpreting a
> section that is generating some confusion within my group
> 
> 	Specifically a part from Section 3.2
> 
> 	Parameter Value: variable length. 
> 	The Parameter Value field contains the actual information to be
> transferred in the parameter. The total length of a parameter
> (including Tag, Parameter Length and Value fields) MUST be a multiple
> of 4 bytes. If the length of the parameter is not a multiple of 4
> bytes, the sender pads the Parameter at the end (i.e., after the
> Parameter Value field) with all zero bytes. The length of the padding
> is NOT included in the parameter length field. A sender SHOULD NOT pad
> with more than 3 bytes. The receiver MUST ignore the padding bytes. 
> 
> 	My question is, if non-zero padding values are used within the
> parameter value, is this still considered a valid message? Based on
> the parameter length value we are able to extract the parameter itself
> from the message irregardless of the padding. And while the spec calls
> for zero bytes to be used, it also states that the padding bytes MUST
> be ignored. 
> 
> 	Is the receiver expected to extract a parameter even if the
> padding bytes are not zero (i.e. ignore the padding bytes) , or should
> the message be rejected as invalid (as the padding is non-zero)
> 
> 	I hope you can help
> 
> 	Thanks
> 
> Kelly McDonald BSc. 
> USP GNPS Team Lead
> ESN: 395-1467 
> External: 613-765-1467 
> [email-masked]
> [email-masked] 
> 
> 
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Barry Nagelberg" <[email-masked]>
Date: Mon, 30 Jan 2006 14:26:35 -0500

Kelly,

Yes, this is still considered a valid message. Please see the definition of "SHOULD NOT" from RFC 2119:

<snip>
4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.
<snip>

In this case, the sender may have a "valid reason" to send non-zero bytes.

Barry Nagelberg
Adax, Inc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Kelly Mcdonald
Sent: Monday, January 30, 2006 2:15 PM
To: Kelly Mcdonald; [email-masked]
Subject: [Sigtran] RE: Parameter Padding Question

SIGTRAN community
I am hoping you can help me out with a matter of interpreting a section that is generating some confusion within my
group
Specifically a part from Section 3.2

Parameter Value: variable length.
The Parameter Value field contains the actual information to be transferred in the parameter. The total length of a
parameter (including Tag, Parameter Length and Value fields) MUST be a multiple of 4 bytes. If the length of the
parameter is not a multiple of 4 bytes, the sender pads the Parameter at the end (i.e., after the Parameter Value field)
with all zero bytes. The length of the padding is NOT included in the parameter length field. A sender SHOULD NOT pad
with more than 3 bytes. The receiver MUST ignore the padding bytes.

My question is, if non-zero padding values are used within the parameter value, is this still considered a valid
message? Based on the parameter length value we are able to extract the parameter itself from the message irregardless
of the padding.

And while the spec calls for zero bytes to be used, it also states that the padding bytes MUST be ignored.

Is the receiver expected to extract a parameter even if the padding bytes are not zero (i.e. ignore the padding bytes) ,
or should the message be rejected as invalid (as the padding is non-zero)

I hope you can help
        Thanks
Kelly McDonald BSc.
USP GNPS Team Lead
ESN: 395-1467
External: 613-765-1467
[email-masked]
[email-masked]