From mark at kram.org Sun Dec 7 20:19:18 2003 From: mark at kram.org (Mark Turner) Date: Sun Dec 7 20:19:17 2003 Subject: nntp-extensions Re: New FAQ/metadata proposal Message-ID: <199608231455.PAA14359@clio.kram.org> Rich Salz wrote: > > If the FAQ is in a URL, then the server would send an appropriately-created > Message-ID and the ARTICLE (and perhaps HEAD) command would be extended > in the server (in one place, not breaking the model of all newsreaders) > would go act as an HTTP client. Consider what might happen if someone managed to specify that the charter (or whatever else, defined by URL) for a particular group was inside a firewall and reachable by the news server but was not normally reachable by the news reading user. I don't like the idea of turning news servers into proxy servers of any flavour, unless there are very tight controls available. Even then some paranoid admins might not be happy to allow such a setup. Cheers, Mark. From mark at kram.org Sun Dec 7 20:19:18 2003 From: mark at kram.org (Mark Turner) Date: Sun Dec 7 20:19:18 2003 Subject: nntp-extensions Re: Multicasting news Message-ID: <199608251020.LAA07165@clio.kram.org> Brian Kantor wrote: > > I think multicasting as a way to distribute news is a damn good idea, if > we can figure out how to do it. Fills, FEC, and other techniques could > be used to ensure that some large percentage of the news is distributed > as first-effort broadcast, with traditional NNTP filling in the holes. I currently have most of the news servers at PIPEX receiving more than 70% of their news via multicast over the PIPEX backbone. The next version of the software will cope with much higher percentages. The same technology will be used by our recently announced satellite news service. In both cases standard NNTP feeds are used to fill in the holes. We do intend to make the protocol and a sample implementation available once the service is fully tested and has gone live. Whilst my work was done from scratch I did go visit the folks at UUNet and have incorporated some ideas that came out of their experiments with MUSE. Cheers, Mark. From clewis at nortel.ca Sun Dec 7 20:19:18 2003 From: clewis at nortel.ca (Chris Lewis) Date: Sun Dec 7 20:19:20 2003 Subject: ietf-nntp Re: nntp-extensions draft-ballou-nntpsrch-00.txt Message-ID: <199612181826.MAA02210@academ.com> In message "Re: ietf-nntp Re: nntp-extensions draft-ballou-nntpsrch-00.txt", 'Chris.Newman@INNOSOFT.COM' writes: >On Tue, 10 Dec 1996, Brian Hernacki wrote: >> Interesting reading Nat. After the feedback we received, Ben and I had >> also been changing our draft to have SEARCH return overview-like data >> directly (without virtual groups). For demand searching (not profiles) >> it seems to be a cleaner approach..and people seemd to like this lighter >> weight approach to SEARCH better. >I think Nat has exactly the right idea -- take IMAP's SEARCH command, >remove the stuff that doesn't apply to NNTP, then add the cross-group >search using a syntax that could be added to IMAP4 via an extension. Do >it that way, and you don't have to fight the character set battle or >address any of the other problems that IMAP has already solved. Unless I misread things, I think it might also be worth while to mention that I find the profile mechanism (having the server remember preferences) somewhat awkward and too heavy-weight. The obvious, simply having the nnrpd (or equivalent) process remember the profile, can cause operational problems if the server has to restart it for some reason or other. The notion of session (with today's offline newsreaders, batching newsreaders, archaic versions of netscape which spawned nnrpd for every command ;-), and operational considerations etc) hasn't been clear for quite some time. A more complex solution, having nnrpd place the profile in a file for later retrieval causes storage management issues not seen before. I tend to not like the idea of the server having to retain any more client-specific state than "current group" and "current article number". Thus, I prefer a more stateless SEARCH mechanism. As per syntax, reusing someone else's standard sounds like a good idea to me. -- Chris Lewis, Senior Network Security Analyst, Nortel. clewis@nortel.ca; Dept 4C16, Ottawa, Canada. (613) 763-2935. From clewis at nortel.ca Sun Dec 7 20:19:18 2003 From: clewis at nortel.ca (Chris Lewis) Date: Sun Dec 7 20:19:20 2003 Subject: ietf-nntp Re: nntp-extensions draft-ballou-nntpsrch-00.txt Message-ID: <199612191806.MAA15107@academ.com> In message "Re: ietf-nntp Re: nntp-extensions draft-ballou-nntpsrch-00.txt", 'bhern@netscape.com' writes: >> A more complex solution, having nnrpd place the profile in a file for >> later retrieval causes storage management issues not seen before. >This is what I imagined implementations would do. It's not really that >hard. >> I tend to not like the idea of the server having to retain any more >> client-specific state than "current group" and "current article number". >Personally, I like the idea of pushing more onto the server and making >the clients more lightweight. I'm not suggesting it's particularly hard to implement. However, you may want to consider: 1) people adjusting headers etc - how do you identify which profile belongs to whom? (short of full authentication) 2) ensuring that person A's profile isn't exposed to person B - confidentiality concerns. (short of full authentication) 3) storage management - lifetime expectancies? Cleanup? Size? Formats? Another expire program? 4) Why is this different than the newsgroup listing in the client-side .newsrc equivalent? If we were to do this, shouldn't we push the .newsrc at the server too? The .newsrc could be 10s of kilobytes. That's a significant amount of storage on a large server (ie: around 50Mb on one of our servers). This introduces a whole new ballgame of per-user storage and a new security dimension to the server. I think it would be better to push storage of profiles onto the client - it's no big deal to implement it on a client as an adjunct to the already-necessary per-user .newsrc equivalent. Even if you contemplated having the server proactively kick a client with a search match, there's no point in trying that unless the client already has an established connection, and has already downloaded its search profile to the server. I think the only advantage of having persistance on the server is so that the server could scan inbound articles as they arrive and produce listings of articles to present to the user when they next log in. Do we need this? Does doing it this way end up cheaper than doing it when the client asks for it? -- Chris Lewis, Senior Network Security Analyst, Nortel. clewis@nortel.ca; Dept 4C16, Ottawa, Canada. (613) 763-2935. From pettern at thule.no Sun Dec 7 20:19:18 2003 From: pettern at thule.no (Petter Nilsen) Date: Sun Dec 7 20:19:21 2003 Subject: nntp-extensions Dealing with internationalization in NNTP In-Reply-To: <344CFAF2.C3B136CD@netscape.com> Message-ID: <1203.234T18T1550736@thule.no> In article <344CFAF2.C3B136CD@netscape.com>, bhern@netscape.com (Brian Hernacki) wrote: > see us defined something like UTF8 as the default charset used. While I > heard from people who agreed with me on this, I didn't hear any > objections. Is this OK? Do poeple think this would be a bad thing? If > not should we change the draft? UTF8 sounds fine. > o a language specification/negotiation extension > While having the charset well known is great, it still doesn't help the > Japanese user who gets error messages popping up in English. What I'd > like to see is something akin to IMAP's LANGUAGE extension. This allows > client and server to negotiate a non-default language to use for things > like error messages, newsgroup descriptions, etc. Thoughts? Ok, this sounds fine, but what _language_ should the LANGUAGE command take the parameter in? Native language introduces some charset problems.. -- \\\\\\ Petter Nilsen - IRC: Mitchman - mailto:pettern@thule.no |\ >>>>>>============================================================| > ////// THOR Team Coordinator - http://www.thule.no/~pettern/ |/ From sew at ces.kyutech.ac.jp Sun Dec 7 20:19:18 2003 From: sew at ces.kyutech.ac.jp (sew@ces.kyutech.ac.jp) Date: Sun Dec 7 20:19:22 2003 Subject: nntp-extensions Unsold Orders of SEWING MACHINES ! Message-ID: <199903041224.NAA11004@www.mag-net.de> There is no need to respond to the above email address to be removed. This is a 1 Time Mailing ********************* * PUBLIC SALE !! * ********************* UNSOLD ORDERS OF SEW AND SERGE SEWING MACHINES ! _________________________________________________________________ *** To view machine click below or visit ! *** http://3438189385/ar/sew The Necchi Company produced a large quantity of their 1999 Sew and Serge Sewing Machines, anticipating increased sales. But due to the current market conditions, these orders remain unsold. *********************************** * THESE MACHINES MUST BE SOLD! * *********************************** These heavy duty machines are made of metal, with metal gears. They have been prepared for sale to schools and cottage industries nationally. The manufacturer warrants these machines for 5 years against parts failure. WHY PAY THOUSANDS OF $ FOR A SERGER AND SEWING MACHINE WHEN A SEW AND SERGE SEWING MACHINE DOES IT ALL! _________________________________________________________________ Today Necchi offers a machine that performs all of your sewing tasks! ** 1st: As a sophisticated sewing machine, it performs: Buttonhole (any size), Stretch, Invisible Blind hems, Monograms, Quilting, Elastic Stitch, Top Stitching Applique, & Decorative sewing. Turn the dial and sew magic! ** 2nd : The Built-In Professional Serging stitch: allows you to sew super strong seams and over edge the material in one step... Our optional cutter trims as you sew. ** 3rd: No more complicated threading and you don't have to tie off seams like you do with a serger! They handle all fabrics with ease. They even sew on leather and vinyl. _________________________________________________________________ ALL MACHINES ARE CABINET READY IN FACTORY SEALED CARTONS. Your price when mentioning this ad. ***************** * $198 * ***************** _________________________________________________________________ LIMITED STOCK! Phone orders accepted with major credit cards ** To view machine and or place your order click below or visit! ** http://3438189385/ar/sew/