headers
Jonathan Grobe | 1 Mar 2000 06:36
Picon

Time to Attempt Implementation of New Draft?

Judging from the recent discussion, there does not seem to be much
controversy about the new features added in the new draft. Consequently
I think it is time to attempt implementation of these in test versions
of news software. Comments? Any volunteers?

--

-- 
Jonathan Grobe      Jonathan Grobe Books. Used & out-of-print books:
Search or browse subject catalogs: <http://www.netins.net/showcase/grobe>
For millions of used/out-of-print books try <http://www.abebooks.com>
<http://www.bibliofind.com> <http://www.bookavenue.com>
Permalink | Reply | 13 comments |
headers
Andrew Gierth | 1 Mar 2000 07:08
Picon
Picon

Re: RFC 1036 Revision: Replaces/Supersedes/Xref Headers

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

 >> 1. the message-id versioning stuff imposes significant constraints
 >> on the design of the history mechanism. The fact that it happens
 >> to be possible with INN's dbz is not a convincing argument.

 Brad> What are those constraints?

The requirement that given an existing (unversioned) message-id
<foo <at> bar>, that it be possible to update that (whether by adding a
duplicate entry or by other means) to refer to a different article.
(The arrival of article <foo$n=2$xxx <at> bar> changes the result of doing
a lookup of <foo <at> bar>.)

 Brad> I've never liked the xref additions, though.  I've always felt
 Brad> that replace-in-place is the right answer.

That does not solve the implementation problems. In particular, the
requirement to locate the article numbers of the article being
replaced is still a show-stopper on clustered systems.

--

-- 
Andrew.
Permalink | Reply | 43 comments |
headers
Andrew Gierth | 1 Mar 2000 07:11
Picon
Picon

Re: Time to Attempt Implementation of New Draft?

>>>>> "Jonathan" == Jonathan Grobe <grobe <at> netins.net> writes:

 Jonathan> Judging from the recent discussion, there does not seem to
 Jonathan> be much controversy about the new features added in the new
 Jonathan> draft. Consequently I think it is time to attempt
 Jonathan> implementation of these in test versions of news
 Jonathan> software. Comments? Any volunteers?

I, for one, do not yet consider the draft to be even close to being
implementable.

--

-- 
Andrew.
Permalink | Reply | 8 comments |
headers
Brad Templeton | 1 Mar 2000 09:22
Picon

Re: RFC 1036 Revision: Replaces/Supersedes/Xref Headers

On Wed, Mar 01, 2000 at 06:08:54AM +0000, Andrew Gierth wrote:
> >>>>> "Brad" == Brad Templeton <brad <at> templetons.com> writes:
> 
>  >> 1. the message-id versioning stuff imposes significant constraints
>  >> on the design of the history mechanism. The fact that it happens
>  >> to be possible with INN's dbz is not a convincing argument.
> 
>  Brad> What are those constraints?
> 
> The requirement that given an existing (unversioned) message-id
> <foo <at> bar>, that it be possible to update that (whether by adding a
> duplicate entry or by other means) to refer to a different article.
> (The arrival of article <foo$n=2$xxx <at> bar> changes the result of doing
> a lookup of <foo <at> bar>.)

Well, not if one does replace with the same article number, as I
had always intended it when I proposed this header.   However, it is
not strictly necessary to alter the record for <foo <at> bar> to attain this
goal.   In particular, article fetch by message-id is currently not a
very common thing, and in particular, fetch by message-id of a replaced
article is unlikely to become common, even in a suck feed.

So the implementation, with any history mechanism is as follows:

	a) Fetch <foo <at> bar>.  Note that article is not present.  (It was
		replaced, after all.)
	b) Fetch special record named V<foo <at> bar> or some
		other record not to collide with actual message-ids.
		This can be a pointer to the current record for <foo <at> bar>
		(actual message-id, contents or just the number itself)
(Continue reading)

Permalink | Reply | 5 comments |
headers
Andrew Gierth | 1 Mar 2000 09:35
Picon
Picon

Re: RFC 1036 Revision: Replaces/Supersedes/Xref Headers

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

 >> The requirement that given an existing (unversioned) message-id
 >> <foo <at> bar>, that it be possible to update that (whether by adding a
 >> duplicate entry or by other means) to refer to a different article.
 >> (The arrival of article <foo$n=2$xxx <at> bar> changes the result of doing
 >> a lookup of <foo <at> bar>.)

 Brad> Well, not if one does replace with the same article number,

Article numbers don't have anything to do with it. My history file,
like that of most current servers, is a mapping from message-id-digest
to storage-location; the storage location has no relationship to the
group or article number. I don't even store the actual message-id in
the history.

 [replacement in place]

 >> That does not solve the implementation problems. In particular, the
 >> requirement to locate the article numbers of the article being
 >> replaced is still a show-stopper on clustered systems.

 Brad> The number of articles involved in version chaining will be
 Brad> several orders of magnitude less than the total article volume.
 Brad> Effectively, it will be regular postings and corrected
 Brad> postings.  Fetch by message-id can be very common but fetch by
 Brad> message ID of since-replaced articles will not be as far as I
 Brad> can see..

This is irrelevent. The problem is what to do about fetch by _number_
(Continue reading)

Permalink | Reply | 4 comments |
headers
Erland Sommarskog | 1 Mar 2000 09:43
Picon
Picon

Re: .invalid (MUST versus SHOULD) alterative

John Stanley <stanley <at> peak.org> writes:
> Because they cannot do it. Pretend you are the injecting agent at Deja.
> I've posted an article with the From: address "stanley <at> peak.org". Am I
> authorized to use that address? I next post with the address
> "stanley <at> argus.oce.orst.edu". Am I authorized to use that address?

Hm, I've never posted through Deja myself, but I am under the impression
that Deja do require that you post through a usuable address. I suppose
that is carried by means if registration. If you have registered
stanley <at> argus.oce.orst.edu, then you are not authorized to use that
address as far as Deja is concerned.
--
Erland Sommarskog, Stockholm, sommar <at> algonet.se
Permalink | Reply | 1 comment |
headers
Brad Templeton | 1 Mar 2000 09:50
Picon

Re: RFC 1036 Revision: Replaces/Supersedes/Xref Headers

On Wed, Mar 01, 2000 at 08:35:24AM +0000, Andrew Gierth wrote:
> >>>>> "Brad" == Brad Templeton <brad <at> templetons.com> writes:
> 
>  >> The requirement that given an existing (unversioned) message-id
>  >> <foo <at> bar>, that it be possible to update that (whether by adding a
>  >> duplicate entry or by other means) to refer to a different article.
>  >> (The arrival of article <foo$n=2$xxx <at> bar> changes the result of doing
>  >> a lookup of <foo <at> bar>.)
> 
>  Brad> Well, not if one does replace with the same article number,
> 
> Article numbers don't have anything to do with it. My history file,
> like that of most current servers, is a mapping from message-id-digest
> to storage-location; the storage location has no relationship to the
> group or article number. I don't even store the actual message-id in
> the history.

Yes, but is it not the case that you have the ability to store a pointer
of some kind, any kind at the storage location?    If you do, then it
becomes easy to do the indirection.  You certainly have to have the
ability to say "This article is no longer here" and wherever you say
that you probably have an ability to store a pointer saying, "and here
is where you can now find it."

But even if you don't, all I point out is that all you really need
is the ability to say "It's gone now" (Which is required by existing
rules) and the ability to somehow, somewhere, in some small database,
look up where it's gone.
> 
>  Brad> message ID of since-replaced articles will not be as far as I
(Continue reading)

Permalink | Reply | 3 comments |
headers
Brad Templeton | 1 Mar 2000 09:56
Picon

Re: .invalid (MUST versus SHOULD) alterative

On Wed, Mar 01, 2000 at 09:43:03AM +0100, Erland Sommarskog wrote:
> John Stanley <stanley <at> peak.org> writes:
> > Because they cannot do it. Pretend you are the injecting agent at Deja.
> > I've posted an article with the From: address "stanley <at> peak.org". Am I
> > authorized to use that address? I next post with the address
> > "stanley <at> argus.oce.orst.edu". Am I authorized to use that address?
> 
> Hm, I've never posted through Deja myself, but I am under the impression
> that Deja do require that you post through a usuable address. I suppose
> that is carried by means if registration. If you have registered
> stanley <at> argus.oce.orst.edu, then you are not authorized to use that
> address as far as Deja is concerned.

I don't think anybody dreams, until we have digital certificates of course,
of being able to verify individual e-mail addresses off of one's own
server.   That is not necessary in order to gain valuable anti-spam
techniques.

It is possible for anybody to determine if a *domain* exists or not,
and tell the difference between a fake domain and a real one.  Whether
a particular user is authorized to use an address at a given real
domain is the sole province of that domain, and that's fine.  It means
there is a responsible party, or one who has the power to sue or file
charges under the various laws that already exist to forbid people using
domains against the will of their owners.

Under my draft, there become three states:
	a) A real domain:  Either an authorized user, or somebody who
	has just set themselves up for a lawsuit by the domain owner.
	This creates checks and balances.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jonathan Grobe | 1 Mar 2000 10:28
Picon

Re: Time to Attempt Implementation of New Draft?

Besides comments from you I have seen very little comment that draft
sections are not implementable. [When I posted the draft I was surprised
that the big new complicated sections attracted very little comment--
I had been expecting that the additional readers would find a number
of flaws there.]

Please provide a list of the items which you feel are not implementable.

--

-- 
Jonathan Grobe      Jonathan Grobe Books. Used & out-of-print books:
Search or browse subject catalogs: <http://www.netins.net/showcase/grobe>
For millions of used/out-of-print books try <http://www.abebooks.com>
<http://www.bibliofind.com> <http://www.bookavenue.com> 

On 1 Mar 2000, Andrew Gierth wrote:
> 
> I, for one, do not yet consider the draft to be even close to being
> implementable.
> 
> -- 
> Andrew.
>
Permalink | Reply | 7 comments |
headers
Andrew Gierth | 1 Mar 2000 10:40
Picon
Picon

Re: RFC 1036 Revision: Replaces/Supersedes/Xref Headers

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

 >> This is irrelevent. The problem is what to do about fetch by
 >> _number_ of a replaced article. You want a fetch of the old
 >> article's number to return the new article instead; this requires
 >> that when the system which does the numbering receives the new
 >> article, it must be able to find the article numbers that were
 >> used for the old article. This is a sticking point on a cluster
 >> system, because even though the old article is still in the reader
 >> spools, it has likely expired from the hub itself.

 Brad> Ah.  You had expressed the problem is "how do I look up
 Brad> <foo <at> bar>" and did not ask this question.

To be precise, I brought this up in my initial post on the subject.

 Brad> Generally, I had not expected replacement to mandate that
 Brad> fetches of the old *number* should work,

Still doesn't solve the problem. Part of the functionality that you're
trying to add is for a newsreader to be able to tell "this new article
replaces that old one, we've already read the old one, no need to show
the new article".

Since tracking which articles have been read is almost invariably done
by article number, this means that there must be _some_ way to connect
the new article with the old article number. The draft says that this
is done via Xref, and my objection at the start of this thread is that
this would be expensive at best and impractical at worst.
(Continue reading)

Permalink | Reply | 2 comments |

Gmane