Subject: RE: [protocol] maxInt

From: "Ramsay, Ron" <[email-masked]>
Date: Mon, 27 Sep 2004 13:44:54 +1000

Well ... no. You've pointed out that maxInt is architecture dependent, but for interoperability I think the value can't depend on architecture.

If you send the messageID 2^^32 + 15 to a 32-bit system, you could reasonably expect to receive the messageID 15 in response, which would naturally be rejected.

It is a tricky problem, but keeping the smaller number is the best bet for interoperability.

Ron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Vithalprasad
Gaitonde
Sent: Saturday, 25 September 2004 00:47
To: [email-masked]
Subject: [protocol] maxInt

The [protocol] draft defined maxInt as (2^^31 - 1). Does it make sense
to change this to (2^^63 - 1) to make use of 64 bit platforms. This will
affect messageID, sizeLimit and timeLimit.

Thanks,
Prasad

---

From: John McMeeking <[email-masked]>
Date: Mon, 27 Sep 2004 07:58:29 -0500

I agree with keeping the existing limits, though I hope an implementation
would return protocol error if presented with a value greater than 2^^31 -
1 for these fields.

messageID - message ids are assigned by the client.  Increasing the current
limit (for any of the fields) would require a mechanism for the client to
determine that the larger range is accepted by the server -- protocol
version = 4 or something like that.

timelimit - I doubt there is any need for timelimit to exceed the current
limit of 68 years ;-)

sizelimit - I have a hard time seeing a need for specifying a search limit
greater than 2 billion entries.  If this limit were number of bytes, rather
than number of entries, maybe.

John  McMeeking

[email-masked] wrote on 09/26/2004 10:44:54 PM:

> Well ... no. You've pointed out that maxInt is architecture
> dependent, but for interoperability I think the value can't depend
> on architecture.
>
> If you send the messageID 2^^32 + 15 to a 32-bit system, you could
> reasonably expect to receive the messageID 15 in response, which
> would naturally be rejected.
>
>

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 27 Sep 2004 12:33:32 -0700

>messageID - message ids are assigned by the client.

The server cannot return a protocol error here without itself
violating the protocol.  Notice of Disconnect seems more appropriate
here (especially given that it likely that the future requests
would also likely suffer from the same problem).

For the other cases, returning protocol error seems reasonable.
However, a server may not be able to parse PDUs containing
INTEGERs above maxInt.  So here, Notice of Disconnect is also
reasonable.

I see no need to elaborate on this in [Protocol].  Do you?

Kurt

---

From: John McMeeking <[email-masked]>
Date: Mon, 27 Sep 2004 14:55:02 -0500

I don't think any elaboration in [protocol] is necessary.  I was just
explaining my response.

John  McMeeking