headers
Keith Moore | 1 Dec 01:10
Picon

Re: Attempts at establishing harmful conventions


>> what's broken is something else - perhaps our expectation that all 
>> messages in a thread should have the same subject.
>
> Users often reply to mail in order to start a new thread with the same 
> set of folks in it.  Sometimes they change the subject when they do 
> this, sometimes they don't.  You can bet they NEVER edit the 
> References or In-Reply-To fields before they send the mail (a few 
> members of this mailing list excepted, no doubt).
>
> So if you don't consider subject when doing threads, you lose one 
> thing that users actually DO occasionally use to mark a new topic.

a changed subject is not a reliable indicator of a new thread.

just because the author of a reply changes the subject from that of the 
message being replied to doesn't mean that the reply is unrelated to 
the message being replied to, and it doesn't mean that recipients won't 
want to see the relationships between the messages.

users are lazy - they will sometimes reply to a message just as an easy 
way to get the same recipient list, even if the topics are different.  
often they don't even change the subject.    (but how many MUAs give 
users a better way to do this?)

Keith
Permalink | Reply | 11 comments |
headers
Nathaniel Borenstein | 1 Dec 01:16
Favicon

MoreOn: Attempts at establishing harmful conventions


Distinguished and revered colleagues,

I think we need to distinguish between human-level conventions and 
protocol elements.  Any "harmfulness" in the former is not something 
that can be addressed technically.

When you choose the "Reply" function in your MUA, and it gives you a 
window in which the subject has been initialized to "Re: <old 
subject>," this is at best a "helpful suggestion" from your MUA, 
because you can always change it.  In the case of this particular 
message, for example, I decided to change it to "MoreOn" and no harm 
was done, unless someone chose to regard it as an insulting pun.  (And 
don't tell me that your mail reader needs "Re:" for message threading, 
because if your MUA can't get thread info from the In-Reply-To field, 
it isn't trying hard enough.)

Ultimately, the user-editability of "Subject" makes it almost valueless 
as a machine-usable protocol, but highly valuable for interpersonal 
conventions.  We should not be surprised, however, if different 
conventions arise among different subcultures, perhaps with subtly 
different semantics.  In fact, this happens all the time -- some email 
communities already have informal but quite complex norms for making 
their subjects "more useful" at the human level.  (I put "more useful" 
in quotes because they aren't always more useful -- at IBM, 
confidential messages often start with an "IBM Confidential and 
Proprietary" prefix that is so long as to eclipse all information in 
the subject, but it is a convention which is almost mandatory within 
the company.)  This is not a problem of protocol design -- it is simply 
a reality of evolving human norms and etiquette.
(Continue reading)

Permalink | Reply | 17 comments |
headers
Steve Dorner | 1 Dec 01:20
Favicon

Re: Attempts at establishing harmful conventions


At 7:10 PM -0500 11/30/04, Keith Moore wrote:
>users are lazy - they will sometimes reply to a message just as an 
>easy way to get the same recipient list, even if the topics are 
>different.  often they don't even change the subject.

Barring Bayesian analysis, I think we're SOL if they don't change the subject.

But if they do change the subject, and one slavishly follows IRT 
anyway, how is that A Good Thing?
--

-- 
Where are we going, and why are we in this handbasket?
Permalink | Reply | 10 comments |
headers
Keith Moore | 1 Dec 01:28
Picon

Re: Attempts at establishing harmful conventions


>> users are lazy - they will sometimes reply to a message just as an 
>> easy way to get the same recipient list, even if the topics are 
>> different.  often they don't even change the subject.
>
> Barring Bayesian analysis, I think we're SOL if they don't change the 
> subject.

I think we're SOL if user interfaces don't evolve.

Keith
Permalink | Reply | 0 comments |
headers
Keith Moore | 1 Dec 01:33
Picon

Re: MoreOn: Attempts at establishing harmful conventions


> I think we need to distinguish between human-level conventions and 
> protocol elements.  Any "harmfulness" in the former is not something 
> that can be addressed technically. [...]

I dislike intermediaries that modify the subject line.  Otherwise, I'm 
substantially in agreement with your message.

and if we start asking users to fill in multiple fields that are 
descriptive of the messages they send - one for the topic, another for 
message attributes (reply, forward, confidential, etc) the instructions 
for trying to get users to "do the right thing" with those fields are 
going to look as if Lewis Carroll wrote them.
Permalink | Reply | 4 comments |
headers
Steve Dorner | 1 Dec 01:39
Favicon

Re: MoreOn: Attempts at establishing harmful conventions


At 7:16 PM -0500 11/30/04, Nathaniel Borenstein wrote:
>I think we need to distinguish between human-level conventions and 
>protocol elements.  Any "harmfulness" in the former is not something 
>that can be addressed technically.

Ok, human bad, protocol element good.  That's quite clear.  Pesky humans.

Is [nameoflist] inserted by a list processor a human-level convention?

If a machine puts it there, I think it's reasonable for another 
machine to try to take it out.  If we as an Internet community can 
make that easier, we will have done a good thing.
--

-- 
Where are we going, and why are we in this handbasket?
Permalink | Reply | 9 comments |
headers
Nathaniel Borenstein | 1 Dec 01:51
Favicon

Re: MoreOn: Attempts at establishing harmful conventions


The "[listname]" insertion is clearly the "sore point" case.  This is 
natural because it seems to defy the otherwise reasonable-sounding rule 
that i myself proposed, which is that the Subject field is for human 
beings.  However, I'm not sure that this is really as bad a layering 
violation as it might seem.  While the list processor is indeed 
inserting something into the "human" part of the stream, it is (at 
least in theory) doing so in accord with a policy set by a list owner.  
A list owner should be able to choose to insert any strings he wants to 
in messages that go through his list, to convey a meaning that he wants 
to convey.  The fact that list processors make it so easy to insert 
such strings may be simply a reflection of the fact that so many list 
owners want to be able to do that.  But they want it for its human 
meaning, not for any intended protocol consequences.

I would certainly be unhappy with a list processor that *required* the 
insertion of such strings, but when a list administrator chooses to 
have them inserted,this is the human moderator's decision to "put his 
mark" on all messages to the list.  Sort of like a dog urinating on a 
tree -- it may not always be pretty or desirable, but it's going to be 
awfully hard to design a tree that can prevent itself from being peed 
on.  -- Nathaniel

On Nov 30, 2004, at 7:39 PM, Steve Dorner wrote:

> At 7:16 PM -0500 11/30/04, Nathaniel Borenstein wrote:
>> I think we need to distinguish between human-level conventions and 
>> protocol elements.  Any "harmfulness" in the former is not something 
>> that can be addressed technically.
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Bruce Lilly | 1 Dec 01:50
Picon

Subject field hacks and machine processing of "only human-readable information"


On Tue November 30 2004 18:27, Keith Moore wrote:

> what's wrong with abbreviations?

Not much per se.

> why should I have to say "reply to  
> your message: Attempts at establishing harmful conventions" instead of 
> using "Re:"?

If this were a century ago and taking place via pieces
of paper, something like "Re: your correspondence of
30 November" might be appropriate.  For quite some
time there has been provision in the message
format for something similar (via the In-Reply-To
field, which until 2822 was permitted to contain a
phrase such as the above), However, it has been
unnecessary to do so in the Subject field (that is
redundant with In-Reply-To).  In the specific
instance cited, you could simply leave the Subject
field unaltered, or change it if the topic changes
(as I have done in this message).  Unlike century-old
paper correspondence, modern electronic messages
carry with them a set of references to previous
correspondence, making explicit reference in the
Subject field unnecessary.

> more to the point, why is it a bad idea for the subject  
> to indicate that the message is a reply or some other kind of response?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Keith Moore | 1 Dec 01:52
Picon

Re: MoreOn: Attempts at establishing harmful conventions


>> I think we need to distinguish between human-level conventions and 
>> protocol elements.  Any "harmfulness" in the former is not something 
>> that can be addressed technically.
>
> Ok, human bad, protocol element good.  That's quite clear.  Pesky 
> humans.

well, the human behavior is at least somewhat influenced by the 
interfaces they're using.  improved interfaces might produce better 
behavior independently of any changes to protocol elements or how they 
are used.

> Is [nameoflist] inserted by a list processor a human-level convention?
>
> If a machine puts it there, I think it's reasonable for another 
> machine to try to take it out.  If we as an Internet community can 
> make that easier, we will have done a good thing.

perhaps.  but while we might accept an arms race ("complexity race"?) 
as a short-term necessity,  it seems like there are better ways for 
lists to tag their contents and for MUAs to display information about 
list origin to recipients.
Permalink | Reply | 2 comments |
headers
Steve Dorner | 1 Dec 02:05
Favicon

Re: MoreOn: Attempts at establishing harmful conventions


At 7:52 PM -0500 11/30/04, Keith Moore wrote:
>it seems like there are better ways for lists to tag their contents 
>and for MUAs to display information about list origin to recipients.

I agree.  But I don't think lists are the only problem here.

I think there are increasing numbers of proxies and filters that all 
would like to communicate with the recipient, and are prevented from 
doing so by MUA's that show only certain fields, period.

If a solution for lists generalizes to virus scanners, security 
software, etc, etc, good.  If it's just a special case for lists, I 
don't think we've solved the problem.
--

-- 
Where are we going, and why are we in this handbasket?
Permalink | Reply | 1 comment |

Gmane