headers
Erland Sommarskog | 1 Dec 1999 10:52
Picon
Picon

Re: Warning about Imperative/Reflex Headers

"G. James Berigan" <usefor <at> war-of-the-worlds.org> writes:
> It seems that the current proposal for Mail-Copies-To and its current
> implementation in several newsreaders has brought into existence and a new
> and troubling header class: the Imperative Header, defined as a header
> which causes an action to be taken that would not necessarily be taken in
> its absence.  Specifically, Mail-Copies-To is causing an e-mail message to
> be sent if its content is "poster", "always" (obsolete), or an e-mail
> address (in common implementation, any other content not recognized as a
> keyword) by default rather than by conscious choice of the user.

In my opinion, it's only beneficial for the confusion factor to introduce
a header class only deprecate it. Is there any other conceivable header
of this kind, apart from this Mail-Copies-To?

People may write proposals for Mail-Copies-To, but am I utterly naïve,
when I assume that these proposals are written in vain, if we fail to
include these proposals in our Standard? That is, if we don't mention
Mail-Copies-To, then the proposed semantics are implcitly deprecated.
Of course, we can't prevent people from putting in non-standard headers,
neither prevent newsreaders from acting on these non-standard headers.
But this applies even if classify them as Reflex headers.

I fully agree with Greg that the defined semantics for Mail-Copies-To
are bad. In fact, I have always found this proposed header to be of
marginal value.
--
Erland Sommarskog, Stockholm, sommar <at> algonet.se
Permalink | Reply | 7 comments |
headers
Jonathan Grobe | 1 Dec 1999 16:04
Picon

Re: Section_7.02.03

On Wed, 1 Dec 1999, Charles Lindsey wrote:

>    The Newsgroups header of each control message MUST include the
>    newsgroup-name(s) for the group(s) affected (i.e. groups to be
>    created, modified or removed, or containing articles to be
>    canceled).

Your examples don't do this, where is example.admin.info in the
Newsgroups header in the newgroup example? Where is example.admin.obsolete
in the  Newsgroups header in the rmgroup example? Where are the several
dozen groups in the Newsgroups header in the mvgroup example?
Are you sure we want to do this (put potentially hundreds of groups)
in the Newsgroups header for mvgroup messages?

> 7.1.4.  Example
> 
>    A "newgroup" with bilingual charter and policy information:
> 
>       From: "example.all Administrator" <admin <at> example.invalid>
>       Newsgroups: example.admin.groups,example.admin.announce
>       Date: 27 Feb 1997 12:50:22 +0200
>       Subject: Group example.admin.info created.
>       Approved: admin <at> example.invalid
>       Control: newgroup example.admin.info moderated
>       Message-ID: <ng-example.admin.info-19970227 <at> example.invalid>
>       Content-Type: multipart/mixed; boundary="nxtprt"
>       Content-Transfer-Encoding: 8bit
> 
> 7.2.1.  Example
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Charles Lindsey | 1 Dec 1999 12:32
Picon
Picon

Section_7.02.03

I posted this at the ned of last week, but to the old address at
templetons.com. It doesn't seem to have appeared.

Here is the revised draft of section 7, incorporating results of recent
discussions. The diffs are at the end. The principal changes are as
follows:

1. Clearer text on what to put in Newsgroups header for Control
messages.

2. "unmoderated" flag removed.

3. Various notes on more-or-less obvious implementation techniques
removed.

4. The application/news-groupinfo is now UTF-8 regardless, with no
charset parameter.

5. The "For your newsgroups file:" is now optional, but SHOULD be
present.

6. mvgroup comp.* computers.* (i.e. '*' in both places).

7. "moderated" flag reuired in a mvgroup if the (new) group is moderated

8. possibility of mvgroup comp.foo (as a way of just doing a newgroup)
removed

9. Invalidations (that line beginning with '!') entirely removed from
checkgroups.
(Continue reading)

Permalink | Reply | 67 comments |
headers
Unknown | 1 Dec 1999 18:47

Duplicates.

If you received duplicate messages this morning it was due 
to a mailer problem here.  The cause has been corrected so 
it should not happen again.  Sorry for the inconvenience.

--

-- 
Kent Landfield                        Phone: 1-817-545-2502             
Email: kent <at> landfield.com             http://www.landfield.com/
Email: kent <at> nfr.net                   http://www.nfr.net/
Search the Usenet FAQ Archive at http://www.faqs.org/faqs/
Search the RFC/FYI/STD/BCP Archive at http://www.faqs.org/rfcs/
Permalink | Reply | 1 comment |
headers
John Moreno | 1 Dec 1999 20:52

Re: Warning about Imperative/Reflex Headers

sommar-usefor <at> algonet.se (Erland Sommarskog) wrote:

This message was sent to usefor <at> rkive.landfield.com, it looks like it
got onto the mailing list anyway, but... 

> "G. James Berigan" <usefor <at> war-of-the-worlds.org> writes:
> > It seems that the current proposal for Mail-Copies-To and its current
> > implementation in several newsreaders has brought into existence and a new
> > and troubling header class: the Imperative Header, defined as a header
> > which causes an action to be taken that would not necessarily be taken in
> > its absence.  Specifically, Mail-Copies-To is causing an e-mail message to
> > be sent if its content is "poster", "always" (obsolete), or an e-mail
> > address (in common implementation, any other content not recognized as a
> > keyword) by default rather than by conscious choice of the user.
> 
> In my opinion, it's only beneficial for the confusion factor to introduce
> a header class only deprecate it. Is there any other conceivable header
> of this kind, apart from this Mail-Copies-To?
> 
> People may write proposals for Mail-Copies-To, but am I utterly naÔve,
> when I assume that these proposals are written in vain, if we fail to
> include these proposals in our Standard? That is, if we don't mention
> Mail-Copies-To, then the proposed semantics are implcitly deprecated.

No, I don't see that at all -- they aren't endorsed, which is a
different thing all together.  Given the number of programs that have
actually implemented this, it could probably make its own way through
the RFC process as a standalone, without reference to USEFOR at all.

(Isn't the minimum 2 separate implementations?)
(Continue reading)

Permalink | Reply | 5 comments |
headers
Russ Allbery | 1 Dec 1999 22:37
Picon
Favicon
Gravatar

Re: Section_7.02.03

Charles Lindsey <chl <at> clw.cs.man.ac.uk> writes:

> Here is the revised draft of section 7, incorporating results of recent
> discussions. The diffs are at the end. The principal changes are as
> follows:

The changes look good.  Thanks!

> 7.1.  The 'newgroup' Control Message

>       newgroup-verb       = "newgroup"
>       newgroup-arguments  = CFWS newsgroup-name [ CFWS newgroup-flag ]
>       newgroup-flag       = "moderated"

>    The "newgroup" control message requests that the specified group be
>    created or changed. The newgroup-flag "moderated" is appended to
>    mark the group as moderated. The absence of this flag marks the
>    group as unmoderated. The message body comprises or includes a
>    "multipart/news-groupinfo" (section 7.1.1) part containing machine-
>    and human-readable information about the group.

>         NOTE: some alternative flags such as "y" and "m", which are
>         sent and recognised by some current software, are NOT part of
>         this standard and MUST NOT be used.

Do we want to mention extensions here, with something like:

     "newgroup" control messages containing an unknown newgroup-flag
     SHOULD be ignored, and specifically MUST NOT be treated as equivalent
     to a "newgroup" control message for an unmoderated newsgroup.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Terje Bless | 1 Dec 1999 22:30
Picon

Mail-Copies-To, again... (was: Warning about Imperative/Reflex Headers)

On 01.12.99 at 14:52, John Moreno <phenix <at> interpath.com> wrote:

[about Mail-Copies-To]
>No, I don't see that at all -- they aren't endorsed, which is a different
>thing all together.  Given the number of programs that have actually
>implemented this, it could probably make its own way through the RFC
>process as a standalone, without reference to USEFOR at all.
>
>(Isn't the minimum 2 separate implementations?)

It's out there. It's in use. It should be documented. Saying it's nasty
horrible stuff and /shouldn't/ be used is another thing, but it should be
documented as current practice.

>Request for messages to be both posted and mailed, in the body of
>messages, are not all infrequent (I see it in the body at least twice a
>week).

Yes, but the use for the "extended" syntax where you can stuff an email
address in there (so CCed followups can go somewhere other than Replies) is
pretty marginal stuff. What is really necessary is a way to say "I want CCs
of followups" which is basically a boolean (default is no CCs). A boolean
function shouldn't require a separate header field.

What was the outcome of the discussion on having a field where we could
stuff flags like this along with X-No-Archive and similar stuff? Could the
functionality be put there and Mail-Copies-To deprecated? Barring that,
"Mail-Copies-To: never" could be replaced by "Reply-To: <>" and
"Mail-Copies-To: always" could be left in limbo (which would probably
legitimize defaulting to CCed followups in the long run since there is a
(Continue reading)

Permalink | Reply | 4 comments |
headers
Clive D.W. Feather | 1 Dec 1999 23:18

Re: Duplicates.

Kent Landfield said:
> If you received duplicate messages this morning it was due 
> to a mailer problem here.  The cause has been corrected so 
> it should not happen again.  Sorry for the inconvenience.

Pity I got that message 17 times.

--

-- 
Clive D.W. Feather  | Work:  <clive <at> demon.net>   | Tel: +44 20 8371 1138
Internet Expert     | Home:  <clive <at> davros.org>  | Fax: +44 20 8371 1037
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Permalink | Reply | 0 comments |
headers
G. James Berigan | 1 Dec 1999 23:34

Re: Warning about Imperative/Reflex Headers

kaih <at> khms.westfalen.de (Kai Henningsen) wrote:
>usefor <at> war-of-the-worlds.org (G. James Berigan) wrote:

> We're also not trying to prevent flooding newsgroups by restricting
> Followups-To: headers. That's exactly the same situation.

No, Followup-To isn't exactly the same situation.  If I choose to send an
e-mail message with my newsreader, the presence of a Followup-To header is
irrelevant and does not cause the emission of a news posting.  If however I
choose to post a followup, the presence of a Mail-Copies-To header of value
"poster" or an e-mail address DOES cause the emission of an e-mail message
BY DEFAULT.  That is the implementation that is making its way into more
and more newsreaders, giving this header a power not exhibited by any other
header.

> And there is certainly no reason for those headers to *not* allow multiple
> addresses.

And I have yet to see even one good reason for those header to *allow*
multiple addresses.  If there's no good reason *for* it, why allow it?

>> What really enables the power for abuse is the Imperative nature of the
>> header.  If the header instead behaved in a passive manner like the other
>> *-To headers Reply-To and Followup-To, there wouldn't be a problem even
>> with MCT containing multiple addresses itself.

> Well, it does behave in exactly that way as far as I can see. It sends
> something under exactly the same condition that Followup-To: does. The one
> is exactly as imperative as the other.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Seth Breidbart | 2 Dec 1999 04:42
Picon
Favicon

Re: Mail-Copies-To, again... (was: Warning about Imperative/Reflex Headers)

>  Barring that,
> "Mail-Copies-To: never" could be replaced by "Reply-To: <>"

Except that I _want_ people able to send me email in response to
postings, and it should go to the appropriate address; I just don't
want automatic copies of followup posts mailed to me, I'll read them
int he newsgroup if I care.

So, that doesn't match the desired functionality.

Seth
Permalink | Reply | 3 comments |

Gmane