[Ti] Why do URL's die when wrapped?

[Mark C. Langston]

On Mon, Jan 27, 2003 at 03:18:50PM -0500, b wrote:
> 
> No, I believe that the manner in which mail messages are displayed, 
> differs, but all emailers wrap somewhere these days. Maybe the 
> wrapping [which one sees in those 'quotes' where every other line is 
> only one or two words] occurs only in certain mail apps, or on the 
> the output from smtp servers, i don't know.

There's almost always a maximum line length imposed somewhere, either
in the MUA or MTA, even though it may appear to "wrap" around the
maximum displayable lines in the MUA.

Postfix, for example, has a default maximum line length of 255 
characters, and will break longer lines.  RFC821 and 2821 (which
supercedes 821) specify that lines must be a maximum of 1000 characters
in length, including CR/LF.  RFC2821 recommends a maximum length of
78 characters.

As the RFCs and STDs are the standards and draft standards upon which
all mail servers (and clients) are based, you're going to run into
line breaks whether your MUA allows you to type continuously without
hitting return, or not.


> 
> It used to be that email clients sent one long line of text, broken 
> only [on the sender's end] by hard carriage returns, or paragraphs. 
> As i compose this text, here, in Eudora, I can stretch the window so 
> that it spans two monitors and there is no 'wrap' at all. Except for 
> the paragraph 'commands'.

...and as I read it, in an 80-column xterm (or at console with an
80-column display), it's broken for me at 78 characters or less, As It
Should Be(TM). 

email got to be the ubiquitous tool it is today by respecting the
constraints of all likely environments.  To keep it ubiquitous, it's
important to continue respecting those constraints.

To take a page from the HTML/browser philosophy:  You worry about the
content; let the delivery and display mechanism worry about how to
display it.

Of course, as long as the delivery and display mechanism includes
text-based e-mail (and, as long as server logs and emails must be read
from console or via remote serial connection, it will), we won't 
progress beyond simple text-based email with kludges for dealing with
things like URLs.  Many people have neither the inclination nor need to
click directly on a URL in an email; copy-and-paste works just as well,
and allows the user enough time to consider what it is they're about to
do, should they decide they dno't want to do it.

One might argue that this is all a throwback to appease the *nix crowd.
I'd tend to direct the attention of such people at phones and pagers and
other portable devices that have severe constraints on data flow,
display size, and processing power.  They are the future, not the past,
and text-based email and messaging is their bread-and-butter.





> 
> Word wrap has never bothered me, and I  have to assume that the 
> 'uglier', unbalanced line lengths, that one sees in other people's 
> "quoted" text, occasionally, must originate from Entourage,or 
> Outlook..


*putting on Psychology hat*

There are many psychological studies that demonstrate the desireability
of a ragged right-hand-side.  It improves readability.

> I never have problems with my 'own' URLs, yet, we see, all 
> the time, that URLs that are underlined on one line, and 'broken' 
> [i.e. not underlined, and not in brackets] don't always work 

If they're underlined, it's because the user's MUA has recognized the
text as a URL and has displayed it as an active, clickable item.  Some
MUAs process and guess at URLs better than others.  A good test is
to append a period at the end of a URL, such as http://bitshift.org.
A good MUA will ignore the period.  A bad MUA might not.  And this 
says nothing of the fact that "bitshift.org." is a valid, parseable
domain and should work just fine... "." indicates the top level of
the DNS hierarchy.

Of course, a URL appended by another punctuaion, such as
http://bitshift.org!  is perhaps a better test in certain circumstances.



> Or, 

(note:  The reason there's one word on that line is because the "Or"
was the last word on the previous quoted sentence, and I manually
broke that line for readability and added the line-initial '>'.  It's
easier to do that than to prepend it to the following line, and thus
have to re-justify all subsequent text, as well as reposition all
'>' quote indicators.

Some MUAs may do this for the same reasons of expediancy as I've done it
here.)


> they'll lead to a 'parent' and some of the 'children' of the URLs 
> domain structure, but not all the way to the intended URL's page. My 
> point was that this is where the email app is 'forcing a normal [in 
> it's terms] line break, and by the user 'forcing a carriage return 
> before that point, the break in the URL can be prevented.
> 

Indeed.  Even (luddite that I am) using a text-based MUA (mutt) and
a text-based editor (vim), the editor's smart enough to wrap an entire
URL to the next line, should it encroach on my preset line-length.

Of course, it can't do much about URLs that are longer than 78
characters.  But one could argue that the problem there lies with the
overly (and often unnecessarily) long URL, and not the preset
line-length limit.



-- 
Mark C. Langston                                    Sr. Unix SysAdmin
mark at bitshift.org                                       mark at seti.org
Systems & Network Admin                                SETI Institute
http://bitshift.org                               http://www.seti.org