Robert Rosenberg writes:
>There is a limit on how long a URL can be. That type of URL gets long
>very fast if you are embedding the actual data into it.
Yes, but staying within 2000 characters is generally regarded as safe,
which is presumably a lot for the sort of ancillary data Brian wants to
transmit. Also, there's no particular requirement how to encode the data.
You could use something like this:
...myurl.com?data=abcdef...
where the data ("abcdef...") consists of one long string of parameter
information that has first been compressed (e.g. AMATERSEd) then
pseudo-xxencoded (shorter) or hex coded (longer), for example. You are not
required to use the classic param1=xyz?param2=123?param3=abc sort of
format.
For some degree of future proofing, instead of data= you might choose
myprodcode1.0= so that you can change the format in the future but still
interpret and support the old encoding format if necessary.
Shmuel Metz writes:
>That won't work for e-mail clients that don't support clicking on a
>URL.
That's true, but it's also presumably true that the installations sending
these e-mails would control their format (via a parameter in the product to
switch between plain text and HTML e-mail output, ideally per user) and
have at least indirect management authority over the recipients and thus
influence their e-mail capabilities. I don't think these e-mails are
getting sent to arbitrary individuals.
In other words, I don't think having e-mail clients with clickable (or
tappable) URLs (to internal Web sites) is an *unreasonable* prerequisite to
enjoy this ancillary functionality, especially in 2014 and beyond.
--------------------------------------------------------------------------------------------------------
Timothy Sipples
GMU VCT Architect Executive (Based in Singapore)
E-Mail: [email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
