brad@looking.on.ca (Brad Templeton) (09/20/89)
With more thought I have decided that what I really need (and what might be useful to the net in general) is a mechanism to allow one news article to replace another. By this I mean that unlike a supersedes, where the old article is cancelled, and the replacement takes the next available article number, we would have a 'Replaces:' (or something like it) where the new article actually replaces the old, getting the same article number. With supersedes (or the simple cancel and repost) if you have read an old version, you still get the new version presented to you. For those who didn't read the old one, they only see one article, but it's out of order. With a replacment mechanism you would never see the article more than once, unless you went back to look. You would not see articles out of order, however, except for the various other reasons that happens. (See another thread) There are a couple of ways that replacement could be done: 1) A Replaces: header that is just like Supersedes: For backward compatibility, if an article has a Supersedes and an empty (or identical) 'Replaces:', a Replacement is done. Sites with semi-old software would ignore the 'Replaces' and do the supersedes of course. (Unfortunately, few sites understand supersedes as it is, so backwards compatibility with them may not be that useful.) 2) Replacement articles move out with the *same* message-id, but a later date of posting. If inews sees an article come in with a duplicate message id, instead of throwing it away, it checks the date from the history file (which it's already half-way to looking at). If the new message has a greater date, it 'Replaces:' the old. For redundency, such a lookup and replace might only be done if the message has some sort of replacement header. Sites with old software will toss such articles unfortunately. Now of course, replacement does allow a bit of revisionism to take place. But I doubt that is a big worry. Forgery also presents some ugly problems. No doubt some disk-rich sites can just move replaced articles to a 'to-be-deleted' spool directory, and also make sure there is a header in every replaced article stating that it is a replacement, version N, of this article. It is also important to allow replacements to 're-create' cancelled articles. This is important, since for sites with old software, you may have to issue a cancel of the old article anyway before replacing it. But this would also allow one to 'un-cancel' an article. Unfortunately, it presents problems in the case of multiple feeds and messages that get out of order, where a late cancel might come in and zap the replacement. (Perhaps cancel messages must include the version number to cancel a replacement?) In conclusion, I suspect the following is the preferred method: A) Replacement messages have a line of the form: Replaces: <message-id> <version> but they have a unique message-id. Such messages replace the actual files for <message-id>, or recreate some if cancelled. The addition or deletion of groups must also be dealt with. Replacement takes place only if the message is missing or the date on the replacement exceeds the date on the original. One always replaces using the *original* message-id, no matter how many replacements occur. The version number is a comment for the reader. Cancel messages may arrive for the original or subsequent versions, using the unique message-id of each message. A cancel for the original does not cancel any replacements, unless the cancel message has something in it to indicate it cancels all versions. -- Brad Templeton, Looking Glass Software Ltd. -- Waterloo, Ontario 519/884-7473
henry@utzoo.uucp (Henry Spencer) (09/22/89)
In article <17596@looking.on.ca> brad@looking.on.ca (Brad Templeton) writes: >2) Replacement articles move out with the *same* message-id, but a later > date of posting. If inews sees an article come in with a duplicate > message id, instead of throwing it away, it checks the date from the > history file ... Unfortunately, in the standard software (both B and C), the date in the history file is arrival date, not posting date. This will be difficult to change; things like NNTP know about it and rely on it. And having to dig through the article to decide whether a same-message-id article is a duplicate or not will be a massive headache -- it will slow news processing badly, and on NNTP it may not be practical at all. Many things assume that message-IDs really are unique identifiers (which is what they are supposed to be according to the RFCs) and that the message-ID<->contents relationship does not change. I think this had better be taken as a clear requirement. I don't think the forgery/fraud aspects of this are much worse than we have now with cancellations and such. There is a general problem with what the history-file entry for these things looks like. For things like duplicate checking and loop breaking, it is very important that new versions get their own history-file lines. But if they have distinct message-IDs, do they show up as regular entries with the same filename(s) as older versions? There are problems both ways. For example, expire (any version) is not prepared to cope with the notion that there might be more than one entry for an article -- it thinks that when the oldest entry expires, it is okay to remove the file. You really have to go back and rewrite the original entry, which is a major hassle. Appealing though "Replaces" sounds, the complications with things like the history file strike me as a strong indication that the mechanisms are being pushed beyond their practical limits. I suspect that a better approach is the combination of Supersedes (it is probably easier to get universal adoption of Supersedes than universal adoption of something new and strange) plus changes in the news reader(s). -- "Where is D.D. Harriman now, | Henry Spencer at U of Toronto Zoology when we really *need* him?" | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
brad@looking.on.ca (Brad Templeton) (09/22/89)
I don't see a big problem, if we forget about what I said about re-using the same message-id for a replacement. If the original message-id stays around with files associated, the new (replacement) message ids could instead be pointers to the original entry. We need to look up the date, to assure that if articles come in the wrong order, that an old one doesn't replace a new one, but that's only when replacing, and we can afford to read the real article for the posting date at this point. -- Brad Templeton, Looking Glass Software Ltd. -- Waterloo, Ontario 519/884-7473