I am working on an AI NNTP application that will be capable of communicating both with people and with clones of itself via NNTP. This works in "repair paradigms" whether you are repairing people, electronics, networks, relationships, etc. However, this will cause a significant problem on newsgroups shared with other non-automated human users:The clone-to-clone communications, while it will be made as people-readible as possible, will nonetheless be pretty uninteresting to casual readers. Much of this traffic will be minor "tweaks" to its distributed database. Obviously this can easily be hidden within X-HeaderFields, but there is no way to hide the entire messages from those who would chose not to see such messages.A different but parallel problem is the issue of adult-content SPAM, etc., which is another category of communications that many users wish would become invisible.What is clearly needed is a published standard header field that states why a message should be suppressed for some readers. Perhaps something like:Content: AdultorContent: UpdatesOn a different but related note, lots of NNTP traffic is third-party, where someone is researching something for someone else. Since NNTP clients are now pretty easy to build, these should find their way into various proprietary medical, legal, and other products, but now can't. There is presently no standardized way to recognize a reply on a newsgroup and map that back to just which patient or client it refers to, without a doctor, lawyer, consultant, etc., spending their valuable time actually reading the postings to find what pertains to their clients. There REALLY needs to be a field that propagates this information so that automated newsreader software can recognize pertinent replies and file them with the clients that they pertain to.Article IDs might possibly be made to work, but these are NOT provided by a POST command, so there is no way to know what to look for without some VERY complex logic to pick this information out of your own postings when they eventually become visible. Another meaning of the word "Subject" is the name of the person that this is about, but "Subject:" already has other meanings. What is needed is something that is carried from posting to responses to carry jewels of essential filing information, like who this is really about.This is really out of place on a Subject: line, because who wants to seeRe: Patient 930-87-1435on a subject line?! This should properly be hidden from view in the header. There needs to be something like:Client: 930-87-1435in the header that is specified to be propagated from original posting to response to response much like the Subject: line is, but without any modification whatsoever, and without automatically displaying it to the reader.Note that all of the above issues relate NOT to how my application works, as I have absolutely no problem using X-format header lines. Rather, they affect how OTHER software works, both with satellite communications and with messages that my software will soon be posting. Let's fix this stuff so that automated NNTP applications can eventually become a smooth reality. Their present lack certainly demonstrates the problems that such applications now face with the RFCs as they now stand.Steve Richfie1dSteve@smart-life.net
|
