On Mon, 29 Apr 2013, Andrew Deason wrote:
On Fri, 26 Apr 2013 14:43:09 -0400 (EDT)
Benjamin Kaduk <[email protected]> wrote:
typedef opaque RXGK_Data<>;
[ ... ]
RXGK_Data token;
[...]
If we were to explicitly limit the size of a token (or a generic
RXGK_Data, I suppose), what would such a limit be? If we start
talking about X.509 identities, maybe 16k is too small?
Some care is called for here. We've had issues in the past with
limits on token sizes, so we should try to avoid setting one that is
too small.
I think perhaps the right thing here might be to say that the limit
is implementation-defined (or subject to local policy), but MUST NOT
be less than a certain value.
I could see doing something like that.
So, does this mean each rxgk-using application gets its own slightly
different RPC-L? To make it easier, of course at least define a constant
for all of these and just have the application define it. Unless we're
talking about just not putting limits in the RPC-L, and having the XDR
decoder enforce these limits a different way.
The RPC-L in OpenAFS will differ from that in the document regardless, as
we will use the afs_[u]intNN types instead of int/hyper/etc.
It does not seem a big deal to also change an array limit.
I would say just use a limit of 100M or something and forget about it,
but if this can somehow work well with specifying this per-application,
then sure.
The above notwithstanding, I don't really see a problem with just using
100M, either.
-Ben
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
