Re: Protocols at the Point of a Gun
4/11/96, Bill Stewart wrote:
There are serious technical problems with the suggestion that labelling packets as "Adult" or "Child" using IP options and filtering at ISPs for censorship.
IMHO, the technical problems can somehow be solved, whether we like it or not, although it will probably be botched intentionally or otherwise. It's tougher than most protocol upgrades, but easier than was designing X.400 (just to give some GROSS bounds to the problem). My (simplistically presented) suggestion in such a scheme would be that we don't want a "flag" on packets: we want two "fields": - content-classification field in packets: _roughly_ analogous to a dewey-decimal number -- says a lot (?) about the content, not merely which end of the library it goes in - user-classification field appended to user-id's: a micro-bio of the user -- says something about age, languages known, interests Before you flame -- I'm not thinking about the potential abuses, I'm thinking about the useful applications: more useful filtering based on such fields can be installed as agents on: - user machine - "dial-in" network node - retrieval engines - database engines "A great project is only a little harder than a good project" - A Kay Regards, -rkm (not on cypherpunks) ~=-=-=-=-=-=-=-=~=-=-=-=-=-=-=-=-=~--~=-=-=-=-=-=-=-=-=~=-=-=-=-=-=-=-=-=~ Posted by Richard K. Moore - rkmoore@iol.ie - Wexford, Ireland Cyberlib: www | ftp --> ftp://ftp.iol.ie/users/rkmoore/cyberlib ~=-=-=-=-=-=-=-=~=-=-=-=-=-=-=-=-=~--~=-=-=-=-=-=-=-=-=~=-=-=-=-=-=-=-=-=~
On Fri, 12 Apr 1996, Richard K. Moore wrote:
4/11/96, Bill Stewart wrote:
There are serious technical problems with the suggestion that labelling packets as "Adult" or "Child" using IP options and filtering at ISPs for censorship.
IMHO, the technical problems can somehow be solved, whether we like it or not, although it will probably be botched intentionally or otherwise. It's tougher than most protocol upgrades, but easier than was designing X.400 (just to give some GROSS bounds to the problem).
Hello? We're talking packets, not sessions. Trying to do this at the network layer (or lower) is so monstrously wrong that it's not worth talking about. It's impossible by design. In a properly designed system, the application should have no way to tell the protocol stack to flip special bits. What about encapsulation? Fragmentation? LAN emulation? Although... if you're talking ATM PVCs rather than packets, I could imagine adding minor/adult negotiation to the setup phase. But despite the hype, I don't expect to see many people using raw ATM (not LAN emulation/encapsulation) for a decade, if at all.
My (simplistically presented) suggestion in such a scheme would be that we don't want a "flag" on packets: we want two "fields": - content-classification field in packets: _roughly_ analogous to a dewey-decimal number -- says a lot (?) about the content, not merely which end of the library it goes in
- user-classification field appended to user-id's: a micro-bio of the user -- says something about age, languages known, interests
We're talking packets here, not sessions.
Before you flame -- I'm not thinking about the potential abuses, I'm thinking about the useful applications: more useful filtering based on such fields can be installed as agents on: - user machine - "dial-in" network node - retrieval engines - database engines
For this you use different TCP ports and out-of-band cryptographic authentication, not extra fields in the packets. -rich
participants (2)
-
Rich Graves -
rkmoore＠iol.ie