NANOG Community,
The issue of altering the NANOG Archive has come up and I wish to present Merit’s position on the matter.
The NANOG Acceptable Use Policy as it currently stands includes the following:
Discussion will focus on Internet operational and technical issues as described in the charter of NANOG.
Postings of issues inconsistent with the charter are prohibited.
:
Postings that include foul language, character assassination, and lack of respect for other participants are prohibited.
:
The part of the post in dispute is not operational or technical and clearly shows a lack of respect for a participant. The subject of the post and not the poster requested that we remove his name from the post in the Archive. Merit has decided to replace the subject’s name with “NAME REMOVED”. Since this post was not allowed, we believe that we are correcting our mistake in a way that we think has the least impact on the integrity of the archive. We are not removing the post itself. The poster’s name and the rest of the text are intact. The topic of the post is still clear even though the individual targeted is not. Operational or technical content was not modified.
We have considered a number of things in making this decision including: the age of the post, the reason for the request and Merit’s legal exposure. We let the Steering Committee know what we were doing. If you disagree, do not blame the Steering Committee although we consulted with the Steering Committee, it was my decision.
This issue has been helpful in that it pointed out some shortcomings in our policies and notification mechanism. We are working with the Steering Committee to address those now.
We are not removing a thoughtless post at the request of the poster and do not anticipate doing so in the future.
This issue is unique and does not represent a blanket policy. Any request to modify the archive is a serious issue that requires consultation with the Steering Committee and must be balanced against the loss of archive integrity.
Bill, it's really time for you to upgrade from UCB Mail to Pine. Those of
us who've gotten with the program and upgraded to 1990's software get all
the nasty <tag> things stripped out automatically!
This issue is unique and does not represent a blanket policy. Any
request to modify the archive is a serious issue that requires
consultation with the Steering Committee and must be balanced against
the loss of archive integrity.
Right here is the heart of the matter. This is a unique issue. Attempts to set policies to cover unique issues _will_ result in bad policies.
Policies should be set to cover the general cases. Management prerogative (which should be bounded by policy) will best deal with the unique issues.
PINE? looking at MUTT, but i'm really partial to
UCBMail stripping out all kinds of cruft/spam.
Next you'll be telling me that IMAP is the wave of
the future and that i should read email on some
PDA/CELL thingie...
you sent html as opposed to an email message. as i do not use a web browser
to read mail, i can not read your message. if you want me to read your
email, send email.
It was tagged as text/html, but 'mutt' will usually pass such things off
to my Web browser, and it didn't. Not sure why not. But when I forced
the issue, it passed it to the Web browser - and I still saw the raw
HTML. I'm not sure what the problem was. Another Web browser did
translate the page.
IOW, some recent programs will not be as generous as accepting
problematic input as others, and some recent programs unfortunately
still produce problematic output.
you sent html as opposed to an email message. as i do not use a web browser
to read mail, i can not read your message. if you want me to read your
email, send email.
An e-mail message *can* in fact, be HTML, as HTML is a text payload like any
other.
It's not his (or the world's) fault your MUA is locked into 1982 mode and
won't process the tags that are included in it.
Cheers,
D
>
>you sent html as opposed to an email message. as i do not use a web browser
>to read mail, i can not read your message. if you want me to read your
>email, send email.
>
>randy
>
More to the point, why punish the entire list by bickering about a
minority inability to cope with the fact that some people are different?
I'm sure if the message had been posted in Spanish, or hey, maybe even
French, since English isn't the singular language of North America, this
wouldn't be an issue.
The world has more than eight bits. The community at large (read: me) does
not care if someone has been left out because they *chose* to be or lacks
the ability or wherewithal to adapt. In short: Technical snobbery is not
operational. It took more effort to respond saying the mail couldn't be
read than it probably took to sanitize it for reading. Being a member of
the vocal minority isn't a point of pride, you're just louder than
someone else.
All ten out of the ten dinosaurs interviewed agree: Evolve, dodge the
flaming ball of death, or stop showing up for dinner. The network will
still be here long after your non-threaded news reader stops working.
i suspect the html non-email issue has been discussed a bit in the past. but perhaps folk can not find the previous discussion because it has been removed from the archive :).
so, since we need to relive it, perhaps we should do so over on nanog-futures.
but there are a couple of more significant issues being discussed over there, those surrounding the community's desires for maintaining mailing list archive integrity.
More to the point, why punish the entire list by bickering about a
minority inability to cope with the fact that some people are different?
It's because some MUAs are dain bramaged.
The world has more than eight bits.
Which is just one of the reasons that the MIME type
"multipart/alternative" exists. Sane MUAs that wish to send HTML also
send a text/plain alternative segment in the same MIME stream.
The unfortunate part is that this classifies Thunderbird as not
"sane", because its default configuration for dual-format output is
"ask me" based on whether all addresses are in the address book with
the HTML option enabled, rather than simply always sending multipart
by default.
I can understand that. The point I'm trying to make, is why does Randy
Bush *need* to make this a community problem, instead of talking directly
to the user whose mail he cannot read? Why clog up nanog-l and
nanog-futures over such a trivial issue that can be solved behind the
scenes with something as simple as a polite query? Better yet, how about a
polite email to the gang over at Thunderbird? They strike me as a pretty
reasonable bunch that's open to community input.
A couple of the responses I got to my initial salvo were, in summary,
'because it's NANOG.' As funny and appropriate as the answers may be, I
hold up any recovering crack addict as an example. If you know you have a
problem, and you can do something about it, please think of the children
and put the pipe down.
Bring back the exploding squirrel threads. Please. They may not have been
directly operational, but at least they weren't a email flavored rehash of
vi vs emacs.
Vernon Schreyer made a very good point years ago that multipart/alternative
is fundementally busticated, because there's two options:
Option 1: The actual information content of both the text/plain and text/html
is identical. Sending the html is therefor superflous.
Option 2: There is added crucial semantic content in the HTML (links, table
formatting, etc) that is not representable in the text/plain. At that point,
sending the text/plain is *also* incorrect, as it allows the receiving MUA to
punt and provide an incomplete and incorrect version of the information. Sending
just the text/html and requiring the receiving MUA to do the downgrading with
more precise knowledge of the exact non-representable brain damage is the
correct behavior here (for instance, some MUAs are able to provide clickable
links after filtering to text/plain, but unable to do proper table alignment).
Similar ideas are included in RFC4141, where the receiving end provides info
on what can/cant be displayed.
In either case, sending both plain and html versions is boneheaded and wrong.
The world has more than eight bits. The community at large (read: me)
does
not care if someone has been left out because they *chose* to be or lacks
the ability or wherewithal to adapt. In short: Technical snobbery is not
operational. It took more effort to respond saying the mail couldn't be
read than it probably took to sanitize it for reading. Being a member of
the vocal minority isn't a point of pride, you're just louder than
someone else.
I don't know why this is even an issue.
I'm on a shell account, on a linux box, reading mail using Pine, and HTML
mail is rendered just fine here, as text with some minimal amount of
markup (extremely minimal).
Pine runs on just about anything, has been around for years, is stable,
and doesn't require plugins or mailcap entries to sanely render HTML to a
text-only display.
