J. Scheerder | 1 Dec 22:13 1998
X-Face
Picon
Picon

Re: Internal draft release

Charles Lindsey:

> In <199811282146.WAA08343 <at> kairos.algonet.se> sommar-usefor <at> algonet.se (Erland Sommarskog) writes:

> >> An internal-to-the-group draft release is available now at
> >>
> >> http://tao.ne.mediaone.net/~dsr/draft-ietf-usefor-article-02

> Yes, this draft is just an assemblage of various texts into approximately
> the correct order, without any attempt to remove duplicate texts, or to
> format it correctly. Also, many changes and corrections I forwarded to Dan
> months ago are still not incorporated. Altogether a most disappointing
> effort.

I'd put that differently.  Slightly.

"This is rather pre-pre-final.  I'd be happy to lend a hand to help
 improve it."

Which is true.

-- J$
--

-- 
Everyone's entitled to my opinion.

Charles Lindsey | 2 Dec 19:48 1998
Picon
Picon

DRAFT: Supersedes, Replaces and Xref

The following reflects where I think we had arrived at after recent
discussions. I have left Brad's texts alone as far as possible,
consistent with the changes we are trying to make. But you will see
there are various matters we still need to think about, as indicated in
the texts, so these are clearly no way final.

Share and Enjoy!

6.16. Supersedes / Replaces

        These two headers take a list of msg-ids (msgid-list) that the
        current article is expected to replace or supersede. All
        listed articles MUST be treated as though a "cancel" control
        message had arrived for the message, except as detailed below.

        These headers are essentially synonyms, with a change in
        behavior - with "Replaces" it is intended that the new article
        be not shown to a reader who has already read the predecessor.

        The  Supersedes-content and Replaces-content specify articles
        to be cancelled on arrival of this one:

        Supersedes-content = msg-id *( CFWS msg-id )
        Replaces-content   = msg-id *( CFWS msg-id )

        NOTE: There is no "c" in "Supersedes".

        Older software supported only Supersedes, and with only one
        Message-ID. Until the Year 2000, software SHOULD generate
        Supersedes with only one Message-ID, and cancel control
(Continue reading)

Bill Godfrey | 3 Dec 01:31 1998
Picon
Picon

NoCem comments

Hello,

Having just read the charter for this WG, I note that one of our tasks is
to standardize the nocem. I can't see the subject in the mailing list
archive, so I'll take this opportunity to bring it up now.

If you are not familiar with the NoCeM, hvae a read of http://www.cm.org/

If I had my way from scratch, the format of a nocem would look different.
But having said that, nocem is out there and my dislike of the  <at>  <at>  symbols
really isn't worth a new standard just because I said so.

Nocem is out there. My suggestions will make the transition as painless as
possible.

My feeling is that a nocem message should be a type of control message, as
well as have a MIME type.

I suggest that all nocems should include the headers 
Control: nocem
Content-Type: application/nocem
Content-Transfer-Encoding: 7bit

or

Control: nocem
Content-Type: multipart/signed

(For those odd people who like S/MIME)

(Continue reading)

John Stanley | 3 Dec 01:37 1998

Re: DRAFT: Supersedes, Replaces and Xref


On Wed, 2 Dec 1998, Charles Lindsey wrote:

>         These two headers take a list of msg-ids (msgid-list) that the

"... contain a list of ..."

>         These headers are essentially synonyms, with a change in
>         behavior - with "Replaces" it is intended that the new article

"... synonyms, with one difference: with ..."

>         be not shown to a reader who has already read the predecessor.

I am not at all sure that this intent is mappable into a difference in
server behaviour. It is not the server that knows when an article has
already been seen by a user.

>         The  Supersedes-content and Replaces-content specify articles
>         to be cancelled on arrival of this one:

"... to be supreseded or replaced upon arrival...". Although the action of
supersedes and replace effectively includes cancelling, neither is a
cancel.

>         Older software supported only Supersedes, and with only one
>         Message-ID. Until the Year 2000, software SHOULD generate

What is special about 2000 that necessitates it being a proper noun, and
what is special about it in the first place? I know this is not a typo
(Continue reading)

Andrew Gierth | 3 Dec 02:33 1998
Picon
Picon

Re: NoCem comments

>>>>> "Bill" == Bill Godfrey <bill-usefor <at> bacchae.demon.co.uk> writes:

 Bill> Note: How would an existing news server cope when it saw a
 Bill> control message it doesn't recognise?

 Bill> I 'spose it would be one of...

 Bill>  a. File it in the control psuedo-newsgroup.
 Bill>  b. File it in control.nocem.
 Bill>  c. Put it in a control.* newsgroup, consistently.
 Bill>  d. Put it in the junk psuedo-newsgroup.
 Bill>  e. Ignore the Cancel header and put in the newsgroups listed in the 
 Bill>         Newsgroups: header.
 Bill>  f. Throw it away.

You missed out g. Mail it to the newsadmin.

(I once deliberately posted an invalid control message to one of the
demon.* groups to illustrate a point in a discussion of control message
vulnerabilities. I got quite a lot of responses from people who found it
in their newsmaster mailboxes....)

 Bill> An editorial message can have the Newsgroups: line as the
 Bill> newsgroups the offending message was posted in the first place,
 Bill> leaving the Subject: with nothing to do.

This is nice for group-based editorial NoCeMs, but not much use for
abuse-related NoCeMs.

 Bill> Much of these headers seem to duplicate the news
(Continue reading)

Brad Templeton | 3 Dec 04:16 1998
Picon

Re: NoCem comments

I see little reason for backwards compatability with the old NoCems.

They are generated by just a few parties who can easily generate them in
a new format.

In truth, in a proper system there is no such thing strictly as a NoCem.
There is just a cancel, in its bulk form.  There is no special signing
of such a message, it's the standard signing (whatever method we choose) for
any message.

My personal recommendation is not to even add a new message.  Simply say
that "cancel", if given no argument, or if perhaps given the argument
"multi", provides a list of message-ids in the body of the message which
are to cancel.

Everything else is part of other work.  The only very mild extension is
the extension of cancel to provide multiple messages in the body.  If
you really want we could define a new control message, but for what
reason?

The handling of where nocems go should be handled by the Distribution
header, with its slightly modified semantics.

The authentication of Nocems is no different from the authentication of
any other control message (except for the author's cancel which can also
use a cancel lock as is currently specified.)

Now the only thing I can think that might be special is if people want to
build complex advisory systems for nocems, to do things like cancel stuff
if they get nocems from 2 different people or something.  Is there desire
(Continue reading)

Andrew Gierth | 3 Dec 04:35 1998
Picon
Picon

Re: NoCem comments

>>>>> "Brad" == Brad Templeton <brad <at> templetons.com> writes:

 Brad> I see little reason for backwards compatability with the old
 Brad> NoCems.  They are generated by just a few parties who can
 Brad> easily generate them in a new format.

And they are processed by an unknown, larger number of users (either
individuals, or sites running NoCeM-on-spool).

 Brad> In truth, in a proper system there is no such thing strictly as
 Brad> a NoCem.  There is just a cancel, in its bulk form.

NoCeMs are not cancels.

A NoCeM is a classification of articles. The fact that some users
elect to remove articles from their spools based on that classification
is irrelevent.

 Brad> Or do readers wish to scan these things for personal lists?  In
 Brad> that case they aren't really control messages.

Exactly.

NoCeMs are useful for many other things than mere spam-removal.

--

-- 
Andrew.

Brad Templeton | 3 Dec 04:45 1998
Picon

Re: NoCem comments

On Thu, Dec 03, 1998 at 03:35:55AM +0000, Andrew Gierth wrote:
> Exactly.
> 
> NoCeMs are useful for many other things than mere spam-removal.

So in effect, what we're talking about is an annotation control message,
which adds attributes to articles, including but not limited to "this is
spam" and so on.

Now attributes can mean a lot of things -- binary things like "don't bother
reading" or english text, or other large things.

However, having the newsreader read the stream of annotations is surely
a slow and inefficient way to do things, and of course has the problem
of syncing the arrival of annotations with the articles. 

For example, you might want to not even read articles until annotations from
the people you like have arrived to tell you more.  But you might not want
to wait too long for them.

So you might have one control message which says, "Add the following
annotations to the following articles", which would be in effect a mime
multipart with one part per article to be annotated, with each part
consisting of a line with the message-id, and then the annotations in some
language.

This is not as bulky as it sounds.  Normally the mime delimiter would be
a simple "---", so you would see:

---
(Continue reading)

Ralph Babel | 3 Dec 12:12 1998
Picon

Re: NoCem comments

Andrew Gierth wrote:

> A NoCeM is a classification of articles.

So is a cancel.

> The fact that some users elect to remove articles from
> their spools based on that classification is irrelevent.

Ditto.

Charles Lindsey | 3 Dec 12:52 1998
Picon
Picon

Re: NoCem comments

In <yam7641.485.2014780464 <at> post.demon.co.uk> Bill Godfrey <bill-usefor <at> bacchae.demon.co.uk> writes:

>My feeling is that a nocem message should be a type of control message, as
>well as have a MIME type.

I am not so convinced that it should be a control message, but the Mime
idea is interesting.

>If you have access to a news server, and can post a control message without
>it leaking, please have a go, unless you think it'll crash the thing.

I tried on CNEWS. It put it in control, and did not report anything to the
newsmaster.

>As for how some application/nocem is defined...

>The start of a nocem message begins with a line reading
>" <at>  <at> BEGIN NCM HEADERS" (w/out quotes)

I think normal MIME practice would be not to have that  <at>  <at> BEGIN NCM HEADERS
at all (nor at the end). If it was inside some sort of multipart (likely)
than the normal MIME separators do all that is required (the purpose is
only to show where the strict NOCEM syntax begins and ends).

>The prologue (any text between the news header and this line) may include
>PGP headers and any explanatory text the issuer feels neccesary.

It would be better to put the whole thing inside a multipart/signed (yes,
there is a PGP version of multipart/signed).

(Continue reading)


Gmane