Subject: [Dime] Integer32 encoding

From: "Roland Gecse \(IJ/ETH\)" <[email-masked]>
Date: Tue, 24 Apr 2007 12:52:49 +0200

Dear DIME Members,

I would be glad if someone could answer my question: 

Where does the diameter base protocol specify how to encode a negative
Integer32 AVP value?

Please CC replies directly to my e-mail address, as I am not subscribed
to this mailing list.

Regards,
Roland.

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

---

From: <[email-masked]>
Date: Thu, 17 May 2007 16:36:15 +0200

Hi Roland,

Section 4.2. in RFC3588 says that Integer32 is a 32 bit _signed_
value, in network byte order. So the highest bit in the value
defines the sign just like in normal signed integer arithmetic.

E.g. 0x80000000 would be negative whereas 0x7fffffff would be
positive.

Cheers,
	Jouni

> -----Original Message-----
> From: Roland Gecse (IJ/ETH) [mailto:[email-masked]] 
> Sent: Tuesday, April 24, 2007 1:53 PM
> To: [email-masked]
> Subject: [Dime] Integer32 encoding
> 
> Dear DIME Members,
> 
> Please CC replies directly to my e-mail address, as I am not 
> subscribed to this mailing list.
> 
> Regards,
> Roland.
>

---

From: "Tang, Alan Shanjing \(Alan\)" <[email-masked]>
Date: Fri, 18 May 2007 14:17:40 +0800

Hello:

I have a general question about the AVP flags. 

In section 4.1 of RFC3588, it is clearly stated that the AVP code
combined with the Vendor-Id field is used to identify the attribute
uniquely. How do I understand the "uniqueness" of the attribute? Does
the "attribute" here include the AVP flags also? Does this mean that the
AVP flags must be unique as well?

For example, there are two AVPs used by two different applications. The
AVP code and Vendor-Id for these two AVPs are both the same. Does this
mean that the AVP flags must be the same for these "two" AVPs?

Excerpt from RFC3588, section 4.1 is at below, FYI.

=====================================================

4.1.    AVP Header

      AVP Code

      The AVP Code, combined with the Vendor-Id field, identifies the

      attribute uniquely.  AVP numbers 1 through 255 are reserved for

      backward compatibility with RADIUS, without setting the Vendor-Id

      field.  AVP numbers 256 and above are used for Diameter, which are

      allocated by IANA (see Section 11.1).

=====================================================

Thanks in advance!

Alan Tang

Alcatel-Lucent

---

From: <[email-masked]>
Date: Fri, 18 May 2007 10:48:43 +0200

Hi,

Funny.. I never came to think that Interger32 could be anything else
than two's complement ;-) I guess you are right about this ambiguity.

Cheers,
	Jouni

> Sent: Thursday, May 17, 2007 6:36 PM
> To: Korhonen, Jouni /TeliaSonera Finland Oyj; [email-masked]
> Subject: RE: [Dime] Integer32 encoding
> 
> Hi Jouni,
> 
> first of all thanks for your mail. I had also the 1st idea to 
> use two's complement representation of 32bits integer but 
> this is _not_ explicitly stated in the RFC. There are a 
> number of representations of signed numbers. OK, two's 
> complement is the most common. But RFC3588 does not regulate 
> this, so I could also use one's complement, sign-bit and 
> magnitude or excess-(2^31-1) representation as common with 
> some other protocols and still have a conforming 
> implementation that most likely would not be able to 
> interwork properly. I believe a clarification would be 
> worth-while --- that's why the question.
> 
> Roland.
> 
> > From: [email-masked]
> > [mailto:[email-masked]]
> > Sent: Thursday, May 17, 2007 16:36
> > To: Roland Gecse (IJ/ETH); [email-masked]
> > Subject: RE: [Dime] Integer32 encoding
> > 
> > Hi Roland,
> > 
> > value, in network byte order. So the highest bit in the 
> value defines 
> > the sign just like in normal signed integer arithmetic.
> >

---

From: "Roland Gecse \(IJ/ETH\)" <[email-masked]>
Date: Thu, 17 May 2007 17:35:33 +0200

Hi Jouni,

first of all thanks for your mail. I had also the 1st idea to use two's
complement representation of 32bits integer but this is _not_ explicitly
stated in the RFC. There are a number of representations of signed
numbers. OK, two's complement is the most common. But RFC3588 does not
regulate this, so I could also use one's complement, sign-bit and
magnitude or excess-(2^31-1) representation as common with some other
protocols and still have a conforming implementation that most likely
would not be able to interwork properly. I believe a clarification would
be worth-while --- that's why the question.

Roland.

> Section 4.2. in RFC3588 says that Integer32 is a 32 bit 
> _signed_ value, in network byte order. So the highest bit in 
> the value defines the sign just like in normal signed integer 
> arithmetic.
>

---

From: "Roland Gecse \(IJ/ETH\)" <[email-masked]>
Date: Thu, 17 May 2007 17:35:33 +0200

Hi Jouni,

Roland.