On Fri, 26 Apr 2013, Benjamin Kaduk wrote:
On Thu, 25 Apr 2013, Simon Wilkinson wrote:
Same question here - RXGK_Data has no limits.
But what would the limit be?
I suppose I can mention my commit message for when I went and put in length
restrictions:
%%%%%%%%%%%%%%
Supply bounds for variable-length arrays
Define constants and use them.
There is no limit for the RXGK_Data typedef at this time, though that
is perhaps the most important case to consider. Such a limit should
probably be merged in with a prospective limit on the generic OpenAFS
rx_opaque type.
The authenticator limit implicitly limits the appdata and call_numbers
fields, so separate limits are not needed there.
%%%%%%%%%%%%%%
It is tempting to say that we need not talk about a global limit for this
document and can move such discussion to the thread Andrew started
("Unlimited array lengths"). I suppose I can look if there is literature on
the size of GSS negotiation tokens for guidance.
A couple of data points: the RPCSEC_GSS spec (used for NFS) specifies an
opaque gss_token<> with no limit, and my examination of the FreeBSD and
linux NFS kernel sources did not find particular limits on most variable
length arrays. I don't think there's strong precedent for any particular
limit.
After reflection, I think that if we are to say anything about the limit
for the general RXGK_Data type (and similar), leaving flexibility for the
application as in Jeff's suggestion is the best option. This would
involve some customization of RPC-L for each application, but that doesn't
seem like a big issue.
I do feel like a generic solution (e.g., in rxgen, but still
application-specific) will be appropriate, and would supercede anything
specific here.
-Ben
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
