Re: More comments on the mailserver URL scheme

[ You wrote: ]

} Is the danger that the limit '512' is too short, or that there should
} be no limit at all? If the former, what would you propose as a
} reasonable limit?

Actually, I think I'd prefer to see no fixed limit, and
put in negotiation mechanisms so clients and servers can
specify what's needed to work together in all cases, but I
don't know how successful this approach would be (since it
would require all developers to buy in). Certainly
"reasonable" limits for humans (eg. 512 bytes) is not
enough for machines now and as we go on, we can only expect
the required length to grow.

} > Setting a general limit on the lengths of URLs may be a
} > practical necessity, but 512 bytes is way too short for
} > some of the applications we're already seeing. We've run
} > into problems with early clients that had URL buffer
} > lengths set too low when using URLs in which the selector
} > portion contains strings which are machine generated and
} > used internally by the server.
} 
} This sounds like an argument for having a well-known length limit.  If
} clients are going to have any limit at all, it would be useful for
} servers to know what it might be so that they won't send out URLs that
} the clients can't handle. Right?

I think it is an arguement for the client and the server
to agree on how long a URL will be and well-known limits
is the easiest way to do that. Negotiating a length on
each transaction is going to cost, and thus we probably
want a fixed limit. I just can't help but think how much
trouble we went through to increase the file name size in
UNIX a few years ago...


					- peterd


-- 
------------------------------------------------------------------------------

  ...there is reason to hope that the machines will use us kindly, for
  their existance will be in a great measure dependent on ours; they will
  rule us with a rod of iron, but they will not eat us...

                                               - Samuel Butler, 1872
------------------------------------------------------------------------------

Received on Sunday, 25 June 1995 12:13:10 UTC