Re: SCTP API section 5.2.2

From: David Lehmann <lehmann@ulticom.com>
Date: Tue Mar 01 2005 - 15:29:16 EST

('binary' encoding is not supported, stored as-is) ('binary' encoding is not supported, stored as-is) Kacheong Poon wrote:
> David Lehmann wrote:
>
>> That was a lot of words just to state that it is in network byte
>> order. For a couple fields, the draft does explicitly says that
>> the values are in "network byte order."
>
> Actually, even though the sinfo_ppid is "supposed" to be
> a 32 bit integer, it is really opaque to the SCTP stack and
> socket layer. So the app may as well put 4 8 bit bytes
> there. Specifying any byte order in the text is probably
> not correct. This also applies to the sinfo_context.

I think that I would have to disagree. This is a 32-bit value
which is sent over the network and read by the peer SCTP user.
The payload protocol has to be interpreted by the upper layer.
There is nothing in RFC 2960 that makes this field different
from any other field (e.g. the stream number, SSN, etc) in
this regard.

In addition, when Sigtran protocols define the payload
protocol ID, they just specify the number. (e.g. 2 for
M2UA. See RFC 3331, section 8.1. M2UA doesn't specify
which of the four bytes should be set to 2.)

The sinfo_context, OTOH, should be opaque. It is passed
by the user to SCTP, which may send it back to the _same_ user.
The sinfo_context does not get sent over the network.
Since the user that is interpreting the sinfo_context
value is the _same_ user that created the value, it makes
sense that it is opaque.

>> IMHO, the draft should be explicit for all fields. Maybe for each
>> structure, the draft should state something like:
>> "All members of struct sctp_xxxx are in network byte order,
>> except for member3 and member6, which are in host byte order."

I still think the above clarification should be made for each
structure.

-- 
David Lehmann
Ulticom, Inc.
http://www.ulticom.com

Received on Tue Mar 1 15:53:27 2005