From ftp-wg-owner@hethmon.com Fri Jun 2 01:10:36 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA13240 for ; Fri, 2 Jun 2000 01:10:35 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000602000428-59696-8 ; Fri, 02 Jun 2000 00:04:29 -0500 Received: from surfree (sdn-ar-009casfrMP218.dialsprint.net [158.252.240.220]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000602000423-25878-6 ; Fri, 02 Jun 2000 00:04:24 -0500 Message-Id: <20000602000423-25878-6@mail.hethmon.com> X-Sender: Do_Not_Reply@none.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 X-MSMail-Priority: Normal Date: Fri, 2 Jun 2000 00:04:26 -0500 X-OldDate: Thu, 01 Jun 2000 21:01:06 -0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Do_Not_Reply@none.com To: Online.Merchants! Subject: Ftp-WG: Accept Credit Cards Online! ACCEPT CREDIT CARDS ONLINE! Do you want to make more Money from your web site? There are over 50 million people with access to the Internet. Can you sell to 10,000 of them and profit $20 each? If you can you will make over $200,000. Thousands of other businesses are selling online BECAUSE IT WORKS! We have the LOWEST credit card processing rates in the industry starting from 1.6% No application fee until June 7th, 2000 (savings of $195) Access to your processing terminal from any computer with a Internet connection, 24 hours a day All money deposited directly into your business checking account (within 3 business days) Can Integrate credit card processing with any website (with forms) Complete Shopping Cart software "if needed" (offering the most widely used shopping cart on the Internet!) Guaranteed security for all transactions Complete setup in less than 5 days Toll Free Technical Support ______________________________ CHOOSE FROM THE FOLLOWING PRODUCTS: ______________________________ TOTAL STORE SOLUTION: * Bank Processing Merchant Account (account to accept credit cards) * Virtual Terminal (access your terminal from any computer with a Internet Connection) * Shopping Cart Software (features: hosted shopping cart, no software to download, most widly used on the Internet, all point and click without programming!) * Web Promotion Kit (includes: eMarketing book, web promotion software, ffa submission tool) TOTAL PRICE: from $59 / month __________________________ TOTAL STORE Light: * Bank Processing Merchant Account (account to accept credit cards) * Virtual Terminal (access your terminal from any computer with a Internet Connection) * Buy One Now! forms to integrate with your existing website * Web Promotion Kit (includes: eMarketing book, web promotion software, ffa submission tool) TOTAL PRICE: from $36 / month __________________________________ THERE ARE 3 WAYS TO GET STARTED: 1. Call us at the following telephone number: (415) 717-4787 (24hr LINE) 2. Click on the following link: http://www.geocities.com/a4157174787 3. Complete the following form and fax it back to us at: (253) 484-5081 TYPE OF BUSINESS: INTERNET_____ PHYSICAL STORE _____ MAIL ORDER______ ALL____ NAME ________________________ PHONE INCLUDE AREA CODE ____________________________ CITY_________________________________________ STATE________________ EMAIL ADDRESS______________________________ COMMENTS_____________________________________________ ______________________________________________________________________ ANY QUESTIONS? Call us at the following telephone number: (415) 717-4787 (24hr LINE) OR Send a fax to: (253) 484-5081 All applicants must be businesses residing in the United States. THIS IS NOT AN OFFER OR CONTRACT FOR A MERCHANT ACCOUNT, but rather a confidential informational inquiry and a free Ecommerce Consultation. All merchant applications will be reviewed and processed by one of the following F.D.I.C. insured banks: First National Bank, New Hampton; Humboldt Bank, Eureka; Woodforest National Bank; Houston. If you have received this email in error or if you wish to be removed from this list, please send an email to xme91@ifreedom.com and type in REMOVE in the subject line and your email address will be removed from our database within 24 hours. All information submitted is strictly confidential, and will be given to an Accounts Processing Professional who will contact you and provide your quote directly From ftp-wg-owner@hethmon.com Fri Jun 2 19:37:18 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA16997 for ; Fri, 2 Jun 2000 19:37:18 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000602183635-20797-7 ; Fri, 02 Jun 2000 18:36:35 -0500 Received: from havoc.entera.com (havoc.entera.com [206.165.109.130]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000602183631-61668-6 ; Fri, 02 Jun 2000 18:36:31 -0500 Received: from entera.com ([208.48.116.174]) by havoc.entera.com (Post.Office MTA v3.5.3 release 223 ID# 0-61971U200L100S0V35) with ESMTP id com for ; Fri, 2 Jun 2000 16:31:02 -0700 Message-ID: <39384457.CE35B76B@entera.com> Organization: Entera, Inc. X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.7 i86pc) X-Accept-Language: en MIME-Version: 1.0 References: <61A45D5AE74BD311A76D00A0D21B18723672C8@magritte.felspar.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 2 Jun 2000 18:36:32 -0500 X-OldDate: Fri, 02 Jun 2000 16:33:43 -0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Stephen Head To: FTPEXT Working Group Subject: Ftp-WG: thoughts on ftp extensions and caching Content-Transfer-Encoding: 7bit How about: The control channel responses for RETR are a 125 response (non STREAM mode) and a 150 response (STREAM mode). An extended 125 response consists of: "125-Ext" CRLF 1*( SP entry CRLF ) "125 End" CRLF An extended 150 response consists of: "150-Ext" CRLF 1*( SP entry CRLF ) "150 End" CRLF where: entry = [ facts ] SP pathname facts = 1*( fact ";" ) fact = factname "=" value factname = "Binary-Size" / "Size" / "Modify" / "Create" / "Type" / "Unique" / "Perm" / "Lang" / "Media-Type" / "CharSet" / os-depend-fact / local-fact os-depend-fact = "." token local-fact = "X." token value = *RCHAR and where pathname is the fully qualified pathname of the object* and facts MUST include the following factname-value pairs** if FEAT returns "X150" or "X125": Binary-Size Modify Note that a caching proxy server has the option of fetching the binary version of the file, even if it is ASCII that is being requested by the client. This makes reporting the Size (in contrast to Binary-Size, which would be the binary size of the file only) appear to be somewhat less critical. -s * permits managing file object cache using fully qualified pathname, presumed to be unique (even in presence of symbolic links on the server). ** presumeably the states of the other stuff is explicitly managed by the client and so not needed. I haven't exhaustively checked that this is the case (eg for 3-party transfers, etc.). ----- Dave Cridland wrote: > > > Before I commence wittering, a caveat: It's before noon here, and I'm > hungover, and can't remember everything in the MLST spec, and > unfortunately I'm at work and somewhat busy. > > However, I suggest the following: > > In responses to RETR commands, the Server-PI SHOULD respond with the > following as the text of the response: > > response = identifier SP mlst-line > > identifier = "" (or some such - more than a character should > avoid confusion) > > And also include the extra facts, not normally put in: > > "download-mode", "download-type", "download-structure" - defining the > method of downloading. Assuming I've remembered these right. > > The "size" fact, if present, should indicate to a reasonable degree > the size of the file being downloaded - perhaps not wholly accurately > for ASCII mode downloads, but enough for policy based caching systems > to take a view on whether to cache or not. > > Perhaps include an optional "download-size" fact for the exact size. From ftp-wg-owner@hethmon.com Fri Jun 2 23:44:37 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA21603 for ; Fri, 2 Jun 2000 23:44:36 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000602223915-10939-8 ; Fri, 02 Jun 2000 22:39:15 -0500 Received: from www.gsinet.it (192.106.99.138 [192.106.99.138]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000602223910-38737-6 ; Fri, 02 Jun 2000 22:39:11 -0500 Received: from [209.206.87.49] by www.occupazione.org (NTMail 4.20.0009/NU2370.00.ce28d7c3) with ESMTP id qvjkaaaa for ; Sat, 3 Jun 2000 05:35:11 +0200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Message-Id: Date: Fri, 2 Jun 2000 22:39:12 -0500 X-OldDate: Thu, 01 Jun 2000 20:34:38 -0800 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: massivereach@post.com To: denny@acme-rockets.com Subject: Ftp-WG: 10 MILLION ADDRESSES! Content-Transfer-Encoding: 8BIT 10 MILLION EMAIL ADDRESSES FOR ONLY $99 You want to make some money? we can put you in touch with over 10 million people at virtually no cost. Can you make one cent from each of theses names? If you can you have a profit of over $250,000.00 That's right, we have 10 Million Fresh email addresses that we will sell for only $99. These are all fresh addresses with no duplications. They are all sorted and ready to be mailed. That is the best deal anywhere today! Imagine selling a product for only $5 and getting only a 1/10% response. That's $1,350,000 in your pocket !!! Don't believe it? People are making that kind of money right now by doing the same thing, that is why you get so much email from people selling you their product....it works! we will even include, a FREE demo copy of the worlds leading BULK MAILING SOFTARE! These 10 Million email addresses and software are yours to keep, so you can use them over and over and they come on 1 CD. This offer is not for everyone. If you can not see just how excellent the risk / reward ratio in this offer is then there is nothing we can do for you. To make money you must stop dreaming and TAKE ACTION. **************************************** 10 MILLION email addresses on CD These name are all in text files ready to mail!!! (includes bulk mailing sotware) $99.00 ************************************************************* VISA/MC ONLY STEP 1: Print out the below ORDER FORM STEP 2: Type or Print your order information into the form STEP 3: FAX Your order to us. FAX TO: 415-704-3071 (Order with confidence. This is a secure fax area. Only our qualified sales team will have access to your order information) ORDER FORM(Print clearly with DARK pen) ************************************************************************************************ Name: ________________________________ Address: ________________________________ * *BILLING ADDRESS ONLY City, State, ZIP: ________________________________ Country: ______________ (International Orders) Phone Number: ______________ (In case we can't make out your order) METHOD OF PAYMENT- CREDIT CARD ONLY [ ]Visa [ ]MasterCard Credit Card #: __________________________________ Exp Date: _______________ Signature: ____________________________ (Required) E-Mail Address: ____________________________ *(PRINT CLEARLY!!) ************************************************************************************************ WE WILL BILL 99.00 to your account plus the following shipping costs SHIPPING COST OF 4.85 FIRST CLASS MAIL ALL INFORMATION NECESSARY FOR YOU TO SUCCESSFULLY MAIL, QUICKLY, PROPERLY, LEGALLY PROVIDED WITH ORDER Copyright 2000 All rights reserved From ftp-wg-owner@hethmon.com Sat Jun 3 18:37:41 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13115 for ; Sat, 3 Jun 2000 18:37:40 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000603173719-51524-8 ; Sat, 03 Jun 2000 17:37:19 -0500 Received: from siswa.utm.my (siswa.utm.my [161.139.18.6]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000603173711-23302-6 ; Sat, 03 Jun 2000 17:37:14 -0500 Received: from 161.139.18.6 by siswa.utm.my (SMI-8.6/SMI-SVR4) id GAA20126; Sun, 4 Jun 2000 06:35:51 -0800 Message-Id: <200006041435.GAA20126@siswa.utm.my> Date: Sat, 3 Jun 2000 17:37:17 -0500 X-OldDate: Sat, 03 Jun 00 17:32:03 EST Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Publishers@mx-212.fsnet.co.uk To: Publisher@mx-202.fsnet.co.uk Subject: Ftp-WG: Publishing Company for Sale! See information about Free Credit Application Below! My Multi-Million Dollar Publishing Company ONLY $149 Free Pre-Approved Merchant Account Application with Order!! To Start Your Business Out Right!! If you ever wanted "the easy way out" to make a lot of money with a business of your own.... Here is the EASIEST WAY TO START! I'm writing this letter to let you in on something that'll blow you away. What I'm about to present is something I've never done before...something that I'll never do again.... So PAY ATTENTION! For the past few years...I've have been running ads in newspapers & magazines, by direct mail, and throughout the internet. These ads were always small and very cheap... On these ads, we have been selling little manuals. These manuals have sold for anywhere between $10 to $99 each. We always ran different ads for each manual we were selling. I like selling information because NOBODY can put a price on it...ESPECIALLY when it is your own...The Sky is the Limit! Plus it is very cheap to reproduce How-To manuals. It costs between 40 cents and $3 to print the entire print manuals and around 35 cents to copy the manuals on disk. AND you can sell them for up to $99 each. That is one hell of a markup! These manuals tell you how to get a car with no money down and no credit...another one tells you how to avoid taxes by depositing income offshore...now you may not be interested in saving money by going offshore...but believe me....there are MILLIONS OF PEOPLE WHO DO...and they are willing to pay me to teach them!!! Well this is where the unbelievable offer comes in...I hope you are sitting down for this one...because this is a once in a lifetime chance for you. I do not know of an easier way to become financially independent...In fact THERE IS NO EASIER WAY!!! The next few paragraphs will reveal everything to you. I am willing to sell you my entire informational product line with FULL REPRINT RIGHTS and complete step-by-step instructions on how to start your mail order information business with very little money. Remember, these are PROVEN WINNERS. If you are stumped on something to sell or if you are having trouble writing a good ad, I have also included an entire book on disk to help you produce KILLER ads! This entire package which I call a Publishing Company in a Box will come on 1 CD containing over 2000 'Hot-Selling' Books, Reports And Manuals ready to print and sell, Sell, SELL! It also will come with a signed letter giving YOU FULL REPRINT RIGHTS allowing you to sell them for as much as you want and however you want. You Can even sell the entire kit to someone else to resale on their own! You also receive copies of KILLER ads which can fill your mailbox with cash! I am not even going to ask you for any of the money either... What you make is yours to keep . In fact...you get to make a ton of money on these manuals for as long as you wish...and you will never have to pay me another red cent in royalties! I am even going to print out and prepare our #1 selling report which contains the secrets of obtaining credit without a credit check and producing an offshore income without taxes so that you will be able to take it down to your local copy shop and be ready to sell it the same day you have received it. Watch out though - one individual is making $70,000 a month on this report alone! (Why - Because you can include a FREE offshore credit application for those with bad or no credit with this report and explode your mailbox with orders) Note: THIS APPLICATION IS INCLUDED! All I ask for is...$149 and I will include FREE Priority Mail Shipping! Yes, I said $149. There are no zeros missing. Plus if you order before June 10, 2000 I will include 4 extra special bonuses... Bonus #1 - "Search Engine Magic" on disk. This report will shoot your web site up to the top of the search engine listings. Other web advertisers are selling this manual for $99 by itself - But I will give it to you for FREE with this package. Bonus #2 - The report "How to Make at least $1,600 a week online...Starting Now!" which is taking the internet by storm will be included absolutely FREE! Bonus #3 - I will include special details about a secret source for direct mail leads that can produce cash orders along with out KILLER ads. And another source will be given which allows you to advertise nationwide through newspapers to 70,000,000 readers for as low as 7 cents per word. Bonus #4 - I also will include a pre-approved application for a merchant account for your business benefit. Taking credit cards will increase your business up to 100%. The normal $195 application fee will be waved with this pre-approved application. But there is one drawback... I am sending this ad to 10,000 other people...and I will only allow 50 kits to be sold. It wouldn't make much sense if I sold this kit to 1,000 or 2,000 people...The market would be saturated with these same manuals... and I don't want to do that. To make sure that the people in this offer get the same results I have...ONLY 50 people can have it for $149.00! Chances are, I will get all 50 within a week's time. So if this is something you are interested in...RUSH me a check or money order for $149.00 TODAY to insure your future business. But, even if you decide to pass this up...Don't sweat it. It's not like I am going to be mad or anything like that. I know I will get my 50 order limit really fast. And anyone who gets their check into me late... I will simply send it back. For only $149.00, I am going to let you have the easiest money you will ever make. The manuals are written, the ads are presented, the advertising plan is laid out, and all you have to do is print them out for pennies and place the ads. Do it today! Rush me your payment of $149.00 right now...and get your very own MILLION DOLLAR publishing company going! You can start with one or two manuals...even the day you receive the package...and then expand to include ALL of them! For $149.00, you have everything you need to make a killing with your very own business. If you want to make real money - then this offer is for you! "I took the report "Search Engine Magic" and sold over 50 copies on disk within 2 weeks! They sold for $99 and I was able to copy them for under 50 cents each. Wait till I start marketing the other products included in this line!!!" Joe Fisher - Internet Marketer To rush order this "MILLION DOLLAR Publishing Company in a Box" simply fill out the order form below and fax it to our 24 hour order line at: FAX ORDER LINE: 1 (212) 504-8032 Regular Mail to: Financial Systems P.O. Box 301 Orange, Ma 01364 ORDER FORM -------------------------------------------------------------- Please send to: Your Name__________________________________________ Your Address________________________________________ Your City____________________________________________ State / Zip___________________________________________ Phone #: ____________________________________________ (For problems with your order only. No salesmen will call.) Email Address_______________________________________ We Accept Checks or Money Orders along with all Major Credit Cards including Visa, MasterCard and American Express. (NOTE - We only ship to the address listed on the credit card) (Please Fill Out Below Section and Make sure that the above name and address are listed as it appears on the card) for $149.00 Credit Card Number:________________________________ Expiration Date___________________________ Signature:_________________________ Date:____________________ [ ] YES! Please rush my Publishing Company in a Box. I understand I have FULL REPRINT Rights and can sell any of the items for whatever price I desire, even the entire kit. [ ] DOUBLE YES! I am ordering before June 10, 2000! Please include the extra special bonuses! * Please check one of the following payment options: [ ] I am faxing a check (Do not send original, we will make a draft from the faxed check) [ ] I am faxing or mailing my credit card number. (Note your card will be charged for $149.00 and we only ship to the address on the card) [ ] I am enclosing a check or money order for $149.00! Note - If ordering outside continental US, please add $5 to S&H P.S. Don't forget you will receive 2,000 Manuals, Books, and Reports (Some of which are up to 200 pages each)...all for $149...You have full reprint and resale rights to make as much money as you want without ever paying any royalties whatsoever! _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ If you have received this message in error and would like to be removed from future mailings, please reply with the word remove in the subject. x _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From ftp-wg-owner@hethmon.com Sat Jun 3 21:45:18 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA13807 for ; Sat, 3 Jun 2000 21:45:18 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000603204449-593-8 ; Sat, 03 Jun 2000 20:44:49 -0500 Received: from mailbox.campus.rpslmc.edu (mailbox.campus.rpslmc.edu [144.74.60.10]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000603204410-37803-6 ; Sat, 03 Jun 2000 20:44:45 -0500 Received: from 63.23.238.206 (1Cust206.tnt2.durham.nc.da.uu.net [63.23.238.206]) by mailbox.campus.rpslmc.edu (8.8.4/8.8.4) with SMTP id VAA27311; Sat, 3 Jun 2000 21:33:00 -0500 (CDT) Message-Id: <200006040233.VAA27311@mailbox.campus.rpslmc.edu> X-Priority: 3 X-MSMailPriority: Normal Importance: Normal Date: Sat, 3 Jun 2000 20:44:47 -0500 X-OldDate: Fri, 02 Jun 00 21:36:14 Eastern Daylight Time Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: mm2mmgfh@wmin.ac.uk Subject: Ftp-WG: Make up to $1,000 or more a week from home! At Vanderbilt Financial International we will show you how to make up to $1,000 dollars or much more every week while working from your home by filling out just a few forms. This will not require you to quit your present job; in fact it will only require 8-15 hours of your time a week. You choose! Imagine yourself in control of your destiny for once! You only have one life and it would be nice if you could be your own boss with a steady income month after month, living anywhere that you choose, enjoying more time with your loved ones and taking nice vacations whenever you want! Vanderbilt Financial International guarantees to change your life and make you the money you have always dreamed about! CLICK HERE! http://home.earthlink.net/~jtannery/vbf23.htm Remove your name from our list here: remove88@excite.com Thank You and Have a Great Day! From ftp-wg-owner@hethmon.com Sun Jun 4 22:23:28 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA12049 for ; Sun, 4 Jun 2000 22:23:27 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000604211630-291-8 ; Sun, 04 Jun 2000 21:16:30 -0500 Received: from mail.visualcities.com (MAIL.VISUALCITIES.COM [208.197.229.7]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000604211625-31258-7 ; Sun, 04 Jun 2000 21:16:25 -0500 Message-Id: <20000604211625-31258-7@mail.hethmon.com> Received: from mail.visualcities.com (sfr-tgn-sfi-vty66.as.wcom.net[216.192.11.66])by NT_VCM_SERVER(MailMax 3.033) with ESMTP id 1517880 for loseweightfast@visualcities.com; Sun, 04 Jun 2000 22:13:11 -0400 EDT Date: Sun, 4 Jun 2000 21:16:28 -0500 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: loseweightfast@visualcities.com To: loseweightfast@visualcities.com Subject: Ftp-WG: We Pay You TO LOSE WEIGHT! Free Samples to GET YOU STARTED!!! ******FREE SAMPLE******** Whether you need to lose 5 pounds or 150, this is the place for you! http://www.dietdietdiet.com "I Lost 40 Pounds in 2 Months! So can YOU!" PLUS!!! Ask about how you can get paid to lose weight!!! 1-800-275-THIN FREE SAMPLES HAVE BEEN ARRANGED FOR YOU!!! We Specialize in Weight Loss, Weight Gain and in the Finest Nutrition, Health and Fitness, Beauty and Personal Care in the WORLD. Now in 47 Countries! http://www.dietdietdiet.com ________________________________________________________ This Message was Sent To You BY REQUEST. IF you wish to be removed from all future mailings, please reply with the subject "Remove" and this software will automatically block you from all future mailings. INCLUDING OUR FREE OFFERS AND SWEEPSTAKES!!! From ftp-wg-owner@hethmon.com Mon Jun 5 08:01:39 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA29533 for ; Mon, 5 Jun 2000 08:01:39 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000605070146-53794-8 ; Mon, 05 Jun 2000 07:01:46 -0500 Received: from hwacomsys.com.tw (203.69.252.161 [203.69.252.161]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000605070139-30986-6 ; Mon, 05 Jun 2000 07:01:40 -0500 Received: from 203.69.252.161 by hwacomsys.com.tw (SMI-8.6/SMI-SVR4) id TAA07153; Mon, 5 Jun 2000 19:59:12 +0800 Message-Id: <200006051159.TAA07153@hwacomsys.com.tw> Date: Mon, 5 Jun 2000 07:01:43 -0500 X-OldDate: Tue, 06 Jun 00 05:11:29 EST Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: HomeHelp@oiio.fsnet.co.uk To: HomeHelp@oiio.fsnet.co.uk Subject: Ftp-WG: Attention: Homeowners & Soon To Be Homeowners Hit reply to be removed. Homeowners, let the power of the internet work for you. Fill in our quick loan request form and you will get competitive mortgage quotes from 3 of over 150 lenders signed up for our service. When lenders compete you win. Cash back refinances No Equity 2nd Trust Deeds Debt Consolidation No Income Verification The most competitive interest rates! Lenders are standing by, ready to approve your loan today! They will contact you, often minutes after filling in the form or when it's best for you. Visit this site: http://204048631/?SP0602 (If web site doesn't come right up, please try back later) -Save Time -Save Money -Save Aggravation There is NEVER any fee to consumers for using this service. _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Copyright © 1999, 2000 eWorld Marketing, Inc. 1-888-418-2575. This is not a solicitation or offer to lend money. eWorld Marketing is not a lender, broker or other financial intermediary. We provide marketing services to the mortgage industry. _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From ftp-wg-owner@hethmon.com Mon Jun 5 08:21:13 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA29968 for ; Mon, 5 Jun 2000 08:21:12 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000605071740-19675-11 ; Mon, 05 Jun 2000 07:17:40 -0500 Received: from magritte.felspar.net (195.13.68.90 [195.13.68.90]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000605071736-61354-8 ; Mon, 05 Jun 2000 07:17:36 -0500 Received: by magritte.felspar.net with Internet Mail Service (5.5.2448.0) id ; Mon, 5 Jun 2000 13:17:41 +0100 Message-ID: <61A45D5AE74BD311A76D00A0D21B18723672DC@magritte.felspar.net> MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFCEE8.0B8A1BB0" Date: Mon, 5 Jun 2000 07:17:38 -0500 X-OldDate: Mon, 5 Jun 2000 13:17:40 +0100 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Dave Cridland To: "'FTPEXT Working Group'" Subject: Ftp-WG: thoughts on ftp extensions and caching This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFCEE8.0B8A1BB0 Content-Type: text/plain; charset="iso-8859-1" Sounds better, however, I'd prefer it to be Size that's mandatory, and Binary-Size optional based on whether the client has turned it on or not. After all, I have my doubts that any proxy-caching system really needs to know what the exact size is in order to make a policy decision on whether to cache the entire file, continue the download after the proxy's client has quit, etc. -----Original Message----- From: Stephen Head [mailto:smh@entera.com] Sent: Saturday, June 03, 2000 12:37 AM To: FTPEXT Working Group Subject: Ftp-WG: thoughts on ftp extensions and caching How about: The control channel responses for RETR are a 125 response (non STREAM mode) and a 150 response (STREAM mode). An extended 125 response consists of: "125-Ext" CRLF 1*( SP entry CRLF ) "125 End" CRLF An extended 150 response consists of: "150-Ext" CRLF 1*( SP entry CRLF ) "150 End" CRLF where: entry = [ facts ] SP pathname facts = 1*( fact ";" ) fact = factname "=" value factname = "Binary-Size" / "Size" / "Modify" / "Create" / "Type" / "Unique" / "Perm" / "Lang" / "Media-Type" / "CharSet" / os-depend-fact / local-fact os-depend-fact = "." token local-fact = "X." token value = *RCHAR and where pathname is the fully qualified pathname of the object* and facts MUST include the following factname-value pairs** if FEAT returns "X150" or "X125": Binary-Size Modify Note that a caching proxy server has the option of fetching the binary version of the file, even if it is ASCII that is being requested by the client. This makes reporting the Size (in contrast to Binary-Size, which would be the binary size of the file only) appear to be somewhat less critical. -s * permits managing file object cache using fully qualified pathname, presumed to be unique (even in presence of symbolic links on the server). ** presumeably the states of the other stuff is explicitly managed by the client and so not needed. I haven't exhaustively checked that this is the case (eg for 3-party transfers, etc.). ----- Dave Cridland wrote: > > > Before I commence wittering, a caveat: It's before noon here, and I'm > hungover, and can't remember everything in the MLST spec, and > unfortunately I'm at work and somewhat busy. > > However, I suggest the following: > > In responses to RETR commands, the Server-PI SHOULD respond with the > following as the text of the response: > > response = identifier SP mlst-line > > identifier = "" (or some such - more than a character should > avoid confusion) > > And also include the extra facts, not normally put in: > > "download-mode", "download-type", "download-structure" - defining the > method of downloading. Assuming I've remembered these right. > > The "size" fact, if present, should indicate to a reasonable degree > the size of the file being downloaded - perhaps not wholly accurately > for ASCII mode downloads, but enough for policy based caching systems > to take a view on whether to cache or not. > > Perhaps include an optional "download-size" fact for the exact size. ------_=_NextPart_001_01BFCEE8.0B8A1BB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Ftp-WG: thoughts on ftp extensions and caching

Sounds better, however, I'd prefer it to be Size = that's mandatory, and Binary-Size optional based on whether the client = has turned it on or not. After all, I have my doubts that any = proxy-caching system really needs to know what the exact size is in = order to make a policy decision on whether to cache the entire file, = continue the download after the proxy's client has quit, = etc.

-----Original Message-----
From: Stephen Head [mailto:smh@entera.com]
Sent: Saturday, June 03, 2000 12:37 AM
To: FTPEXT Working Group
Subject: Ftp-WG: thoughts on ftp extensions and = caching


How about:

The control channel responses for RETR are a 125 = response
(non STREAM mode) and a 150 response (STREAM = mode).

An extended 125 response consists of:

        = "125-Ext" CRLF
         1*( = SP entry CRLF )
         = "125 End" CRLF

An extended 150 response consists of:

        = "150-Ext" CRLF
         1*( = SP entry CRLF )
         = "150 End" CRLF

where:

        = entry            = =3D [ facts ] SP pathname
        = facts            = =3D 1*( fact ";" )
        = fact           &n= bsp; =3D factname "=3D" value
        = factname         =3D = "Binary-Size" / "Size" / "Modify" / = "Create"
/
          &nb= sp;           &nb= sp;    "Type" / "Unique" / = "Perm" /
          &nb= sp;           &nb= sp;    "Lang" / "Media-Type" / = "CharSet" /
          &nb= sp;           &nb= sp;    os-depend-fact / local-fact
        = os-depend-fact   =3D <IANA assigned OS name> = "." token
        = local-fact       =3D "X." = token
        value = ;           =3D = *RCHAR

and where pathname is the fully qualified pathname of = the object*
and facts MUST include the following factname-value = pairs**
if FEAT returns "X150" or = "X125":

        = Binary-Size
        = Modify

Note that a caching proxy server has the option of = fetching
the binary version of the file, even if it is ASCII = that is being
requested by the client.  This makes reporting = the Size
(in contrast to Binary-Size, which would be the = binary size
of the file only) appear to be somewhat less = critical.

-s

* permits managing file object cache using fully = qualified pathname,
presumed to be unique (even in presence of symbolic = links on
the server).

** presumeably the states of the other stuff is = explicitly managed
by the client and so not needed.  I haven't = exhaustively checked
that this is the case (eg for 3-party transfers, = etc.).

-----

Dave Cridland wrote:

>
>
> Before I commence wittering, a caveat: It's = before noon here, and I'm
> hungover, and can't remember everything in the = MLST spec, and
> unfortunately I'm at work and somewhat = busy.
>
> However, I suggest the following:
>
> In responses to RETR commands, the Server-PI = SHOULD respond with the
> following as the text of the response:
>
> response =3D identifier SP mlst-line
>
> identifier =3D "<EXT>" (or some = such - more than a character should
> avoid confusion)
>
> And also include the extra facts, not normally = put in:
>
> "download-mode", = "download-type", "download-structure" - defining = the
> method of downloading. Assuming I've remembered = these right.
>
> The "size" fact, if present, should = indicate to a reasonable degree
> the size of the file being downloaded - perhaps = not wholly accurately
> for ASCII mode downloads, but enough for policy = based caching systems
> to take a view on whether to cache or = not.
>
> Perhaps include an optional = "download-size" fact for the exact size.

------_=_NextPart_001_01BFCEE8.0B8A1BB0-- From ftp-wg-owner@hethmon.com Mon Jun 5 09:08:11 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01357 for ; Mon, 5 Jun 2000 09:08:10 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000605080739-14371-7 ; Mon, 05 Jun 2000 08:07:39 -0500 Received: from ACFcluster.NYU.EDU (AXP2.ACF.NYU.EDU [128.122.250.38]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000605080735-57594-6 ; Mon, 05 Jun 2000 08:07:35 -0500 Received: from ACFcluster.NYU.EDU by ACFcluster.NYU.EDU (PMDF V5.2-32 #33915) id <01JQ8KHDAZHS8WZO5G@ACFcluster.NYU.EDU> for ftp-wg@hethmon.com; Mon, 5 Jun 2000 09:04:04 EDT In-reply-to: "Your message dated Mon, 05 Jun 2000 07:17:38 -0500" <61A45D5AE74BD311A76D00A0D21B18723672DC@magritte.felspar.net> Message-id: <01JQ8L9F15GA8WZO5G@ACFcluster.NYU.EDU> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Date: Mon, 5 Jun 2000 08:07:37 -0500 X-OldDate: Mon, 05 Jun 2000 09:01:35 -0400 (EDT) Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Stephen Tihor To: FTPEXT Working Group Subject: Ftp-WG: thoughts on ftp extensions and caching I am not quite sure how you are defining Binary size. But I suspect from context the author is uner the delusion that binary-size == size when transfered in image mode == number of bytes required oin disk to store. This is -- of course -- false in the general case. There are a number of operating systems where this is not true though its usually the case for UNIX and MS-DOS based systems with vanillia storage subsystems. I believe an approximate size is the best thing to send and if someone really cares thenthey will want the bounds (minimum, maximum) of the bytestream which are quick to compute, albeit inaccurate. From ftp-wg-owner@hethmon.com Mon Jun 5 11:37:21 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04840 for ; Mon, 5 Jun 2000 11:37:21 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000605103541-19841-14 ; Mon, 05 Jun 2000 10:35:41 -0500 Received: from havoc.entera.com (havoc.entera.com [206.165.109.130]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000605103538-60652-13 ; Mon, 05 Jun 2000 10:35:38 -0500 Received: from entera.com ([208.48.116.174]) by havoc.entera.com (Post.Office MTA v3.5.3 release 223 ID# 0-61971U200L100S0V35) with ESMTP id com for ; Mon, 5 Jun 2000 08:30:04 -0700 Message-ID: <393BC819.DAF7CBA9@entera.com> Organization: Entera, Inc. X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.7 i86pc) X-Accept-Language: en MIME-Version: 1.0 References: <01JQ8L9F15GA8WZO5G@ACFcluster.NYU.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 5 Jun 2000 10:35:39 -0500 X-OldDate: Mon, 05 Jun 2000 08:32:41 -0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Stephen Head To: FTPEXT Working Group Subject: Ftp-WG: thoughts on ftp extensions and caching Content-Transfer-Encoding: 7bit I specified binary size with three primary motivations in mind: 1, it is (reputedly) easier for the server to compute than the other leading brand (size in ASCII type); 2, the proxy cache server can always store the image version of the file, and serve either the image or ASCII version depending on demand; and 3, the proxy cache server should not or at least might not necessarily use a UN*X file system to store file objects, so filesystem fragmentation concerns (etc.) are or at least appear as if they should be of less importance in this context. -s ----- Stephen Tihor wrote: > I am not quite sure how you are defining Binary size. But I suspect > from context the author is uner the delusion that binary-size == > size when transfered in image mode == number of bytes required oin disk to store. > This is -- of course -- false in the general case. There are a number of > operating systems where this is not true though its usually the case > for UNIX and MS-DOS based systems with vanillia storage subsystems. > > I believe an approximate size is the best thing to send and if someone really > cares thenthey will want the bounds (minimum, maximum) of the bytestream > which are quick to compute, albeit inaccurate. From ftp-wg-owner@hethmon.com Mon Jun 5 12:26:19 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05594 for ; Mon, 5 Jun 2000 12:26:18 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000605111928-16981-8 ; Mon, 05 Jun 2000 11:19:28 -0500 Received: from ACFcluster.NYU.EDU (AXP2.ACF.NYU.EDU [128.122.250.38]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000605111924-54299-7 ; Mon, 05 Jun 2000 11:19:24 -0500 Received: from ACFcluster.NYU.EDU by ACFcluster.NYU.EDU (PMDF V5.2-32 #33915) id <01JQ8RFIZYOW8WZXPU@ACFcluster.NYU.EDU> for ftp-wg@hethmon.com; Mon, 5 Jun 2000 12:15:52 EDT In-reply-to: "Your message dated Mon, 05 Jun 2000 10:35:39 -0500" <393BC819.DAF7CBA9@entera.com> Message-id: <01JQ8S1Y1THE8WZXPU@ACFcluster.NYU.EDU> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII References: <01JQ8L9F15GA8WZO5G@ACFcluster.NYU.EDU> Date: Mon, 5 Jun 2000 11:19:26 -0500 X-OldDate: Mon, 05 Jun 2000 12:15:36 -0400 (EDT) Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Stephen Tihor To: FTPEXT Working Group Subject: Ftp-WG: thoughts on ftp extensions and caching It still seems that an approximate size should serve just fine. No? From ftp-wg-owner@hethmon.com Mon Jun 5 12:44:23 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05975 for ; Mon, 5 Jun 2000 12:44:22 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000605113326-33772-12 ; Mon, 05 Jun 2000 11:33:26 -0500 Received: from havoc.entera.com (havoc.entera.com [206.165.109.130]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000605113323-13031-11 ; Mon, 05 Jun 2000 11:33:24 -0500 Received: from entera.com ([208.48.116.174]) by havoc.entera.com (Post.Office MTA v3.5.3 release 223 ID# 0-61971U200L100S0V35) with ESMTP id com for ; Mon, 5 Jun 2000 09:27:57 -0700 Message-ID: <393BD5A8.D836685E@entera.com> Organization: Entera, Inc. X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.7 i86pc) X-Accept-Language: en MIME-Version: 1.0 References: <61A45D5AE74BD311A76D00A0D21B18723672DC@magritte.felspar.net> Content-Type: multipart/alternative; boundary="------------97F3C3744C5DF23BF67B01C5" Date: Mon, 5 Jun 2000 11:33:24 -0500 X-OldDate: Mon, 05 Jun 2000 09:30:32 -0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Stephen Head To: FTPEXT Working Group Subject: Ftp-WG: thoughts on ftp extensions and caching --------------97F3C3744C5DF23BF67B01C5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Binary-size (Image-size would probably be an improvement on name) also appears to be useful to squid (see squid-2.2.STABLE4/src/ftp.c, etc.) to generate Content-Length and (for restart) Content-Range HTTP headers for ftp-related requests. Apache also uses it for similar purposes (see apache_1.3.6/src/modules//proxy_ftp.c) --though just from skimming source code it appears not to care whether ASCII or Image mode and seems very if not overly trusting of the ftp server's response to SIZE. Harvest (docs/old-manual/node130.html#SECTION00089700000000000000) uses object size as a parameter in its cache decision flowchart, but in any case I didn't want to preclude it if it could be obtained cheaply. (This could be added to the motivations list I previously sent out, as #4.) A very early form of my "thoughts" used plain old Size but I was told it could potentially cause an undue amount of overhead, eg in the case of ASCII type. So I modified it before I sent out the group version. Either way works for me, but I am trying to make it as easy as possible for a server to be conforming in order to attempt to guarantee the maximum possible compliance (eg become the default and if failing that become a near-universally-supported option). -s ----- (Dave Cridland wrote: > > > Sounds better, however, I'd prefer it to be Size that's mandatory, and > Binary-Size optional based on whether the client has turned it on or > not. After all, I have my doubts that any proxy-caching system really > needs to know what the exact size is in order to make a policy > decision on whether to cache the entire file, continue the download > after the proxy's client has quit, etc. > --------------97F3C3744C5DF23BF67B01C5 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Binary-size (Image-size would probably be an improvement on name)
also appears to be useful to squid  (see squid-2.2.STABLE4/src/ftp.c,
etc.) to generate Content-Length and (for restart) Content-Range
HTTP headers for ftp-related requests.  Apache also uses it
for similar purposes (see apache_1.3.6/src/modules//proxy_ftp.c)
--though just from skimming source code it appears not to care
whether ASCII or Image mode and seems very if not overly trusting of
the ftp server's response to SIZE.
Harvest (docs/old-manual/node130.html#SECTION00089700000000000000)
uses object size as a parameter in its cache decision flowchart,
but in any case I didn't want to preclude it if it could be obtained cheaply.
(This could be added to the motivations list I previously sent out, as #4.)

A very early form of my "thoughts" used plain old Size but I was
told it could potentially cause an undue amount of overhead, eg
in the case of ASCII type.  So I modified it before I sent out the group
version.  Either way works for me, but I am trying to make it as easy
as possible for a server to be conforming in order to attempt
to guarantee the maximum possible compliance (eg become the default
and if failing that become a near-universally-supported option).

-s

-----

(Dave Cridland wrote:

 

Sounds better, however, I'd prefer it to be Size that's mandatory, and Binary-Size optional based on whether the client has turned it on or not. After all, I have my doubts that any proxy-caching system really needs to know what the exact size is in order to make a policy decision on whether to cache the entire file, continue the download after the proxy's client has quit, etc.
 

--------------97F3C3744C5DF23BF67B01C5-- From ftp-wg-owner@hethmon.com Mon Jun 5 12:54:25 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06227 for ; Mon, 5 Jun 2000 12:54:25 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000605115337-17879-7 ; Mon, 05 Jun 2000 11:53:37 -0500 Received: from ACFcluster.NYU.EDU (AXP2.ACF.NYU.EDU [128.122.250.38]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000605115335-64280-6 ; Mon, 05 Jun 2000 11:53:35 -0500 Received: from ACFcluster.NYU.EDU by ACFcluster.NYU.EDU (PMDF V5.2-32 #33915) id <01JQ8SYW36808WZXPU@ACFcluster.NYU.EDU> for ftp-wg@hethmon.com; Mon, 5 Jun 2000 12:50:05 EDT In-reply-to: "Your message dated Mon, 05 Jun 2000 11:33:24 -0500" <393BD5A8.D836685E@entera.com> Message-id: <01JQ8T8P8JLQ8WZXPU@ACFcluster.NYU.EDU> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii References: <61A45D5AE74BD311A76D00A0D21B18723672DC@magritte.felspar.net> Date: Mon, 5 Jun 2000 11:53:36 -0500 X-OldDate: Mon, 05 Jun 2000 12:49:30 -0400 (EDT) Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Stephen Tihor To: FTPEXT Working Group Subject: Ftp-WG: thoughts on ftp extensions and caching If you want it to be easy then it shoudl be speced out as an rough-size sort of option. From ftp-wg-owner@hethmon.com Mon Jun 5 13:20:58 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06910 for ; Mon, 5 Jun 2000 13:20:57 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000605121308-24705-7 ; Mon, 05 Jun 2000 12:13:08 -0500 Received: from havoc.entera.com (havoc.entera.com [206.165.109.130]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000605121303-17931-6 ; Mon, 05 Jun 2000 12:13:04 -0500 Received: from entera.com ([208.48.116.174]) by havoc.entera.com (Post.Office MTA v3.5.3 release 223 ID# 0-61971U200L100S0V35) with ESMTP id com for ; Mon, 5 Jun 2000 10:07:35 -0700 Message-ID: <393BDEF2.9B8ED700@entera.com> Organization: Entera, Inc. X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.7 i86pc) X-Accept-Language: en MIME-Version: 1.0 References: <61A45D5AE74BD311A76D00A0D21B18723672DC@magritte.felspar.net> <01JQ8T8P8JLQ8WZXPU@ACFcluster.NYU.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 5 Jun 2000 12:13:06 -0500 X-OldDate: Mon, 05 Jun 2000 10:10:10 -0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Stephen Head To: FTPEXT Working Group Subject: Ftp-WG: thoughts on ftp extensions and caching Content-Transfer-Encoding: 7bit Stephen Tihor wrote: > If you want it to be easy then it shoudl be speced out as an rough-size sort of > option. Before doing that, I would think it should be considered the relative ease of supplying the various alternative responses. In particular, what is difficult about supplying the image type size? Also, the tendency (see RFCs 1945, 2616 re Content-Length) is to specify exact # of OCTETs. Also, what should or can Squid and Apache do with approximations in contrast to exact size when fetching ftp files? -s From ftp-wg-owner@hethmon.com Mon Jun 5 13:27:56 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07025 for ; Mon, 5 Jun 2000 13:27:55 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000605122158-5295-11 ; Mon, 05 Jun 2000 12:21:58 -0500 Received: from magritte.felspar.net (195.13.68.90 [195.13.68.90]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000605122154-5703-8 ; Mon, 05 Jun 2000 12:21:55 -0500 Received: by magritte.felspar.net with Internet Mail Service (5.5.2448.0) id ; Mon, 5 Jun 2000 18:22:09 +0100 Message-ID: <61A45D5AE74BD311A76D00A0D21B18723672E6@magritte.felspar.net> MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFCF12.94439AD0" Date: Mon, 5 Jun 2000 12:21:56 -0500 X-OldDate: Mon, 5 Jun 2000 18:22:09 +0100 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Dave Cridland To: "'FTPEXT Working Group'" Subject: Ftp-WG: thoughts on ftp extensions and caching This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFCF12.94439AD0 Content-Type: text/plain; charset="iso-8859-1" I agree entirely, as I've said. But to clarify from what Stephen Head has said, surely the MLST fact "size" is an approximation anyway? I thought only the SIZE command returned the exact transfer size. As far as I know, the worst case is that we'll be proferring a transfer size that's out by 100%, but that's assuming a file on UNIX consisting of only '\n' characters, for instance. My vote for the name of any new fact should be "TransferSize" or "transfer-size", depending on whether we want '-' characters or not in our facts. Which raises an interesting, albeit pedantic, thought. The ABNF for MLST doesn't restrict the characters available for use in a factname - should it? -----Original Message----- From: Stephen Tihor [mailto:TIHOR@ACFcluster.NYU.EDU] Sent: Monday, June 05, 2000 5:19 PM To: FTPEXT Working Group Subject: Ftp-WG: thoughts on ftp extensions and caching It still seems that an approximate size should serve just fine. No? ------_=_NextPart_001_01BFCF12.94439AD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Ftp-WG: thoughts on ftp extensions and caching

I agree entirely, as I've said.

But to clarify from what Stephen Head has said, = surely the MLST fact "size" is an approximation anyway? I = thought only the SIZE command returned the exact transfer = size.

As far as I know, the worst case is that we'll be = proferring a transfer size that's out by 100%, but that's assuming a = file on UNIX consisting of only '\n' characters, for = instance.

My vote for the name of any new fact should be = "TransferSize" or "transfer-size", depending on = whether we want '-' characters or not in our facts.

Which raises an interesting, albeit pedantic, = thought. The ABNF for MLST doesn't restrict the characters available = for use in a factname - should it?

-----Original Message-----
From: Stephen Tihor [mailto:TIHOR@ACFcluster.NYU.EDU= ]
Sent: Monday, June 05, 2000 5:19 PM
To: FTPEXT Working Group
Subject: Ftp-WG: thoughts on ftp extensions and = caching


It still seems that an approximate size should serve = just fine.
No?

------_=_NextPart_001_01BFCF12.94439AD0-- From ftp-wg-owner@hethmon.com Mon Jun 5 13:47:47 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07384 for ; Mon, 5 Jun 2000 13:47:47 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000605124635-21739-7 ; Mon, 05 Jun 2000 12:46:35 -0500 Received: from ACFcluster.NYU.EDU (AXP2.ACF.NYU.EDU [128.122.250.38]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000605124631-59065-6 ; Mon, 05 Jun 2000 12:46:31 -0500 Received: from ACFcluster.NYU.EDU by ACFcluster.NYU.EDU (PMDF V5.2-32 #33915) id <01JQ8UK1QXE88WZNEV@ACFcluster.NYU.EDU> for ftp-wg@hethmon.com; Mon, 5 Jun 2000 13:43:01 EDT In-reply-to: "Your message dated Mon, 05 Jun 2000 12:13:06 -0500" <393BDEF2.9B8ED700@entera.com> Message-id: <01JQ8V06PFNM8WZNEV@ACFcluster.NYU.EDU> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII References: <61A45D5AE74BD311A76D00A0D21B18723672DC@magritte.felspar.net> <01JQ8T8P8JLQ8WZXPU@ACFcluster.NYU.EDU> Date: Mon, 5 Jun 2000 12:46:33 -0500 X-OldDate: Mon, 05 Jun 2000 13:40:29 -0400 (EDT) Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Stephen Tihor To: FTPEXT Working Group Subject: Ftp-WG: thoughts on ftp extensions and caching If your operating systmes does not track end bybtes in an easilly accessible way an image size may be rounded to the enxt nearest container unit. Example VMS files will yield a container object size in round disk blocks. as the natural size. The bytestream is considerably smaller. The image mode stream is somewhat smaller since it can see more internal structure plus somewhat larger since it adds overhead blocks. the later I believ shoudl be estiamted in at a maximum value by the size code but as long as the result need only be an approximate and not the exact number of bytes sent over the wire its ffine. THe protocols where i see content lengths the content is already being redndered and processed, here we are talking aboutlooking at a raw disk object or virtual object which may have no exact size. From ftp-wg-owner@hethmon.com Mon Jun 5 14:20:50 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07976 for ; Mon, 5 Jun 2000 14:20:49 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000605131845-25377-7 ; Mon, 05 Jun 2000 13:18:46 -0500 Received: from ACFcluster.NYU.EDU (AXP2.ACF.NYU.EDU [128.122.250.38]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000605131841-12438-6 ; Mon, 05 Jun 2000 13:18:42 -0500 Received: from ACFcluster.NYU.EDU by ACFcluster.NYU.EDU (PMDF V5.2-32 #33915) id <01JQ8W6C53HC8WZNEV@ACFcluster.NYU.EDU> for ftp-wg@hethmon.com; Mon, 5 Jun 2000 14:15:09 EDT In-reply-to: "Your message dated Mon, 05 Jun 2000 12:46:33 -0500" <01JQ8V06PFNM8WZNEV@ACFcluster.NYU.EDU> Message-id: <01JQ8W6USF8M8WZNEV@ACFcluster.NYU.EDU> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII References: <61A45D5AE74BD311A76D00A0D21B18723672DC@magritte.felspar.net> <01JQ8T8P8JLQ8WZXPU@ACFcluster.NYU.EDU> <393BDEF2.9B8ED700@entera.com> Date: Mon, 5 Jun 2000 13:18:43 -0500 X-OldDate: Mon, 05 Jun 2000 14:14:06 -0400 (EDT) Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Stephen Tihor To: FTPEXT Working Group Subject: Ftp-WG: thoughts on ftp extensions and caching I have reviewed the size fact and its definiton is, as I recalled, acceptable in this context. what specific NEED exists for a more accurate number lets see if its worth a potentially large delay (equal to trasmission time over a very fast medium)? From ftp-wg-owner@hethmon.com Mon Jun 5 14:53:35 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08502 for ; Mon, 5 Jun 2000 14:53:34 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000605135348-30791-7 ; Mon, 05 Jun 2000 13:53:48 -0500 Received: from havoc.entera.com (havoc.entera.com [206.165.109.130]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000605135344-43919-6 ; Mon, 05 Jun 2000 13:53:45 -0500 Received: from entera.com ([208.48.116.174]) by havoc.entera.com (Post.Office MTA v3.5.3 release 223 ID# 0-61971U200L100S0V35) with ESMTP id com for ; Mon, 5 Jun 2000 11:48:18 -0700 Message-ID: <393BF68D.3992D185@entera.com> Organization: Entera, Inc. X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.7 i86pc) X-Accept-Language: en MIME-Version: 1.0 References: <61A45D5AE74BD311A76D00A0D21B18723672DC@magritte.felspar.net> <01JQ8T8P8JLQ8WZXPU@ACFcluster.NYU.EDU> <393BDEF2.9B8ED700@entera.com> <01JQ8W6USF8M8WZNEV@ACFcluster.NYU.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 5 Jun 2000 13:53:46 -0500 X-OldDate: Mon, 05 Jun 2000 11:50:53 -0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Stephen Head To: FTPEXT Working Group Subject: Ftp-WG: thoughts on ftp extensions and caching Content-Transfer-Encoding: 7bit Apache and Squid convert ftp SIZE response information into HTTP Content-Length headers. The following is from RFC 1945 (HTTP/1.0): Note: Some older servers supply an invalid Content-Length when sending a document that contains server-side includes dynamically inserted into the data stream. It must be emphasized that this will not be tolerated by future versions of HTTP. Unless the client knows that it is receiving a response from a compliant server, it should not depend on the Content-Length value being correct. The following is from RFC 2616 (HTTP/1.1): 3.If a Content-Length header field (section 14.13) is present, its decimal value in OCTETs represents both the entity-length and the transfer-length. The Content-Length header field MUST NOT be sent if these two lengths are different (i.e., if a Transfer-Encoding header field is present). If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored. and: When a Content-Length is given in a message where a message-body is allowed, its field value MUST exactly match the number of OCTETs in the message-body. HTTP/1.1 user agents MUST notify the user when an invalid length is received and detected. So it would appear that there are some situations in which http server and proxy servers could return incorrect results as defined by RFC 2616 if they use some ftp SIZE variant or 150 response variant that returns an approximation and not an exact size. When faced with approximations, I also tend to ask what the worst case is, and 100% does not sound very appealing to me, even if it is only worst case (DOS attacks?). I'm looking into the concern about VMS filesystem not returning a true size for an image file size but my reflex response is that ftp servers are better and I want to believe more often running UN*X and variants. A question here: for that subset of servers that for some reason cannot respond with the exact size, how about indicating that via a fact such as Approx-size and/or Approx-image-size in the response so the downstream components are appropriately alerted? (More thoughts here -- excised for the moment.) It appears to me that I have somehow wandered into a sensitive area. FWIW, it was not my intent to do so-- maybe I should have sent out a couple of MMFs first instead :-). -s Stephen Tihor wrote: > I have reviewed the size fact and its definiton is, as I recalled, acceptable > in this context. what specific NEED exists for a more accurate number > lets see if its worth a potentially large delay (equal to trasmission time over a very fast medium)? From ftp-wg-owner@hethmon.com Mon Jun 5 16:10:59 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09721 for ; Mon, 5 Jun 2000 16:10:58 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000605151027-27049-7 ; Mon, 05 Jun 2000 15:10:27 -0500 Received: from ACFcluster.NYU.EDU (AXP2.ACF.NYU.EDU [128.122.250.38]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000605151023-64962-6 ; Mon, 05 Jun 2000 15:10:23 -0500 Received: from ACFcluster.NYU.EDU by ACFcluster.NYU.EDU (PMDF V5.2-32 #33915) id <01JQ8W6C53HC8WZNEV@ACFcluster.NYU.EDU> for ftp-wg@hethmon.com; Mon, 5 Jun 2000 16:06:51 EDT In-reply-to: "Your message dated Mon, 05 Jun 2000 13:53:46 -0500" <393BF68D.3992D185@entera.com> Message-id: <01JQ904NOTH08WZNEV@ACFcluster.NYU.EDU> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii References: <61A45D5AE74BD311A76D00A0D21B18723672DC@magritte.felspar.net> <01JQ8T8P8JLQ8WZXPU@ACFcluster.NYU.EDU> <393BDEF2.9B8ED700@entera.com> <01JQ8W6USF8M8WZNEV@ACFcluster.NYU.EDU> Date: Mon, 5 Jun 2000 15:10:25 -0500 X-OldDate: Mon, 05 Jun 2000 16:06:19 -0400 (EDT) Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Stephen Tihor To: FTPEXT Working Group Subject: Ftp-WG: thoughts on ftp extensions and caching The current definiton for the Size fact is approximate. If want ones to define an EXACT -size then and only then can servers that require an exact number rely on it. From ftp-wg-owner@hethmon.com Mon Jun 5 16:43:29 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10177 for ; Mon, 5 Jun 2000 16:43:28 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000605154044-34501-7 ; Mon, 05 Jun 2000 15:40:44 -0500 Received: from havoc.entera.com (havoc.entera.com [206.165.109.130]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000605154040-37461-6 ; Mon, 05 Jun 2000 15:40:41 -0500 Received: from entera.com ([208.48.116.174]) by havoc.entera.com (Post.Office MTA v3.5.3 release 223 ID# 0-61971U200L100S0V35) with ESMTP id com for ; Mon, 5 Jun 2000 13:35:13 -0700 Message-ID: <393C0F9C.B68776AB@entera.com> Organization: Entera, Inc. X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.7 i86pc) X-Accept-Language: en MIME-Version: 1.0 References: <61A45D5AE74BD311A76D00A0D21B18723672DC@magritte.felspar.net> <01JQ8T8P8JLQ8WZXPU@ACFcluster.NYU.EDU> <393BDEF2.9B8ED700@entera.com> <01JQ8W6USF8M8WZNEV@ACFcluster.NYU.EDU> <01JQ904NOTH08WZNEV@ACFcluster.NYU.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 5 Jun 2000 15:40:41 -0500 X-OldDate: Mon, 05 Jun 2000 13:37:48 -0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Stephen Head To: FTPEXT Working Group Subject: Ftp-WG: thoughts on ftp extensions and caching Content-Transfer-Encoding: 7bit I was trying to answer the previous question ("what specific NEED exists..."). The illustration I provided was that there exist current servers that rely on the non-standard SIZE command results to form Content-Length and Content-Range HTTP headers for which the trend, standards, and general expectation is that they report the exact number of OCTETS. It seems to me that this is potentially a valid area that the ftp-wg can contribute an extended standard to help satisfy that need. Conceivably, it's the way HTTP permits FTP urls to be fetched and/or the server writers that created this particular problem. Obviously, a server whose goal is interoperability can't use a networking feature before it has been standardized. That is always the case with every new emerging standard/extension. Identify need, then identify options, then discuss and choose best option. My opinion is that exact size is more generally useful than approximate size and in most cases is just as easy to obtain from a reasonable OS. If that view is not generally shared, then no biggie, then how about Exact-image-size and an Exact-size facts as companions to existing Size fact instead of redefining Size and adding Approximate-size variant(s). I'm not hung up on naming (if that is the main issue) (?)... -s ----- Stephen Tihor wrote: > The current definiton for the Size fact is approximate. If want ones to define > an EXACT -size then and only then can servers that require an exact number rely > on it. From ftp-wg-owner@hethmon.com Mon Jun 5 16:52:17 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10255 for ; Mon, 5 Jun 2000 16:52:16 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000605155012-31427-14 ; Mon, 05 Jun 2000 15:50:12 -0500 Received: from ACFcluster.NYU.EDU (AXP2.ACF.NYU.EDU [128.122.250.38]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000605155009-39212-13 ; Mon, 05 Jun 2000 15:50:09 -0500 Received: from ACFcluster.NYU.EDU by ACFcluster.NYU.EDU (PMDF V5.2-32 #33915) id <01JQ8W6C53HC8WZNEV@ACFcluster.NYU.EDU> for ftp-wg@hethmon.com; Mon, 5 Jun 2000 16:46:39 EDT In-reply-to: "Your message dated Mon, 05 Jun 2000 15:40:41 -0500" <393C0F9C.B68776AB@entera.com> Message-id: <01JQ91GEJLD88WZNEV@ACFcluster.NYU.EDU> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII References: <61A45D5AE74BD311A76D00A0D21B18723672DC@magritte.felspar.net> <01JQ8T8P8JLQ8WZXPU@ACFcluster.NYU.EDU> <393BDEF2.9B8ED700@entera.com> <01JQ8W6USF8M8WZNEV@ACFcluster.NYU.EDU> <01JQ904NOTH08WZNEV@ACFcluster.NYU.EDU> Date: Mon, 5 Jun 2000 15:50:10 -0500 X-OldDate: Mon, 05 Jun 2000 16:45:21 -0400 (EDT) Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Stephen Tihor To: FTPEXT Working Group Subject: Ftp-WG: thoughts on ftp extensions and caching Aside from the prejudicial definiton of reasonable OS. (Ease is in fact an attribute of the primitiiviness of the data model and the file system.) its a fine idea. but such facts shoudl come with cautionary ntoes that they may put a very serious load on the operating systemn and thus should not be asked for causally or when avoidable. From ftp-wg-owner@hethmon.com Mon Jun 5 17:40:53 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10941 for ; Mon, 5 Jun 2000 17:40:52 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000605164022-38214-12 ; Mon, 05 Jun 2000 16:40:23 -0500 Received: from havoc.entera.com (havoc.entera.com [206.165.109.130]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000605164017-13513-11 ; Mon, 05 Jun 2000 16:40:20 -0500 Received: from entera.com ([208.48.116.174]) by havoc.entera.com (Post.Office MTA v3.5.3 release 223 ID# 0-61971U200L100S0V35) with ESMTP id com for ; Mon, 5 Jun 2000 14:34:51 -0700 Message-ID: <393C1D97.85FB94FE@entera.com> Organization: Entera, Inc. X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.7 i86pc) X-Accept-Language: en MIME-Version: 1.0 References: <61A45D5AE74BD311A76D00A0D21B18723672DC@magritte.felspar.net> <01JQ8T8P8JLQ8WZXPU@ACFcluster.NYU.EDU> <393BDEF2.9B8ED700@entera.com> <01JQ8W6USF8M8WZNEV@ACFcluster.NYU.EDU> <01JQ904NOTH08WZNEV@ACFcluster.NYU.EDU> <01JQ91GEJLD88WZNEV@ACFcluster.NYU.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 5 Jun 2000 16:40:21 -0500 X-OldDate: Mon, 05 Jun 2000 14:37:27 -0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Stephen Head To: FTPEXT Working Group Subject: Ftp-WG: thoughts on ftp extensions and caching Content-Transfer-Encoding: 7bit But it does not put a serious load on the OS if the information is pre-generated (eg via a sufficiently smart server and/or attendant utility which "preps" a given ftp server NVS via a parallel directory tree that contains files which contain the exact file size in the ftp server readable format). Doing it part of the time instead of most if not all of the time generally won't result in avoiding the load altogether, but just offloads the responsibility towards the leaf cache nodes and destination client in addition to loading the net with more request-responses. The point of commonality being the origin ftp server, that is the logical optimal place where the computation should take place IMHO (and also have it done once and for all for a given version of the file object). BTW http servers tend to require very fast initial (i.e. HTTP/1.x header, ideally incorporating a valid Content-Length/Content-Range header line) response, the more reason to have this kind of info readily available the first time and every time (I had nothing to do with the design of HTTP, just looking at and reacting to the situation as it now stands). I would not want to advance anything that doesn't ultimately make good sense so feel free to check and be skeptical. For dividing and conquering's sake, I can amend the notion to use Exact-Image-Size and Exact-Size for names of exact image size and exact size facts, respectively. As a separate train of thought I would regard as friendly the alternative of renaming Size to Approx-Size (and variations). -s ----- Stephen Tihor wrote: > Aside from the prejudicial definiton of reasonable OS. (Ease is in fact an attribute of the primitiiviness of the data model and the file system.) its a > fine idea. but such facts shoudl come with cautionary ntoes that they may put a very serious load on the operating systemn and thus should not be asked > for causally or when avoidable. From ftp-wg-owner@hethmon.com Mon Jun 5 23:45:30 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA16404 for ; Mon, 5 Jun 2000 23:45:29 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000605223841-35164-7 ; Mon, 05 Jun 2000 22:38:41 -0500 Received: from ACFcluster.NYU.EDU (AXP2.ACF.NYU.EDU [128.122.250.38]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000605223837-6975-6 ; Mon, 05 Jun 2000 22:38:38 -0500 Received: from ACFcluster.NYU.EDU by ACFcluster.NYU.EDU (PMDF V5.2-32 #33915) id <01JQ9FFWWSK08WZXPU@ACFcluster.NYU.EDU> for ftp-wg@hethmon.com; Mon, 5 Jun 2000 23:34:47 EDT In-reply-to: "Your message dated Mon, 05 Jun 2000 16:40:21 -0500" <393C1D97.85FB94FE@entera.com> Message-id: <01JQ9FQD5G288WZXPU@ACFcluster.NYU.EDU> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII References: <61A45D5AE74BD311A76D00A0D21B18723672DC@magritte.felspar.net> <01JQ8T8P8JLQ8WZXPU@ACFcluster.NYU.EDU> <393BDEF2.9B8ED700@entera.com> <01JQ8W6USF8M8WZNEV@ACFcluster.NYU.EDU> <01JQ904NOTH08WZNEV@ACFcluster.NYU.EDU> <01JQ91GEJLD88WZNEV@ACFcluster.NYU.EDU> Date: Mon, 5 Jun 2000 22:38:39 -0500 X-OldDate: Mon, 05 Jun 2000 23:34:15 -0400 (EDT) Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Stephen Tihor To: FTPEXT Working Group Subject: Ftp-WG: thoughts on ftp extensions and caching Nope it would not. Seems to be letting the HTTP tail wag the host file system dog though. From ftp-wg-owner@hethmon.com Tue Jun 6 07:51:10 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01219 for ; Tue, 6 Jun 2000 07:51:05 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000606063530-5451-7 ; Tue, 06 Jun 2000 06:35:30 -0500 Received: from magritte.felspar.net (195.13.68.90 [195.13.68.90]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000606063526-43543-6 ; Tue, 06 Jun 2000 06:35:26 -0500 Received: by magritte.felspar.net with Internet Mail Service (5.5.2448.0) id ; Tue, 6 Jun 2000 12:35:34 +0100 Message-ID: <61A45D5AE74BD311A76D00A0D21B18723672E8@magritte.felspar.net> MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFCFAB.533AE5F0" Date: Tue, 6 Jun 2000 06:35:28 -0500 X-OldDate: Tue, 6 Jun 2000 12:35:32 +0100 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Dave Cridland To: "'FTPEXT Working Group'" Subject: Ftp-WG: thoughts on ftp extensions and caching This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFCFAB.533AE5F0 Content-Type: text/plain; charset="iso-8859-1" I'm unconvinced that it's needed, though, in any case. Yes, if a HTTP->FTP proxy system really wants to use Content-Length headers, that's fine, but given that we're mainly interested in HTTP/1.1, I can't see the issue here - Chunked Encoding should work fine for giving the size of the data transfer, simply by buffering a handful of k. The startup time would then be as it is now, and the whole thing fits into both standards as of now. Obviously in the case of HTTP/1.0, there's no need to give any indication of the download length, so there's no need to attempt to support it. Putting in a MLST line in the response for a file being downloaded makes sense to me, simply because it can be done with ease - and gives cues on whether the proxy should consider this file for caching. This is a performance advantage for the proxy, and the way MLST is designed, a minumum hit on the server. If Squid, Apache and the others are actually issuing SIZE commands and Content-Length headers, then it's my thinking that they're doing things the wrong way in any case. -----Original Message----- From: Stephen Tihor [mailto:TIHOR@ACFcluster.NYU.EDU] Sent: Tuesday, June 06, 2000 4:39 AM To: FTPEXT Working Group Subject: Ftp-WG: thoughts on ftp extensions and caching Nope it would not. Seems to be letting the HTTP tail wag the host file system dog though. ------_=_NextPart_001_01BFCFAB.533AE5F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Ftp-WG: thoughts on ftp extensions and caching

I'm unconvinced that it's needed, though, in any = case.

Yes, if a HTTP->FTP proxy system really wants to = use Content-Length headers, that's fine, but given that we're mainly = interested in HTTP/1.1, I can't see the issue here - Chunked Encoding = should work fine for giving the size of the data transfer, simply by = buffering a handful of k. The startup time would then be as it is now, = and the whole thing fits into both standards as of now. Obviously in = the case of HTTP/1.0, there's no need to give any indication of the = download length, so there's no need to attempt to support = it.

Putting in a MLST line in the response for a file = being downloaded makes sense to me, simply because it can be done with = ease - and gives cues on whether the proxy should consider this file = for caching. This is a performance advantage for the proxy, and the way = MLST is designed, a minumum hit on the server.

If Squid, Apache and the others are actually issuing = SIZE commands and Content-Length headers, then it's my thinking that = they're doing things the wrong way in any case.

-----Original Message-----
From: Stephen Tihor [mailto:TIHOR@ACFcluster.NYU.EDU= ]
Sent: Tuesday, June 06, 2000 4:39 AM
To: FTPEXT Working Group
Subject: Ftp-WG: thoughts on ftp extensions and = caching


Nope it would not. Seems to be letting the HTTP tail = wag the host file
system dog though.

------_=_NextPart_001_01BFCFAB.533AE5F0-- From ftp-wg-owner@hethmon.com Tue Jun 6 13:00:31 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14639 for ; Tue, 6 Jun 2000 13:00:30 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000606115758-43441-11 ; Tue, 06 Jun 2000 11:57:59 -0500 Received: from havoc.entera.com (havoc.entera.com [206.165.109.130]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000606115756-61577-8 ; Tue, 06 Jun 2000 11:57:56 -0500 Received: from entera.com ([208.48.116.174]) by havoc.entera.com (Post.Office MTA v3.5.3 release 223 ID# 0-61971U200L100S0V35) with ESMTP id com for ; Tue, 6 Jun 2000 09:52:31 -0700 Message-ID: <393D2CE8.8F24117E@entera.com> Organization: Entera, Inc. X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.7 i86pc) X-Accept-Language: en MIME-Version: 1.0 References: <61A45D5AE74BD311A76D00A0D21B18723672E8@magritte.felspar.net> Content-Type: multipart/alternative; boundary="------------DE97CB21B1473EF466211CCB" Date: Tue, 6 Jun 2000 11:57:56 -0500 X-OldDate: Tue, 06 Jun 2000 09:55:04 -0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Stephen Head To: FTPEXT Working Group Subject: Ftp-WG: thoughts on ftp extensions and caching --------------DE97CB21B1473EF466211CCB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dave Cridland wrote: > > > I'm unconvinced that it's needed, though, in any case. > > Yes, if a HTTP->FTP proxy system really wants to use Content-Length > headers, that's fine, but given that we're mainly interested in > HTTP/1.1, I can't see the issue here - Chunked Encoding should work > fine for giving the size of the data transfer, simply by buffering a > handful of k. The startup time would then be as it is now, and the > whole thing fits into both standards as of now. Obviously in the case > of HTTP/1.0, there's no need to give any indication of the download > length, so there's no need to attempt to support it. Although again the use of chunked-encoding can result in added processing burden in proxies. Also any benefit from the potential use of Content-Length along the way to the destination client is completely foiled, and avoiding it seems to imply it has relatively little value to begin with, etc.... > Putting in a MLST line in the response for a file being downloaded > makes sense to me, simply because it can be done with ease - and gives > cues on whether the proxy should consider this file for caching. This > is a performance advantage for the proxy, and the way MLST is > designed, a minumum hit on the server. > > If Squid, Apache and the others are actually issuing SIZE commands and > Content-Length headers, then it's my thinking that they're doing > things the wrong way in any case. Perhaps but it might conceivably also be interpreted as acts of desperation on the part of the authors (?) in lieu of a reliable standard to begin with. > > -----Original Message----- > From: Stephen Tihor [mailto:TIHOR@ACFcluster.NYU.EDU] > Sent: Tuesday, June 06, 2000 4:39 AM > To: FTPEXT Working Group > Subject: Ftp-WG: thoughts on ftp extensions and caching > > Nope it would not. Seems to be letting the HTTP tail wag the host file > > system dog though. Maybe though caching seems to be attracting considerable interest these days. RFC 959 contains the following which also may be relevant to discussions: A comment on transfer modes. The stream transfer mode is inherently unreliable, since one can not determine if the connection closed prematurely or not. The other transfer modes (Block, Compressed) do not close the connection to indicate the end of file. They have enough FTP encoding that the data connection can be parsed to determine the end of the file. It seems as if it would be nice to be able to clear this up one way or another. -s --------------DE97CB21B1473EF466211CCB Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Dave Cridland wrote:
 

I'm unconvinced that it's needed, though, in any case.

Yes, if a HTTP->FTP proxy system really wants to use Content-Length headers, that's fine, but given that we're mainly interested in HTTP/1.1, I can't see the issue here - Chunked Encoding should work fine for giving the size of the data transfer, simply by buffering a handful of k. The startup time would then be as it is now, and the whole thing fits into both standards as of now. Obviously in the case of HTTP/1.0, there's no need to give any indication of the download length, so there's no need to attempt to support it.


Although again the use of chunked-encoding can result in added processing burden
in proxies.  Also any benefit from the potential use of Content-Length along the way
to the destination client is completely foiled, and avoiding it seems to imply it
has relatively little value to begin with, etc....

Putting in a MLST line in the response for a file being downloaded makes sense to me, simply because it can be done with ease - and gives cues on whether the proxy should consider this file for caching. This is a performance advantage for the proxy, and the way MLST is designed, a minumum hit on the server.

If Squid, Apache and the others are actually issuing SIZE commands and Content-Length headers, then it's my thinking that they're doing things the wrong way in any case.

Perhaps but it might conceivably also be interpreted as acts of desperation on the part of the authors (?)
in lieu of a reliable standard to begin with.
 
-----Original Message-----
From: Stephen Tihor [mailto:TIHOR@ACFcluster.NYU.EDU]
Sent: Tuesday, June 06, 2000 4:39 AM
To: FTPEXT Working Group
Subject: Ftp-WG: thoughts on ftp extensions and caching

Nope it would not. Seems to be letting the HTTP tail wag the host file
system dog though.

Maybe though caching seems to be attracting considerable interest these days.

RFC 959 contains the following which also may be relevant to discussions:

         A comment on transfer modes.  The stream transfer mode is
         inherently unreliable, since one can not determine if the
         connection closed prematurely or not.  The other transfer modes
         (Block, Compressed) do not close the connection to indicate the
         end of file.  They have enough FTP encoding that the data
         connection can be parsed to determine the end of the file.

It seems as if it would be nice to be able to clear this up one way or another.

-s
 
 
 
 
  --------------DE97CB21B1473EF466211CCB-- From ftp-wg-owner@hethmon.com Tue Jun 6 13:25:39 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15159 for ; Tue, 6 Jun 2000 13:25:39 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000606122458-17742-7 ; Tue, 06 Jun 2000 12:24:58 -0500 Received: from ACFcluster.NYU.EDU (AXP2.ACF.NYU.EDU [128.122.250.38]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000606122456-11401-6 ; Tue, 06 Jun 2000 12:24:56 -0500 Received: from ACFcluster.NYU.EDU by ACFcluster.NYU.EDU (PMDF V5.2-32 #33915) id <01JQA848ITHC8WZUJ4@ACFcluster.NYU.EDU> for ftp-wg@hethmon.com; Tue, 6 Jun 2000 13:21:24 EDT In-reply-to: "Your message dated Tue, 06 Jun 2000 11:57:56 -0500" <393D2CE8.8F24117E@entera.com> Message-id: <01JQA8MBV3N48WZUJ4@ACFcluster.NYU.EDU> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII References: <61A45D5AE74BD311A76D00A0D21B18723672E8@magritte.felspar.net> Date: Tue, 6 Jun 2000 12:24:56 -0500 X-OldDate: Tue, 06 Jun 2000 13:20:58 -0400 (EDT) Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Stephen Tihor To: FTPEXT Working Group Subject: Ftp-WG: thoughts on ftp extensions and caching For predictive cacheing approximate sizes or (min,max) pairs are pretty good. With a defined indefinite value/return type From ftp-wg-owner@hethmon.com Tue Jun 6 14:31:52 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16549 for ; Tue, 6 Jun 2000 14:31:52 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000606132058-24425-7 ; Tue, 06 Jun 2000 13:20:58 -0500 Received: from havoc.entera.com (havoc.entera.com [206.165.109.130]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000606132053-13625-7 ; Tue, 06 Jun 2000 13:20:54 -0500 Received: from entera.com ([208.48.116.174]) by havoc.entera.com (Post.Office MTA v3.5.3 release 223 ID# 0-61971U200L100S0V35) with ESMTP id com for ; Tue, 6 Jun 2000 11:15:28 -0700 Message-ID: <393D4059.905999FE@entera.com> Organization: Entera, Inc. X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.7 i86pc) X-Accept-Language: en MIME-Version: 1.0 References: <61A45D5AE74BD311A76D00A0D21B18723672E8@magritte.felspar.net> <01JQA8MBV3N48WZUJ4@ACFcluster.NYU.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 6 Jun 2000 13:20:55 -0500 X-OldDate: Tue, 06 Jun 2000 11:18:01 -0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Stephen Head To: FTPEXT Working Group Subject: Ftp-WG: thoughts on ftp extensions and caching Content-Transfer-Encoding: 7bit Stephen Tihor wrote: > For predictive cacheing approximate sizes or (min,max) pairs are pretty good. > With a defined indefinite value/return type This gets into the thoughts I excised from an earlier message. As I understand it the current draft-10 does not give mininum or maximum indications. If it did, it would be better than a simple "approximation" which could go either way. I didn't really want to complicate the notion too much at least without cause since as I've addressed before I am of the opinion exact sizes is worth the effort and can be pre-computed for given files. I would personally view something along the lines of Approx-min-size and Approx-max-size as a last resort given my current awareness of the issue(s). -s From ftp-wg-owner@hethmon.com Tue Jun 6 14:48:13 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16990 for ; Tue, 6 Jun 2000 14:48:12 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000606134549-21439-8 ; Tue, 06 Jun 2000 13:45:50 -0500 Received: from ACFcluster.NYU.EDU (AXP2.ACF.NYU.EDU [128.122.250.38]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000606134545-58734-7 ; Tue, 06 Jun 2000 13:45:46 -0500 Received: from ACFcluster.NYU.EDU by ACFcluster.NYU.EDU (PMDF V5.2-32 #33915) id <01JQABBVQNHC8WZUJ4@ACFcluster.NYU.EDU> for ftp-wg@hethmon.com; Tue, 6 Jun 2000 14:42:11 EDT In-reply-to: "Your message dated Tue, 06 Jun 2000 13:20:55 -0500" <393D4059.905999FE@entera.com> Message-id: <01JQABG1H5T68WZUJ4@ACFcluster.NYU.EDU> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii References: <61A45D5AE74BD311A76D00A0D21B18723672E8@magritte.felspar.net> <01JQA8MBV3N48WZUJ4@ACFcluster.NYU.EDU> Date: Tue, 6 Jun 2000 13:45:47 -0500 X-OldDate: Tue, 06 Jun 2000 14:41:04 -0400 (EDT) Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Stephen Tihor To: FTPEXT Working Group Subject: Ftp-WG: thoughts on ftp extensions and caching I belive we cna cheaply provide a guarenteed minimum or maximum size for almost ervery file and aboth for only slightly fewer files, very efficiency. its the exact number in between that is hard. Of course a facotr of 2x or 4x may be involved. From ftp-wg-owner@hethmon.com Tue Jun 6 15:11:54 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17434 for ; Tue, 6 Jun 2000 15:11:52 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000606140342-26043-7 ; Tue, 06 Jun 2000 14:03:43 -0500 Received: from magritte.felspar.net (195.13.68.90 [195.13.68.90]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000606140338-43540-6 ; Tue, 06 Jun 2000 14:03:38 -0500 Received: by magritte.felspar.net with Internet Mail Service (5.5.2448.0) id ; Tue, 6 Jun 2000 20:03:51 +0100 Message-ID: <61A45D5AE74BD311A76D00A0D21B18723672ED@magritte.felspar.net> MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFCFE9.F3233250" Date: Tue, 6 Jun 2000 14:03:39 -0500 X-OldDate: Tue, 6 Jun 2000 20:03:50 +0100 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Dave Cridland To: "'FTPEXT Working Group'" Subject: Ftp-WG: thoughts on ftp extensions and caching This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFCFE9.F3233250 Content-Type: text/plain; charset="iso-8859-1" My theory: 1) We have a problem here. We know that much. 2) The problem is in three parts: a) STREAM mode transfers, which I think probably account for all FTP transfers these days, do not have any indication of whether a file has been successfully RETRieved, although the response code after the transfer will usually give it away. b) HTTP->FTP gateways are required to give some indication of when the file has been transferred, either in advance, by the Content-Length method, or inherently, using the Chunked Encoding method. These are required by HTTP/1.1 for keeping alive connections, as I understand things. c) HTTP->FTP gateways which perform some kind of policy based caching require some file size indication in order to know whether to consider the file for caching or not. There is some speculation about whether the size here needs to be wholly accurate, or whether it can be approximate. 3) There is significant overhead, as discussed before on this list, for determining the transfer size (as given by the SIZE command) of a file. There is no significant overhead in giving an approximate size, as given by the "size" fact of MLS*. My suggestions: a) In the real world, I've experienced few problems with being unsure of whether the file has been transferred or not. In the absence of finding the transfer size, I find that the use of the response code afterwards seems to give a reliable indication with today's networks and technology. Having said that, it'd be nice if the file transfer size was indicated during commencement of a download. However, if I relied on it, I'd be using SIZE beforehand. So, FTP servers which support our currently non-existent extension should give a "transfer-size" fact in any MLS* line, including that given by responses to RETR, where this does not place a significant burden on the FTP server. This includes caching responses to previous requests for SIZE if this is possible and/or desirable. Note that this is only a solution for downloads, and not for uploads. The only way I can think of for uploads would be to suggest the use of the ALLO command prior to the upload, or else define another, similar, command for this use. This is a tad unfortunate, as I have a sneaky feeling that uploads in STREAM mode are by far the more problematic. b) The solution to this seems to me to be Chunked Encoding, where the transfer-size is not available, and Content-Length where it is. It fits the bill nicely, and is interoperable with all current FTP servers. HTTP->HTTP gateways chaining onto the back of the HTTP->FTP gateway may suffer some loss of meta-information, however. See below: c) Where the transfer-size is available form the FTP server, the HTTP->FTP gateway should use this. Where it isn't, the HTTP->FTP server should use the approximate size, where available, for policy decisions. This should be accurate enough in almost every case. Where there is no size information available, which includes current FTP servers, the method for policy decision making is undefined, however, HTTP->FTP gateway implementors should be aware that using STAT on MLST capable FTP servers will be faster than SIZE in some cases. Ideally, however, the HTTP->FTP gateway should avoid using multiple commands due to latency issues, and should instead attempt to either cache the information from previous MLSD requests, or make their decisions based on some other means. Since HTTP->HTTP gateways chaining onto the HTTP->FTP gateway may also require this information for their own policy decisions, this "approximate size" meta-information, however derived, should be passed back in some as yet undefined HTTP header (Content-Approx-Length?). That's my thoughts for now, anyways. Feel free to rip them apart, but do bear in mind that while I realise there's a problem for HTTP->FTP gateways, I'm fairly sure it's really two seperate problems, and if the problems appear to be in the current, limited set of implementations, then its these which we should fix as a priority. -----Original Message----- From: Stephen Head [ mailto:smh@entera.com ] Sent: Tuesday, June 06, 2000 5:58 PM To: FTPEXT Working Group Subject: Ftp-WG: thoughts on ftp extensions and caching Dave Cridland wrote: I'm unconvinced that it's needed, though, in any case. Yes, if a HTTP->FTP proxy system really wants to use Content-Length headers, that's fine, but given that we're mainly interested in HTTP/1.1, I can't see the issue here - Chunked Encoding should work fine for giving the size of the data transfer, simply by buffering a handful of k. The startup time would then be as it is now, and the whole thing fits into both standards as of now. Obviously in the case of HTTP/1.0, there's no need to give any indication of the download length, so there's no need to attempt to support it. Although again the use of chunked-encoding can result in added processing burden in proxies. Also any benefit from the potential use of Content-Length along the way to the destination client is completely foiled, and avoiding it seems to imply it has relatively little value to begin with, etc.... Putting in a MLST line in the response for a file being downloaded makes sense to me, simply because it can be done with ease - and gives cues on whether the proxy should consider this file for caching. This is a performance advantage for the proxy, and the way MLST is designed, a minumum hit on the server. If Squid, Apache and the others are actually issuing SIZE commands and Content-Length headers, then it's my thinking that they're doing things the wrong way in any case. Perhaps but it might conceivably also be interpreted as acts of desperation on the part of the authors (?) in lieu of a reliable standard to begin with. -----Original Message----- From: Stephen Tihor [ mailto:TIHOR@ACFcluster.NYU.EDU ] Sent: Tuesday, June 06, 2000 4:39 AM To: FTPEXT Working Group Subject: Ftp-WG: thoughts on ftp extensions and caching Nope it would not. Seems to be letting the HTTP tail wag the host file system dog though. Maybe though caching seems to be attracting considerable interest these days. RFC 959 contains the following which also may be relevant to discussions: A comment on transfer modes. The stream transfer mode is inherently unreliable, since one can not determine if the connection closed prematurely or not. The other transfer modes (Block, Compressed) do not close the connection to indicate the end of file. They have enough FTP encoding that the data connection can be parsed to determine the end of the file. It seems as if it would be nice to be able to clear this up one way or another. -s ------_=_NextPart_001_01BFCFE9.F3233250 Content-Type: text/html; charset="iso-8859-1"

My theory:
 
1) We have a problem here. We know that much.
2) The problem is in three parts:
a) STREAM mode transfers, which I think probably account for all FTP transfers these days, do not have any indication of whether a file has been successfully RETRieved, although the response code after the transfer will usually give it away.
b) HTTP->FTP gateways are required to give some indication of when the file has been transferred, either in advance, by the Content-Length method, or inherently, using the Chunked Encoding method. These are required by HTTP/1.1 for keeping alive connections, as I understand things.
c) HTTP->FTP gateways which perform some kind of policy based caching require some file size indication in order to know whether to consider the file for caching or not. There is some speculation about whether the size here needs to be wholly accurate, or whether it can be approximate.
3) There is significant overhead, as discussed before on this list, for determining the transfer size (as given by the SIZE command) of a file. There is no significant overhead in giving an approximate size, as given by the "size" fact of MLS*.
 
My suggestions:
 
a) In the real world, I've experienced few problems with being unsure of whether the file has been transferred or not. In the absence of finding the transfer size, I find that the use of the response code afterwards seems to give a reliable indication with today's networks and technology.
 
Having said that, it'd be nice if the file transfer size was indicated during commencement of a download. However, if I relied on it, I'd be using SIZE beforehand.
 
So, FTP servers which support our currently non-existent extension should give a "transfer-size" fact in any MLS* line, including that given by responses to RETR, where this does not place a significant burden on the FTP server. This includes caching responses to previous requests for SIZE if this is possible and/or desirable.
 
Note that this is only a solution for downloads, and not for uploads. The only way I can think of for uploads would be to suggest the use of the ALLO command prior to the upload, or else define another, similar, command for this use. This is a tad unfortunate, as I have a sneaky feeling that uploads in STREAM mode are by far the more problematic.
 
b) The solution to this seems to me to be Chunked Encoding, where the transfer-size is not available, and Content-Length where it is. It fits the bill nicely, and is interoperable with all current FTP servers.
 
HTTP->HTTP gateways chaining onto the back of the HTTP->FTP gateway may suffer some loss of meta-information, however. See below:
 
c) Where the transfer-size is available form the FTP server, the HTTP->FTP gateway should use this.
 
Where it isn't, the HTTP->FTP server should use the approximate size, where available, for policy decisions. This should be accurate enough in almost every case. Where there is no size information available, which includes current FTP servers, the method for policy decision making is undefined, however, HTTP->FTP gateway implementors should be aware that using STAT <file> on MLST capable FTP servers will be faster than SIZE <file> in some cases.
 
Ideally, however, the HTTP->FTP gateway should avoid using multiple commands due to latency issues, and should instead attempt to either cache the information from previous MLSD requests, or make their decisions based on some other means.
 
Since HTTP->HTTP gateways chaining onto the HTTP->FTP gateway may also require this information for their own policy decisions, this "approximate size" meta-information, however derived, should be passed back in some as yet undefined HTTP header (Content-Approx-Length?).
 
 
That's my thoughts for now, anyways. Feel free to rip them apart, but do bear in mind that while I realise there's a problem for HTTP->FTP gateways, I'm fairly sure it's really two seperate problems, and if the problems appear to be in the current, limited set of implementations, then its these which we should fix as a priority.
 
 -----Original Message-----
From: Stephen Head [mailto:smh@entera.com]
Sent: Tuesday, June 06, 2000 5:58 PM
To: FTPEXT Working Group
Subject: Ftp-WG: thoughts on ftp extensions and caching

Dave Cridland wrote:
 

I'm unconvinced that it's needed, though, in any case.

Yes, if a HTTP->FTP proxy system really wants to use Content-Length headers, that's fine, but given that we're mainly interested in HTTP/1.1, I can't see the issue here - Chunked Encoding should work fine for giving the size of the data transfer, simply by buffering a handful of k. The startup time would then be as it is now, and the whole thing fits into both standards as of now. Obviously in the case of HTTP/1.0, there's no need to give any indication of the download length, so there's no need to attempt to support it.


Although again the use of chunked-encoding can result in added processing burden
in proxies.  Also any benefit from the potential use of Content-Length along the way
to the destination client is completely foiled, and avoiding it seems to imply it
has relatively little value to begin with, etc....

Putting in a MLST line in the response for a file being downloaded makes sense to me, simply because it can be done with ease - and gives cues on whether the proxy should consider this file for caching. This is a performance advantage for the proxy, and the way MLST is designed, a minumum hit on the server.

If Squid, Apache and the others are actually issuing SIZE commands and Content-Length headers, then it's my thinking that they're doing things the wrong way in any case.

Perhaps but it might conceivably also be interpreted as acts of desperation on the part of the authors (?)
in lieu of a reliable standard to begin with.
 
-----Original Message-----
From: Stephen Tihor [mailto:TIHOR@ACFcluster.NYU.EDU]
Sent: Tuesday, June 06, 2000 4:39 AM
To: FTPEXT Working Group
Subject: Ftp-WG: thoughts on ftp extensions and caching

Nope it would not. Seems to be letting the HTTP tail wag the host file
system dog though.

Maybe though caching seems to be attracting considerable interest these days.

RFC 959 contains the following which also may be relevant to discussions:

         A comment on transfer modes.  The stream transfer mode is
         inherently unreliable, since one can not determine if the
         connection closed prematurely or not.  The other transfer modes
         (Block, Compressed) do not close the connection to indicate the
         end of file.  They have enough FTP encoding that the data
         connection can be parsed to determine the end of the file.

It seems as if it would be nice to be able to clear this up one way or another.

-s
 
 
 
 
 

------_=_NextPart_001_01BFCFE9.F3233250-- From ftp-wg-owner@hethmon.com Tue Jun 6 15:29:17 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17682 for ; Tue, 6 Jun 2000 15:29:16 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000606142900-54192-7 ; Tue, 06 Jun 2000 14:29:00 -0500 Received: from havoc.entera.com (havoc.entera.com [206.165.109.130]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000606142856-3487-6 ; Tue, 06 Jun 2000 14:28:56 -0500 Received: from entera.com ([208.48.116.174]) by havoc.entera.com (Post.Office MTA v3.5.3 release 223 ID# 0-61971U200L100S0V35) with ESMTP id com for ; Tue, 6 Jun 2000 12:23:32 -0700 Message-ID: <393D504D.C970EAE3@entera.com> Organization: Entera, Inc. X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.7 i86pc) X-Accept-Language: en MIME-Version: 1.0 References: <61A45D5AE74BD311A76D00A0D21B18723672E8@magritte.felspar.net> <01JQA8MBV3N48WZUJ4@ACFcluster.NYU.EDU> <01JQABG1H5T68WZUJ4@ACFcluster.NYU.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 6 Jun 2000 14:28:57 -0500 X-OldDate: Tue, 06 Jun 2000 12:26:05 -0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Stephen Head To: FTPEXT Working Group Subject: Ftp-WG: thoughts on ftp extensions and caching Content-Transfer-Encoding: 7bit Stephen Tihor wrote: > I belive we cna cheaply provide a guarenteed minimum or maximum size for almost > ervery file and aboth for only slightly fewer files, very efficiency. its the > exact number in between that is hard. Of course a facotr of 2x or 4x may be > involved. Has a survey been done or attempted as to what percentage of ftp servers now in service use a OS in which giving the exact size would require undue computation? Of those, what percentage of files actually exhibit the problem? Will a FTP put followed by a get result in exhibiting the problem? Or is it due to some other factor(s), such as deleted records embedded in the file? (Apologies if this has already been discussed in detail in the wg already; if not, some estimates might be of help in getting consensus.) I have difficulty agreeing with the opinion that approximate sizes or min, max pairs are "pretty good" for caching servers. To me it seems it is not yet demonstrated to the point where there are compelling circumstances in which no alternatives are available. The algorithm implied for caching decision would seem to be to replace a simple conditional with something along the lines of: if Approx-max-size fact returned then if Approx-max-size-value > (Configurable-fudge-factor * Configurable-highwatermark-size) then bail out else /* attempt to cache */ begin caching and later, elsewhere: if Actual-running-accumulation-size > (Configurable-fudge-factor * Configurable-highwatermark-size) then terminate caching delete cache-entry while the destination client is subjected to a potential quality of service fluctuation in overall response time, the complexity of the caching server is increased substantially (affecting reliability and time to market) and testing cases must be expanded considerably to incorporate the new and more complex code paths and new boundary conditions. This is especially true if the Configurable-fudge-factor is underestimated relative to the actual load on a live network. (What will the recommended default(s) be?) Add a corresponding amount of complexity for anyone wishing to use Approx-min-size in their caching policies. Can we envision that there would be demand such that benchmarks would ever be expanded to incorporate such test cases, at least in the reasonably forseeable future? Also approximations do not appear to help the purported inherent unreliability of stream transfer mode mentioned in RFC959, if that is viewed as an issue... -s From ftp-wg-owner@hethmon.com Tue Jun 6 15:35:50 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17811 for ; Tue, 6 Jun 2000 15:35:50 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000606143546-55787-8 ; Tue, 06 Jun 2000 14:35:46 -0500 Received: from ACFcluster.NYU.EDU (AXP2.ACF.NYU.EDU [128.122.250.38]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000606143542-62444-7 ; Tue, 06 Jun 2000 14:35:43 -0500 Received: from ACFcluster.NYU.EDU by ACFcluster.NYU.EDU (PMDF V5.2-32 #33915) id <01JQAD1YAMZK8WZUJ4@ACFcluster.NYU.EDU> for ftp-wg@hethmon.com; Tue, 6 Jun 2000 15:32:12 EDT In-reply-to: "Your message dated Tue, 06 Jun 2000 14:28:57 -0500" <393D504D.C970EAE3@entera.com> Message-id: <01JQAD71GC4Y8WZUJ4@ACFcluster.NYU.EDU> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii References: <61A45D5AE74BD311A76D00A0D21B18723672E8@magritte.felspar.net> <01JQA8MBV3N48WZUJ4@ACFcluster.NYU.EDU> <01JQABG1H5T68WZUJ4@ACFcluster.NYU.EDU> Date: Tue, 6 Jun 2000 14:35:43 -0500 X-OldDate: Tue, 06 Jun 2000 15:29:02 -0400 (EDT) Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Stephen Tihor To: FTPEXT Working Group Subject: Ftp-WG: thoughts on ftp extensions and caching > Has a survey been done or attempted as to what percentage of ftp servers > now in service use a OS in which giving the exact size would require undue > computation? This is not the way to create good internet standards. This is how you get Microsft incompatibleware and vendor locking. > Of those, what percentage of files actually exhibit the problem? Of the ones I am aware, most. > Will a FTP put followed by a get result in exhibiting the problem? Unless the FTP server specifically maaintained a cache of size information. I am not aware of any doing this though one can imagine a variety of such strategies - several of which IO object to sinc they are incompatible with good security practices on ystems otehr than dedicated FTP server appliances. > Or is it due to some other factor(s), such as deleted records embedded in the > file? > (Apologies if this has already been discussed in detail in the wg already; > if not, some estimates might be of help in getting consensus.) Again, this sounds like a There are less than x% of these so we can make them all work very very hard to pretend they are brand X which happens to work this way. From ftp-wg-owner@hethmon.com Tue Jun 6 17:51:44 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19701 for ; Tue, 6 Jun 2000 17:51:41 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000606164800-50195-12 ; Tue, 06 Jun 2000 16:48:00 -0500 Received: from havoc.entera.com (havoc.entera.com [206.165.109.130]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000606164756-61402-8 ; Tue, 06 Jun 2000 16:47:57 -0500 Received: from entera.com ([208.48.116.174]) by havoc.entera.com (Post.Office MTA v3.5.3 release 223 ID# 0-61971U200L100S0V35) with ESMTP id com for ; Tue, 6 Jun 2000 14:42:32 -0700 Message-ID: <393D70E1.9880D073@entera.com> Organization: Entera, Inc. X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.7 i86pc) X-Accept-Language: en MIME-Version: 1.0 References: <61A45D5AE74BD311A76D00A0D21B18723672ED@magritte.felspar.net> Content-Type: multipart/alternative; boundary="------------EC0AD040623824702B0C73BB" Date: Tue, 6 Jun 2000 16:47:57 -0500 X-OldDate: Tue, 06 Jun 2000 14:45:05 -0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Stephen Head To: FTPEXT Working Group Subject: Ftp-WG: thoughts on ftp extensions and caching --------------EC0AD040623824702B0C73BB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit <> On using the response code to determine whether a file has been successfully retrieved, it certainly seems to imply that the server application process (assuming it is implemented as a process) considers all the data to have been presented to its underlying TCP module without error. It is unclear to me exactly why, if the contention is true, that the note still exists in RFC 959; if it is a warning about a condition that can always be avoided, why include it (somewhat rhetorically)? But if there is some valid problem (what?), then having exact size information up front would certainly fix it as far as I can tell. [Either way, it is possible that RFC 959 could benefit at a minimum from some textual wordsmithing in this regard if it is indeed a no-op in practice.] [Certainly Content-Length can be useful for keepalive connections but its use predated HTTP/1.1 which it is my understanding introduced connection re-use for requests except for experimental versions (I am looking at HTTP/1.0 RFC 1945, section 1.3). Content-Length is present (though not required yet) acc. to HTTP/1.0 RFC 1945 section 10.4.] [I am relatively neutral on the merit of a Content-Approx-Length HTTP header since I do not now perceive its value currently to be of sufficient worth that I would personally go out of my way to use it to any significant degree if I encountered it. I am however noting it for further consideration and my opinion might change in the future.] Whether approximate size is "accurate enough" for cache servers raises some concerns which I tried to illustrate in my previous message. Stephen Tihor mentioned earlier that accuracy could vary by at least a factor of 2-4. For implementation purposes one presumeably ought to be concerned, fortunately or otherwise, with worst cases in order to avoid problems. I would be hesitant to rely very much on a value which could be off by a factor of 2-4 or more for anything I would want to try to implement that relied on an approximation of size. An alternative is to try to cache everything and bail out when some policy criterion is exceeded on a per-transaction basis; however, it is often the case that such a policy incurs price/performance penalties for the caching server and the downstream clients it serves. An accurate size up front would help to avoid such penalties. Making the up front reporting of accurate size information is, IMHO, of sufficient value such that the working group may wish to consider ways to encourage reporting it by conforming servers, since it seems (to me at least) of general benefit to network health at large in minimizing net message overhead, response latency, and so on. Correspondingly, to the extent it is made optional ("should") and to the extent that it is not reliably available for use downstream reduces the benefit (at times, probably resulting in missed opportunities for optimizing overall net bandwidth). [Upload considerations do not appear to be a caching concern so I leave this to others.] <> Philosophically, if there is a network-transfer-related benefit to be obtained by calculation of a static value, it would seem advantageous to consider slanting the playing field in favor of reporting that value for the benefit of the more restrictive-constrained systems involved in the dynamic transfer in contrast to requiring those systems to compensate by added complexity, impaired functionality, or both. Were someone seriously/frequently using ftp for some kind of tunneling of dynamically generated data (?) I would be more reluctant to put forward such an argument. -s ----- Dave Cridland wrote: > > My theory: > 1) We have a problem here. We know that much. > 2) The problem is in three parts: > a) STREAM mode transfers, which I think probably account for all FTP > transfers these days, do not have any indication of whether a file has > been successfully RETRieved, although the response code after the > transfer will usually give it away. > b) HTTP->FTP gateways are required to give some indication of when the > file has been transferred, either in advance, by the Content-Length > method, or inherently, using the Chunked Encoding method. These are > required by HTTP/1.1 for keeping alive connections, as I understand > things. > c) HTTP->FTP gateways which perform some kind of policy based caching > require some file size indication in order to know whether to consider > the file for caching or not. There is some speculation about whether > the size here needs to be wholly accurate, or whether it can be > approximate. > 3) There is significant overhead, as discussed before on this list, > for determining the transfer size (as given by the SIZE command) of a > file. There is no significant overhead in giving an approximate size, > as given by the "size" fact of MLS*. > > My suggestions: > a) In the real world, I've experienced few problems with being unsure > of whether the file has been transferred or not. In the absence of > finding the transfer size, I find that the use of the response code > afterwards seems to give a reliable indication with today's networks > and technology. > Having said that, it'd be nice if the file transfer size was indicated > during commencement of a download. However, if I relied on it, I'd be > using SIZE beforehand. > So, FTP servers which support our currently non-existent extension > should give a "transfer-size" fact in any MLS* line, including that > given by responses to RETR, where this does not place a significant > burden on the FTP server. This includes caching responses to previous > requests for SIZE if this is possible and/or desirable. > Note that this is only a solution for downloads, and not for uploads. > The only way I can think of for uploads would be to suggest the use of > the ALLO command prior to the upload, or else define another, similar, > command for this use. This is a tad unfortunate, as I have a sneaky > feeling that uploads in STREAM mode are by far the more problematic. > b) The solution to this seems to me to be Chunked Encoding, where the > transfer-size is not available, and Content-Length where it is. It > fits the bill nicely, and is interoperable with all current FTP > servers. > HTTP->HTTP gateways chaining onto the back of the HTTP->FTP gateway > may suffer some loss of meta-information, however. See below: > c) Where the transfer-size is available form the FTP server, the > HTTP->FTP gateway should use this. > Where it isn't, the HTTP->FTP server should use the approximate size, > where available, for policy decisions. This should be accurate enough > in almost every case. Where there is no size information available, > which includes current FTP servers, the method for policy decision > making is undefined, however, HTTP->FTP gateway implementors should be > aware that using STAT on MLST capable FTP servers will be > faster than SIZE in some cases. > Ideally, however, the HTTP->FTP gateway should avoid using multiple > commands due to latency issues, and should instead attempt to either > cache the information from previous MLSD requests, or make their > decisions based on some other means. > Since HTTP->HTTP gateways chaining onto the HTTP->FTP gateway may also > require this information for their own policy decisions, this > "approximate size" meta-information, however derived, should be passed > back in some as yet undefined HTTP header (Content-Approx-Length?). > > That's my thoughts for now, anyways. Feel free to rip them apart, but > do bear in mind that while I realise there's a problem for HTTP->FTP > gateways, I'm fairly sure it's really two seperate problems, and if > the problems appear to be in the current, limited set of > implementations, then its these which we should fix as a priority. > > --------------EC0AD040623824702B0C73BB Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <<devil's advocate mode on>>

On using the response code to determine whether a file has been successfully
retrieved, it certainly seems to imply that the server application process
(assuming it is implemented as a process) considers all the data to have
been presented to its underlying TCP module without error.  It is unclear
to me exactly why, if the contention is true, that the note still exists
in RFC 959; if it is a warning about a condition that can always be avoided,
why include it (somewhat rhetorically)?  But if there is some valid problem
(what?), then having exact size information up front would certainly
fix it as far as I can tell.  [Either way, it is possible that RFC 959 could
benefit at a minimum from some textual wordsmithing in this regard
if it is indeed a no-op in practice.]

[Certainly Content-Length can be useful for keepalive connections
but its use predated HTTP/1.1 which it is my understanding introduced
connection re-use for requests except for experimental versions
(I am looking at HTTP/1.0 RFC 1945, section 1.3).  Content-Length
is present (though not required yet) acc. to HTTP/1.0 RFC 1945 section 10.4.]

[I am relatively neutral on the merit of a Content-Approx-Length HTTP
header since I do not now perceive its value currently to be of sufficient worth
that I would personally go out of my way to use it to any significant degree
if I encountered it.  I am however noting it for further consideration
and my opinion might change in the future.]

Whether approximate size is "accurate enough" for cache servers
raises some concerns which I tried to illustrate in my previous message.
Stephen Tihor mentioned earlier that accuracy could vary by at least a factor
of 2-4.  For implementation purposes one presumeably ought to be concerned,
fortunately or otherwise, with worst cases in order to avoid problems.  I would
be hesitant to rely very much on a value which could be off by a factor
of 2-4 or more for anything I would want to try to implement that relied on
an approximation of size.  An alternative is to try to cache everything and
bail out when some policy criterion is exceeded on a per-transaction basis;
however, it is often the case that such a policy incurs price/performance
penalties for the caching server and the downstream clients it serves.
An accurate size up front would help to avoid such penalties.

Making the up front reporting of accurate size information
is, IMHO, of sufficient value such that the working group may
wish to consider ways to encourage reporting it by conforming
servers, since it seems (to me at least) of general benefit
to network health at large in minimizing net message overhead,
response latency, and so on.  Correspondingly, to the extent it is
made optional ("should") and to the extent that it is not reliably available
for use downstream reduces the benefit (at times, probably
resulting in missed opportunities for optimizing overall net bandwidth).

[Upload considerations do not appear to be a caching concern so I leave this
to others.]

<<devil's advocate mode off>>

Philosophically, if there is a network-transfer-related benefit
to be obtained by calculation of a static value, it would seem
advantageous to consider slanting the playing field in favor
of reporting that value for the benefit of the more restrictive-constrained
systems involved in the dynamic transfer in contrast to requiring
those systems to compensate by added complexity, impaired
functionality, or both.  Were someone seriously/frequently using ftp for
some kind of tunneling of dynamically generated data (?) I would
be more reluctant to put forward such an argument.

-s

-----

Dave Cridland wrote:

 
My theory:
1) We have a problem here. We know that much.
2) The problem is in three parts:
a) STREAM mode transfers, which I think probably account for all FTP transfers these days, do not have any indication of whether a file has been successfully RETRieved, although the response code after the transfer will usually give it away.
b) HTTP->FTP gateways are required to give some indication of when the file has been transferred, either in advance, by the Content-Length method, or inherently, using the Chunked Encoding method. These are required by HTTP/1.1 for keeping alive connections, as I understand things.
c) HTTP->FTP gateways which perform some kind of policy based caching require some file size indication in order to know whether to consider the file for caching or not. There is some speculation about whether the size here needs to be wholly accurate, or whether it can be approximate.
3) There is significant overhead, as discussed before on this list, for determining the transfer size (as given by the SIZE command) of a file. There is no significant overhead in giving an approximate size, as given by the "size" fact of MLS*.
 
My suggestions:
a) In the real world, I've experienced few problems with being unsure of whether the file has been transferred or not. In the absence of finding the transfer size, I find that the use of the response code afterwards seems to give a reliable indication with today's networks and technology.
Having said that, it'd be nice if the file transfer size was indicated during commencement of a download. However, if I relied on it, I'd be using SIZE beforehand.
So, FTP servers which support our currently non-existent extension should give a "transfer-size" fact in any MLS* line, including that given by responses to RETR, where this does not place a significant burden on the FTP server. This includes caching responses to previous requests for SIZE if this is possible and/or desirable.
Note that this is only a solution for downloads, and not for uploads. The only way I can think of for uploads would be to suggest the use of the ALLO command prior to the upload, or else define another, similar, command for this use. This is a tad unfortunate, as I have a sneaky feeling that uploads in STREAM mode are by far the more problematic.
b) The solution to this seems to me to be Chunked Encoding, where the transfer-size is not available, and Content-Length where it is. It fits the bill nicely, and is interoperable with all current FTP servers.
HTTP->HTTP gateways chaining onto the back of the HTTP->FTP gateway may suffer some loss of meta-information, however. See below:
c) Where the transfer-size is available form the FTP server, the HTTP->FTP gateway should use this.
Where it isn't, the HTTP->FTP server should use the approximate size, where available, for policy decisions. This should be accurate enough in almost every case. Where there is no size information available, which includes current FTP servers, the method for policy decision making is undefined, however, HTTP->FTP gateway implementors should be aware that using STAT <file> on MLST capable FTP servers will be faster than SIZE <file> in some cases.
Ideally, however, the HTTP->FTP gateway should avoid using multiple commands due to latency issues, and should instead attempt to either cache the information from previous MLSD requests, or make their decisions based on some other means.
Since HTTP->HTTP gateways chaining onto the HTTP->FTP gateway may also require this information for their own policy decisions, this "approximate size" meta-information, however derived, should be passed back in some as yet undefined HTTP header (Content-Approx-Length?).
 
That's my thoughts for now, anyways. Feel free to rip them apart, but do bear in mind that while I realise there's a problem for HTTP->FTP gateways, I'm fairly sure it's really two seperate problems, and if the problems appear to be in the current, limited set of implementations, then its these which we should fix as a priority.
 
--------------EC0AD040623824702B0C73BB-- From ftp-wg-owner@hethmon.com Tue Jun 6 18:28:37 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20163 for ; Tue, 6 Jun 2000 18:28:35 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000606172636-31716-7 ; Tue, 06 Jun 2000 17:26:36 -0500 Received: from havoc.entera.com (havoc.entera.com [206.165.109.130]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000606172633-7085-6 ; Tue, 06 Jun 2000 17:26:33 -0500 Received: from entera.com ([208.48.116.174]) by havoc.entera.com (Post.Office MTA v3.5.3 release 223 ID# 0-61971U200L100S0V35) with ESMTP id com for ; Tue, 6 Jun 2000 15:21:09 -0700 Message-ID: <393D79EF.9B890EA@entera.com> Organization: Entera, Inc. X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.7 i86pc) X-Accept-Language: en MIME-Version: 1.0 References: <61A45D5AE74BD311A76D00A0D21B18723672E8@magritte.felspar.net> <01JQA8MBV3N48WZUJ4@ACFcluster.NYU.EDU> <01JQABG1H5T68WZUJ4@ACFcluster.NYU.EDU> <01JQAD71GC4Y8WZUJ4@ACFcluster.NYU.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 6 Jun 2000 17:26:33 -0500 X-OldDate: Tue, 06 Jun 2000 15:23:43 -0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Stephen Head To: FTPEXT Working Group Subject: Ftp-WG: thoughts on ftp extensions and caching Content-Transfer-Encoding: 7bit Stephen Tihor wrote: > > Has a survey been done or attempted as to what percentage of ftp servers > > now in service use a OS in which giving the exact size would require undue > > computation? > > This is not the way to create good internet standards. This is how you get > Microsft incompatibleware and vendor locking. Sorry, didn't quite get this, or at least intend to imply that some formal questionnaire be sent out. I was trying to address current actual practice only and (for example) rough estimates from knowledgeable administrator-types as some kind of starting point to get an estimate of the measure of difficulty of implementing whatever alternatives one is already considering versus new alternatives. It is an attempt to be fair under the presumtion that the more readily available advance knowledge assembled for consideration, the better... > > Of those, what percentage of files actually exhibit the problem? > Of the ones I am aware, most. What I mean is, is there a sense of which OSs and what percentage, for Image/ASCII/whatever types, and for each OS which native file types have the problem and under what circumstances? Conceding that ASCII is already a pain in the neck even for Un*x (so don't need to consider that particular case), but recalling that Exact-image-size appears to be a fully useable substitute for caching purposes as I mentioned earlier Any ventures as to breakdown guesstimates? And is there a cutoff that the wg is willing to accept, for example if only XXXOS YYY files have a problem and if only 0.1% of ftp servers use XXXOS and only 0.5% of such servers have YYY files with the problem, is this deemed sufficient to withhold adoption of some feature that would require pre-computation on XXXOS wrt YYY files? (what are the specific names and values to substitute here) > > Will a FTP put followed by a get result in exhibiting the problem? > Unless the FTP server specifically maaintained a cache of size information. > I am not aware of any doing this though one can imagine a variety of such > strategies - several of which IO object to sinc they are incompatible with good > security practices on ystems otehr than dedicated FTP server appliances. [So then staging a transfer through a FTP server could potentially result in loss of useful exact-size variety header info under both current and your preferred future standards. In general, is this a good thing?] [Not sure what the reference to security concerns was about-- explain if you like. I was positing the hypothetical example of a relatively simple A->B, B->C transfer sequence. And trying to determine how image files are typically generated (wrt choice of appropriate native OS file type) on the server to begin with for OSs with these issues.] > > > Or is it due to some other factor(s), such as deleted records embedded in the > > file? > > (Apologies if this has already been discussed in detail in the wg already; > > if not, some estimates might be of help in getting consensus.) > > Again, this sounds like a There are less than x% of these so we can make them > all work very very hard to pretend they are brand X which happens to work this > way. No, it's not an attempt by me to discriminate against anyone's favorite OS, and apologies if that appeared to be the case. I thought there was a prima facie case for the general network-related usefulness of the information independent of the OS and proceeded on that presumption. I was just looking for specific cases. It's just a bit hard to attempt to understand and/or try to offer solutions concerning a difficult case without a definitive description of the difficulty to begin with. Sorry if I am baying at the wrong moon here; again if the point has already been discussed thoroughly and conceded for image files then maybe it's not worth revisiting at this time. -s From ftp-wg-owner@hethmon.com Tue Jun 6 18:35:35 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20278 for ; Tue, 6 Jun 2000 18:35:33 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000606173159-23154-13 ; Tue, 06 Jun 2000 17:31:59 -0500 Received: from mail.vr.net (mail.vr.net [205.133.13.8]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000606173156-63608-11 ; Tue, 06 Jun 2000 17:31:57 -0500 Received: from osiris (osiris.vr.net [205.133.13.9]) (authenticated) by mail.vr.net (8.10.1/8.10.1) with ESMTP id e56MSPB03783 for ; Tue, 6 Jun 2000 18:28:25 -0400 Message-ID: <00e601bfd006$102e1560$090d85cd@vr.net> References: <61A45D5AE74BD311A76D00A0D21B18723672ED@magritte.felspar.net> <393D70E1.9880D073@entera.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Date: Tue, 6 Jun 2000 17:31:57 -0500 X-OldDate: Tue, 6 Jun 2000 18:24:57 -0400 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: "Gregory A Lundberg" To: "FTPEXT Working Group" Subject: Ftp-WG: thoughts on ftp extensions and caching Content-Transfer-Encoding: 7bit > <> > > On using the response code to determine whether a file has been > successfully > retrieved, it certainly seems to imply that the server application > process > (assuming it is implemented as a process) considers all the data to have > > been presented to its underlying TCP module without error. It is > unclear > to me exactly why, if the contention is true, that the note still exists > > in RFC 959; if it is a warning about a condition that can always be > avoided, > why include it (somewhat rhetorically)? But if there is some valid > problem > (what?), then having exact size information up front would certainly > fix it as far as I can tell. [Either way, it is possible that RFC 959 > could > benefit at a minimum from some textual wordsmithing in this regard > if it is indeed a no-op in practice.] Jumping in in the middle ... As I see it, determining if a up/down load was complete is fairly easy. At end-of-file, the sender half-closes the data connection and waits for the receiver to half-close the connection; this brings us to a "closed" state (per TCP) which is required by 959. Once the data connection is in a "closed" state, the server sends the positive reply. Upon receipt of the positive reply, the client may safely assume the transfer was complete. While this addresses the problem of determining if a transfer was complete, it does not aid in pre-determining the byte-count. My problem with pre-determining the exact byte-count comes when some conversion or generation of data occurs during the data transfer. The only way, for instance, to accurately determine the exact size of an on-the-fly tar'd and gzip'd downloaded directory would be to peform the entire operation prior to beginning the data transfer. This would add an unacceptable delay to the beginning of a transfer, and place an unacceptable load on the server host. I could see a 'middle ground' ... If the size of the data transfer can be exactly predicted, then that size MUST be provided as a property and MUST appear in the positive intermediate reply to the download. If the size cannot be exactly predicted, then the size property MUST NOT be present and MUST NOT be given in the intermediate reply. I would say, given the wide error range which would be required, any 'approximation' would be a load of whew-y and should treated as such. From ftp-wg-owner@hethmon.com Tue Jun 6 19:00:16 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20400 for ; Tue, 6 Jun 2000 19:00:15 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000606175934-25864-6 ; Tue, 06 Jun 2000 17:59:34 -0500 Received: from havoc.entera.com (havoc.entera.com [206.165.109.130]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000606175930-1220-8 ; Tue, 06 Jun 2000 17:59:30 -0500 Received: from entera.com ([208.48.116.174]) by havoc.entera.com (Post.Office MTA v3.5.3 release 223 ID# 0-61971U200L100S0V35) with ESMTP id com for ; Tue, 6 Jun 2000 15:54:07 -0700 Message-ID: <393D81A8.7E86AC11@entera.com> Organization: Entera, Inc. X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.7 i86pc) X-Accept-Language: en MIME-Version: 1.0 References: <61A45D5AE74BD311A76D00A0D21B18723672ED@magritte.felspar.net> <393D70E1.9880D073@entera.com> <00e601bfd006$102e1560$090d85cd@vr.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 6 Jun 2000 17:59:31 -0500 X-OldDate: Tue, 06 Jun 2000 15:56:40 -0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Stephen Head To: FTPEXT Working Group Subject: Ftp-WG: thoughts on ftp extensions and caching Content-Transfer-Encoding: 7bit Gregory A Lundberg wrote: > As I see it, determining if a up/down load was complete is fairly easy. Agreed, possibly with the following consideration. > At end-of-file, the sender half-closes the data connection and waits for the > receiver to half-close the connection; this brings us to a "closed" state > (per TCP) which is required by 959. Once the data connection is in a > "closed" state, the server sends the positive reply. > Upon receipt of the positive reply, the client may safely assume the > transfer was complete. In theory, it seems as if the TCP FIN sent by the server on the data channel could be delayed in transmission relative to the positive reply sent by the server on the control channel. The client can presume the file to be successfully transmitted in total, therefore, if both conditions become true in either order (or at least, so it would seem). If so, the problem referred to in RFC 959 does not exist in practice (and if so becomes a candidate for wordsmithing out). [In what form will the eventual FTP extension reach the RFC stage?-- if rolling RFC959 in its entirety with a new RFC #, then this might be opportune to address at that time.] > > I could see a 'middle ground' ... > > If the size of the data transfer can be exactly predicted, then that size > MUST be provided as a property and MUST appear in the positive intermediate > reply to the download. > > If the size cannot be exactly predicted, then the size property MUST NOT be > present and MUST NOT be given in the intermediate reply. I would only observe that the process of placing the file in the server NVS to begin with, presuming accomplished via some form of file copy operation native to the server OS, typically (?) involves writing the contents of the file to that server's secondary storage. If so, keeping a cumulative count of the number of valid (re-readable in image format) bytes written to the file would appear to be relatively trivial (in theory at least) and invariant with time (ie it is always predictable). Storing and later retrieving on demand such information concurrently with file retrieval is additional work but not necessarily involving a significant delay if done intelligently. > I would say, given the wide error range which would be required, any > 'approximation' would be a load of whew-y and should treated as such. No objection from here... -s From ftp-wg-owner@hethmon.com Tue Jun 6 21:38:22 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21591 for ; Tue, 6 Jun 2000 21:38:22 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000606203837-29972-14 ; Tue, 06 Jun 2000 20:38:37 -0500 Received: from mail.vr.net (mail.vr.net [205.133.13.8]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000606203833-3029-13 ; Tue, 06 Jun 2000 20:38:33 -0500 Received: from osiris (osiris.vr.net [205.133.13.9]) (authenticated) by mail.vr.net (8.10.1/8.10.1) with ESMTP id e571Z3B10006 for ; Tue, 6 Jun 2000 21:35:03 -0400 Message-ID: <007001bfd020$24ee6f80$090d85cd@vr.net> References: <61A45D5AE74BD311A76D00A0D21B18723672ED@magritte.felspar.net> <393D70E1.9880D073@entera.com> <00e601bfd006$102e1560$090d85cd@vr.net> <393D81A8.7E86AC11@entera.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Date: Tue, 6 Jun 2000 20:38:35 -0500 X-OldDate: Tue, 6 Jun 2000 21:31:45 -0400 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: "Gregory A Lundberg" To: "FTPEXT Working Group" Subject: Ftp-WG: thoughts on ftp extensions and caching Content-Transfer-Encoding: 7bit > (or at least, so it would seem). If so, the problem referred to in RFC 959 > does not exist in practice (and if so becomes a candidate for wordsmithing > out). > > [In what form will the eventual FTP extension reach the RFC stage?-- > if rolling RFC959 in its entirety with a new RFC #, then this might be > opportune to address at that time.] In practice, WU-FTPD 2.6.0 made the switch. What we've found is a few (actually, very few) clients which will lock up waiting for the reply before closing the data channel. The list is fairly short, most vendors made updates when it was pointed out to them (if they'd not already run across the problem .. seems some far-less-often used daemons were doing the same thing). We support backward compatability with a compile-time option. From the questions on the support mailing lists, while the subject is a FAQ (and covered there), it seems the sites most in need of the backward compatability are those in support of specific products where the client is a legacy and having users upgrade is infeasable or impractical in the short/middle term. Sites where most users come in using graphical clients such as IE and NS have no such problems and generate very few pleas for help. > Storing and later retrieving on demand such information concurrently with file > retrieval > is additional work but not necessarily involving a significant delay if done > intelligently. What I'm referring to is massive pre-processing such as tar/gzip like we do in wu-ftpd's ftpconversions. I can (and have) ftp'd multi-Gbyte directories as a tar/gzip piped to the data channel. If I needed to wait for the tar/gzip to complete it could be several minutes and the server host would be required to store the entire tar/gzip in temp storage (which I hope is disk otherwise a sufficiently large archive will cause massive swapping on the host). Technically, it's possible. As a practical matter, though, I would never ask our users to live with such. -- On the subject of rolling RFC 959 into a new RFC; I'd like to see that. Heck, I'd like to see simply clarification and modernization of the language in RFC 959. I'm not sure, however, I'd like to see that begun until we've sealed and shipped the MLST and HOST RFCs. Let's not derail the work on those with a massive new project, yet. From ftp-wg-owner@hethmon.com Wed Jun 7 07:15:12 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA08977 for ; Wed, 7 Jun 2000 07:15:10 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000607061405-40732-8 ; Wed, 07 Jun 2000 06:14:05 -0500 Received: from magritte.felspar.net (195.13.68.90 [195.13.68.90]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000607061400-43357-7 ; Wed, 07 Jun 2000 06:14:01 -0500 Received: by magritte.felspar.net with Internet Mail Service (5.5.2448.0) id ; Wed, 7 Jun 2000 12:14:12 +0100 Message-ID: <61A45D5AE74BD311A76D00A0D21B18723672EF@magritte.felspar.net> MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD071.81C40010" Date: Wed, 7 Jun 2000 06:14:02 -0500 X-OldDate: Wed, 7 Jun 2000 12:14:02 +0100 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Dave Cridland To: "'FTPEXT Working Group'" Subject: Ftp-WG: thoughts on ftp extensions and caching This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFD071.81C40010 Content-Type: text/plain; charset="iso-8859-1" Following on from my earlier attempt at breaking down the problem into its parts: a) Seems to be fixed in practise, but not documented. Presumably the solution works for uploading as well, which as I said before is going to be the more common instance of this in my opinion. b) Seems still to hold. c) Nobody seems to like the idea of using approximate sizes, and in some cases these are not available at all. I think that, where available, and "reasonable", the reasonability of a particular estimate being defined by configuration, the approximate size is still useful. Stephen Tihor suggests a factor of 4 between "size" and "transfer-size", however, I think he'd probably agree that this is only in theory rather than in practise. Certainly while UNIX text files can have a factor of 2 between the "size" and the "transfer-size", when transferred as ASCII, this is never going to be the case unless the file consists only of the character '\n', which my gut tells me is somewhat unlikely in practise, and my brain agrees totally, for once. I'd managed to completely forget about dynamic archive creation, of course, but this simply means that no "size" fact is available for that file. Which in itself may cause a problem with the MLST draft - if a fact cannot be found for only some files in a listing, then does the MLST draft allow us to drop the fact for just those files? Reading the draft, it appears not to. I'm happy to be proved wrong, of course. -----Original Message----- From: Gregory A Lundberg [mailto:lundberg@vr.net] Sent: Wednesday, June 07, 2000 2:39 AM To: FTPEXT Working Group Subject: Ftp-WG: thoughts on ftp extensions and caching > (or at least, so it would seem). If so, the problem referred to in RFC 959 > does not exist in practice (and if so becomes a candidate for wordsmithing > out). > > [In what form will the eventual FTP extension reach the RFC stage?-- > if rolling RFC959 in its entirety with a new RFC #, then this might be > opportune to address at that time.] In practice, WU-FTPD 2.6.0 made the switch. What we've found is a few (actually, very few) clients which will lock up waiting for the reply before closing the data channel. The list is fairly short, most vendors made updates when it was pointed out to them (if they'd not already run across the problem .. seems some far-less-often used daemons were doing the same thing). We support backward compatability with a compile-time option. From the questions on the support mailing lists, while the subject is a FAQ (and covered there), it seems the sites most in need of the backward compatability are those in support of specific products where the client is a legacy and having users upgrade is infeasable or impractical in the short/middle term. Sites where most users come in using graphical clients such as IE and NS have no such problems and generate very few pleas for help. > Storing and later retrieving on demand such information concurrently with file > retrieval > is additional work but not necessarily involving a significant delay if done > intelligently. What I'm referring to is massive pre-processing such as tar/gzip like we do in wu-ftpd's ftpconversions. I can (and have) ftp'd multi-Gbyte directories as a tar/gzip piped to the data channel. If I needed to wait for the tar/gzip to complete it could be several minutes and the server host would be required to store the entire tar/gzip in temp storage (which I hope is disk otherwise a sufficiently large archive will cause massive swapping on the host). Technically, it's possible. As a practical matter, though, I would never ask our users to live with such. -- On the subject of rolling RFC 959 into a new RFC; I'd like to see that. Heck, I'd like to see simply clarification and modernization of the language in RFC 959. I'm not sure, however, I'd like to see that begun until we've sealed and shipped the MLST and HOST RFCs. Let's not derail the work on those with a massive new project, yet. ------_=_NextPart_001_01BFD071.81C40010 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Ftp-WG: thoughts on ftp extensions and caching

Following on from my earlier attempt at breaking down = the problem into its parts:

a) Seems to be fixed in practise, but not documented. = Presumably the solution works for uploading as well, which as I said = before is going to be the more common instance of this in my = opinion.

b) Seems still to hold.

c) Nobody seems to like the idea of using approximate = sizes, and in some cases these are not available at all.

I think that, where available, and = "reasonable", the reasonability of a particular estimate = being defined by configuration, the approximate size is still = useful.

Stephen Tihor suggests a factor of 4 between = "size" and "transfer-size", however, I think he'd = probably agree that this is only in theory rather than in practise. = Certainly while UNIX text files can have a factor of 2 between the = "size" and the "transfer-size", when transferred as = ASCII, this is never going to be the case unless the file consists only = of the character '\n', which my gut tells me is somewhat unlikely in = practise, and my brain agrees totally, for once.

I'd managed to completely forget about dynamic = archive creation, of course, but this simply means that no = "size" fact is available for that file. Which in itself may = cause a problem with the MLST draft - if a fact cannot be found for = only some files in a listing, then does the MLST draft allow us to drop = the fact for just those files? Reading the draft, it appears not to. = I'm happy to be proved wrong, of course.

-----Original Message-----
From: Gregory A Lundberg [mailto:lundberg@vr.net]
Sent: Wednesday, June 07, 2000 2:39 AM
To: FTPEXT Working Group
Subject: Ftp-WG: thoughts on ftp extensions and = caching


> (or at least, so it would seem).  If so, = the problem referred to in RFC
959
> does not exist in practice (and if so becomes a = candidate for wordsmithing
> out).
>
> [In what form will the eventual FTP extension = reach the RFC stage?--
> if rolling RFC959 in its entirety with a new = RFC #, then this might be
> opportune to address at that time.]

In practice, WU-FTPD 2.6.0 made the switch.  = What we've found is a few
(actually, very few) clients which will lock up = waiting for the reply before
closing the data channel.  The list is fairly = short, most vendors made
updates when it was pointed out to them (if they'd = not already run across
the problem .. seems some far-less-often used = daemons were doing the same
thing).

We support backward compatability with a compile-time = option.  From the
questions on the support mailing lists, while the = subject is a FAQ (and
covered there), it seems the sites most in need of = the backward
compatability are those in support of specific = products where the client is
a legacy and having users upgrade is infeasable or = impractical in the
short/middle term.  Sites where most users come = in using graphical clients
such as IE and NS have no such problems and generate = very few pleas for
help.

> Storing and later retrieving on demand such = information concurrently with
file
> retrieval
> is additional work but not necessarily = involving a significant delay if
done
> intelligently.

What I'm referring to is massive pre-processing such = as tar/gzip like we do
in wu-ftpd's ftpconversions.  I can (and have) = ftp'd multi-Gbyte directories
as a tar/gzip piped to the data channel.  If I = needed to wait for the
tar/gzip to complete it could be several minutes and = the server host would
be required to store the entire tar/gzip in temp = storage (which I hope is
disk otherwise a sufficiently large archive will = cause massive swapping on
the host).  Technically, it's possible.  = As a practical matter, though, I
would never ask our users to live with such.

--

On the subject of rolling RFC 959 into a new RFC; I'd = like to see that.
Heck, I'd like to see simply clarification and = modernization of the language
in RFC 959.  I'm not sure, however, I'd like to = see that begun until we've
sealed and shipped the MLST and HOST RFCs.  = Let's not derail the work on
those with a massive new project, yet.

------_=_NextPart_001_01BFD071.81C40010-- From ftp-wg-owner@hethmon.com Wed Jun 7 08:49:52 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09832 for ; Wed, 7 Jun 2000 08:49:52 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000607075007-4268-17 ; Wed, 07 Jun 2000 07:50:08 -0500 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000607075003-42417-15 ; Wed, 07 Jun 2000 07:50:04 -0500 Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id MA32622; Wed, 7 Jun 2000 22:43:30 +1000 (from kre@munnari.OZ.AU) In-Reply-To: Your message of "Wed, 07 Jun 2000 06:14:02 EST." <61A45D5AE74BD311A76D00A0D21B18723672EF@magritte.felspar.net> Message-Id: <4680.960381798@mundamutti.cs.mu.OZ.AU> Date: Wed, 7 Jun 2000 07:50:05 -0500 X-OldDate: Wed, 07 Jun 2000 22:43:18 +1000 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Robert Elz To: FTPEXT Working Group Subject: Ftp-WG: thoughts on ftp extensions and caching Date: Wed, 7 Jun 2000 06:14:02 -0500 From: Dave Cridland Message-ID: <61A45D5AE74BD311A76D00A0D21B18723672EF@magritte.felspar.net> | Which | in itself may cause a problem with the MLST draft - if a fact cannot be | found for only some files in a listing, then does the MLST draft allow us to | drop the fact for just those files? Reading the draft, it appears not to. That certainly wasn't the intent. Any fact is supposed to be able to be dropped when it cannot be supplied, or makes no sense. In practice, dynamic archive type things tend not to appear in directory listings anyway, as they don't really exist - the "RETR dir.tar.gz" hack is truly that - using the ".tar.gz" part of the filename as a set of options to the command to indicate to the server what it is supposed to do with the entity requested (which is just "dir" in this example). It's totally legal FTP, but also horribly ugly. kre ps: is there no-one else but me here who believes that attempting to standardise (in any form) the responses from RETR is just a little too far from rational after all this time to even be discussing, however benefitial it might be in some contexts? From ftp-wg-owner@hethmon.com Wed Jun 7 09:58:49 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10640 for ; Wed, 7 Jun 2000 09:58:49 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000607085803-36858-13 ; Wed, 07 Jun 2000 08:58:03 -0500 Received: from anvil.murkworks.com (murkwork.pey.clarkson.edu [128.153.30.16]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000607085759-12386-7 ; Wed, 07 Jun 2000 08:57:59 -0500 Received: from coal.murkworks.com (coal.murkworks.com [128.153.43.3]) by anvil.murkworks.com (8.9.1/8.9.1) with ESMTP id JAA22785 for ; Wed, 7 Jun 2000 09:54:24 -0400 (EDT) Received: from GIMPELSTIMER/SpoolDir by coal.murkworks.com (Mercury 1.44); 7 Jun 00 09:59:44 -0400 Received: from SpoolDir by GIMPELSTIMER (Mercury 1.44); 7 Jun 00 09:59:24 -0400 Organization: MurkWorks, Incorporated. MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Message-ID: <393E1CF5.6852.3745B80@localhost> In-reply-to: <61A45D5AE74BD311A76D00A0D21B18723672ED@magritte.felspar.net> X-mailer: Pegasus Mail for Win32 (v3.12c) Date: Wed, 7 Jun 2000 08:58:01 -0500 X-OldDate: Wed, 7 Jun 2000 09:59:19 -0500 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: "Brad Clements" To: FTPEXT Working Group Subject: Ftp-WG: Transfer Size info, was: thoughts on ftp extensions and caching Content-Transfer-Encoding: 7BIT On 6 Jun 2000, at 14:03, Dave Cridland wrote: > My suggestions: > > a) In the real world, I've experienced few problems with being unsure of > whether the file has been transferred or not. In the absence of finding the > transfer size, I find that the use of the response code afterwards seems to > give a reliable indication with today's networks and technology. > > Having said that, it'd be nice if the file transfer size was indicated > during commencement of a download. However, if I relied on it, I'd be using > SIZE beforehand. > Uh, would it be possible to have a second intermediate response code sent after the transfer, reporting the number of octets transmitted? This response would come before "transfer complete". This way the server doesn't have to pre-calculate the size, yet can tell the client exactly how many bytes the file was. > Note that this is only a solution for downloads, and not for uploads. The > only way I can think of for uploads would be to suggest the use of the ALLO > command prior to the upload, or else define another, similar, command for > this use. This is a tad unfortunate, as I have a sneaky feeling that > uploads in STREAM mode are by far the more problematic. Same solution here, an intermediate response code from the server .. that says how many octets where received before saying "transfer complete". Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com AOL-IM: BKClements From ftp-wg-owner@hethmon.com Wed Jun 7 10:39:40 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11711 for ; Wed, 7 Jun 2000 10:39:39 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000607093842-20491-14 ; Wed, 07 Jun 2000 09:38:42 -0500 Received: from ACFcluster.NYU.EDU (AXP2.ACF.NYU.EDU [128.122.250.38]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000607093838-57751-13 ; Wed, 07 Jun 2000 09:38:38 -0500 Received: from ACFcluster.NYU.EDU by ACFcluster.NYU.EDU (PMDF V5.2-32 #33915) id <01JQBGSMM7JK8WZXPU@ACFcluster.NYU.EDU> for ftp-wg@hethmon.com; Wed, 7 Jun 2000 10:35:01 EDT In-reply-to: "Your message dated Wed, 07 Jun 2000 08:58:01 -0500" <393E1CF5.6852.3745B80@localhost> Message-id: <01JQBH3Y4D4U8WZXPU@ACFcluster.NYU.EDU> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII References: <61A45D5AE74BD311A76D00A0D21B18723672ED@magritte.felspar.net> Date: Wed, 7 Jun 2000 09:38:40 -0500 X-OldDate: Wed, 07 Jun 2000 10:34:22 -0400 (EDT) Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Stephen Tihor To: FTPEXT Working Group Subject: Ftp-WG: Transfer Size info, was: thoughts on ftp extensions and caching In terms of sending sizes this is a wonderful idea. Would it be an incompatible change in the state transitions that would break clients? From ftp-wg-owner@hethmon.com Wed Jun 7 10:51:46 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11997 for ; Wed, 7 Jun 2000 10:51:45 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000607095113-43751-31 ; Wed, 07 Jun 2000 09:51:13 -0500 Received: from anvil.murkworks.com (murkwork.pey.clarkson.edu [128.153.30.16]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000607095108-46895-22 ; Wed, 07 Jun 2000 09:51:08 -0500 Received: from coal.murkworks.com (coal.murkworks.com [128.153.43.3]) by anvil.murkworks.com (8.9.1/8.9.1) with ESMTP id KAA22881 for ; Wed, 7 Jun 2000 10:47:32 -0400 (EDT) Received: from GIMPELSTIMER/SpoolDir by coal.murkworks.com (Mercury 1.44); 7 Jun 00 10:52:52 -0400 Received: from SpoolDir by GIMPELSTIMER (Mercury 1.44); 7 Jun 00 10:52:39 -0400 Organization: MurkWorks, Incorporated. MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Message-ID: <393E296C.11029.3A50E7D@localhost> References: "Your message dated Wed, 07 Jun 2000 08:58:01 -0500" <393E1CF5.6852.3745B80@localhost> In-reply-to: <01JQBH3Y4D4U8WZXPU@ACFcluster.NYU.EDU> X-mailer: Pegasus Mail for Win32 (v3.12c) Date: Wed, 7 Jun 2000 09:51:09 -0500 X-OldDate: Wed, 7 Jun 2000 10:52:30 -0500 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: "Brad Clements" To: FTPEXT Working Group Subject: Ftp-WG: Transfer Size info, was: thoughts on ftp extensions and caching Content-Transfer-Encoding: 7BIT On 7 Jun 2000, at 9:38, Stephen Tihor wrote: > In terms of sending sizes this is a wonderful idea. Would it be an > incompatible change in the state transitions that would break clients? > > Oh, yeah.. existing clients.. What if the 226 "transfer complete" was "standardized" in some way? An ugly idea: 226 transfer complete, sent: 8363343 octets I don't like this idea, but it would be compatible with old clients and not involve a state machine change. Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com AOL-IM: BKClements From ftp-wg-owner@hethmon.com Wed Jun 7 11:22:33 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12830 for ; Wed, 7 Jun 2000 11:22:32 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000607102202-17069-8 ; Wed, 07 Jun 2000 10:22:02 -0500 Received: from anarchy.io.com (anarchy.io.com [199.170.88.101]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000607102159-60262-6 ; Wed, 07 Jun 2000 10:21:59 -0500 Received: from magnus.io.com (aus-as4-042.io.com [208.2.105.42]) by anarchy.io.com (8.9.3/8.9.3) with ESMTP id KAA01607 for ; Wed, 7 Jun 2000 10:18:27 -0500 Message-Id: <4.3.1.2.20000607100625.00c8c100@mail.io.com> X-Sender: alun@mail.io.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 In-Reply-To: <4680.960381798@mundamutti.cs.mu.OZ.AU> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Date: Wed, 7 Jun 2000 10:22:00 -0500 X-OldDate: Wed, 07 Jun 2000 10:17:18 -0500 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Alun Jones To: FTPEXT Working Group Subject: Ftp-WG: thoughts on ftp extensions and caching Sorry I haven't been able to chime in on this sooner. At 07:50 AM 6/7/2000, you wrote: >ps: is there no-one else but me here who believes that attempting to >standardise (in any form) the responses from RETR is just a little too >far from rational after all this time to even be discussing, however >benefitial it might be in some contexts? I'm with you on that one, Robert, on two counts, that may actually appear to be contradictory: 1. RFC 959 (among many other protocol documents) makes it clear that the goal of the number is to provide information to the client, and the goal of the text is to provide information to the user. Very few commands supply information in the text of a response that is expected to be read by the client - PASV, CWD, PWD, STOU, are the only ones that I can think of from RFC 959. Later added commands provide more use of the response text for server to client communications, such as SIZE, MDTM, FEAT, etc. However, only once (to my recollection), in RFC 1123, has an accepted command been provided with a new standard for its text response. I'd like to see a lot more reason than "it saves issuing one command" before requiring a format of text, and one that is not directly unrelated to the command at hand. STOU really _needs_ to tell the client what it stored the file as. CWD and PWD _need_ to tell the client what your new directory is. PASV _needs_ to tell the client where it's listening. RETR does _not_ need to tell the client, and may not even know, how many bytes to expect. 2. It's already common for the RETR command to return the number of bytes expected in the 150 response, where reasonable. Many FTP clients use this value to generate a progress indicator. It's not as reliable as SIZE, perhaps, but it is common, and it is used. Requiring a new format in the 150 response would have the rather unhelpful effect of removing functionality from those clients. Alun. ~~~~ -- Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find us 1602 Harvest Moon Place | at web site http://www.wftpd.com or email Cedar Park TX 78613 | us at alun@texis.com. VISA / MC accepted. Fax +1 (512) 378 3246 | NT-based ISPs, be sure to read details of Phone +1 (512) 378 3246 | WFTPD Pro, NT service version - $100. From ftp-wg-owner@hethmon.com Wed Jun 7 11:45:24 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13633 for ; Wed, 7 Jun 2000 11:45:17 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000607104310-5382-13 ; Wed, 07 Jun 2000 10:43:10 -0500 Received: from magritte.felspar.net (195.13.68.90 [195.13.68.90]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000607104305-43468-18 ; Wed, 07 Jun 2000 10:43:06 -0500 Received: by magritte.felspar.net with Internet Mail Service (5.5.2448.0) id ; Wed, 7 Jun 2000 16:43:22 +0100 Message-ID: <61A45D5AE74BD311A76D00A0D21B18723672F4@magritte.felspar.net> MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD097.1BF58580" Date: Wed, 7 Jun 2000 10:43:07 -0500 X-OldDate: Wed, 7 Jun 2000 16:43:12 +0100 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Dave Cridland To: "'FTPEXT Working Group'" Subject: Ftp-WG: thoughts on ftp extensions and caching This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFD097.1BF58580 Content-Type: text/plain; charset="iso-8859-1" If I were to write an FTP server which supported dynamic archiving, then I'd probably put it in the directory listings purely to allow downloads by GUI clients with more ease. After all, it's in my interests, because it saves me (hypothetical) bandwidth. When I read through the MLST draft trying to see whether I was allowed to drop a fact when the client had requested it, I couldn't find anything about it, either way, which suggested to me in my pedantically crippled way that it wasn't allowed - or at least, that it probably shouldn't be done from a server PoV, but should be allowed for in a client context. It may well be just me, though, I don't know if anyone else reads it that way. Of course, I might have missed the critical phrase while skimming through it, at which point I apologise profusely for my stupidity. :-) Standardising the responses from RETR is surely fine if it only becomes active with a OPT setting? Or not? Having said that, Alun Jones makes very good sense indeed in his point (2). Perhaps all that is needed is a mention of this de-facto standard in more detail. If so, all the better. I do still like the concept of the transfer-size fact being defined, though. -----Original Message----- From: Robert Elz [mailto:kre@munnari.OZ.AU] Sent: Wednesday, June 07, 2000 1:50 PM To: FTPEXT Working Group Subject: Ftp-WG: thoughts on ftp extensions and caching Date: Wed, 7 Jun 2000 06:14:02 -0500 From: Dave Cridland Message-ID: <61A45D5AE74BD311A76D00A0D21B18723672EF@magritte.felspar.net> | Which | in itself may cause a problem with the MLST draft - if a fact cannot be | found for only some files in a listing, then does the MLST draft allow us to | drop the fact for just those files? Reading the draft, it appears not to. That certainly wasn't the intent. Any fact is supposed to be able to be dropped when it cannot be supplied, or makes no sense. In practice, dynamic archive type things tend not to appear in directory listings anyway, as they don't really exist - the "RETR dir.tar.gz" hack is truly that - using the ".tar.gz" part of the filename as a set of options to the command to indicate to the server what it is supposed to do with the entity requested (which is just "dir" in this example). It's totally legal FTP, but also horribly ugly. kre ps: is there no-one else but me here who believes that attempting to standardise (in any form) the responses from RETR is just a little too far from rational after all this time to even be discussing, however benefitial it might be in some contexts? ------_=_NextPart_001_01BFD097.1BF58580 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Ftp-WG: thoughts on ftp extensions and caching

If I were to write an FTP server which supported = dynamic archiving, then I'd probably put it in the directory listings = purely to allow downloads by GUI clients with more ease. After all, = it's in my interests, because it saves me (hypothetical) = bandwidth.

When I read through the MLST draft trying to see = whether I was allowed to drop a fact when the client had requested it, = I couldn't find anything about it, either way, which suggested to me in = my pedantically crippled way that it wasn't allowed - or at least, that = it probably shouldn't be done from a server PoV, but should be allowed = for in a client context. It may well be just me, though, I don't know = if anyone else reads it that way. Of course, I might have missed the = critical phrase while skimming through it, at which point I apologise = profusely for my stupidity. :-)

Standardising the responses from RETR is surely fine = if it only becomes active with a OPT setting? Or not?

Having said that, Alun Jones makes very good sense = indeed in his point (2). Perhaps all that is needed is a mention of = this de-facto standard in more detail. If so, all the = better.

I do still like the concept of the transfer-size fact = being defined, though.

-----Original Message-----
From: Robert Elz [mailto:kre@munnari.OZ.AU]
Sent: Wednesday, June 07, 2000 1:50 PM
To: FTPEXT Working Group
Subject: Ftp-WG: thoughts on ftp extensions and = caching


    = Date:        Wed, 7 Jun 2000 = 06:14:02 -0500
    = From:        Dave Cridland = <dac@felspar.com>
    Message-ID:  = <61A45D5AE74BD311A76D00A0D21B18723672EF@magritte.felspar.net>

  | Which
  | in itself may cause a problem with the MLST = draft - if a fact cannot be
  | found for only some files in a listing, = then does the MLST draft allow us to
  | drop the fact for just those files? Reading = the draft, it appears not to.

That certainly wasn't the intent.   Any = fact is supposed to be able to
be dropped when it cannot be supplied, or makes no = sense.

In practice, dynamic archive type things tend not to = appear in directory
listings anyway, as they don't really exist - the = "RETR dir.tar.gz"
hack is truly that - using the ".tar.gz" = part of the filename as a
set of options to the command to indicate to the = server what it is
supposed to do with the entity requested (which is = just "dir" in this
example).   It's totally legal FTP, but = also horribly ugly.

kre

ps: is there no-one else but me here who believes = that attempting to
standardise (in any form) the responses from RETR is = just a little too
far from rational after all this time to even be = discussing, however
benefitial it might be in some contexts?

------_=_NextPart_001_01BFD097.1BF58580-- From ftp-wg-owner@hethmon.com Wed Jun 7 11:51:25 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13855 for ; Wed, 7 Jun 2000 11:51:23 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000607104845-29971-19 ; Wed, 07 Jun 2000 10:48:45 -0500 Received: from mail.corp.domainit.com (199.18.156.62 [199.18.156.62]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000607104840-2287-18 ; Wed, 07 Jun 2000 10:48:41 -0500 Received: from wintest (dhcp64.corp.domainit.com [192.168.2.64]) (authenticated as lundberg with LOGIN) by mail.corp.domainit.com (8.10.0.Beta10/8.10.0.Beta10) with ESMTP id e57Fj9E04356 for ; Wed, 7 Jun 2000 11:45:10 -0400 Message-ID: <014801bfd097$5cbd1d40$4002a8c0@corp.domainit.com> References: <393E1CF5.6852.3745B80@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Date: Wed, 7 Jun 2000 10:48:42 -0500 X-OldDate: Wed, 7 Jun 2000 11:45:09 -0400 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: "Gregory A Lundberg" To: "FTPEXT Working Group" Subject: Ftp-WG: Transfer Size info, was: thoughts on ftp extensions and caching Content-Transfer-Encoding: 7bit > Uh, would it be possible to have a second intermediate response code > sent after the transfer, reporting the number of octets transmitted? > > This response would come before "transfer complete". > > This way the server doesn't have to pre-calculate the size, yet can tell > the client exactly how many bytes the file was. Adding an intermediate response could break a vast number of clients. If the desire is for a proxy to have the information required to make a policy decision prior to the data transfer, the information should be available prior to sending the data transfer command. For RETR-type, the MLST facts, and possibly the SIZE command, should be sufficient for this purpose. For STOR-type, there would need to be some means to communicate the expected size to the remote server; the ALLO command comes to mind here. If the desire is for a client to be able to determine whether a specific upload/download is complete; proper use of TCP and sequencing of the data-channel activity with the command-channel replies is sufficient. So, the question becomes simply: should there be a standardized format for the intermediate and final reply? Let's examine what's done now (using a command-line client and WU-FTPD). Here's a sample session: $ ftp ftp.vr.net Connected to www.vr.net. 220 ftp.vr.net FTP server ready. Name (ftp.vr.net:lundberg): anonymous 331 Guest login ok, send your complete e-mail address as password. Password: 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp> ls /pub/pgp-keys/lundberg@vr.net 200 PORT command successful. 150 Opening ASCII mode data connection for /bin/ls. -r--r--r-- 1 lundberg vrnet 712 Jul 9 1999 /pub/pgp-keys/lundberg@vr.net 226 Transfer complete. ftp> bin 200 Type set to I. ftp> size /pub/pgp-keys/lundberg@vr.net 213 712 ftp> asc 200 Type set to A. ftp> size /pub/pgp-keys/lundberg@vr.net 213 727 It appears, at least for WU-FTPD, the size command already provides the necessary information to make a policy decision for this file. ftp> size /pub/pgp-keys/lundberg@vr.net.Z 550 /pub/pgp-keys/lundberg@vr.net.Z: No such file or directory. Although WU-FTPD does not go to the work of running any complex conversions on the file simply to support the SIZE command. Ah well. For a cache/no-cache decision, at least, there appears to be enough information already available. ftp> bin 200 Type set to I. ftp> get /pub/pgp-keys/lundberg@vr.net aaaa local: aaaa remote: /pub/pgp-keys/lundberg@vr.net 200 PORT command successful. 150 Opening BINARY mode data connection for /pub/pgp-keys/lundberg@vr.net (712 bytes). On this reply we see, among other things, the exact size. Should this be formalized? Why not. While the original intention of the FTP was that the numeric codes be sufficient for the client, by formalizing the information on the 150 reply we enable (or ease) automata. The minimum requirement should remain the numeric replies; the server MAY send additional information in some predetermined format; the client MUST be able to handle a 150 reply with non-formatted textual information and even MUST be able to handle a "150 " reply with no textual information at all. 226 Transfer complete. 712 bytes received in 0.00109 secs (6.4e+02 Kbytes/sec) Here my client has helpfully displayed the number of bytes transferred. As a human, I can easily compare this to the size given on the 150 reply to see the transfer was complete. Using a formatted reply enables additional cross-checks, which is probably a Good Thing (even if not strictly required). The server MAY send the size information again; the client MUST NOT depend upon the server actually doing so. ftp> get /pub/pgp-keys/lundberg@vr.net bbbb local: bbbb remote: /pub/pgp-keys/lundberg@vr.net 200 PORT command successful. 150 Opening ASCII mode data connection for /pub/pgp-keys/lundberg@vr.net (712 bytes). Now we see that the WU-FTPD is giving an incorrect fact (which I guess I should note as a bug :). We know from the SIZE command earlier, the daemon _could_ determine the correct value. But that might mean doing what we did for the SIZE command; processing the entire file to determine the size and discarding the resulting data stream. Since we're about to transmit the file, pre-processing just to send an accurate size seems a waste of time and resources. If the server does not already have the size information available (ie., by stat'ing the file) or the information can be expected to be incorrect, I would say it MUST NOT send that information in the initial, intermediate reply. 226 Transfer complete. 727 bytes received in 0.00515 secs (1.4e+02 Kbytes/sec) Again, my client knows how many bytes (octets) were received. But as a human I am confused; the numbers do not match. At this point, the server SHOULD send the actual number of bytes (octets) transmitted. Now here's an issue: how should it be worded? I'd like to see the server only sending the size information once. But sometimes that information is available prior to the transfer, sometimes not until after. If sent before the transfer the client (proxy?) can use the information to make policy decisions (cache/no-cache). But it's ftp> quot allo 727 202 ALLO command ignored. Sigh. Well, this isn't really what ALLO was intended for. I suppose WU-FTPD _could_ do a filesystem space availability check. But that would be very hard to do inside a chroot'd environment. The best way to check would be to actually try creating a file of the desired size, but we don't know where to create the file and even if we did I'd think long and hard about the DoS possibilities. ftp> bin 200 Type set to I. ftp> put aaaa /incoming/aaaa local: aaaa remote: /incoming/aaaa 200 PORT command successful. 150 Opening BINARY mode data connection for /incoming/aaaa. 226 Transfer complete. 712 bytes sent in 0.000797 secs (8.7e+02 Kbytes/sec) ftp> asc 200 Type set to A. ftp> put bbbb /incoming/bbbb local: bbbb remote: /incoming/bbbb 200 PORT command successful. 150 Opening ASCII mode data connection for /incoming/bbbb. 226 Transfer complete. 727 bytes sent in 0.000873 secs (8.1e+02 Kbytes/sec) Obviously the server has no size information. But it probably SHOULD give a read-back of the bytes received. ftp> quit 221 Goodbye. As to Alun's comments about changing the accepted textual reply ... If the existing definition is "unspecified", and if the new specification is no stronger than SHOULD on the server, and the client MUST be able to handle the case of "unspecified" or even missing textual information, I don't see a problem. The RFC gives example relies for those which are "unspecified". I see those as no more than recommendations. Also, a client which depended upon the recommended replies would have problems handling a server which was using non-English text in replies. The best method, if we don't want to change the final reply, is to use extended replies, such as: 226-727 bytes received 226 Transfer complete. From ftp-wg-owner@hethmon.com Wed Jun 7 12:33:05 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15362 for ; Wed, 7 Jun 2000 12:33:01 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000607112801-27553-16 ; Wed, 07 Jun 2000 11:28:01 -0500 Received: from magritte.felspar.net (195.13.68.90 [195.13.68.90]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000607112755-45732-8 ; Wed, 07 Jun 2000 11:27:56 -0500 Received: by magritte.felspar.net with Internet Mail Service (5.5.2448.0) id ; Wed, 7 Jun 2000 17:28:14 +0100 Message-ID: <61A45D5AE74BD311A76D00A0D21B18723672F6@magritte.felspar.net> nd caching MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD09D.60875150" Date: Wed, 7 Jun 2000 11:27:57 -0500 X-OldDate: Wed, 7 Jun 2000 17:28:12 +0100 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Dave Cridland To: "'FTPEXT Working Group'" Subject: Ftp-WG: Transfer Size info, was: thoughts on ftp extensions a This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFD09D.60875150 Content-Type: text/plain; charset="iso-8859-1" As far as the SHOULDs and MUST NOTs go, we have got a perfectly good FEAT which will allow a client to identify whether the server can send the extended 150/226 responses, and a perfectly good OPT which allows the client to ask for them. In the absence of a client request, the server probably MUST use the defacto standard if it supports our new FEAT, but with a client request it MUST use our new MLST style message, perhaps at the beginning and the end. That, and defining the size mentioned in the defacto 150 response as being only a transfer size (or no mention if it can't discover that quickly), and defining a "transfer-size" fact, and we're away. Aren't we? Or does that break something further I haven't yet thought of? (Incidentally, while WU-FTPD is quite right in specifying a 550 response for the "SIZE xxx.Z", surely it really ought to recognise the fact that this is a valid entity, and respond with some other textual part?) -----Original Message----- From: Gregory A Lundberg [mailto:lundberg@vr.net] Sent: Wednesday, June 07, 2000 4:49 PM To: FTPEXT Working Group Subject: Ftp-WG: Transfer Size info, was: thoughts on ftp extensions and caching > Uh, would it be possible to have a second intermediate response code > sent after the transfer, reporting the number of octets transmitted? > > This response would come before "transfer complete". > > This way the server doesn't have to pre-calculate the size, yet can tell > the client exactly how many bytes the file was. Adding an intermediate response could break a vast number of clients. If the desire is for a proxy to have the information required to make a policy decision prior to the data transfer, the information should be available prior to sending the data transfer command. For RETR-type, the MLST facts, and possibly the SIZE command, should be sufficient for this purpose. For STOR-type, there would need to be some means to communicate the expected size to the remote server; the ALLO command comes to mind here. If the desire is for a client to be able to determine whether a specific upload/download is complete; proper use of TCP and sequencing of the data-channel activity with the command-channel replies is sufficient. So, the question becomes simply: should there be a standardized format for the intermediate and final reply? Let's examine what's done now (using a command-line client and WU-FTPD). Here's a sample session: $ ftp ftp.vr.net Connected to www.vr.net. 220 ftp.vr.net FTP server ready. Name (ftp.vr.net:lundberg): anonymous 331 Guest login ok, send your complete e-mail address as password. Password: 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp> ls /pub/pgp-keys/lundberg@vr.net 200 PORT command successful. 150 Opening ASCII mode data connection for /bin/ls. -r--r--r-- 1 lundberg vrnet 712 Jul 9 1999 /pub/pgp-keys/lundberg@vr.net 226 Transfer complete. ftp> bin 200 Type set to I. ftp> size /pub/pgp-keys/lundberg@vr.net 213 712 ftp> asc 200 Type set to A. ftp> size /pub/pgp-keys/lundberg@vr.net 213 727 It appears, at least for WU-FTPD, the size command already provides the necessary information to make a policy decision for this file. ftp> size /pub/pgp-keys/lundberg@vr.net.Z 550 /pub/pgp-keys/lundberg@vr.net.Z: No such file or directory. Although WU-FTPD does not go to the work of running any complex conversions on the file simply to support the SIZE command. Ah well. For a cache/no-cache decision, at least, there appears to be enough information already available. ftp> bin 200 Type set to I. ftp> get /pub/pgp-keys/lundberg@vr.net aaaa local: aaaa remote: /pub/pgp-keys/lundberg@vr.net 200 PORT command successful. 150 Opening BINARY mode data connection for /pub/pgp-keys/lundberg@vr.net (712 bytes). On this reply we see, among other things, the exact size. Should this be formalized? Why not. While the original intention of the FTP was that the numeric codes be sufficient for the client, by formalizing the information on the 150 reply we enable (or ease) automata. The minimum requirement should remain the numeric replies; the server MAY send additional information in some predetermined format; the client MUST be able to handle a 150 reply with non-formatted textual information and even MUST be able to handle a "150 " reply with no textual information at all. 226 Transfer complete. 712 bytes received in 0.00109 secs (6.4e+02 Kbytes/sec) Here my client has helpfully displayed the number of bytes transferred. As a human, I can easily compare this to the size given on the 150 reply to see the transfer was complete. Using a formatted reply enables additional cross-checks, which is probably a Good Thing (even if not strictly required). The server MAY send the size information again; the client MUST NOT depend upon the server actually doing so. ftp> get /pub/pgp-keys/lundberg@vr.net bbbb local: bbbb remote: /pub/pgp-keys/lundberg@vr.net 200 PORT command successful. 150 Opening ASCII mode data connection for /pub/pgp-keys/lundberg@vr.net (712 bytes). Now we see that the WU-FTPD is giving an incorrect fact (which I guess I should note as a bug :). We know from the SIZE command earlier, the daemon _could_ determine the correct value. But that might mean doing what we did for the SIZE command; processing the entire file to determine the size and discarding the resulting data stream. Since we're about to transmit the file, pre-processing just to send an accurate size seems a waste of time and resources. If the server does not already have the size information available (ie., by stat'ing the file) or the information can be expected to be incorrect, I would say it MUST NOT send that information in the initial, intermediate reply. 226 Transfer complete. 727 bytes received in 0.00515 secs (1.4e+02 Kbytes/sec) Again, my client knows how many bytes (octets) were received. But as a human I am confused; the numbers do not match. At this point, the server SHOULD send the actual number of bytes (octets) transmitted. Now here's an issue: how should it be worded? I'd like to see the server only sending the size information once. But sometimes that information is available prior to the transfer, sometimes not until after. If sent before the transfer the client (proxy?) can use the information to make policy decisions (cache/no-cache). But it's ftp> quot allo 727 202 ALLO command ignored. Sigh. Well, this isn't really what ALLO was intended for. I suppose WU-FTPD _could_ do a filesystem space availability check. But that would be very hard to do inside a chroot'd environment. The best way to check would be to actually try creating a file of the desired size, but we don't know where to create the file and even if we did I'd think long and hard about the DoS possibilities. ftp> bin 200 Type set to I. ftp> put aaaa /incoming/aaaa local: aaaa remote: /incoming/aaaa 200 PORT command successful. 150 Opening BINARY mode data connection for /incoming/aaaa. 226 Transfer complete. 712 bytes sent in 0.000797 secs (8.7e+02 Kbytes/sec) ftp> asc 200 Type set to A. ftp> put bbbb /incoming/bbbb local: bbbb remote: /incoming/bbbb 200 PORT command successful. 150 Opening ASCII mode data connection for /incoming/bbbb. 226 Transfer complete. 727 bytes sent in 0.000873 secs (8.1e+02 Kbytes/sec) Obviously the server has no size information. But it probably SHOULD give a read-back of the bytes received. ftp> quit 221 Goodbye. As to Alun's comments about changing the accepted textual reply ... If the existing definition is "unspecified", and if the new specification is no stronger than SHOULD on the server, and the client MUST be able to handle the case of "unspecified" or even missing textual information, I don't see a problem. The RFC gives example relies for those which are "unspecified". I see those as no more than recommendations. Also, a client which depended upon the recommended replies would have problems handling a server which was using non-English text in replies. The best method, if we don't want to change the final reply, is to use extended replies, such as: 226-727 bytes received 226 Transfer complete. ------_=_NextPart_001_01BFD09D.60875150 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Ftp-WG: Transfer Size info, was: thoughts on ftp extensions = and caching

As far as the SHOULDs and MUST NOTs go, we have got a = perfectly good FEAT which will allow a client to identify whether the = server can send the extended 150/226 responses, and a perfectly good = OPT which allows the client to ask for them. In the absence of a client = request, the server probably MUST use the defacto standard if it = supports our new FEAT, but with a client request it MUST use our new = MLST style message, perhaps at the beginning and the end.

That, and defining the size mentioned in the defacto = 150 response as being only a transfer size (or no mention if it can't = discover that quickly), and defining a "transfer-size" fact, = and we're away. Aren't we? Or does that break something further I = haven't yet thought of?

(Incidentally, while WU-FTPD is quite right in = specifying a 550 response for the "SIZE xxx.Z", surely it = really ought to recognise the fact that this is a valid entity, and = respond with some other textual part?)

-----Original Message-----
From: Gregory A Lundberg [mailto:lundberg@vr.net]
Sent: Wednesday, June 07, 2000 4:49 PM
To: FTPEXT Working Group
Subject: Ftp-WG: Transfer Size info, was: thoughts = on ftp extensions and
caching


> Uh, would it be possible to have a second = intermediate response code
> sent after the transfer, reporting the number = of octets transmitted?
>
> This response would come before "transfer = complete".
>
> This way the server doesn't have to = pre-calculate the size, yet can tell
> the client exactly how many bytes the file = was.

Adding an intermediate response could break a vast = number of clients.

If the desire is for a proxy to have the information = required to make a
policy decision prior to the data transfer, the = information should be
available prior to sending the data transfer = command.  For RETR-type, the
MLST facts, and possibly the SIZE command, should be = sufficient for this
purpose.  For STOR-type, there would need to be = some means to communicate
the expected size to the remote server; the ALLO = command comes to mind here.

If the desire is for a client to be able to determine = whether a specific
upload/download is complete; proper use of TCP and = sequencing of the
data-channel activity with the command-channel = replies is sufficient.

So, the question becomes simply: should there be a = standardized format for
the intermediate and final reply?

Let's examine what's done now (using a command-line = client and WU-FTPD).
Here's a sample session:

    $ ftp ftp.vr.net
    Connected to www.vr.net.
    220 ftp.vr.net FTP server ready.
    Name (ftp.vr.net:lundberg): = anonymous
    331 Guest login ok, send your = complete e-mail address as password.
    Password:
    230 Guest login ok, access = restrictions apply.
    Remote system type is = UNIX.
    Using binary mode to transfer = files.
    ftp> ls = /pub/pgp-keys/lundberg@vr.net
    200 PORT command = successful.
    150 Opening ASCII mode data = connection for /bin/ls.
    -r--r--r--   1 lundberg = vrnet         712 Jul  = 9  1999
/pub/pgp-keys/lundberg@vr.net
    226 Transfer complete.
    ftp> bin
    200 Type set to I.
    ftp> size = /pub/pgp-keys/lundberg@vr.net
    213 712
    ftp> asc
    200 Type set to A.
    ftp> size = /pub/pgp-keys/lundberg@vr.net
    213 727

It appears, at least for WU-FTPD, the size command = already provides the
necessary information to make a policy decision for = this file.

    ftp> size = /pub/pgp-keys/lundberg@vr.net.Z
    550 = /pub/pgp-keys/lundberg@vr.net.Z: No such file or directory.

Although WU-FTPD does not go to the work of running = any complex conversions
on the file simply to support the SIZE = command.  Ah well.  For a
cache/no-cache decision, at least, there appears to = be enough information
already available.

    ftp> bin
    200 Type set to I.
    ftp> get = /pub/pgp-keys/lundberg@vr.net aaaa
    local: aaaa remote: = /pub/pgp-keys/lundberg@vr.net
    200 PORT command = successful.
    150 Opening BINARY mode data = connection for
/pub/pgp-keys/lundberg@vr.net (712 bytes).

On this reply we see, among other things, the exact = size.  Should this be
formalized?  Why not.  While the original = intention of the FTP was that the
numeric codes be sufficient for the client, by = formalizing the information
on the 150 reply we enable (or ease) = automata.

The minimum requirement should remain the numeric = replies; the server MAY
send additional information in some predetermined = format; the client MUST be
able to handle a 150 reply with non-formatted = textual information and even
MUST be able to handle a "150 " reply with = no textual information at all.

    226 Transfer complete.
    712 bytes received in 0.00109 = secs (6.4e+02 Kbytes/sec)

Here my client has helpfully displayed the number of = bytes transferred.  As
a human, I can easily compare this to the size given = on the 150 reply to see
the transfer was complete.  Using a formatted = reply enables additional
cross-checks, which is probably a Good Thing (even = if not strictly
required).  The server MAY send the size = information again; the client MUST
NOT depend upon the server actually doing so.

    ftp> get = /pub/pgp-keys/lundberg@vr.net bbbb
    local: bbbb remote: = /pub/pgp-keys/lundberg@vr.net
    200 PORT command = successful.
    150 Opening ASCII mode data = connection for /pub/pgp-keys/lundberg@vr.net
(712 bytes).

Now we see that the WU-FTPD is giving an incorrect = fact (which I guess I
should note as a bug :).  We know from the SIZE = command earlier, the daemon
_could_ determine the correct value.  But that = might mean doing what we did
for the SIZE command; processing the entire file to = determine the size and
discarding the resulting data stream.  Since = we're about to transmit the
file, pre-processing just to send an accurate size = seems a waste of time and
resources.  If the server does not already have = the size information
available (ie., by stat'ing the file) or the = information can be expected to
be incorrect, I would say it MUST NOT send that = information in the initial,
intermediate reply.

    226 Transfer complete.
    727 bytes received in 0.00515 = secs (1.4e+02 Kbytes/sec)

Again, my client knows how many bytes (octets) were = received.  But as a
human I am confused; the numbers do not match.  = At this point, the server
SHOULD send the actual number of bytes (octets) = transmitted.

Now here's an issue: how should it be worded?  = I'd like to see the server
only sending the size information once.  But = sometimes that information is
available prior to the transfer, sometimes not until = after.  If sent before
the transfer the client (proxy?) can use the = information to make policy
decisions (cache/no-cache).  But it's

    ftp> quot allo 727
    202 ALLO command ignored.

Sigh.  Well, this isn't really what ALLO was = intended for.  I suppose
WU-FTPD _could_ do a filesystem space availability = check.  But that would be
very hard to do inside a chroot'd environment.  = The best way to check would
be to actually try creating a file of the desired = size, but we don't know
where to create the file and even if we did I'd = think long and hard about
the DoS possibilities.

    ftp> bin
    200 Type set to I.
    ftp> put aaaa = /incoming/aaaa
    local: aaaa remote: = /incoming/aaaa
    200 PORT command = successful.
    150 Opening BINARY mode data = connection for /incoming/aaaa.
    226 Transfer complete.
    712 bytes sent in 0.000797 secs = (8.7e+02 Kbytes/sec)
    ftp> asc
    200 Type set to A.
    ftp> put bbbb = /incoming/bbbb
    local: bbbb remote: = /incoming/bbbb
    200 PORT command = successful.
    150 Opening ASCII mode data = connection for /incoming/bbbb.
    226 Transfer complete.
    727 bytes sent in 0.000873 secs = (8.1e+02 Kbytes/sec)

Obviously the server has no size information.  = But it probably SHOULD give a
read-back of the bytes received.

    ftp> quit
    221 Goodbye.



As to Alun's comments about changing the accepted = textual reply ...

If the existing definition is = "unspecified", and if the new specification is
no stronger than SHOULD on the server, and the = client MUST be able to handle
the case of "unspecified" or even missing = textual information, I don't see a
problem.

The RFC gives example relies for those which are = "unspecified".  I see those
as no more than recommendations.  Also, a = client which depended upon the
recommended replies would have problems handling a = server which was using
non-English text in replies.

The best method, if we don't want to change the final = reply, is to use
extended replies, such as:

226-727 bytes received
226 Transfer complete.



------_=_NextPart_001_01BFD09D.60875150-- From ftp-wg-owner@hethmon.com Wed Jun 7 13:06:33 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16218 for ; Wed, 7 Jun 2000 13:06:33 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000607120325-19514-17 ; Wed, 07 Jun 2000 12:03:26 -0500 Received: from anarchy.io.com (anarchy.io.com [199.170.88.101]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000607120321-44387-11 ; Wed, 07 Jun 2000 12:03:21 -0500 Received: from magnus.io.com (aus-as4-042.io.com [208.2.105.42]) by anarchy.io.com (8.9.3/8.9.3) with ESMTP id LAA08787 for ; Wed, 7 Jun 2000 11:59:50 -0500 Message-Id: <4.3.1.2.20000607114742.00bbb570@mail.io.com> X-Sender: alun@mail.io.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 In-Reply-To: <014801bfd097$5cbd1d40$4002a8c0@corp.domainit.com> References: <393E1CF5.6852.3745B80@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Date: Wed, 7 Jun 2000 12:03:22 -0500 X-OldDate: Wed, 07 Jun 2000 11:58:36 -0500 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Alun Jones To: FTPEXT Working Group Subject: Ftp-WG: Transfer Size info, was: thoughts on ftp extensions and caching At 10:48 AM 6/7/2000, you wrote: >As to Alun's comments about changing the accepted textual reply ... > >If the existing definition is "unspecified", and if the new specification is >no stronger than SHOULD on the server, and the client MUST be able to handle >the case of "unspecified" or even missing textual information, I don't see a >problem. I think you misunderstand me. You seem to be merging my two points into one. Since I already stated that they were largely contradictory (perhaps "complementary", or "orthogonal" would have been better), this isn't appropriate. Again, the first argument is that numerical responses should be sufficient for most operations; by adding requirements on the text presented, we will be preventing a server from supplying the data that it previously chose to provide (for whatever custom purpose). The server will have to choose between remaining usable in its current configuration, or breaking that functionality to support a new RFC. The second argument is that there is _already_ a de-facto standard for the 150 response, that is used by many graphical FTP clients to create a progress bar. To change from this standard to a new one would again cause servers to make the choice between supporting old standards or new ones. Presumably the clients would catch up eventually to the new standards, but in the meantime, functionality that I presume users consider valuable would be lost. >The RFC gives example relies for those which are "unspecified". I see those >as no more than recommendations. Also, a client which depended upon the >recommended replies would have problems handling a server which was using >non-English text in replies. The clients do not depend on the response, but they use the byte count if it is there. >The best method, if we don't want to change the final reply, is to use >extended replies, such as: > >226-727 bytes received >226 Transfer complete. Any client that couldn't handle a change to "226 Transfer complete (727 bytes)." would be seriously broken. I see no objections to including a byte count in the termination response [though remember that a QUIT and close of the command/response stream does _not_ disconnect a transfer associated with that connection - an FTP client that disconnects before the transfer is complete, of course, pretty much deserves not to know whether it got all the data]. To clarify, my objection is with requiring a change to the 150 text, as it would require the generation of information that is often complex to generate (the size fact isn't necessarily the only slow fact to generate), and it would break an existing, commonly-used, albeit de-facto, standard format of response. I have no objection to adding a byte count to the 226 response, since there is no existing functionality to break (AFAIK), and the information is no harder to generate than to simply hold a count of bytes accepted by the send() function. If the client wants to know the MLST facts when retrieving a file, why not simply call MLST prior to retrieving the file? Alun. ~~~~ -- Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find us 1602 Harvest Moon Place | at web site http://www.wftpd.com or email Cedar Park TX 78613 | us at alun@texis.com. VISA / MC accepted. Fax +1 (512) 378 3246 | NT-based ISPs, be sure to read details of Phone +1 (512) 378 3246 | WFTPD Pro, NT service version - $100. From ftp-wg-owner@hethmon.com Wed Jun 7 13:07:41 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16253 for ; Wed, 7 Jun 2000 13:07:41 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000607120323-14619-13 ; Wed, 07 Jun 2000 12:03:23 -0500 Received: from anarchy.io.com (anarchy.io.com [199.170.88.101]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000607120318-52500-11 ; Wed, 07 Jun 2000 12:03:19 -0500 Received: from magnus.io.com (aus-as4-042.io.com [208.2.105.42]) by anarchy.io.com (8.9.3/8.9.3) with ESMTP id LAA08767 for ; Wed, 7 Jun 2000 11:59:45 -0500 Message-Id: <4.3.1.2.20000607112338.00b3dab0@mail.io.com> X-Sender: alun@mail.io.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 In-Reply-To: <61A45D5AE74BD311A76D00A0D21B18723672F4@magritte.felspar.ne t> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Date: Wed, 7 Jun 2000 12:03:20 -0500 X-OldDate: Wed, 07 Jun 2000 11:38:22 -0500 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Alun Jones To: FTPEXT Working Group Subject: Ftp-WG: thoughts on ftp extensions and caching At 10:43 AM 6/7/2000, you wrote: >When I read through the MLST draft trying to see whether I was allowed to >drop a fact when the client had requested it, I couldn't find anything >about it, either way, which suggested to me in my pedantically crippled >way that it wasn't allowed - or at least, that it probably shouldn't be >done from a server PoV, but should be allowed for in a client context. It >may well be just me, though, I don't know if anyone else reads it that >way. Of course, I might have missed the critical phrase while skimming >through it, at which point I apologise profusely for my stupidity. :-) End of 7.2: "Facts should be provided in each output line only if they both provide relevant information about the file named on the same line, and they are in the set requested by the user-PI. There is no requirement that the same set of facts be provided for each file, or that the facts presented occur in the same order for each file." Sounds like facts should _not_ be provided if they don't provide relevant information about the named file. Perhaps a clarification is in order, but I read it as meaning that a nonsensical fact should not be displayed (e.g. a size on a directory). Note also that section 7.7.3 shows an MSLD example that does _not_ include the Size fact for its directory entries. 7.7.9 includes a similar example that shows dropping of the size facts on directories, but since that looks like my server, I'd say I'm biased :-) >Standardising the responses from RETR is surely fine if it only becomes >active with a OPT setting? Or not? > >Having said that, Alun Jones makes very good sense indeed in his point >(2). Perhaps all that is needed is a mention of this de-facto standard in >more detail. If so, all the better. > >I do still like the concept of the transfer-size fact being defined, though. The way I've written my server is that the expression "(N bytes)" is output, and is essentially the only item in parentheses on that line (unless you want to try and break your FTP client by creating a file called "(-1 bytes)" and retrieve that :-)) That appears to be standard - here's an example: 150 "/uplap.bat" file ready to send (437 bytes) in ASCII mode Any transfer where I do not have a ready count of the bytes to send, gets no byte count - nothing in the parentheses. If you're going to document that, I'd suggest also documenting that the byte count given may, for all sorts of reasons, not be the same as the number of bytes sent. Let's say, for instance, you're transferring a text file that logs every FTP response message sent - that will _never_ be the same size as reported! [I also have customers who use my server to 'stream' video files of 13GB or so - when they first appear on the server to be downloaded, they'll look like they only have a few KB in them, so the value given at the start of the transfer is _greatly_ different from the number of bytes transferred - by several orders of magnitude!] Alun. ~~~~ P.S. On the subject of changing file sizes, it's clear that many people are unaware of file stores that use paged or record structures on files, where many pages/records are "empty" and hence not stored. A file could occupy a few bytes on disk, but when transferred in File / Image mode, be several megabytes (mostly zero, or whatever the fill character is defined to be). -- Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find us 1602 Harvest Moon Place | at web site http://www.wftpd.com or email Cedar Park TX 78613 | us at alun@texis.com. VISA / MC accepted. Fax +1 (512) 378 3246 | NT-based ISPs, be sure to read details of Phone +1 (512) 378 3246 | WFTPD Pro, NT service version - $100. From ftp-wg-owner@hethmon.com Wed Jun 7 13:35:33 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16784 for ; Wed, 7 Jun 2000 13:35:32 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000607123339-38200-7 ; Wed, 07 Jun 2000 12:33:39 -0500 Received: from mail.corp.domainit.com (199.18.156.62 [199.18.156.62]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000607123335-5284-6 ; Wed, 07 Jun 2000 12:33:35 -0500 Received: from wintest (dhcp64.corp.domainit.com [192.168.2.64]) (authenticated as lundberg with LOGIN) by mail.corp.domainit.com (8.10.0.Beta10/8.10.0.Beta10) with ESMTP id e57HU5E04748 for ; Wed, 7 Jun 2000 13:30:05 -0400 Message-ID: <01f601bfd0a6$051e8ce0$4002a8c0@corp.domainit.com> References: <393E1CF5.6852.3745B80@localhost> <4.3.1.2.20000607114742.00bbb570@mail.io.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Date: Wed, 7 Jun 2000 12:33:37 -0500 X-OldDate: Wed, 7 Jun 2000 13:30:05 -0400 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: "Gregory A Lundberg" To: "FTPEXT Working Group" Subject: Ftp-WG: Transfer Size info, was: thoughts on ftp extensions and caching Content-Transfer-Encoding: 7bit > I think you misunderstand me. You seem to be merging my two points into > one. Since I already stated that they were largely contradictory (perhaps > "complementary", or "orthogonal" would have been better), this isn't > appropriate. I like "contradictory" .. fits more with what I think when reading 959. > Any client that couldn't handle a change to "226 Transfer complete (727 > bytes)." would be seriously broken. I see no objections to including a > byte count in the termination response [though remember that a QUIT and > close of the command/response stream does _not_ disconnect a transfer > associated with that connection - an FTP client that disconnects before the > transfer is complete, of course, pretty much deserves not to know whether > it got all the data]. > > To clarify, my objection is with requiring a change to the 150 text, as it > would require the generation of information that is often complex to > generate (the size fact isn't necessarily the only slow fact to generate), > and it would break an existing, commonly-used, albeit de-facto, standard > format of response. I have no objection to adding a byte count to the 226 > response, since there is no existing functionality to break (AFAIK), and > the information is no harder to generate than to simply hold a count of > bytes accepted by the send() function. I agree with all of this, and your point about changing the 150 intermediate reply is well taken. From ftp-wg-owner@hethmon.com Wed Jun 7 14:34:16 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17816 for ; Wed, 7 Jun 2000 14:34:15 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000607133049-19008-7 ; Wed, 07 Jun 2000 13:30:49 -0500 Received: from havoc.entera.com (havoc.entera.com [206.165.109.130]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000607133045-61641-6 ; Wed, 07 Jun 2000 13:30:45 -0500 Received: from entera.com ([208.48.116.174]) by havoc.entera.com (Post.Office MTA v3.5.3 release 223 ID# 0-61971U200L100S0V35) with ESMTP id com for ; Wed, 7 Jun 2000 11:25:22 -0700 Message-ID: <393E942A.739CD494@entera.com> Organization: Entera, Inc. X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.7 i86pc) X-Accept-Language: en MIME-Version: 1.0 References: <4.3.1.2.20000607112338.00b3dab0@mail.io.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 7 Jun 2000 13:30:47 -0500 X-OldDate: Wed, 07 Jun 2000 11:27:54 -0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Stephen Head To: FTPEXT Working Group Subject: Ftp-WG: thoughts on ftp extensions and caching Content-Transfer-Encoding: 7bit Alun Jones wrote: > >Having said that, Alun Jones makes very good sense indeed in his point > >(2). Perhaps all that is needed is a mention of this de-facto standard in > >more detail. If so, all the better. > > > >I do still like the concept of the transfer-size fact being defined, though. > > The way I've written my server is that the expression "(N bytes)" is > output, and is essentially the only item in parentheses on that line > (unless you want to try and break your FTP client by creating a file called > "(-1 bytes)" and retrieve that :-)) That appears to be standard - here's > an example: > > 150 "/uplap.bat" file ready to send (437 bytes) in ASCII mode > > Any transfer where I do not have a ready count of the bytes to send, gets > no byte count - nothing in the parentheses. Whoa there pilgrim, does this adequately express how a client should interpret that format under all circumstances? In particular, considering the permissible character set from which file names are comprised, as in the following sequence: ... 230 User smh logged in. ftp> put /tmp/rot "/tmp/xxx (437 bytes)" 200 PORT command successful. 150 ASCII data connection for /tmp/xxx (437 bytes) (a.b.c.d,49720). 226 Transfer complete. local: /tmp/rot remote: /tmp/xxx (437 bytes) 108042 bytes sent in 0.017 seconds (6176.30 Kbytes/s) ftp> put /tmp/rot /tmp/rot55 200 PORT command successful. 150 ASCII data connection for /tmp/rot55 (a.b.c.d,49722). 226 Transfer complete. local: /tmp/rot remote: /tmp/rot55 108042 bytes sent in 0.018 seconds (5991.47 Kbytes/s) ftp> get /tmp/rot "/tmp/xxx (437 bytes)" 200 PORT command successful. 150 ASCII data connection for /tmp/rot (a.b.c.d,49724) (9139 bytes). 226 ASCII Transfer complete. local: /tmp/xxx (437 bytes) remote: /tmp/rot 9340 bytes received in 0.058 seconds (157.37 Kbytes/s) ftp> ... [a.b.c.d] uname -a SunOS tomcat 5.7 Generic_106541-07 sun4u sparc SUNW,UltraSPARC-IIi-Engine In particular, how should a client reliably parse the so-called de-facto 150 response given that filenames can contain all those funky characters? If forwards, then they could run into files with the same name (granted, unlikely, but still apparently "legal", at least in the common-practice sense). If this is correct, but not widely implemented, perhaps at least this is a valid issue for standardization in some manner, at the earliest convenience. (Or what have I missed...) > If you're going to document that, I'd suggest also documenting that the > byte count given may, for all sorts of reasons, not be the same as the > number of bytes sent. Let's say, for instance, you're transferring a text > file that logs every FTP response message sent - that will _never_ be the > same size as reported! [I also have customers who use my server to > 'stream' video files of 13GB or so - when they first appear on the server > to be downloaded, they'll look like they only have a few KB in them, so the > value given at the start of the transfer is _greatly_ different from the > number of bytes transferred - by several orders of magnitude!] Noted, though I still would tend to expect the majority of files transferred around the net to be of the static exact-size variety (and so good potential candidates for caching). -s From ftp-wg-owner@hethmon.com Wed Jun 7 14:50:59 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18118 for ; Wed, 7 Jun 2000 14:50:58 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000607134601-33394-7 ; Wed, 07 Jun 2000 13:46:01 -0500 Received: from mail.corp.domainit.com (199.18.156.62 [199.18.156.62]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000607134557-2867-6 ; Wed, 07 Jun 2000 13:45:57 -0500 Received: from wintest (dhcp64.corp.domainit.com [192.168.2.64]) (authenticated as lundberg with LOGIN) by mail.corp.domainit.com (8.10.0.Beta10/8.10.0.Beta10) with ESMTP id e57IgRE04883 for ; Wed, 7 Jun 2000 14:42:27 -0400 Message-ID: <025e01bfd0b0$215e1a60$4002a8c0@corp.domainit.com> References: <4.3.1.2.20000607112338.00b3dab0@mail.io.com> <393E942A.739CD494@entera.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Date: Wed, 7 Jun 2000 13:45:59 -0500 X-OldDate: Wed, 7 Jun 2000 14:42:27 -0400 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: "Gregory A Lundberg" To: "FTPEXT Working Group" Subject: Ftp-WG: thoughts on ftp extensions and caching Content-Transfer-Encoding: 7bit > Whoa there pilgrim, does this adequately express how a client should > interpret that format under all circumstances? In particular, considering > the permissible character set from which file names are comprised, > as in the following sequence: > ftp> put /tmp/rot "/tmp/xxx (437 bytes)" Not to mention what RFC 2640 could do to you. > Noted, though I still would tend to expect the majority of files transferred > around the net to be of the static exact-size variety (and so > good potential candidates for caching). I dunno. I get the feeling that if we put something akin to a CGI interface in WU-FTPD you'd see a lot more on-the-fly stuff. Just from the questions I've fielded on the support lists and via phone conversations. I know it smacks of HTTP-izing FTP, but people want it, I know some who are doing it now, and I think many more would use it. From ftp-wg-owner@hethmon.com Wed Jun 7 15:04:44 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18477 for ; Wed, 7 Jun 2000 15:04:43 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000607140123-17984-7 ; Wed, 07 Jun 2000 14:01:23 -0500 Received: from havoc.entera.com (havoc.entera.com [206.165.109.130]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000607140119-62210-6 ; Wed, 07 Jun 2000 14:01:19 -0500 Received: from entera.com ([208.48.116.174]) by havoc.entera.com (Post.Office MTA v3.5.3 release 223 ID# 0-61971U200L100S0V35) with ESMTP id com for ; Wed, 7 Jun 2000 11:55:57 -0700 Message-ID: <393E9B54.7ED44415@entera.com> Organization: Entera, Inc. X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.7 i86pc) X-Accept-Language: en MIME-Version: 1.0 References: <4.3.1.2.20000607112338.00b3dab0@mail.io.com> <393E942A.739CD494@entera.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 7 Jun 2000 14:01:21 -0500 X-OldDate: Wed, 07 Jun 2000 11:58:28 -0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Stephen Head To: FTPEXT Working Group Subject: Ftp-WG: thoughts on ftp extensions and caching Content-Transfer-Encoding: 7bit Stephen Head wrote: > 230 User smh logged in. > ftp> put /tmp/rot "/tmp/xxx (437 bytes)" > 200 PORT command successful. > 150 ASCII data connection for /tmp/xxx (437 bytes) (a.b.c.d,49720). Sorry, that example did not quite illustrate what I expected, haste made waste, for the vicariously interested my local machine uname -a is SunOS viking.entera.com 5.7 Generic_106542-08 i86pc i386 i86pc but the following comes close (and is actually what I had in an earlier version of my message before I tried to fine tune it): ftp> put /tmp/rot "/tmp/(437 bytes)" 200 PORT command successful. 150 ASCII data connection for /tmp/(437 bytes) (208.48.116.174,49681). 226 Transfer complete. local: /tmp/rot remote: /tmp/(437 bytes) 108042 bytes sent in 0.022 seconds (4749.27 Kbytes/s) ftp> get "/tmp/(437 bytes)" /tmp/fooi 200 PORT command successful. 150 ASCII data connection for /tmp/(437 bytes) (208.48.116.174,49685) (105088 bytes). 226 ASCII Transfer complete. local: /tmp/fooi remote: /tmp/(437 bytes) 108042 bytes received in 0.035 seconds (3035.99 Kbytes/s) ftp> put /tmp/rot "/tmp (437 bytes)" ... (Note in particular the two occurences of the pattern "(nnn bytes)" in the second and last 150 response.) (Looks as if one perhaps can't quite presume the doublequotes do consistent duty on solaris 5.7 solaris ftp...) -s From ftp-wg-owner@hethmon.com Wed Jun 7 15:45:10 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19181 for ; Wed, 7 Jun 2000 15:45:09 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000607144524-16144-7 ; Wed, 07 Jun 2000 14:45:24 -0500 Received: from anarchy.io.com (anarchy.io.com [199.170.88.101]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000607144520-54053-6 ; Wed, 07 Jun 2000 14:45:20 -0500 Received: from magnus.io.com (aus-as4-042.io.com [208.2.105.42]) by anarchy.io.com (8.9.3/8.9.3) with ESMTP id OAA19019 for ; Wed, 7 Jun 2000 14:41:49 -0500 Message-Id: <4.3.1.2.20000607143104.00bdb180@mail.io.com> X-Sender: alun@mail.io.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 In-Reply-To: <393E942A.739CD494@entera.com> References: <4.3.1.2.20000607112338.00b3dab0@mail.io.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Date: Wed, 7 Jun 2000 14:45:22 -0500 X-OldDate: Wed, 07 Jun 2000 14:40:38 -0500 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Alun Jones To: FTPEXT Working Group Subject: Ftp-WG: thoughts on ftp extensions and caching At 01:30 PM 6/7/2000, you wrote: >Alun Jones wrote: > > The way I've written my server is that the expression "(N bytes)" is > > output, and is essentially the only item in parentheses on that line > > (unless you want to try and break your FTP client by creating a file called > > "(-1 bytes)" and retrieve that :-)) That appears to be standard - here's > > an example: ... >Whoa there pilgrim, does this adequately express how a client should >interpret that format under all circumstances? In particular, considering >the permissible character set from which file names are comprised, >as in the following sequence: > >... > >230 User smh logged in. >ftp> put /tmp/rot "/tmp/xxx (437 bytes)" Uh, yeah, that's what my "creating a file called '(-1 bytes)'" note was about. It's not perfect, and it's not documented, but it seems to be what other FTP servers do, and it seems to be, for the most part, quite usable. >200 PORT command successful. >150 ASCII data connection for /tmp/xxx (437 bytes) (a.b.c.d,49720). To be honest, I've never seen the local port assignment returned inside of an FTP server response. That's definitely a new one on me. >In particular, how should a client reliably parse the so-called de-facto >150 response given that filenames can contain all those funky characters? "so-called de-facto"? It's about as 'de-facto' as the 'ls -l' format is for file listings, and it's perhaps more 'de-facto' than the SIZE and MDTM commands were before the MLST draft came along. Whether it's reliable or not, it _is_ here, it _is_ widespread, and it _is_ used by many of the FTP clients I run into on a daily basis. While that's not a statistically valid survey, I think you will find that a removal or disabling of that functionality, by requiring a different 150 response, would produce a lot of complaint from client users. >If forwards, then they could run into files with the same name (granted, >unlikely, but still apparently "legal", at least in the common-practice >sense). Were it my FTP client, I'd parse backwards from the end of the last line, but then I'm perfect :-) >If this is correct, but not widely implemented, perhaps at least this is a >valid >issue >for standardization in some manner, at the earliest convenience. Perhaps we need to collect examples of 150 text messages from various servers, to know what is usual. Anyone want to send me examples of their 150 responses, so I can collate? [RETR only, please, and no mucky filenames like that given in the examples above!] >Noted, though I still would tend to expect the majority of files transferred >around the net to be of the static exact-size variety (and so >good potential candidates for caching). Maybe so, but it is worth informing FTP client authors that this does not _always_ happen. In most file systems / operating systems, you can append to a file while it is open for reading by an FTP server, and that extra data would then appear in the transfer. To provide a means by which a client can 'tell' the size of a file before it is transferred implies to some programmers that this is where the file shall stop. 'tain't necessarily so, and anything that documents such a measure as being a foretelling of the size of the file would do well to remind programmers that the eventual size may be different. Alun. ~~~~ -- Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find us 1602 Harvest Moon Place | at web site http://www.wftpd.com or email Cedar Park TX 78613 | us at alun@texis.com. VISA / MC accepted. Fax +1 (512) 378 3246 | NT-based ISPs, be sure to read details of Phone +1 (512) 378 3246 | WFTPD Pro, NT service version - $100. From ftp-wg-owner@hethmon.com Wed Jun 7 18:06:56 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21417 for ; Wed, 7 Jun 2000 18:06:55 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000607170548-22042-17 ; Wed, 07 Jun 2000 17:05:48 -0500 Received: from havoc.entera.com (havoc.entera.com [206.165.109.130]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000607170542-62862-14 ; Wed, 07 Jun 2000 17:05:43 -0500 Received: from entera.com ([208.48.116.174]) by havoc.entera.com (Post.Office MTA v3.5.3 release 223 ID# 0-61971U200L100S0V35) with ESMTP id com for ; Wed, 7 Jun 2000 15:00:20 -0700 Message-ID: <393EC68B.427BA394@entera.com> Organization: Entera, Inc. X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.7 i86pc) X-Accept-Language: en MIME-Version: 1.0 References: <4.3.1.2.20000607112338.00b3dab0@mail.io.com> <4.3.1.2.20000607143104.00bdb180@mail.io.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 7 Jun 2000 17:05:45 -0500 X-OldDate: Wed, 07 Jun 2000 15:02:51 -0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Stephen Head To: FTPEXT Working Group Subject: Ftp-WG: thoughts on ftp extensions and caching Content-Transfer-Encoding: 7bit Alun Jones wrote: > "so-called de-facto"? It's about as 'de-facto' as the 'ls -l' format is > for file listings, and it's perhaps more 'de-facto' than the SIZE and MDTM > commands were before the MLST draft came along. Whether it's reliable or > not, it _is_ here, it _is_ widespread, and it _is_ used by many of the FTP > clients I run into on a daily basis. While that's not a statistically > valid survey, I think you will find that a removal or disabling of that > functionality, by requiring a different 150 response, would produce a lot > of complaint from client users. The point I was trying to make was that there appears (or at least, appears to me) to be some variation between the existing relevant standard (959) and each of the various forms of the de-facto-whatever :-) standard. (Also a FEAT variable permit more latitude in the response and avoid compatibility problems it would seem to me.) > >If forwards, then they could run into files with the same name (granted, > >unlikely, but still apparently "legal", at least in the common-practice > >sense). > > Were it my FTP client, I'd parse backwards from the end of the last line, > but then I'm perfect :-) Thanks; perhaps this can be noted that this is the correct way to parse it if this format is chosen (I was concerned about how frequently parsing backwards is done in practice-- this is one of the concerns I sought to avoid by using FEAT and a spiffier format loosely based on d-10). > >If this is correct, but not widely implemented, perhaps at least this is a > >valid > >issue > >for standardization in some manner, at the earliest convenience. > > Perhaps we need to collect examples of 150 text messages from various > servers, to know what is usual. Anyone want to send me examples of their > 150 responses, so I can collate? [RETR only, please, and no mucky > filenames like that given in the examples above!] I already sent out two variants a few messages back for illustrative purposes. They differed in that one used a fully-qualified name and the other did not. Also, ASCII was inaccurate even in the static case. I also suggested the notion of using FEAT in some manner to help clean it up. For caching purposes, fully qualified name and accurate size are better than 'base' filename and approx-size. Modified date would also, I believe, be useful to avoid sending separate MDTM for caching (if parsing backwards is the ticket for the extended 150 response, then there should be some room to play with between the filename and the byte count to put a datestamp). > >Noted, though I still would tend to expect the majority of files transferred > >around the net to be of the static exact-size variety (and so > >good potential candidates for caching). > > Maybe so, but it is worth informing FTP client authors that this does not > _always_ happen. In most file systems / operating systems, you can append > to a file while it is open for reading by an FTP server, and that extra > data would then appear in the transfer. To provide a means by which a > client can 'tell' the size of a file before it is transferred implies to > some programmers that this is where the file shall stop. 'tain't > necessarily so, and anything that documents such a measure as being a > foretelling of the size of the file would do well to remind programmers > that the eventual size may be different. Yes... These discussions have helped clarify to me some of the origin of the extended response but its reliability for use is still somewhat of a concern from my viewpoint. I thought it would be an overall win to bring these issues to the attention of the wg, in the form of some constructive potential solutions. Well, back to the pub XXX work, -s From ftp-wg-owner@hethmon.com Wed Jun 7 21:14:08 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA23508 for ; Wed, 7 Jun 2000 21:14:07 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000607201331-62465-20 ; Wed, 07 Jun 2000 20:13:31 -0500 Received: from havoc.entera.com (havoc.entera.com [206.165.109.130]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000607201327-53816-20 ; Wed, 07 Jun 2000 20:13:27 -0500 Received: from entera.com ([208.48.116.174]) by havoc.entera.com (Post.Office MTA v3.5.3 release 223 ID# 0-61971U200L100S0V35) with ESMTP id com for ; Wed, 7 Jun 2000 18:08:03 -0700 Message-ID: <393EF28A.176DBA10@entera.com> Organization: Entera, Inc. X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.7 i86pc) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 7 Jun 2000 20:13:28 -0500 X-OldDate: Wed, 07 Jun 2000 18:10:34 -0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Stephen Head To: ftp-wg@hethmon.com Subject: Ftp-WG: alternative thoughts on RETR/response variations Content-Transfer-Encoding: 7bit I originally thought I could try to live with the de-facto 150 response but became concerned with parsing it correctly under the circumstances, and/or parsing an extended version with funky characters in the pathname and an MTDM value embedded somewhere. It seemed a bit risky for the ROI. As a workaround for no ground given on the de-facto 150 response, a proxy could transform a RETR pathname command into a bundled sequence of commands to the origin server like (TYPE I) ... (receive RETR request from destination client) ... PWD MDTM pathname SIZE pathname RETR ... (send data to destination client, possibly transformed into ASCII, and optionally cache) for each request from the destination client, and process the responses as they come (ftp server daemon processes could, independently, be trained to look for such sequences and respond in kind with an aggregated response sequence if encountered). (SIZE and response could be replaced with a standardized, reliable form of the de-facto response which reported an accurate image size -- variation.) An economization of this would be to have an extended version of RETR, perhaps something like XRET, and pair with it a correspondingly extended 15x-Ext response of the type I mentioned earlier. An XRET could also carry with it the notion of switching momentarily to image type and then revert back to the previous type -- a minor variation. (Compression?) Ideally, in both cases, the response would contain an exact size, at least modulo the issues that have been brought up about that so far (dynamic file generation, dynamic file modification, and possibly stuff like structured file record deletes on OSs with those types of files). Considering tradeoffs at a glance, the former alternative seems to have somewhat more overhead even if requests and responses are bundled on the control channel. I guess no one uses non-Stream mode transfer so 12x-Ext responses would be moot. (?) -s From ftp-wg-owner@hethmon.com Wed Jun 7 21:42:52 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA23876 for ; Wed, 7 Jun 2000 21:42:51 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000607204230-13175-8 ; Wed, 07 Jun 2000 20:42:30 -0500 Received: from anarchy.io.com (anarchy.io.com [199.170.88.101]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000607204224-51086-6 ; Wed, 07 Jun 2000 20:42:24 -0500 Received: from magnus.io.com (aus-as4-004.io.com [208.2.105.4]) by anarchy.io.com (8.9.3/8.9.3) with ESMTP id UAA07690 for ; Wed, 7 Jun 2000 20:38:54 -0500 Message-Id: <4.3.1.2.20000607202054.00c7e900@mail.io.com> X-Sender: alun@mail.io.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 In-Reply-To: <393EF28A.176DBA10@entera.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Date: Wed, 7 Jun 2000 20:42:27 -0500 X-OldDate: Wed, 07 Jun 2000 20:35:15 -0500 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Alun Jones To: FTPEXT Working Group Subject: Ftp-WG: alternative thoughts on RETR/response variations At 08:13 PM 6/7/2000, you wrote: >I originally thought I could try to live with the de-facto 150 response >but became concerned with parsing it correctly under the circumstances, >and/or parsing an extended version with funky characters in the pathname >and an MTDM value embedded somewhere. It seemed a bit risky for >the ROI. Six of one, half a dozen of the other. While it's easy to demonstrate a degenerative case, there are very few in actual circulation, and it's none too difficult to claim that a user creating that kind of file name deserves for it to cause problems with FTP clients (as long as the clients don't crash!). >As a workaround for no ground given on the de-facto 150 response, >a proxy could transform a RETR pathname command into a bundled sequence >of commands to the origin server like Why not PASV|PORT / MLST / [REST / ] RETR? >for each request from the destination client, >and process the responses as they come (ftp server daemon processes >could, independently, be trained to look for such sequences and respond >in kind with an aggregated response sequence if encountered). >(SIZE and response could be replaced with a standardized, reliable form >of the de-facto response which reported an accurate image size -- >variation.) I'm uncomfortable with this idea of batching requests and/or responses, but I can't _quite_ put it into words just yet. Maybe someone else can? >An economization of this would be to have an extended version >of RETR, perhaps something like XRET, and pair with it >a correspondingly extended 15x-Ext response of the type >I mentioned earlier. An XRET could also carry with it the notion >of switching momentarily to image type and then revert back >to the previous type -- a minor variation. (Compression?) MLST is one extra command, and provides essentially what you want. >Ideally, in both cases, the response would contain an exact size, >at least modulo the issues that have been brought up about that >so far (dynamic file generation, dynamic file modification, and >possibly stuff like structured file record deletes on OSs with those >types >of files). For the vast majority of cases, MLST will provide exactly the information you're looking for, or close enough that a proxy can figure out whether to cache or not. SIZE and MDTM will not practically provide you with more information, but they can take longer. Note, also, that in the usual case where MLST responds with an incorrect size, ASCII mode transfer, it is not always possible to determine whether the size given from any one command will match the size of the file when stored on your proxy. In that respect, it appears that the SIZE command is at least as inaccurate as the MLST facts! [You _could_ call MLST _and_ SIZE, to find out how many carriage-return line-feed pairs there are, but again, I can provide you with a degenerate case to screw your calculations up.] >Considering tradeoffs at a glance, the former alternative seems >to have somewhat more overhead even if requests and responses >are bundled on the control channel. One or two extra commands are surely not that much of an overhead - and we are still talking about a proxy cache, which is not IMHO a widespread application for FTP. You're asking for a change to be made that affects many clients, in order to help out a few? Where's that Vulcan blood? :-) >I guess no one uses non-Stream mode transfer so 12x-Ext >responses would be moot. (?) I've given some thought to implementing non-stream modes, but nobody's asked for it yet, so it isn't high on my list of priorities. A client can ask for status information during the stream-mode transfer, but again, there is no standard for the response format. Seems to me, you're asking the standard to be altered mainly so you (or some other proxy author) won't have to do as much work, and that work can be mostly offloaded to the server! As a server author, I'm going to suggest that the proxy needs to do the work, and take the hits. :-) Alun. ~~~~ -- Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find us 1602 Harvest Moon Place | at web site http://www.wftpd.com or email Cedar Park TX 78613 | us at alun@texis.com. VISA / MC accepted. Fax +1 (512) 378 3246 | NT-based ISPs, be sure to read details of Phone +1 (512) 378 3246 | WFTPD Pro, NT service version - $100. From ftp-wg-owner@hethmon.com Wed Jun 7 23:15:34 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA25988 for ; Wed, 7 Jun 2000 23:15:33 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000607220812-20206-15 ; Wed, 07 Jun 2000 22:08:12 -0500 Received: from havoc.entera.com (havoc.entera.com [206.165.109.130]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000607220808-64373-14 ; Wed, 07 Jun 2000 22:08:08 -0500 Received: from entera.com ([208.48.116.174]) by havoc.entera.com (Post.Office MTA v3.5.3 release 223 ID# 0-61971U200L100S0V35) with ESMTP id com for ; Wed, 7 Jun 2000 20:02:46 -0700 Message-ID: <393F0D6B.A28DD296@entera.com> Organization: Entera, Inc. X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.7 i86pc) X-Accept-Language: en MIME-Version: 1.0 References: <4.3.1.2.20000607202054.00c7e900@mail.io.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 7 Jun 2000 22:08:10 -0500 X-OldDate: Wed, 07 Jun 2000 20:05:15 -0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Stephen Head To: FTPEXT Working Group Subject: Ftp-WG: alternative thoughts on RETR/response variations Content-Transfer-Encoding: 7bit Alun Jones wrote: > At 08:13 PM 6/7/2000, you wrote: > >I originally thought I could try to live with the de-facto 150 response > >but became concerned with parsing it correctly under the circumstances, > >and/or parsing an extended version with funky characters in the pathname > >and an MTDM value embedded somewhere. It seemed a bit risky for > >the ROI. > > Six of one, half a dozen of the other. While it's easy to demonstrate a > degenerative case, there are very few in actual circulation, and it's none > too difficult to claim that a user creating that kind of file name deserves > for it to cause problems with FTP clients (as long as the clients don't > crash!). Sure. I would tend to add any potential proxies to the list of those applications that would tend not towant to take any unnecessary chances, though. I would be reluctant to try to formalize the existing syntax without allowances for any heretofore legal pathname, though. People seem to be extending this in various different ad-hoc ways, which will probably(?) lead to a mess sooner or later, but ... whatever... > >As a workaround for no ground given on the de-facto 150 response, > >a proxy could transform a RETR pathname command into a bundled sequence > >of commands to the origin server like > > Why not PASV|PORT / MLST / [REST / ] RETR? Sorry, yes, I think for what I was looking for, SIZE and MDTM can be replaced by MLST, but I was under the impression that MLST and friends were not required to report a fully qualified pathname . As symlink can cause client side confusion about where in the server NVS one is, I believe, a proxy would seem to want a PWD, at least for each new remote directory entered, since my reading of d-10 did not seem to indicate that the return of a _fully_ _qualified_ pathname was required: 7.2. Format of MLSx Response The format of a response to an MLSx command is as follows: ... entry = [ facts ] SP pathname although the example later appears to return a fully qualified pathname (at least if it's a UNIX style NVS). (Formal disambiguation would be nice if so.) I was deferring considering REST but my concept was if I could get a sense of what to do / what would be best for RETR, REST would most likely resolve itself as the issues are pretty much the same as far as I can tell at a first pass. > >for each request from the destination client, > >and process the responses as they come (ftp server daemon processes > >could, independently, be trained to look for such sequences and respond > >in kind with an aggregated response sequence if encountered). > >(SIZE and response could be replaced with a standardized, reliable form > >of the de-facto response which reported an accurate image size -- > >variation.) > > I'm uncomfortable with this idea of batching requests and/or responses, but > I can't _quite_ put it into words just yet. Maybe someone else can? Me too, for what it is worth, but what to do. Maybe some people already do this for other commands already, though. Just as long as the _server_ doesn't crash, maybe... :-) > >An economization of this would be to have an extended version > >of RETR, perhaps something like XRET, and pair with it > >a correspondingly extended 15x-Ext response of the type > >I mentioned earlier. An XRET could also carry with it the notion > >of switching momentarily to image type and then revert back > >to the previous type -- a minor variation. (Compression?) > > MLST is one extra command, and provides essentially what you want. Add PWD (?) and sometimes TYPE I (?) if I'm OK above. > >Ideally, in both cases, the response would contain an exact size, > >at least modulo the issues that have been brought up about that > >so far (dynamic file generation, dynamic file modification, and > >possibly stuff like structured file record deletes on OSs with those > >types > >of files). ... > >Considering tradeoffs at a glance, the former alternative seems > >to have somewhat more overhead even if requests and responses > >are bundled on the control channel. > > One or two extra commands are surely not that much of an overhead - and we > are still talking about a proxy cache, which is not IMHO a widespread > application for FTP. You're asking for a change to be made that affects > many clients, in order to help out a few? Where's that Vulcan blood? :-) ... > > Seems to me, you're asking the standard to be altered mainly so you (or > some other proxy author) won't have to do as much work, and that work can > be mostly offloaded to the server! As a server author, I'm going to > suggest that the proxy needs to do the work, and take the hits. :-) There are I believe actually three kinds of work involved here, implementation, transmission and computation. Given a standard tends to live forever (RR track widths and Roman chariots, etc.) I put somewhat more weight on the latter two than the former. Perhaps my concerns were misplaced in some way (eg idealistically slanted), but I don't think grossly so given the various issues and ambiguities involved. If any of my arguments hit any soft spots in the draft it may still be worthwhile to address those at before going prime time with it. I presumed the wg would find the concerns of at least passing interest as a projected user (enthusiastic consumer? :-) of the upcoming extension. Re: Vulcan blood, please don't tempt me to respond in Klingon :-). -s From ftp-wg-owner@hethmon.com Thu Jun 8 13:11:15 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12264 for ; Thu, 8 Jun 2000 13:11:15 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000608120358-11541-8 ; Thu, 08 Jun 2000 12:03:58 -0500 Received: from mta5.rcsntx.swbell.net (mta5.rcsntx.swbell.net [151.164.30.29]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000608120353-44777-6 ; Thu, 08 Jun 2000 12:03:53 -0500 Received: from zainprov ([207.193.24.81]) by mta5.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with SMTP id <0FVU00D3BFA52U@mta5.rcsntx.swbell.net> for ftp-wg@hethmon.com; Thu, 8 Jun 2000 11:05:16 -0500 (CDT) Date-warning: Date header was inserted by mta5.rcsntx.swbell.net Message-id: <0FVU00DFSFCQ2U@mta5.rcsntx.swbell.net> MIME-version: 1.0 Content-type: text/plain; charset=unknown-8bit Date: Thu, 8 Jun 2000 12:03:54 -0500 X-OldDate: Thu, 08 Jun 2000 11:05:16 -0500 (CDT) Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: zainprov@swbell.net To: ftp-wg@hethmon.com Subject: Ftp-WG: Shocking LOSE 10-100lbs. DESTINY Hello From Destiny, You will LOOSE 20-100 pounds easy! Do to Such a high demand for Destiny, we are able To Dramatically reduce our price for the entire System! You will LOVE our incredible offer on this Scientific Breakthrough in Weight Loss. Now with a 105% Money Back Guarantee! LOOK! http://home.swbell.net/zainprov/destiny.htm We hope things are going well for you. Good luck, God Bless, and HAVE A GREAT DAY! Either you are someone else subscribed to our list. To be removed Simply reply with a blank email. Thank you, Sherry Wilson From ftp-wg-owner@hethmon.com Fri Jun 9 01:53:30 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA29447 for ; Fri, 9 Jun 2000 01:53:30 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000609005229-40811-11 ; Fri, 09 Jun 2000 00:52:29 -0500 Received: from loans@loansplus.net (ip217.phoenix8.az.pub-ip.psi.net [38.29.61.217]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000609005201-26709-6 ; Fri, 09 Jun 2000 00:52:23 -0500 Message-Id: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7BIT Date: Fri, 9 Jun 2000 00:52:26 -0500 X-OldDate: Thu, 08 Jun 2000 19:07:23 -0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: a_z47@yahoo.com To: webmaster@hethmon.com Subject: Ftp-WG: Mortgage and Foreclosure Content-Transfer-Encoding: 7BIT For Homeowners Only Save Now! Are you in debt? Need extra cash? We can get you the loan you need. Regardless of whether you have good or bad credit, we can help you. We specialize in First and Second Mortgages, including loans that other lenders turn down. Funding borrowers with less than perfect credit is our specialty. We have loan programs that are unheard of. Our loan programs can get you the cash you need for: Debt Consolidation Needs Home Improvements Dream Vacations New Car College Tuition ..and much, much more. Incredibly low monthly payments Loans if you have hard to prove (Self-Employed) income Loans if you have collections, foreclosures, BKs or tax debts Loans if you're behind on your mortgageLoans up to 130% of your home's value Fill out the fax application below for fastest service. You will receive immediate attention to lower your payments, help you get the cash you need or consolidate your debts. We can get you the kind of loan you are looking for. Whether your credit is good or bad, if you are serious about improving your lifestyle and need a loan for any reason, contact us now because we can get you the cash you need. We make the loans that other lenders turn down. This form must be completely filled out. Please enter NA in those field which do not apply. FAX TO: (509) 463-0799 Are you a HomeOwner? Y/N Applicant First and Last Name: __________________________________ Co-Applicant First and Last Name: _______________________________ Address: ____________________________________________ City, State: __________________________________________ Zip Code: _______________ Home Phone: _____________________________ Work Phone: ______________________________ Property Type: Single Family Residence Purchase Price: ____________________________ Year Property was Acquired: _________________ Present Value of Property: ___________________ Amount Owed on 1st Mortgage: _________________ Current Interest Rate on 1st: ___________________ Fixed or Adjustable? ______________ Monthly Payment: ________________________ Second Mortgage Balance (if any): _____________________ Current Employer: ___________________________________ Years with Current Employer: _________________________ Yearly Income: __________________________ How would you describe your credit? Excellent/Good/Fair/Poor Best Time to Contact You: ____________________________ Type of Loan Desired: ________________________________ Loan Amount Desired: _____________________ Email Address: ______________________________________ From ftp-wg-owner@hethmon.com Fri Jun 9 02:26:37 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA06211 for ; Fri, 9 Jun 2000 02:26:36 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000609012607-62802-7 ; Fri, 09 Jun 2000 01:26:07 -0500 Received: from wombat.cs.rmit.edu.au (wombat.cs.rmit.edu.au [131.170.24.41]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000609012543-41109-7 ; Fri, 09 Jun 2000 01:26:04 -0500 Received: from goanna.cs.rmit.edu.au (lukem@goanna.cs.rmit.edu.au [131.170.24.40]) by wombat.cs.rmit.edu.au (8.9.3/8.9.3/cshub) with ESMTP id QAA20965; Fri, 9 Jun 2000 16:22:08 +1000 (EST) Message-Id: <200006090622.QAA20965@wombat.cs.rmit.edu.au> Date: Fri, 9 Jun 2000 01:26:05 -0500 X-OldDate: Fri, 09 Jun 2000 16:22:08 +1000 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Luke Mewburn To: ftp-wg@hethmon.com Subject: Ftp-WG: minor example error in draft-ietf-ftpext-mlst-10 ? Hi. I noticed that draft-ietf-ftpext-mlst-10 states the following: 7.9.1. OPTS MLST Response The "response-message" from [6] to a successful OPTS MLST command has the following syntax. mlst-opt-resp = "MLST OPTS" [ SP 1*( factname ";" ) ] This defines the "response-message" as used in the "opts-good" message in RFC2389 [6]. ... 7.9.2. Examples C> Feat S> 211- Features supported S> MLST Type*;Size;Modify*;Perm;Unique;UNIX.mode;UNIX.chgd;X.hidden; S> 211 End C> OptS Mlst Type;UNIX.mode;Perm; S> 201 MLST OPTS Type;Perm;UNIX.mode; I've had a look at RFC2389, and in section 4. The OPTS Command, it says: opts-good = "200" SP response-message CRLF Are the examples wrong in prefixing the response from OPTS with `201' instead of `200'? (Or is my copy of RFC2389 wrong? :-) Luke. From ftp-wg-owner@hethmon.com Fri Jun 9 15:02:27 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17448 for ; Fri, 9 Jun 2000 15:02:26 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000609140121-11576-7 ; Fri, 09 Jun 2000 14:01:21 -0500 Received: from havoc.entera.com (havoc.entera.com [206.165.109.130]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000609140117-51464-6 ; Fri, 09 Jun 2000 14:01:17 -0500 Received: from entera.com ([208.48.116.174]) by havoc.entera.com (Post.Office MTA v3.5.3 release 223 ID# 0-61971U200L100S0V35) with ESMTP id com for ; Fri, 9 Jun 2000 11:55:52 -0700 Message-ID: <39413E4B.67F8EAB@entera.com> Organization: Entera, Inc. X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.7 i86pc) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 9 Jun 2000 14:01:19 -0500 X-OldDate: Fri, 09 Jun 2000 11:58:19 -0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Stephen Head To: ftp-wg@hethmon.com Subject: Ftp-WG: d10: "path name" vs. "pathname"? Content-Transfer-Encoding: 7bit In d-10 there appears "path name" and "pathname". For more convenient skimming/grepping, it may be beneficial to adopt a consistent rendering of the term, and use one or the other throughout. (A very superficial skim of 959 turns up only "pathname", for comparison.) A similar comment could be made about "file name" and "filename" as used. Section 2. Document Conventions seems to imply that "pathname" is the correct rendering of the term, but (it may be just me) it is not clear to me that there is an intent between the distinction or if it is just an oversight of some kind. Section 2. Document Conventions does not have "filename", nor does RFC959. RFC 959 does have "file name". Section 2.2.2 Wildcarding first uses the term "filename". There are both "TVFS file name" (6.1) and "TVFS filename" (6.1). I am not sure but this appears to indicate the terms "file name" and "filename" are intended to mean the same thing (?). If so, perhaps the same is true for "path name" and "pathname". But I am concerned about making such assumptions. (For comparison, RFC959 and d-10 appear to use "directory name" consistently.) On a similar note, I could not find a definition of a "working directory" anywhere, though it is used in both RFC959 and d-10. [A reader might be tempted into making the assumption that TVFS implies support for PWD (print working directory) (but I am told it does not).] Are all these distinctions intentional? It is a concern to try to figure out just how much or how little to read into the distinctions, especially when set next to the intentionally vague terms like NVFS. (If I am off in the weeds, sorry. If there are some valid concerns in this, I would be happy to try to help provide something constructive to address the concerns.) -s From ftp-wg-owner@hethmon.com Fri Jun 9 15:08:17 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17547 for ; Fri, 9 Jun 2000 15:08:16 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000609140831-5490-12 ; Fri, 09 Jun 2000 14:08:31 -0500 Received: from magritte.felspar.net (195.13.68.90 [195.13.68.90]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000609140828-43565-11 ; Fri, 09 Jun 2000 14:08:28 -0500 Received: by magritte.felspar.net with Internet Mail Service (5.5.2448.0) id ; Fri, 9 Jun 2000 19:53:48 +0100 Message-ID: <61A45D5AE74BD311A76D00A0D21B18723672FD@magritte.felspar.net> MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD244.0B9F5640" Date: Fri, 9 Jun 2000 14:08:29 -0500 X-OldDate: Fri, 9 Jun 2000 19:53:48 +0100 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Dave Cridland To: "'FTPEXT Working Group'" Subject: Ftp-WG: thoughts on ftp extensions and caching This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFD244.0B9F5640 Content-Type: text/plain; charset="iso-8859-1" I apologise profusely for my stupidity, as promised. :-) -----Original Message----- From: Alun Jones [mailto:alun@texis.com] Sent: Wednesday, June 07, 2000 6:03 PM To: FTPEXT Working Group Subject: Ftp-WG: thoughts on ftp extensions and caching At 10:43 AM 6/7/2000, you wrote: >When I read through the MLST draft trying to see whether I was allowed to >drop a fact when the client had requested it, I couldn't find anything >about it, either way, which suggested to me in my pedantically crippled >way that it wasn't allowed - or at least, that it probably shouldn't be >done from a server PoV, but should be allowed for in a client context. It >may well be just me, though, I don't know if anyone else reads it that >way. Of course, I might have missed the critical phrase while skimming >through it, at which point I apologise profusely for my stupidity. :-) End of 7.2: "Facts should be provided in each output line only if they both provide relevant information about the file named on the same line, and they are in the set requested by the user-PI. There is no requirement that the same set of facts be provided for each file, or that the facts presented occur in the same order for each file." Sounds like facts should _not_ be provided if they don't provide relevant information about the named file. Perhaps a clarification is in order, but I read it as meaning that a nonsensical fact should not be displayed (e.g. a size on a directory). Note also that section 7.7.3 shows an MSLD example that does _not_ include the Size fact for its directory entries. 7.7.9 includes a similar example that shows dropping of the size facts on directories, but since that looks like my server, I'd say I'm biased :-) >Standardising the responses from RETR is surely fine if it only becomes >active with a OPT setting? Or not? > >Having said that, Alun Jones makes very good sense indeed in his point >(2). Perhaps all that is needed is a mention of this de-facto standard in >more detail. If so, all the better. > >I do still like the concept of the transfer-size fact being defined, though. The way I've written my server is that the expression "(N bytes)" is output, and is essentially the only item in parentheses on that line (unless you want to try and break your FTP client by creating a file called "(-1 bytes)" and retrieve that :-)) That appears to be standard - here's an example: 150 "/uplap.bat" file ready to send (437 bytes) in ASCII mode Any transfer where I do not have a ready count of the bytes to send, gets no byte count - nothing in the parentheses. If you're going to document that, I'd suggest also documenting that the byte count given may, for all sorts of reasons, not be the same as the number of bytes sent. Let's say, for instance, you're transferring a text file that logs every FTP response message sent - that will _never_ be the same size as reported! [I also have customers who use my server to 'stream' video files of 13GB or so - when they first appear on the server to be downloaded, they'll look like they only have a few KB in them, so the value given at the start of the transfer is _greatly_ different from the number of bytes transferred - by several orders of magnitude!] Alun. ~~~~ P.S. On the subject of changing file sizes, it's clear that many people are unaware of file stores that use paged or record structures on files, where many pages/records are "empty" and hence not stored. A file could occupy a few bytes on disk, but when transferred in File / Image mode, be several megabytes (mostly zero, or whatever the fill character is defined to be). -- Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find us 1602 Harvest Moon Place | at web site http://www.wftpd.com or email Cedar Park TX 78613 | us at alun@texis.com. VISA / MC accepted. Fax +1 (512) 378 3246 | NT-based ISPs, be sure to read details of Phone +1 (512) 378 3246 | WFTPD Pro, NT service version - $100. ------_=_NextPart_001_01BFD244.0B9F5640 Content-Type: text/html; charset="iso-8859-1" RE: Ftp-WG: thoughts on ftp extensions and caching

I apologise profusely for my stupidity, as promised. :-)

-----Original Message-----
From: Alun Jones [mailto:alun@texis.com]
Sent: Wednesday, June 07, 2000 6:03 PM
To: FTPEXT Working Group
Subject: Ftp-WG: thoughts on ftp extensions and caching


At 10:43 AM 6/7/2000, you wrote:
>When I read through the MLST draft trying to see whether I was allowed to
>drop a fact when the client had requested it, I couldn't find anything
>about it, either way, which suggested to me in my pedantically crippled
>way that it wasn't allowed - or at least, that it probably shouldn't be
>done from a server PoV, but should be allowed for in a client context. It
>may well be just me, though, I don't know if anyone else reads it that
>way. Of course, I might have missed the critical phrase while skimming
>through it, at which point I apologise profusely for my stupidity. :-)

End of 7.2:

   "Facts
    should be provided in each output line only if they both provide
    relevant information about the file named on the same line, and they
    are in the set requested by the user-PI.  There is no requirement
    that the same set of facts be provided for each file, or that the
    facts presented occur in the same order for each file."

Sounds like facts should _not_ be provided if they don't provide relevant
information about the named file.  Perhaps a clarification is in order, but
I read it as meaning that a nonsensical fact should not be displayed (e.g.
a size on a directory).  Note also that section 7.7.3 shows an MSLD example
that does _not_ include the Size fact for its directory entries.  7.7.9
includes a similar example that shows dropping of the size facts on
directories, but since that looks like my server, I'd say I'm biased :-)

>Standardising the responses from RETR is surely fine if it only becomes
>active with a OPT setting? Or not?
>
>Having said that, Alun Jones makes very good sense indeed in his point
>(2). Perhaps all that is needed is a mention of this de-facto standard in
>more detail. If so, all the better.
>
>I do still like the concept of the transfer-size fact being defined, though.

The way I've written my server is that the expression "(N bytes)" is
output, and is essentially the only item in parentheses on that line
(unless you want to try and break your FTP client by creating a file called
"(-1 bytes)" and retrieve that :-))  That appears to be standard - here's
an example:

150 "/uplap.bat" file ready to send (437 bytes) in ASCII mode

Any transfer where I do not have a ready count of the bytes to send, gets
no byte count - nothing in the parentheses.

If you're going to document that, I'd suggest also documenting that the
byte count given may, for all sorts of reasons, not be the same as the
number of bytes sent.  Let's say, for instance, you're transferring a text
file that logs every FTP response message sent - that will _never_ be the
same size as reported!  [I also have customers who use my server to
'stream' video files of 13GB or so - when they first appear on the server
to be downloaded, they'll look like they only have a few KB in them, so the
value given at the start of the transfer is _greatly_ different from the
number of bytes transferred - by several orders of magnitude!]

Alun.
~~~~
P.S.  On the subject of changing file sizes, it's clear that many people
are unaware of file stores that use paged or record structures on files,
where many pages/records are "empty" and hence not stored.  A file could
occupy a few bytes on disk, but when transferred in File / Image mode, be
several megabytes (mostly zero, or whatever the fill character is defined
to be).
--
Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find us
1602 Harvest Moon Place | at web site http://www.wftpd.com or email
Cedar Park TX 78613     | us at alun@texis.com.  VISA / MC accepted.
Fax +1 (512) 378 3246   | NT-based ISPs, be sure to read details of
Phone +1 (512) 378 3246 | WFTPD Pro, NT service version - $100.


------_=_NextPart_001_01BFD244.0B9F5640-- From ftp-wg-owner@hethmon.com Sat Jun 10 10:27:58 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08805 for ; Sat, 10 Jun 2000 10:27:57 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000610092839-48607-7 ; Sat, 10 Jun 2000 09:28:39 -0500 Received: from ie. (210.119.229.124 [210.119.229.124]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000610092835-45942-6 ; Sat, 10 Jun 2000 09:28:35 -0500 Received: from S854jpA0R by ie. (SMI-8.6/SMI-SVR4) id XAA19247; Sat, 10 Jun 2000 23:07:10 +0900 Message-ID: <9939Kr1Fs0e9km> Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Date: Sat, 10 Jun 2000 09:28:37 -0500 X-OldDate: 10 Jun 00 9:22:35 AM Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Jt13retwf@public1.bta.net.cn Subject: Ftp-WG: Re: your decision Look, we don't want to waste your time...or ours You must be determined to earn a bare minimum of $10,000 in the next 30 - 45 days and to develop a net worth of over 1 Million Dollars Cash in the next 24-36 months. My mission is to help other people develop their life long dreams. Part of what I'm looking for are those people who are committed to that BIG of a picture and are not afraid to work for it. We can help you: REGARDLESS OF YOUR CURRENT AGE OR YOUR DEBT LOAD! NOT MLM or FRANCHISE Don't bother to call unless you are serious. Learn the Facts CALL 1-800-231-5349 (24 hrs) $10,000 IN 30 - 45 DAYS RETIREMENT IN 3-5 YEARS *************************************************************************************** All REMOVE requests AUTOMATICALLY honored upon receipt. mailto:lori1969@altavistausa.com?subject=Remove PLEASE understand that any effort to disrupt, close or block this REMOVE account can only result in difficulties for others wanting to be removed from our mailing list as it will be impossible to take anyone off the list if the remove instruction can not be received. **************************************************************************************** From ftp-wg-owner@hethmon.com Sat Jun 10 10:50:21 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08918 for ; Sat, 10 Jun 2000 10:50:20 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000610095044-57748-7 ; Sat, 10 Jun 2000 09:50:45 -0500 Received: from mail.deor.com (194.177.107.164 [194.177.107.164]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000610095038-29724-7 ; Sat, 10 Jun 2000 09:50:39 -0500 Received: from mail.fides.it (c03-127.006.popsite.net [216.126.136.127]) by mail.deor.com (Netscape Mail Server v2.01) with SMTP id AAE114; Sat, 10 Jun 2000 16:43:45 +0200 Message-ID: <1845774512543369.194874851628@unab.cl> Date: Sat, 10 Jun 2000 09:50:41 -0500 X-OldDate: Sat, 10 Jun 00 10:37:35 EST Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: arsylane@hotmail.com To: subscriber@unab.cl Subject: Ftp-WG: otcbb: HIVC gets a "Strong Buy" rating - (HIV Vaccine) Attn Subscriber: HIV-VAC, Inc. (OTC BB: HIVC) gets a "Strong Buy" rating HIV-VAC, Inc. (OTC BB: HIVC) Recent Price: $0.34 52 Week Range: $0.125 to $3.125 Outstanding shares: 31.9 million Float: 7.93 million Market Cap: $10.8 million 2001 Projected Revenues: $4.375 million 2001 Projected Pre-Tax Loss: 1.468 millin 2002 Projected Revenues: $142.8 million 2002 Projected Pre-Tax Income: $63.1 million Stock Rating: Strong Buy (Speculative) 12-24 Month Target Price: $4 to $5 INVESTMENT SUMMARY - We rate HIV-VAC (OTCBB: HIVC) a "strong buy" for speculative investors. HIVC is developing an HIV Intracellular Vaccine that provides the necessary antibodies to combat HIV. It has the potential to moderate disease progression in already infected persons as well as protect again initial infection. The total number of people in the HIV high-risk category comprises over 25% of the world's population. These are people who have not yet contracted HIV, but will most likely do so during their lifetime. This represents a potential marketplace of over 1.5 billion. Add in the millions of HIV sufferers who could benefit from treatment for their existing infection, the total potential marketplace for this vaccine is staggering. - The United Nations estimates that there are currently 33.6 million people infected worldwide with the AIDS virus. The disease is spreading at a rate of 10,000 people each day. It is estimated that the number of people infected with the AIDS virus by the end of the year 2000 will be 55 million. HIV/AIDS caused 2.6 million deaths worldwide in 1999 and over 16.3 million cumulative number of deaths due to HIV/AIDS has been recorded, according to World Health Organization. This is an epidemic of global proportions. No country or economic group is immune. AIDS is threatening to undo decades of development in Africa, and continues to menace Russia, Eastern Europe and Asia. AIDS is already the fourth-leading cause of death in the world and the leading cause in sub-Saharan Africa. Convinced that the global spread of AIDS is reaching catastrophic dimensions, the Clinton administration has formally designated the disease for the first time as a threat to U.S. national security that could topple foreign governments, touch off ethnic wars and undo decades of work in building free-market democracies abroad. - Current treatment consists of a standard drug "cocktails" that cost over $10,000 per year, per person. To treat all America's HIV patients with this regimen would cost over $5.4 billion. This treatment does not cure the disease, if only holds it in check. Lives hand in the balance, and America's health care system alone expects to add in excess of $6.2 billion in lifetime treatment costs alone to the nation's health care bill. Sales of anti-HIV drugs increased to more than $3 billion last year and could reach $6 billion in coming years worldwide. - Last March, the stock has been traded as high as $3.25 per share. Since then, the stock has been substantially declining to the current level. The stock has been traded extremely active in the past tens days. A rumor is circulating now about a possible buyout by a major pharmaceutical company. Also, we are hearing some major developments are in the works and should be announced shortly. If one of them or both areare true, the stock could be well over $5 before investors could grab any shares. SAFE HARBOR FOR FORWARD-LOOKING STATEMENTS: Except for historical information contained herein, the statements on this website and newsletter are forward-looking statements that are made pursuant to the safe harbor provisions of the Private Securities Reform Act of 1995. Forward-looking statements involve known and unknown risks and uncertainties, which may cause a company's actual results in the future periods to differ materially from forecasted results. These risks and uncertainties include, among other things, product price volatility, product demand, market competition and risk inherent in the companies operations. You can identify these statements by the fact that they do not relate strictly to historical or current facts. They use words such as ``anticipate,'' ``estimate,'' ``expect,'' ``project,'' ``intend,'' ``plan,'' "feel", "think", "hear", "guess", ``believe,'' and other words and terms of similar meaning in connection with any discussion of future operating or financial performance. As always do your own due diligence before making any investments of any kind. We are a small independent group of investors who obviously feel very positive about this stock and do own 20k shares long. From ftp-wg-owner@hethmon.com Sat Jun 10 17:54:05 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10959 for ; Sat, 10 Jun 2000 17:54:04 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000610165438-13564-11 ; Sat, 10 Jun 2000 16:54:38 -0500 Received: from havoc.entera.com (havoc.entera.com [206.165.109.130]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000610165434-53384-7 ; Sat, 10 Jun 2000 16:54:34 -0500 Received: from entera.com ([208.48.116.174]) by havoc.entera.com (Post.Office MTA v3.5.3 release 223 ID# 0-61971U200L100S0V35) with ESMTP id com for ; Sat, 10 Jun 2000 14:49:15 -0700 Message-ID: <3942B86D.A0F3880F@entera.com> Organization: Entera, Inc. X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.7 i86pc) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 10 Jun 2000 16:54:35 -0500 X-OldDate: Sat, 10 Jun 2000 14:51:41 -0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Stephen Head To: ftp-wg@hethmon.com Subject: Ftp-WG: thoughts on MLSx/PWD/TVFS for caching/restart Content-Transfer-Encoding: 7bit For caching, it appears it would be useful to get a relatively unique handle for the object being retrieved (in as passive a manner as possible). One can't reliably use the 150 response because it is not standard and there are variants and parsing problems. One can't reliably use MLSx because the pathname returned is not guaranteed fully qualified, by definition and (so I am told) intent, due to need to operate on various filesystems that don't have fully qualified pathnames. One can't use Unique because it is not guaranteed to be unique across connections by definition and intent (and I would not try to force it to be for implementation reasons). One can't use a concatenation of PWD and MSLx outputs because PWD is not guaranteed to work, not guaranteed unique, has failure modes (eg a concurrent rmdir ..) and even might (421 response allowed in RFC 959) cause the connection to drop. So it appears one can't just issue a PWD and check the results- such a proxy cache server trick would get it disconnected from certain origin servers and unduly interrupt the sequence of requests being made from the destination client. The sum of all that is as far as I can tell it appears to be that one can only reliably cache if there is at a maximum one CWD issued to the origin server per control channel connection with a NVFS or TVFS. Given my understanding of the intent of the TVFS to model Un*x-like tree structured filesystems, this seems to be an unfortunate side-effect of the definitions of the features in d-10. To the concern that it only hurts the potential for caching, it could be said that it also appears to miss an opportunity for permitting restarts across a prematurely closed control connection. I could think of two potential ways to address this problem. One is to add a FEAT command which permits the server to advertise in advance support for the PWD command. This would avoid the 421 response danger described above. I've appended something for this at the end of this message. Alternatively a relatively small additional tweak of the MLSx command could be made in the case of advertised TVFS support could be made, changing the reporting of the fully qualified pathname from SHOULD to MUST. This would still permit NVFS-not-TVFS server systems to squeak by without the need for reporting fully qualified pathnames when they choose (or are unable to comply), because SHOULD would still be operable in those cases. If my understanding of TVFS is correct, servers which have TVFSs will always have fully qualified pathnames available to report for MLSx. Of these alternatives, I like the second better because it seems (?) more in the spirit of the extensions and it also doesn't involve the extra network load of sending PWDs and getting the responses in association with sending MLSxs. If the second alternative were chosen, it is conceivable that one could envision a later, separate extension to the current d-10 which could fix this, but in the meantime there would be created a specification hole in which some (a small few?) systems implementing d-10 TVFS and MLSx would take SHOULD as advisory only and not report fully qualified pathnames in MLSx. That would seem to create at least the possibility of a compatibility problem for extending MLSx. If so, as far as I can tell, it would involve new variants of MLSx, which could be viewed as very distasteful and possibly messy enough that it would be unlikely to be approved, at least along those lines. Adding a FEAT for PWD would still seem to be viable at a later date, but still seems less elegant as well as somewhat more overhead everywhere. To the concern that I am being selfish by bringing up ftp caching by myself, it is not my intent to be selfish here. At least as of a couple of weeks ago (the last time I checked), Inktomi advertised ftp caching on their feature list on their web site http://www.inktomi.com/). More caching companies seem to be appearing on the radar seemingly almost every month, and Inktomi is the current leader in at least the non-streaming caching arena. I think a little credit might be extended to the area of caching given that it is a relatively new and growing area. (I expect that most caching would, in practice, occur for TVFS-style ftp server filesystems.) I also think that a test of a really robust standard is one which can withstand the test of time (and exposure to unexpected new uses) best by adhering to good fundamental principles. So I think it is at least conceivable that allowing this issue might benefit more than just one application. There is also a downside risk (perhaps illustrated in part by Squid, etc.) to attempt to use tempting but not necessarily correct shortcuts to address the issue in lieu of a standard. I am finding it very time consuming to look though old wg discussions (and I haven't at least yet had a chance to write a script to get it all in batch and then read it) so if this duplicates any old discussion that was made and dispensed with in some manner (or if I have missed something, always possible :-) my apologies. -s PS, FWIW A quick and dirty FEAT response for PWD: X.X. FEAT response for PWD When replying to the FEAT command [6], an FTP server process that supports the PWD command MUST include a line containing the single word "PWD". This MAY be sent in upper or lower case, or a mixture of both (it is case insensitive) but SHOULD be transmitted in upper case only. That is, the response SHOULD be C> Feat S> 211- S> ... S> PWD S> ... S> 211 End The ellipses indicate place holders where other features may be included, and are not required. The one space indentation of the feature lines is mandatory [X]. From ftp-wg-owner@hethmon.com Sun Jun 11 11:26:36 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07843 for ; Sun, 11 Jun 2000 11:26:35 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000611102627-4124-8 ; Sun, 11 Jun 2000 10:26:27 -0500 Received: from ACFcluster.NYU.EDU (AXP2.ACF.NYU.EDU [128.122.250.38]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000611102624-50116-7 ; Sun, 11 Jun 2000 10:26:25 -0500 Received: from ACFcluster.NYU.EDU by ACFcluster.NYU.EDU (PMDF V5.2-33 #33915) id <01JQH3LBEJ8G8WZXPU@ACFcluster.NYU.EDU> for ftp-wg@hethmon.com; Sun, 11 Jun 2000 11:22:51 EDT In-reply-to: "Your message dated Sat, 10 Jun 2000 16:54:35 -0500" <3942B86D.A0F3880F@entera.com> Message-id: <01JQH3WAZI808WZXPU@ACFcluster.NYU.EDU> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Date: Sun, 11 Jun 2000 10:26:25 -0500 X-OldDate: Sun, 11 Jun 2000 11:21:46 -0400 (EDT) Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Stephen Tihor To: FTPEXT Working Group Subject: Ftp-WG: thoughts on MLSx/PWD/TVFS for caching/restart If the concern is to get a stable, unique, fully qualified pathname supported it seems more logical to just define an additional fact that would be that and identify the conditions udnerwhich it might exist and suggest strategies for an implemetnation to follow when it does not. From ftp-wg-owner@hethmon.com Sun Jun 11 18:33:08 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10013 for ; Sun, 11 Jun 2000 18:33:08 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000611172714-20512-7 ; Sun, 11 Jun 2000 17:27:14 -0500 Received: from havoc.entera.com (havoc.entera.com [206.165.109.130]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000611172709-61298-6 ; Sun, 11 Jun 2000 17:27:10 -0500 Received: from entera.com ([208.48.116.174]) by havoc.entera.com (Post.Office MTA v3.5.3 release 223 ID# 0-61971U200L100S0V35) with ESMTP id com for ; Sun, 11 Jun 2000 15:21:52 -0700 Message-ID: <3944118E.9A549690@entera.com> Organization: Entera, Inc. X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.7 i86pc) X-Accept-Language: en MIME-Version: 1.0 References: <01JQH3WAZI808WZXPU@ACFcluster.NYU.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 11 Jun 2000 17:27:11 -0500 X-OldDate: Sun, 11 Jun 2000 15:24:14 -0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Stephen Head To: FTPEXT Working Group Subject: Ftp-WG: thoughts on MLSx/PWD/TVFS for caching/restart Content-Transfer-Encoding: 7bit I believe the PWD fact notion is for practical purposes as close to what you describe as one could reasonably hope for. I do believe however that adopting either alternative iff TVFS fact supported seemed at least to me very much in keeping with the spirit of the original TVFS intent (speaking as a reader only and not as an author of the TVFS concept). I don't know what is so illogical about either alternative. Actually, they don't preclude each other (and implementing both would give clients more flexibility for getting info). -s Stephen Tihor wrote: > If the concern is to get a stable, unique, fully qualified pathname supported > it seems more logical to just define an additional fact that would be that and > identify the conditions udnerwhich it might exist and suggest strategies > for an implemetnation to follow when it does not. From ftp-wg-owner@hethmon.com Sun Jun 11 20:57:40 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA10560 for ; Sun, 11 Jun 2000 20:57:39 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000611195811-62763-7 ; Sun, 11 Jun 2000 19:58:11 -0500 Received: from havoc.entera.com (havoc.entera.com [206.165.109.130]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000611195807-51270-6 ; Sun, 11 Jun 2000 19:58:07 -0500 Received: from entera.com ([208.48.116.174]) by havoc.entera.com (Post.Office MTA v3.5.3 release 223 ID# 0-61971U200L100S0V35) with ESMTP id com for ; Sun, 11 Jun 2000 17:52:49 -0700 Message-ID: <394434EF.C818D8DE@entera.com> Organization: Entera, Inc. X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.7 i86pc) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 11 Jun 2000 19:58:08 -0500 X-OldDate: Sun, 11 Jun 2000 17:55:11 -0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Stephen Head To: ftp-wg@hethmon.com Subject: Ftp-WG: error code 550 questions Content-Transfer-Encoding: 7bit In d-10, it says in 2.4 that error-code can be either 4xx or 5xx, where xx are 2 digits, as in RFC959. I am wondering if Sections 3 and 4 have formal error subsections (3.2 and 4.2) but MLSx (Section 7) does not. In particular, 3.2 and 4.2 allow a 550 response for object not found. However, I could not find an analogous 550 response in Section 7 and wonder if this is intentional or not. When I issue a PWD on Solaris x86 5.7 on a working directory that has been deleted after entering via the ftp server, I get a 550 (at least once with some apparent gibberish for the directory name echo, presumeably indicating a problem with that ftpd implementation). CWD on Solaris to a non-existent directory also yields 550. Should MLSx be consistent with PWD, CWD, SIZE and MDTM in this regard? Apologies if already dealt with or I missed something. -s From ftp-wg-owner@hethmon.com Mon Jun 12 12:25:49 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05938 for ; Mon, 12 Jun 2000 12:25:48 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000612111755-1978-15 ; Mon, 12 Jun 2000 11:17:55 -0500 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000612111750-41306-12 ; Mon, 12 Jun 2000 11:17:52 -0500 Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id QA11053; Tue, 13 Jun 2000 02:14:13 +1000 (from kre@munnari.OZ.AU) In-Reply-To: Your message of "Fri, 09 Jun 2000 16:22:08 +1000." <200006090622.QAA20965@wombat.cs.rmit.edu.au> Message-Id: <19947.960826452@mundamutti.cs.mu.OZ.AU> Date: Mon, 12 Jun 2000 11:17:53 -0500 X-OldDate: Tue, 13 Jun 2000 02:14:12 +1000 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Robert Elz To: ftp-wg@hethmon.com Subject: Ftp-WG: Re: minor example error in draft-ietf-ftpext-mlst-10 ? Date: Fri, 09 Jun 2000 16:22:08 +1000 From: Luke Mewburn Message-ID: <200006090622.QAA20965@wombat.cs.rmit.edu.au> | I noticed that draft-ietf-ftpext-mlst-10 states the following: [...] | Are the examples wrong in prefixing the response from OPTS with `201' | instead of `200'? The examples were taken directly from some bozo's ftp server. Clearly that idiot didn't read the doc (even if it was the same idiot as the final editor of the doc...) That server has now been fixed, and the examples in the doc updated, I will submit a -11 draft with those changes. I'll also look at specifying the error codes from MLSx, it is hard to believe that those got forgotten, but it seems like they did... kre From ftp-wg-owner@hethmon.com Mon Jun 12 13:27:16 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07398 for ; Mon, 12 Jun 2000 13:27:15 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000612122605-39596-7 ; Mon, 12 Jun 2000 12:26:05 -0500 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000612122600-38870-6 ; Mon, 12 Jun 2000 12:26:01 -0500 Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id RA29125; Tue, 13 Jun 2000 03:22:24 +1000 (from kre@munnari.OZ.AU) In-Reply-To: Your message of "Fri, 09 Jun 2000 14:01:19 EST." <39413E4B.67F8EAB@entera.com> Message-Id: <21560.960830543@mundamutti.cs.mu.OZ.AU> Date: Mon, 12 Jun 2000 12:26:03 -0500 X-OldDate: Tue, 13 Jun 2000 03:22:23 +1000 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Robert Elz To: FTPEXT Working Group Subject: Ftp-WG: d10: "path name" vs. "pathname"? Date: Fri, 9 Jun 2000 14:01:19 -0500 From: Stephen Head Message-ID: <39413E4B.67F8EAB@entera.com> | In d-10 there appears "path name" and "pathname". [...] | A similar | comment could be made about "file name" and "filename" | as used. I wouldn't have bothered with a new draft just for this, but as a new one is coming anyway... I have switched to "pathname" and "file name" throughout, which is consistent with the usage in rfc959. Any objections, speak now... kre ps: I have also fixed a couple of truly embarrasing typos... From ftp-wg-owner@hethmon.com Mon Jun 12 14:50:34 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08890 for ; Mon, 12 Jun 2000 14:50:33 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000612134801-19888-7 ; Mon, 12 Jun 2000 13:48:01 -0500 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000612134756-28482-6 ; Mon, 12 Jun 2000 13:47:58 -0500 Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id SA00019; Tue, 13 Jun 2000 04:44:20 +1000 (from kre@munnari.OZ.AU) Message-Id: <22959.960835460@mundamutti.cs.mu.OZ.AU> Date: Mon, 12 Jun 2000 13:47:59 -0500 X-OldDate: Tue, 13 Jun 2000 04:44:20 +1000 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Robert Elz To: ftp-wg@hethmon.com Subject: Ftp-WG: Coming changes in -11 mlst draft Aside from the changes mentioned in the last 2 messages (pathname, file name, 200 response to OPTS MLST, and typos fixed), I have made two changes of substance to the -11 draft (which I will submit after you all have had a chance to review the following two pargraphs). First, I wanted to make it clear that clients should not send "." (or anything else) when they want to reference the current directory in a MLSD (or even MLST) command. That's an attempt to force a fix for some unix clients that require the user to enter "dir . |more" or "dir . /tmp/foo", and then send "LIST ." to the server, or there is no way to send a listing of the current directory to a process, or file. The text I added for that was (in the marked lines, the unmarked ones were there already) ... If no argument is given then MLSD must return a listing of the contents of the current working directory, and MLST must return a listing giving information about the current working directory itself. For these purposes, the contents of a directory are whatever file names (not pathnames) the server-PI will allow to be referenced when the current working directory is the directory named, and which the server-PI desires to reveal to the user-PI. Note that omitting | the argument is the only defined way to obtain a listing of the | current directory, unless a pathname that represents the directory | happens to be known. In particular, there is no defined shorthand | name for the current directory. This does not prohibit any | particular server-PI implementing such a shorthand. | And second, some more information on error responses to MLSx. This entire paragraph is new... 7.2.1. Error responses to MLSx commands Many of the 4xy and 5xy responses defined in section 4.2 of RFC959 [3] are possible in response to the MLST and MLSD commands. In particular, syntax errors can generate 500 or 501 replies. Giving a pathname that is not a directory as the argument to a MLSD command generates a 501 reply. Giving a name which does not exist, or for which access permission (to obtain directory information as requested) is not granted will elicit a 550 reply. Other replies (530, 553, 503, 504, and any of the 4xy replies) are also possible in appropriate circumstances. If anyone has any comments on either of those, please send them soon, so I can submit the updated drafts soon. If anyone believes that we need a new WG last call because of any of these changes, also speak up. The default (depending upon what our chair thinks of course) is likely to be no new WG last call. kre From ftp-wg-owner@hethmon.com Mon Jun 12 15:07:27 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09098 for ; Mon, 12 Jun 2000 15:07:26 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000612140556-18592-8 ; Mon, 12 Jun 2000 14:05:57 -0500 Received: from havoc.entera.com (havoc.entera.com [206.165.109.130]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000612140553-59398-6 ; Mon, 12 Jun 2000 14:05:53 -0500 Received: from entera.com ([208.48.116.174]) by havoc.entera.com (Post.Office MTA v3.5.3 release 223 ID# 0-61971U200L100S0V35) with ESMTP id com for ; Mon, 12 Jun 2000 12:00:36 -0700 Message-ID: <394533E1.CAEBEA98@entera.com> Organization: Entera, Inc. X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.7 i86pc) X-Accept-Language: en MIME-Version: 1.0 References: <22959.960835460@mundamutti.cs.mu.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 12 Jun 2000 14:05:54 -0500 X-OldDate: Mon, 12 Jun 2000 12:02:57 -0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Stephen Head To: FTPEXT Working Group Subject: Ftp-WG: Coming changes in -11 mlst draft Content-Transfer-Encoding: 7bit Robert Elz wrote: > 7.2.1. Error responses to MLSx commands > > Many of the 4xy and 5xy responses defined in section 4.2 of RFC959 > [3] are possible in response to the MLST and MLSD commands. In > particular, syntax errors can generate 500 or 501 replies. Giving a > pathname that is not a directory as the argument to a MLSD command > generates a 501 reply. Giving a name which does not exist, or for > which access permission (to obtain directory information as > requested) is not granted will elicit a 550 reply. Other replies > (530, 553, 503, 504, and any of the 4xy replies) are also possible in > appropriate circumstances. Just for consistency's sake, it could be considered to mention explicitly the possibility of encountering (some or all) 4xy responses throughout (that is, in 3.2 and 4.2 as well). -s From ftp-wg-owner@hethmon.com Mon Jun 12 15:14:17 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09285 for ; Mon, 12 Jun 2000 15:14:16 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000612140909-32954-17 ; Mon, 12 Jun 2000 14:09:09 -0500 Received: from anarchy.io.com (anarchy.io.com [199.170.88.101]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000612140906-50854-16 ; Mon, 12 Jun 2000 14:09:06 -0500 Received: from magnus.io.com (aus-as4-165.io.com [208.2.105.165]) by anarchy.io.com (8.9.3/8.9.3) with ESMTP id OAA07084 for ; Mon, 12 Jun 2000 14:05:33 -0500 Message-Id: <4.3.2.7.2.20000612135124.00b3a820@mail.io.com> X-Sender: alun@mail.io.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 In-Reply-To: <3942B86D.A0F3880F@entera.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Date: Mon, 12 Jun 2000 14:09:07 -0500 X-OldDate: Mon, 12 Jun 2000 14:03:39 -0500 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Alun Jones To: FTPEXT Working Group Subject: Ftp-WG: thoughts on MLSx/PWD/TVFS for caching/restart At 04:54 PM 6/10/2000, you wrote: >reasons). One can't use a concatenation of PWD and MSLx >outputs because PWD is not guaranteed to work, not guaranteed >unique, has failure modes (eg a concurrent rmdir ..) and even might >(421 response allowed in RFC 959) cause the connection to drop. In this case, the 421 indicates that the connection is being dropped - it does not mean that the PWD _caused_ the connection to drop. In exactly the circumstances that would generally elicit a 421 error from PWD, a 421 error would generally arrive from FEAT, or even NOOP. _All_ commands should be allowed to produce the response "421", because it is an indication of an event occurring _before_ the command has been received. >So it appears one can't just issue a PWD and check the results- >such a proxy cache server trick would get it disconnected from >certain origin servers and unduly interrupt the sequence of requests >being made from the destination client. Nope. Wrong. PWD / MLST should work for most caching; the only issue comes when two differently named directories are actually the same - by links, mount points, etc. In such a situation, any method you care to choose has its own weaknesses, and cannot be relied upon; hence, a proxy must make some "best effort" to find those directories that are the same, and to suck up the doubly cached files otherwise. >The sum of all that is as far as I can tell it appears to be that one >can only reliably cache if there is at a maximum one CWD issued >to the origin server per control channel connection with a NVFS or >TVFS. In TVFS, you have the concept of a root. Otherwise, there is not necessarily any way to get back to the same directory you logged in to, once you have ventured outside of it. Practically speaking, there almost always is some way to do this, but it is not part of the FTP protocol for good reason - covering every possible way to change directories would make FTP into a protocol that has to morph once more every time a new file system was introduced. [We can not assume that a hierarchical tree is the be-all and end-all of directory structures] >To the concern that it only hurts the potential for caching, it could >be said that it also appears to miss an opportunity for permitting >restarts >across a prematurely closed control connection. No - the CWD sequence and/or RETR that you used to originally fetch the file will still be valid to _reach_ that file, and an MLST / SIZE / DATE combination can give you a good enough idea that the file _is_ the one you thought it was. >One is to add a FEAT command which permits the server to >advertise in advance support for the PWD command. This would >avoid the 421 response danger described above. I've appended >something for this at the end of this message. That's somewhat ludicrous. As I mentioned earlier, the same effect (usually a timeout, or system administrator-forced disconnect) that would "cause PWD" to respond 421 would "cause FEAT" to respond 421 also. The reason being that the 421, and the disconnection, are generally actioned _before_ the server receives (and usually, before the client sends) the command in question. You don't avoid the (non-existent) problem that you claim to be providing a fix for. If you have a reason other than this to provide a FEAT response for PWD, then please suggest it, but avoidance of a possible 421 is not appropriate reason. The 421 is _not_ provided as a valid response in the case of "we don't support PWD". >Alternatively a relatively small additional tweak of the MLSx command >could be made in the case of advertised TVFS support could be made, >changing the reporting of the fully qualified pathname from SHOULD >to MUST. This would still permit NVFS-not-TVFS server systems >to squeak by without the need for reporting fully qualified pathnames >when they choose (or are unable to comply), because SHOULD >would still be operable in those cases. If my understanding >of TVFS is correct, servers which have TVFSs will always have fully >qualified pathnames available to report for MLSx. And the client _will_ be able to tell the difference between a fully qualified pathname (which begins with '/') and one that is not. Just my two ha'p'orth. Alun. ~~~~ -- Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find us 1602 Harvest Moon Place | at web site http://www.wftpd.com or email Cedar Park TX 78613 | us at alun@texis.com. VISA / MC accepted. Fax +1 (512) 378 3246 | NT-based ISPs, be sure to read details of Phone +1 (512) 378 3246 | WFTPD Pro, NT service version - $100. From ftp-wg-owner@hethmon.com Mon Jun 12 15:30:56 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09482 for ; Mon, 12 Jun 2000 15:30:55 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000612143058-3289-7 ; Mon, 12 Jun 2000 14:30:58 -0500 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000612143054-20550-6 ; Mon, 12 Jun 2000 14:30:55 -0500 Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id TA07602; Tue, 13 Jun 2000 05:27:19 +1000 (from kre@munnari.OZ.AU) In-Reply-To: Your message of "Mon, 12 Jun 2000 14:09:07 EST." <4.3.2.7.2.20000612135124.00b3a820@mail.io.com> Message-Id: <23432.960838038@mundamutti.cs.mu.OZ.AU> Date: Mon, 12 Jun 2000 14:30:56 -0500 X-OldDate: Tue, 13 Jun 2000 05:27:18 +1000 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Robert Elz To: FTPEXT Working Group Subject: Ftp-WG: thoughts on MLSx/PWD/TVFS for caching/restart I agree with Alun here. I'm also not sure what problem exactly is being solved. Maybe it is just because I have no clue at all what is involved with caching of FTP files, but ... I don't think that perfect caching of FTP is possible. That is, fetching data to the cache once (and assuming the cache doesn't discard he data, and it remains stable on the server) never fetching it again. The FTP model just doesn't guarantee the kind of information to make that possible. On the other hand, adequate caching is I think possible (or ought to be). That means, being able to detect that a file being requested is in the cache, and returning the copy (when appropriate). But without necessarily preventing the same file being in the cache (under different names) more than once (ie: sometimes it may be fetched when had the cache but known, it could have found a local copy already). I don't think I'd support any changes to FTP that are aimed towards making perfect caching (as I have defined it) work, as I don't think it is possible anyway without discarding too many other aims of FTP. On the other hand, if there's something lacking in FTP that would prevent adequate caching from working, then that perhaps should be fixed. It is also probably worth noting that while lots of things aren't guaranteed from FTP servers, most of them will be found in practice. That means that a cache (or any client) can't rely on evernything being nice and clean, it can optimise itself for that case, and do better when "nice" servers are encountered (which is likely to be most of the time). So, for example, while a client (cache perhaps) might not be able to guarantee it can find a full path name for a file, most of the time it will be able to do that. That ought mean that an adequate cache ought to be able to approach being a perfect cache if it is willing to do the work - for most servers on the net, yet still function for the other oddball cases. kre From ftp-wg-owner@hethmon.com Mon Jun 12 16:22:50 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10520 for ; Mon, 12 Jun 2000 16:22:50 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000612151842-21584-8 ; Mon, 12 Jun 2000 15:18:42 -0500 Received: from anarchy.io.com (anarchy.io.com [199.170.88.101]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000612151838-59398-7 ; Mon, 12 Jun 2000 15:18:38 -0500 Received: from magnus.io.com (aus-as4-165.io.com [208.2.105.165]) by anarchy.io.com (8.9.3/8.9.3) with ESMTP id PAA11702 for ; Mon, 12 Jun 2000 15:15:06 -0500 Message-Id: <4.3.2.7.2.20000612150132.00c012c0@mail.io.com> X-Sender: alun@mail.io.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 In-Reply-To: <23432.960838038@mundamutti.cs.mu.OZ.AU> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Date: Mon, 12 Jun 2000 15:18:40 -0500 X-OldDate: Mon, 12 Jun 2000 15:13:54 -0500 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Alun Jones To: FTPEXT Working Group Subject: Ftp-WG: thoughts on MLSx/PWD/TVFS for caching/restart At 02:30 PM 6/12/2000, you wrote: >I'm also not sure what problem exactly is being solved. Maybe it >is just because I have no clue at all what is involved with caching >of FTP files, but ... > >I don't think that perfect caching of FTP is possible. That is, >fetching data to the cache once (and assuming the cache doesn't discard >he data, and it remains stable on the server) never fetching it again. >The FTP model just doesn't guarantee the kind of information to make >that possible. I presume also that, if such a specific need does require specific additions that have not yet made themselves clear to those of us that have been supporting servers "in the wild" for several years (and I'm one of the junior lot in this case), a new RFC draft might be the better place to include that, rather than in this (already about a decade or so overdue) draft. As I see it, the main purpose of the MLST draft has so far been to document the de-facto standard commands of SIZE and MDTM, the de-facto operation of REST for stream-mode communication, and finally the introduction of MLST and MLSD to avoid what is by _far_ the most common complaint of FTP authors - both server and client - that is of no reliable, machine-parsable listing format. In that sense, we are to some extent taking FTP back from an effective stance of "everyone does it like one or other variety of Unix" to a stance of "everyone does it like this". It just so happens that the TVFS mimics Unix (although that's mostly immaterial), but MLST does not. Some of the things that are asked for in this cache topic - specifically enough information to determine that "these are not the files you are looking for" - are not by any means absolute. Others - the file storage size, and the file transfer size - would require a byte-by-byte read through the file prior to transfer, and the locking of that file both prior to, and during, the transfer. Unfortunately, the cache is going to have to _guess_ some of this information - that makes the cache's job somewhat harder. However, the alternative would be to either make the FTP server's job a whole lot harder, or potentially reduce the number of operating systems that could support an FTP server. Alun. ~~~~ -- Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find us 1602 Harvest Moon Place | at web site http://www.wftpd.com or email Cedar Park TX 78613 | us at alun@texis.com. VISA / MC accepted. Fax +1 (512) 378 3246 | NT-based ISPs, be sure to read details of Phone +1 (512) 378 3246 | WFTPD Pro, NT service version - $100. From ftp-wg-owner@hethmon.com Mon Jun 12 16:41:44 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10806 for ; Mon, 12 Jun 2000 16:41:42 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000612153642-19983-8 ; Mon, 12 Jun 2000 15:36:42 -0500 Received: from havoc.entera.com (havoc.entera.com [206.165.109.130]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000612153638-60783-7 ; Mon, 12 Jun 2000 15:36:38 -0500 Received: from entera.com ([208.48.116.174]) by havoc.entera.com (Post.Office MTA v3.5.3 release 223 ID# 0-61971U200L100S0V35) with ESMTP id com for ; Mon, 12 Jun 2000 13:31:20 -0700 Message-ID: <39454923.58FE775B@entera.com> Organization: Entera, Inc. X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.7 i86pc) X-Accept-Language: en MIME-Version: 1.0 References: <23432.960838038@mundamutti.cs.mu.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 12 Jun 2000 15:36:40 -0500 X-OldDate: Mon, 12 Jun 2000 13:33:39 -0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Stephen Head To: FTPEXT Working Group Subject: Ftp-WG: thoughts on MLSx/PWD/TVFS for caching/restart Content-Transfer-Encoding: 7bit Robert Elz wrote: > I agree with Alun here. I'll concede most if not all of Alun's points and thank him for his patient response. > I'm also not sure what problem exactly is being solved. Maybe it > is just because I have no clue at all what is involved with caching > of FTP files, but ... > > I don't think that perfect caching of FTP is possible. That is, > fetching data to the cache once (and assuming the cache doesn't discard > he data, and it remains stable on the server) never fetching it again. > The FTP model just doesn't guarantee the kind of information to make > that possible. I also agree that perfect caching of FTP is not likely to be possible. Still, there appears to be some market demand for it, regardless (I did not drive it). The expectation is apparently to use a number of admin-configurable, heuristic methods including size, mod date, and timeouts (ugh). > On the other hand, adequate caching is I think possible (or ought to be). > That means, being able to detect that a file being requested is in the > cache, and returning the copy (when appropriate). But without > necessarily preventing the same file being in the cache (under different > names) more than once (ie: sometimes it may be fetched when had the > cache but known, it could have found a local copy already). Yes, by getting pwd-type info I am attempting to make at least a reasonable effort to avoid that. I don't expect to succeed every time, just make a reasonable try. The consequences of multiple copies for the same thing could be a crowding out of other valid info in the cache(s), especially if the copies are relatively large. > I don't think I'd support any changes to FTP that are aimed towards > making perfect caching (as I have defined it) work, as I don't think > it is possible anyway without discarding too many other aims of FTP. > > On the other hand, if there's something lacking in FTP that would > prevent adequate caching from working, then that perhaps should be > fixed. The principle I started out trying to follow was to maximize transparency at both ends: if the destination client did command C1, a maximal-transparency proxy server would try its best to pass the request along as command C1 (maybe varying the data connection address). That didn't work too well with the wg. While RETR can be replaced with a PASV-MLST-PWD-RETR sequence, the more additional commands that are added by the proxy server, the more overhead and alternative code paths are exercised on the origin server, and the more downside risk and performance hit. Minimizing the size of the substitute list of commands minimizes that risk and hit. Proxy server supporters would presumeably want to strive to avoid the situation in which the original destination client command issued to the origin server works, but the substitute proxy server generated command stream for some possibly bogus reason beyond the proxy server's direct control does not work, even though it should by the standard. At this point my situation has been whittled down, as far as I can tell, to either accepting PWD in addition to MLSx, or the following. One could return to the idea supplied by Stephen Tihor (thanks, and sorry for misunderstanding it, I think, the first time around) of a pwdir type fact for MLSx. The advantage of such a fact would be that it would appear to avoid the need for MLSx-PWD cliches being issued ad nauseum by proxy servers. It may be in keeping with the philosophy of MLSx in the first place of rolling a bunch of info into one response (?). It would be nice if TVFSs were required to send such a type if requested in MLSx responses, so the proxy servers would not be forced to try to issue PWDs anyway in case the MLSx responses didn't contain a fully qualified path. From a proxy cache server perspective, part of the "state" of a file is where it is located/locatable on a [TVFS] server. OTOH, a pwdir type fact *is* yet another feature and depending on how the WG is run it *may* delay final elevation of the draft to a standard (dunno, depending on how you all run things). In hindsight, I regret that I did not arrive at this right away but my mind often gets numb going over all the hoary ftp stuff. I think those are the tradeoffs and I can respect the consensus of the group either way. I can try to come up with something for a pwdir just in case there is considerable vocal wg approval (?) expressed towards the notion of going forward on that. At any rate, plowing through this stuff rigorously from the perspective I took apparently helped reveal a couple of minor omissions that are nevertheless nice to fix for a full standard, I guess. So not a complete waste... :-) -s From ftp-wg-owner@hethmon.com Mon Jun 12 17:07:19 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11304 for ; Mon, 12 Jun 2000 17:07:19 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000612160625-46307-7 ; Mon, 12 Jun 2000 16:06:25 -0500 Received: from havoc.entera.com (havoc.entera.com [206.165.109.130]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000612160621-1682-6 ; Mon, 12 Jun 2000 16:06:21 -0500 Received: from entera.com ([208.48.116.174]) by havoc.entera.com (Post.Office MTA v3.5.3 release 223 ID# 0-61971U200L100S0V35) with ESMTP id com for ; Mon, 12 Jun 2000 14:01:04 -0700 Message-ID: <3945501C.DD425823@entera.com> Organization: Entera, Inc. X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.7 i86pc) X-Accept-Language: en MIME-Version: 1.0 References: <4.3.2.7.2.20000612150132.00c012c0@mail.io.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 12 Jun 2000 16:06:22 -0500 X-OldDate: Mon, 12 Jun 2000 14:03:24 -0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Stephen Head To: FTPEXT Working Group Subject: Ftp-WG: thoughts on MLSx/PWD/TVFS for caching/restart Content-Transfer-Encoding: 7bit Alun Jones wrote: ... > As I see it, the main purpose of the MLST draft has so far been to document > the de-facto standard commands of SIZE and MDTM, the de-facto operation of > REST for stream-mode communication, and finally the introduction of MLST > and MLSD to avoid what is by _far_ the most common complaint of FTP authors > - both server and client - that is of no reliable, machine-parsable listing > format. In that sense, we are to some extent taking FTP back from an > effective stance of "everyone does it like one or other variety of Unix" to > a stance of "everyone does it like this". It just so happens that the TVFS > mimics Unix (although that's mostly immaterial), but MLST does not. Yes, I recognize the frustration. However, I did think that draft 10 is a great improvement over draft 7 (the previous draft I was looking at before I was asked to help put out some fires somewhere else) for universal purposes. I would have suggested something along the lines of MLSx myself if I had been continuously engaged in the issue (though if I were writing it, with some kind of notion of pwd included for TVFS case). > Some of the things that are asked for in this cache topic - specifically > enough information to determine that "these are not the files you are > looking for" - are not by any means absolute. Others - the file storage > size, and the file transfer size - would require a byte-by-byte read > through the file prior to transfer, and the locking of that file both prior > to, and during, the transfer. Unfortunately, the cache is going to have to > _guess_ some of this information - that makes the cache's job somewhat > harder. Just to say that I gave up on any refinements to size, for the good reasons expressed by you and others in previous responses. The fully qualified pathname admittedly should, as a workaround for systems that support it, usually be available through a separate PWD command as a workaround for a lack of some pwdir-style fact as I noted in a previous response. Presumeably, for those systems that have it, it is mostly a matter of reporting it in contrast to some huge computational load. (If for any significant server situations not the case, then perhaps not such a good idea despite what caching servers would prefer.) -s From ftp-wg-owner@hethmon.com Mon Jun 12 18:30:33 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12405 for ; Mon, 12 Jun 2000 18:30:32 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000612173022-28852-14 ; Mon, 12 Jun 2000 17:30:22 -0500 Received: from alpha.ipswitch.com (216.104.149.100 [216.104.149.100]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000612173019-6907-13 ; Mon, 12 Jun 2000 17:30:20 -0500 Received: from wks222 [216.104.149.222] by alpha.ipswitch.com (SMTPD32-6.03) id A6E315B90092; Mon, 12 Jun 2000 18:40:35 -0400 Message-ID: <002001bfd4bd$1da5dd20$de9568d8@wks222.augusta.ipswitch.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal In-Reply-To: <22959.960835460@mundamutti.cs.mu.OZ.AU> Date: Mon, 12 Jun 2000 17:30:20 -0500 X-OldDate: Mon, 12 Jun 2000 18:25:29 -0400 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: "Mark Symons" To: "FTPEXT Working Group" Subject: Ftp-WG: Coming changes in -11 mlst draft Content-Transfer-Encoding: 7bit > ...I have made two changes of substance to > the -11 draft (which I will submit after you all have > had a chance to review the following two pargraphs). > First, I wanted to make it clear that clients should > not send "." (or anything else) when they want to > reference the current directory in a MLSD (or even > MLST) command. OK. But note that section 7.7.6. (A different server) gives an example of "MLSD ." as if it were perfectly valid. Is that right? Mark Symons Ipswitch, Inc Augusta, GA From ftp-wg-owner@hethmon.com Mon Jun 12 23:16:03 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA16717 for ; Mon, 12 Jun 2000 23:16:02 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000612221041-11679-8 ; Mon, 12 Jun 2000 22:10:41 -0500 Received: from server1.pickingpack.it (212.210.15.14 [212.210.15.14]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000612221036-43281-6 ; Mon, 12 Jun 2000 22:10:36 -0500 Received: from webcom.com (ppp-207-104-18-14.snfc21.pacbell.net [207.104.18.14]) by server1.pickingpack.it (Post.Office MTA v3.5.2 release 221 ID# 506-57591U200L2S100V35) with SMTP id it; Mon, 12 Jun 2000 21:32:18 +0200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Message-Id: <6y0n7botpquubnj45q.4mdi3l0mtr3w@webcom.com> Date: Mon, 12 Jun 2000 22:10:39 -0500 X-OldDate: Thu, 11 Nov 1999 12:46:59 -0800 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: uemailing@posts.com To: distlist@bigfoot.com Subject: Ftp-WG: ADV - 10 MILLION ADDRESSES! Content-Transfer-Encoding: 8BIT 10 MILLION EMAIL ADDRESSES FOR ONLY $99 You want to make some money? we can put you in touch with over 10 million people at virtually no cost. Can you make one cent from each of theses names? If you can you have a profit of over $250,000.00 That's right, we have 10 Million Fresh email addresses that we will sell for only $99. These are all fresh addresses with no duplications. They are all sorted and ready to be mailed. That is the best deal anywhere today! Imagine selling a product for only $5 and getting only a 1/10% response. That's $1,350,000 in your pocket !!! Don't believe it? People are making that kind of money right now by doing the same thing, that is why you get so much email from people selling you their product....it works! we will even include, a FREE demo copy of the worlds leading BULK MAILING SOFTARE! These 10 Million email addresses and software are yours to keep, so you can use them over and over and they come on 1 CD. This offer is not for everyone. If you can not see just how excellent the risk / reward ratio in this offer is then there is nothing we can do for you. To make money you must stop dreaming and TAKE ACTION. **************************************** 10 MILLION email addresses on CD These name are all in text files ready to mail!!! (includes bulk mailing sotware) $99.00 ************************************************************* VISA/MC ONLY STEP 1: Print out the below ORDER FORM STEP 2: Type or Print your order information into the form STEP 3: FAX Your order to us. FAX TO: 415-704-3071 (Order with confidence. This is a secure fax area. Only our qualified sales team will have access to your order information) ORDER FORM(Print clearly with DARK pen) ************************************************************************************************ Name: ________________________________ Address: ________________________________ * *BILLING ADDRESS ONLY City, State, ZIP: ________________________________ Country: ______________ (International Orders) Phone Number: ______________ (In case we can't make out your order) METHOD OF PAYMENT- CREDIT CARD ONLY [ ]Visa [ ]MasterCard Credit Card #: __________________________________ Exp Date: _______________ Signature: ____________________________ (Required) E-Mail Address: ____________________________ *(PRINT CLEARLY!!) ************************************************************************************************ WE WILL BILL 99.00 to your account plus the following shipping costs SHIPPING COST OF 4.85 FIRST CLASS MAIL INTERNATIOMAL ORDERS ADD 25.00 U.S. DOLLARS ALL INFORMATION NECESSARY FOR YOU TO SUCCESSFULLY MAIL, QUICKLY, PROPERLY, LEGALLY PROVIDED WITH ORDER Copyright 2000 All rights reserved From ftp-wg-owner@hethmon.com Tue Jun 13 02:45:56 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA29962 for ; Tue, 13 Jun 2000 02:45:55 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000613014544-9102-7 ; Tue, 13 Jun 2000 01:45:44 -0500 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000613014539-47230-6 ; Tue, 13 Jun 2000 01:45:40 -0500 Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id GA07654; Tue, 13 Jun 2000 16:42:02 +1000 (from kre@munnari.OZ.AU) In-Reply-To: Your message of "Mon, 12 Jun 2000 17:30:20 EST." <002001bfd4bd$1da5dd20$de9568d8@wks222.augusta.ipswitch.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <1135.960878521@mundamutti.cs.mu.OZ.AU> Date: Tue, 13 Jun 2000 01:45:42 -0500 X-OldDate: Tue, 13 Jun 2000 16:42:01 +1000 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Robert Elz To: FTPEXT Working Group Subject: Ftp-WG: Coming changes in -11 mlst draft Date: Mon, 12 Jun 2000 17:30:20 -0500 From: "Mark Symons" Message-ID: <002001bfd4bd$1da5dd20$de9568d8@wks222.augusta.ipswitch.com> | But note that section 7.7.6. (A different server) gives an example of | "MLSD ." as if it were perfectly valid. Is that right? There's nothing invalid about it, "." is a perfectly valid TVFS pathname (or just NVFS file name), that the server might support, or might not support. However there's nothing anywhere (other than perhaps MLST output with type=cdir facts included) that suggests that "." is any different a pathname than "random-file" (or "random-dir" in this case). Either might refer to any kind of object whatever. If people feel that the "." in the example is in any way suggesting that '.' is something that servers should support to refer to the current directory (because this doc says so, as distinct from because the market demands it because some clients essentially require it), then I will change the example (in this case, I'd probably even cheat, and just erase the "." from the command passed...). Or I could add some more explanatory text after that example making it clear that "." is working here due to the whim of the server implementor, not because it is required, or even expected, to work. What do people think? kre From ftp-wg-owner@hethmon.com Tue Jun 13 06:25:27 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA01697 for ; Tue, 13 Jun 2000 06:25:26 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000613052206-6629-8 ; Tue, 13 Jun 2000 05:22:06 -0500 Received: from magritte.felspar.net (195.13.68.90 [195.13.68.90]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000613052202-44709-6 ; Tue, 13 Jun 2000 05:22:02 -0500 Received: by magritte.felspar.net with Internet Mail Service (5.5.2448.0) id ; Tue, 13 Jun 2000 11:21:58 +0100 Message-ID: <61A45D5AE74BD311A76D00A0D21B1872367303@magritte.felspar.net> ? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD521.347DE760" Date: Tue, 13 Jun 2000 05:22:02 -0500 X-OldDate: Tue, 13 Jun 2000 11:21:57 +0100 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Dave Cridland To: "'FTPEXT Working Group'" Subject: Ftp-WG: Re: minor example error in draft-ietf-ftpext-mlst-10 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFD521.347DE760 Content-Type: text/plain; charset="iso-8859-1" If we're (sorry, you're) going over the draft again, is it worthwhile adding a 'transfer-size' or similar fact, which defines the number of octets of the file which would be transmitted using the current mode, type, etc? With an additional note specifying that the Server-PI may choose not to present this for certain files under certain download parameters, on the basis that this may present a significant cost to the server? (Should the Client really want to know, it can try using SIZE, which may have a higher cost threshold.) In particular, I suggest that should a Server-PI generate the 'transfer-size' fact for a file (when asked for that fact) then it must return the size in response to the SIZE command where SIZE is supported at all, however, the reverse is not true - SIZE may return a value for a file which was not presented with the transfer-size in the MLS* response containing it. No doubt someone else has already asked for this, but on the basis that I haven't checked *all* my mail yet, and haven't found anything about it, I thought it might prove worthwhile to mention it. -----Original Message----- From: Robert Elz [mailto:kre@munnari.OZ.AU] Sent: Monday, June 12, 2000 5:18 PM To: ftp-wg@hethmon.com Subject: Ftp-WG: Re: minor example error in draft-ietf-ftpext-mlst-10 ? Date: Fri, 09 Jun 2000 16:22:08 +1000 From: Luke Mewburn Message-ID: <200006090622.QAA20965@wombat.cs.rmit.edu.au> | I noticed that draft-ietf-ftpext-mlst-10 states the following: [...] | Are the examples wrong in prefixing the response from OPTS with `201' | instead of `200'? The examples were taken directly from some bozo's ftp server. Clearly that idiot didn't read the doc (even if it was the same idiot as the final editor of the doc...) That server has now been fixed, and the examples in the doc updated, I will submit a -11 draft with those changes. I'll also look at specifying the error codes from MLSx, it is hard to believe that those got forgotten, but it seems like they did... kre ------_=_NextPart_001_01BFD521.347DE760 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Ftp-WG: Re: minor example error in draft-ietf-ftpext-mlst-10 = ?

If we're (sorry, you're) going over the draft again, = is it worthwhile adding a 'transfer-size' or similar fact, which = defines the number of octets of the file which would be transmitted = using the current mode, type, etc?

With an additional note specifying that the Server-PI = may choose not to present this for certain files under certain download = parameters, on the basis that this may present a significant cost to = the server? (Should the Client really want to know, it can try using = SIZE, which may have a higher cost threshold.)

In particular, I suggest that should a Server-PI = generate the 'transfer-size' fact for a file (when asked for that fact) = then it must return the size in response to the SIZE command where SIZE = is supported at all, however, the reverse is not true - SIZE may return = a value for a file which was not presented with the transfer-size in = the MLS* response containing it.

No doubt someone else has already asked for this, but = on the basis that I haven't checked *all* my mail yet, and haven't = found anything about it, I thought it might prove worthwhile to mention = it.

-----Original Message-----
From: Robert Elz [mailto:kre@munnari.OZ.AU]
Sent: Monday, June 12, 2000 5:18 PM
To: ftp-wg@hethmon.com
Subject: Ftp-WG: Re: minor example error in = draft-ietf-ftpext-mlst-10 ?


    = Date:        Fri, 09 Jun 2000 = 16:22:08 +1000
    = From:        Luke Mewburn = <lukem@cs.rmit.edu.au>
    Message-ID:  = <200006090622.QAA20965@wombat.cs.rmit.edu.au>

  | I noticed that draft-ietf-ftpext-mlst-10 = states the following:
[...]
  | Are the examples wrong in prefixing the = response from OPTS with `201'
  | instead of `200'?

The examples were taken directly from some bozo's ftp = server.  Clearly
that idiot didn't read the doc (even if it was the = same idiot as the final
editor of the doc...)

That server has now been fixed, and the examples in = the doc updated,
I will submit a -11 draft with those changes.

I'll also look at specifying the error codes from = MLSx, it is hard to
believe that those got forgotten, but it seems like = they did...

kre

------_=_NextPart_001_01BFD521.347DE760-- From ftp-wg-owner@hethmon.com Tue Jun 13 07:11:23 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA02865 for ; Tue, 13 Jun 2000 07:11:22 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000613061119-15924-7 ; Tue, 13 Jun 2000 06:11:19 -0500 Received: from anarchy.io.com (anarchy.io.com [199.170.88.101]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000613061114-53795-6 ; Tue, 13 Jun 2000 06:11:14 -0500 Received: from magnus.io.com (aus-as3-176.io.com [208.2.106.176]) by anarchy.io.com (8.9.3/8.9.3) with ESMTP id GAA13211 for ; Tue, 13 Jun 2000 06:07:42 -0500 Message-Id: <4.3.2.7.2.20000613060112.00c9c100@mail.io.com> X-Sender: alun@mail.io.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 In-Reply-To: <61A45D5AE74BD311A76D00A0D21B1872367303@magritte.felspar.ne t> ? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Date: Tue, 13 Jun 2000 06:11:16 -0500 X-OldDate: Tue, 13 Jun 2000 06:06:14 -0500 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Alun Jones To: FTPEXT Working Group Subject: Ftp-WG: Re: minor example error in draft-ietf-ftpext-mlst-10 At 05:22 AM 6/13/2000, you wrote: >If we're (sorry, you're) going over the draft again, is it worthwhile >adding a 'transfer-size' or similar fact, which defines the number of >octets of the file which would be transmitted using the current mode, >type, etc? > >With an additional note specifying that the Server-PI may choose not to >present this for certain files under certain download parameters, on the >basis that this may present a significant cost to the server? (Should the >Client really want to know, it can try using SIZE, which may have a higher >cost threshold.) I believe the last time something like this was suggested, it was shot down as something that would considerably slow down MLSx responses. If you're in ASCII mode, for instance, you'd have to open _every_ file that was being listed, read _every_ byte in every file, and add up the number of line-feeds to add to the size of the stored file. In this case, should the client actually require this information, you're right, SIZE is the way to go. SIZE is documented as producing this data. The facts for MLSx should be kept to those that can reasonably be provided in a directory listing, without unreasonably delaying that listing - if for no other reason than that authors are going to be tempted to run FEAT, choose _all_ the MLST OPTS they can, and set them on prior to listing - after all, more information is _always_ good, right? :-) Particularly with options for MLSx being switched on and off by a separate command, I'd say that adding such a weighty fact to the list would be overburdening a server. Alun. ~~~~ -- Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find us 1602 Harvest Moon Place | at web site http://www.wftpd.com or email Cedar Park TX 78613 | us at alun@texis.com. VISA / MC accepted. Fax +1 (512) 378 3246 | NT-based ISPs, be sure to read details of Phone +1 (512) 378 3246 | WFTPD Pro, NT service version - $100. From ftp-wg-owner@hethmon.com Tue Jun 13 08:46:01 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05531 for ; Tue, 13 Jun 2000 08:45:59 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000613074540-18872-7 ; Tue, 13 Jun 2000 07:45:40 -0500 Received: from magritte.felspar.net (195.13.68.90 [195.13.68.90]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000613074505-58682-6 ; Tue, 13 Jun 2000 07:45:37 -0500 Received: by magritte.felspar.net with Internet Mail Service (5.5.2448.0) id ; Tue, 13 Jun 2000 13:44:52 +0100 Message-ID: <61A45D5AE74BD311A76D00A0D21B1872367309@magritte.felspar.net> MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD535.2A937F30" Date: Tue, 13 Jun 2000 07:45:38 -0500 X-OldDate: Tue, 13 Jun 2000 13:44:51 +0100 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Dave Cridland To: "'FTPEXT Working Group'" Subject: Ftp-WG: Re: minor example error in draft-ietf-ftpext-mlst-10 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFD535.2A937F30 Content-Type: text/plain; charset="iso-8859-1" Well, what I was suggesting is that for the UNIX/ASCII case, no files would appear with this fact (but clients would get something with SIZE), but for the UNIX/Binary case, all of them would. -----Original Message----- From: Alun Jones [mailto:alun@texis.com] Sent: Tuesday, June 13, 2000 12:11 PM To: FTPEXT Working Group Subject: Ftp-WG: Re: minor example error in draft-ietf-ftpext-mlst-10 At 05:22 AM 6/13/2000, you wrote: >If we're (sorry, you're) going over the draft again, is it worthwhile >adding a 'transfer-size' or similar fact, which defines the number of >octets of the file which would be transmitted using the current mode, >type, etc? > >With an additional note specifying that the Server-PI may choose not to >present this for certain files under certain download parameters, on the >basis that this may present a significant cost to the server? (Should the >Client really want to know, it can try using SIZE, which may have a higher >cost threshold.) I believe the last time something like this was suggested, it was shot down as something that would considerably slow down MLSx responses. If you're in ASCII mode, for instance, you'd have to open _every_ file that was being listed, read _every_ byte in every file, and add up the number of line-feeds to add to the size of the stored file. In this case, should the client actually require this information, you're right, SIZE is the way to go. SIZE is documented as producing this data. The facts for MLSx should be kept to those that can reasonably be provided in a directory listing, without unreasonably delaying that listing - if for no other reason than that authors are going to be tempted to run FEAT, choose _all_ the MLST OPTS they can, and set them on prior to listing - after all, more information is _always_ good, right? :-) Particularly with options for MLSx being switched on and off by a separate command, I'd say that adding such a weighty fact to the list would be overburdening a server. Alun. ~~~~ -- Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find us 1602 Harvest Moon Place | at web site http://www.wftpd.com or email Cedar Park TX 78613 | us at alun@texis.com. VISA / MC accepted. Fax +1 (512) 378 3246 | NT-based ISPs, be sure to read details of Phone +1 (512) 378 3246 | WFTPD Pro, NT service version - $100. ------_=_NextPart_001_01BFD535.2A937F30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Ftp-WG: Re: minor example error in = draft-ietf-ftpext-mlst-10

Well, what I was suggesting is that for the = UNIX/ASCII case, no files would appear with this fact (but clients = would get something with SIZE), but for the UNIX/Binary case, all of = them would.

-----Original Message-----
From: Alun Jones [mailto:alun@texis.com]
Sent: Tuesday, June 13, 2000 12:11 PM
To: FTPEXT Working Group
Subject: Ftp-WG: Re: minor example error in = draft-ietf-ftpext-mlst-10


At 05:22 AM 6/13/2000, you wrote:
>If we're (sorry, you're) going over the draft = again, is it worthwhile
>adding a 'transfer-size' or similar fact, which = defines the number of
>octets of the file which would be transmitted = using the current mode,
>type, etc?
>
>With an additional note specifying that the = Server-PI may choose not to
>present this for certain files under certain = download parameters, on the
>basis that this may present a significant cost = to the server? (Should the
>Client really want to know, it can try using = SIZE, which may have a higher
>cost threshold.)

I believe the last time something like this was = suggested, it was shot down
as something that would considerably slow down MLSx = responses.  If you're
in ASCII mode, for instance, you'd have to open = _every_ file that was being
listed, read _every_ byte in every file, and add up = the number of
line-feeds to add to the size of the stored = file.

In this case, should the client actually require this = information, you're
right, SIZE is the way to go.  SIZE is = documented as producing this data.

The facts for MLSx should be kept to those that can = reasonably be provided
in a directory listing, without unreasonably = delaying that listing - if for
no other reason than that authors are going to be = tempted to run FEAT,
choose _all_ the MLST OPTS they can, and set them on = prior to listing -
after all, more information is _always_ good, right? = :-)

Particularly with options for MLSx being switched on = and off by a separate
command, I'd say that adding such a weighty fact to = the list would be
overburdening a server.

Alun.
~~~~

--
Texas Imperial Software | Try WFTPD, the Windows FTP = Server. Find us
1602 Harvest Moon Place | at web site http://www.wftpd.com or email
Cedar Park TX 78613     | us at = alun@texis.com.  VISA / MC accepted.
Fax +1 (512) 378 3246   | NT-based ISPs, = be sure to read details of
Phone +1 (512) 378 3246 | WFTPD Pro, NT service = version - $100.

------_=_NextPart_001_01BFD535.2A937F30-- From ftp-wg-owner@hethmon.com Tue Jun 13 09:22:56 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07075 for ; Tue, 13 Jun 2000 09:22:55 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000613082214-10952-11 ; Tue, 13 Jun 2000 08:22:14 -0500 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000613082210-49077-7 ; Tue, 13 Jun 2000 08:22:11 -0500 Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id NA22420; Tue, 13 Jun 2000 23:18:24 +1000 (from kre@munnari.OZ.AU) In-Reply-To: Your message of "Tue, 13 Jun 2000 07:45:38 EST." <61A45D5AE74BD311A76D00A0D21B1872367309@magritte.felspar.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <4017.960902297@mundamutti.cs.mu.OZ.AU> Date: Tue, 13 Jun 2000 08:22:12 -0500 X-OldDate: Tue, 13 Jun 2000 23:18:17 +1000 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Robert Elz To: FTPEXT Working Group Subject: Ftp-WG: Re: minor example error in draft-ietf-ftpext-mlst-10 Date: Tue, 13 Jun 2000 07:45:38 -0500 From: Dave Cridland Message-ID: <61A45D5AE74BD311A76D00A0D21B1872367309@magritte.felspar.net> | Well, what I was suggesting is that for the UNIX/ASCII case, no files would | appear with this fact (but clients would get something with SIZE), but for | the UNIX/Binary case, all of them would. For the unix/binary case, size and transfer_size are going to be the same thing in any rational implementation. That's likely true in almost any implementation - if transfer_size is trivial to compute, its value will be used for the size fact, otherwise transfer_size would be omitted. If there really any gain there? Aside from restart (which is what the SIZE command was invented for) I have yet to see a plausible excuse for knowing the exact transfer size of a file ... being able to stick in wacky HTTP headers by http->ftp gateway type things (why do they exist anyway, browsers do ftp?) seems to me to be no rationale at all. That the size fact is an "approximate" size is something that would allow for a bunch of vagueness for sure, but that's really a quality of implementation issue - ftp servers that don't get the size fairly close most of the time (enough for deciding whether a file is too big, or too small to cache, or to use for progress bars) aren't going to be very popular I would have thought. kre From ftp-wg-owner@hethmon.com Tue Jun 13 10:10:21 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08885 for ; Tue, 13 Jun 2000 10:10:20 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000613090859-58129-16 ; Tue, 13 Jun 2000 09:08:59 -0500 Received: from frantic.bsdi.com (frantic.weston.BSDI.COM [209.173.194.254]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000613090851-29251-7 ; Tue, 13 Jun 2000 09:08:55 -0500 Received: (from dab@localhost) by frantic.bsdi.com (8.9.3/8.9.0) id JAA12938 for ftp-wg@hethmon.com; Tue, 13 Jun 2000 09:03:33 -0500 (CDT) Message-Id: <200006131403.JAA12938@frantic.bsdi.com> Date: Tue, 13 Jun 2000 09:08:56 -0500 X-OldDate: Tue, 13 Jun 2000 09:03:33 -0500 (CDT) Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: David Borman To: ftp-wg@hethmon.com Subject: Ftp-WG: Re: minor example error in draft-ietf-ftpext-mlst-10 > Date: Tue, 13 Jun 2000 08:22:12 -0500 > From: Robert Elz > To: FTPEXT Working Group > Subject: Ftp-WG: Re: minor example error in draft-ietf-ftpext-mlst-10 ... > Aside from restart (which is what the SIZE command was invented for) > I have yet to see a plausible excuse for knowing the exact transfer size > of a file ... being able to stick in wacky HTTP headers by http->ftp gateway > type things (why do they exist anyway, browsers do ftp?) seems to me to be > no rationale at all. Ok, I'll offer up another reasonable use of the SIZE command. At Cray Research, the file system under Unicos provided the ability to pre-allocate files. This had the advantage of allowing you to make sure you had enough free disk space for large files before starting the transfer, and it sped the actual writes to the file system, since all the data blocks were pre-allocated. So, before doing a GET, we'd issue a SIZE command and use that info for file pre-allocation. (And if I recall correctly, for small files the data was stored in the inode itself. Once you crossed the threshold, a data block was allocated and the data in the inode was copied out to the block. Doing a pre-allocation eliminated that extra copy, with the initial data going directly into the data block.) -David Borman, dab@bsdi.com From ftp-wg-owner@hethmon.com Tue Jun 13 10:11:48 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08946 for ; Tue, 13 Jun 2000 10:11:47 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000613091150-42789-11 ; Tue, 13 Jun 2000 09:11:50 -0500 Received: from anvil.murkworks.com (murkwork.pey.clarkson.edu [128.153.30.16]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000613091147-29231-8 ; Tue, 13 Jun 2000 09:11:48 -0500 Received: from coal.murkworks.com (coal.murkworks.com [128.153.43.3]) by anvil.murkworks.com (8.9.1/8.9.1) with ESMTP id KAA06644 for ; Tue, 13 Jun 2000 10:07:54 -0400 (EDT) Received: from GIMPELSTIMER/SpoolDir by coal.murkworks.com (Mercury 1.44); 13 Jun 00 10:13:59 -0400 Received: from SpoolDir by GIMPELSTIMER (Mercury 1.44); 13 Jun 00 10:13:57 -0400 Organization: MurkWorks, Incorporated. MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Message-ID: <3946094E.30663.22679A69@localhost> References: Your message of "Mon, 12 Jun 2000 17:30:20 EST." <002001bfd4bd$1da5dd20$de9568d8@wks222.augusta.ipswitch.com> In-reply-to: <1135.960878521@mundamutti.cs.mu.OZ.AU> X-mailer: Pegasus Mail for Win32 (v3.12c) Date: Tue, 13 Jun 2000 09:11:48 -0500 X-OldDate: Tue, 13 Jun 2000 10:13:51 -0400 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: "Brad Clements" To: FTPEXT Working Group Subject: Ftp-WG: Coming changes in -11 mlst draft Content-Transfer-Encoding: 7BIT On 13 Jun 2000, at 1:45, Robert Elz wrote: > If people feel that the "." in the example is in any way suggesting that > '.' is something that servers should support to refer to the current > directory (because this doc says so, as distinct from because the market > demands it because some clients essentially require it), then I will change > the example (in this case, I'd probably even cheat, and just erase the "." > from the command passed...). Or I could add some more explanatory text > after that example making it clear that "." is working here due to the whim > of the server implementor, not because it is required, or even expected, to > work. > > What do people think? Remove the '.' from the examples, it only serves to confuse. Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com AOL-IM: BKClements From ftp-wg-owner@hethmon.com Tue Jun 13 10:22:44 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09358 for ; Tue, 13 Jun 2000 10:22:43 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000613092257-9228-7 ; Tue, 13 Jun 2000 09:22:57 -0500 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000613092252-47337-6 ; Tue, 13 Jun 2000 09:22:53 -0500 Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id OA05936; Wed, 14 Jun 2000 00:19:15 +1000 (from kre@munnari.OZ.AU) In-Reply-To: Your message of "Tue, 13 Jun 2000 09:08:56 EST." <200006131403.JAA12938@frantic.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <4595.960905954@mundamutti.cs.mu.OZ.AU> Date: Tue, 13 Jun 2000 09:22:54 -0500 X-OldDate: Wed, 14 Jun 2000 00:19:14 +1000 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Robert Elz To: FTPEXT Working Group Subject: Ftp-WG: Re: minor example error in draft-ietf-ftpext-mlst-10 Date: Tue, 13 Jun 2000 09:08:56 -0500 From: David Borman Message-ID: <200006131403.JAA12938@frantic.bsdi.com> | Ok, I'll offer up another reasonable use of the SIZE command. For that, is the precise transfer size needed, or just a pretty good idea of roughly how big the file is going to be? In fact, unless the storage encodings were identical to transfer encodings for all transfer types, all SIZE would be giving you is an approximation to the storage size in any case. I can understand making use of SIZE to do that, when the alternative was attempting to parse the output from LIST, but it seems to be overkill to me, assuming some other way of obtaining a good size estimate is available. kre From ftp-wg-owner@hethmon.com Tue Jun 13 11:02:32 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10748 for ; Tue, 13 Jun 2000 11:02:31 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000613100158-20757-7 ; Tue, 13 Jun 2000 10:01:58 -0500 Received: from anarchy.io.com (anarchy.io.com [199.170.88.101]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000613100154-58597-6 ; Tue, 13 Jun 2000 10:01:54 -0500 Received: from magnus.io.com (aus-as4-150.io.com [208.2.105.150]) by anarchy.io.com (8.9.3/8.9.3) with ESMTP id JAA24241 for ; Tue, 13 Jun 2000 09:58:22 -0500 Message-Id: <4.3.2.7.2.20000613095353.00cb2b50@mail.io.com> X-Sender: alun@mail.io.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 In-Reply-To: <3946094E.30663.22679A69@localhost> References: <1135.960878521@mundamutti.cs.mu.OZ.AU> <002001bfd4bd$1da5dd20$de9568d8@wks222.augusta.ipswitch.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Date: Tue, 13 Jun 2000 10:01:56 -0500 X-OldDate: Tue, 13 Jun 2000 09:56:11 -0500 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Alun Jones To: FTPEXT Working Group Subject: Ftp-WG: Coming changes in -11 mlst draft At 09:11 AM 6/13/2000, you wrote: >On 13 Jun 2000, at 1:45, Robert Elz wrote: > > > If people feel that the "." in the example is in any way suggesting that > > '.' is something that servers should support to refer to the current > > directory (because this doc says so, as distinct from because the market > > demands it because some clients essentially require it), then I will change > > the example (in this case, I'd probably even cheat, and just erase the "." > > from the command passed...). Or I could add some more explanatory text > > after that example making it clear that "." is working here due to the whim > > of the server implementor, not because it is required, or even expected, to > > work. > > > > What do people think? > >Remove the '.' from the examples, it only serves to confuse. Agreed - examples should include as little as possible in the way of undocumented, system-dependent extensions to the standard. I'm already anticipating someone insisting that the unique fact needs to contain lots of uppercase 'A's, or start with a 'k'. :-) Alun. ~~~~ -- Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find us 1602 Harvest Moon Place | at web site http://www.wftpd.com or email Cedar Park TX 78613 | us at alun@texis.com. VISA / MC accepted. Fax +1 (512) 378 3246 | NT-based ISPs, be sure to read details of Phone +1 (512) 378 3246 | WFTPD Pro, NT service version - $100. From ftp-wg-owner@hethmon.com Tue Jun 13 11:10:49 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10933 for ; Tue, 13 Jun 2000 11:10:48 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000613100948-45029-11 ; Tue, 13 Jun 2000 10:09:48 -0500 Received: from frantic.bsdi.com (frantic.weston.BSDI.COM [209.173.194.254]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000613100945-29218-8 ; Tue, 13 Jun 2000 10:09:45 -0500 Received: (from dab@localhost) by frantic.bsdi.com (8.9.3/8.9.0) id KAA13089 for ftp-wg@hethmon.com; Tue, 13 Jun 2000 10:04:43 -0500 (CDT) Message-Id: <200006131504.KAA13089@frantic.bsdi.com> Date: Tue, 13 Jun 2000 10:09:46 -0500 X-OldDate: Tue, 13 Jun 2000 10:04:43 -0500 (CDT) Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: David Borman To: ftp-wg@hethmon.com Subject: Ftp-WG: Re: minor example error in draft-ietf-ftpext-mlst-10 > Date: Tue, 13 Jun 2000 09:22:54 -0500 > Reply-To: FTPEXT Working Group > From: Robert Elz > To: FTPEXT Working Group > Subject: Ftp-WG: Re: minor example error in draft-ietf-ftpext-mlst-10 > > Date: Tue, 13 Jun 2000 09:08:56 -0500 > From: David Borman > Message-ID: <200006131403.JAA12938@frantic.bsdi.com> > > | Ok, I'll offer up another reasonable use of the SIZE command. > > For that, is the precise transfer size needed, or just a pretty good idea > of roughly how big the file is going to be? The exact size wasn't needed. If I remember correctly, pre-allocation didn't change the size of the file, that happened when you actually wrote the data. So if the pre-allocation size was too small, it'd just start allocating more blocks when you got to the end. If it was too big, then you'd have some excess unused data blocks associated with the file. > In fact, unless the storage encodings were identical to transfer encodings > for all transfer types, all SIZE would be giving you is an approximation to > the storage size in any case. Well, for the interesting case (binary transfer), the storage encodings and transfer encodings are identical. If you have to do any massaging of the data, you lose big time. The Unicos FTP did a fair amount of work to really grease the skids for the file transfer. Besided doing file pre-allocation, reads and writes to the file system were double buffered and done asynchronously. Files were pre-allocated whenever possible. Socket buffers were bumped way up. With continuous I/O operations to both the network and the disk, FTP transfers pretty much went as fast as the slower of the network and the disk would allow (as opposed to the sum of the network and disk bottlenecks, as it is in the traditional 4.4 BSD implementation). > I can understand making use of SIZE to do that, when the alternative was > attempting to parse the output from LIST, but it seems to be overkill to > me, assuming some other way of obtaining a good size estimate is available. For binary transfers (again, the interesting case), the SIZE command was trivial (just a stat() call), and provides exactly what is needed. If you are doing an ASCII transfer, you've already shot yourself in the foot with regards to performance. -David Borman, dab@bsdi.com From ftp-wg-owner@hethmon.com Tue Jun 13 11:12:13 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11017 for ; Tue, 13 Jun 2000 11:12:12 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000613101258-29431-16 ; Tue, 13 Jun 2000 10:12:58 -0500 Received: from mail0.mailsender.net (mail0.mailsender.net [209.132.1.30]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000613101249-38941-6 ; Tue, 13 Jun 2000 10:12:55 -0500 Received: by mail0.mailsender.net (5.1.034) id 393FDA1F00112ACA for ftp-wg@hethmon.com; Tue, 13 Jun 2000 08:08:23 -0700 Message-ID: <39450F880000022D@mail0.mailsender.net> MIME-Version: 1.0 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 13 Jun 2000 10:12:56 -0500 X-OldDate: Tue, 13 Jun 2000 15:08:22 +0000 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: "Gorkem Ates" To: ftp-wg@hethmon.com Subject: Ftp-WG: Newcomers.. Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA11017 Hi Everybody, Me and some of my friends -who are also suppose to be in this list- are interested in extending the FTP protocol. I am the implementer of FTP++ ftp client project and have been working on the protocol for now 2 years. We have many ideas that I think would help the protocol of FTP a lot. Is this the right place for this purpose? Best Regards, Gorkem Gorkem Ates Fastream Technologies gorkem@fastream.com http://www.fastream.com Ultimate Metallica: http://acespace.simplenet.com/metallica From ftp-wg-owner@hethmon.com Tue Jun 13 11:17:48 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11263 for ; Tue, 13 Jun 2000 11:17:48 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000613101734-29078-18 ; Tue, 13 Jun 2000 10:17:34 -0500 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000613101730-45368-15 ; Tue, 13 Jun 2000 10:17:32 -0500 Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id PA21522; Wed, 14 Jun 2000 01:13:54 +1000 (from kre@munnari.OZ.AU) In-Reply-To: Your message of "Tue, 13 Jun 2000 10:01:56 EST." <4.3.2.7.2.20000613095353.00cb2b50@mail.io.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <5195.960909232@mundamutti.cs.mu.OZ.AU> Date: Tue, 13 Jun 2000 10:17:32 -0500 X-OldDate: Wed, 14 Jun 2000 01:13:52 +1000 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Robert Elz To: FTPEXT Working Group Subject: Ftp-WG: Coming changes in -11 mlst draft Date: Tue, 13 Jun 2000 10:01:56 -0500 From: Alun Jones Message-ID: <4.3.2.7.2.20000613095353.00cb2b50@mail.io.com> | >Remove the '.' from the examples, it only serves to confuse. | Agreed OK, I will fix them. I will need to remember how to check the servers for what response message thy return to "MLSD" instead of "MLSD ." though - I suspect mine is unchanged (you don't give a path, my server just pretends you said "." ...) But you're right, this stuff should remain as invisible as possible... kre From ftp-wg-owner@hethmon.com Tue Jun 13 12:00:01 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12967 for ; Tue, 13 Jun 2000 12:00:00 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000613110047-16437-16 ; Tue, 13 Jun 2000 11:00:48 -0500 Received: from ACFcluster.NYU.EDU (AXP2.ACF.NYU.EDU [128.122.250.38]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000613110045-53682-16 ; Tue, 13 Jun 2000 11:00:45 -0500 Received: from ACFcluster.NYU.EDU by ACFcluster.NYU.EDU (PMDF V5.2-33 #33915) id <01JQJV6IWYWW8WZXPU@ACFcluster.NYU.EDU> for ftp-wg@hethmon.com; Tue, 13 Jun 2000 11:57:10 EDT In-reply-to: "Your message dated Tue, 13 Jun 2000 10:17:32 -0500" <5195.960909232@mundamutti.cs.mu.OZ.AU> Message-id: <01JQJXPV2HR28WZXPU@ACFcluster.NYU.EDU> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII References: <4.3.2.7.2.20000613095353.00cb2b50@mail.io.com> Date: Tue, 13 Jun 2000 11:00:45 -0500 X-OldDate: Tue, 13 Jun 2000 11:55:41 -0400 (EDT) Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Stephen Tihor To: FTPEXT Working Group Subject: Ftp-WG: Coming changes in -11 mlst draft I can see an argument for adding a section on common failings and mentioning presumptions of unix file naming or that . is part of the TVS or that $ and | are not characters in file and directory names, etc. If MSLD . is mention you might as well add an example with MLSD C$| and MLSD SYS$DISK:[] etc. From ftp-wg-owner@hethmon.com Tue Jun 13 14:09:58 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18013 for ; Tue, 13 Jun 2000 14:09:57 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000613130753-21007-7 ; Tue, 13 Jun 2000 13:07:54 -0500 Received: from havoc.entera.com (havoc.entera.com [206.165.109.130]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000613130749-60823-6 ; Tue, 13 Jun 2000 13:07:50 -0500 Received: from entera.com ([208.48.116.174]) by havoc.entera.com (Post.Office MTA v3.5.3 release 223 ID# 0-61971U200L100S0V35) with ESMTP id com for ; Tue, 13 Jun 2000 11:02:34 -0700 Message-ID: <394677C5.18CB4CE7@entera.com> Organization: Entera, Inc. X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.7 i86pc) X-Accept-Language: en MIME-Version: 1.0 References: <23432.960838038@mundamutti.cs.mu.OZ.AU> <4.3.2.7.2.20000612154117.00b3b100@mail.io.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 13 Jun 2000 13:07:51 -0500 X-OldDate: Tue, 13 Jun 2000 11:04:53 -0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Stephen Head To: ftp-wg@hethmon.com Subject: Ftp-WG: thoughts on MSLx and MAY/SHOULD for fqpathnames Content-Transfer-Encoding: 7bit I had some offline discussions about the comparative merits of changing some wording in some cases in 7.3.1 to make reporting the fully qualified pathname always recommended (ie SHOULD), versus required (MUST), versus other possible options for the TVFS case. SHOULD already seems to apply for the TVFS MLST CRLF case (ie no argument in request). I arrived at the tentative conclusion that the notion (credit to Alun) of having MLSx *should* (instead of *may*) return a fully qualified pathname for the TVFS case seems as if it should be "good enough" for my plight with regard to ftp proxy caching. Here is (I believe) why: -> when it is "should", one can reasonably (?) expect "most" implementations to follow the recommendation for mutual benefit of clients and servers (ASSUMPTION) -> an ftp proxy cache server can, if the fully qualified pathname is not returned with MLST response, either issue a followup PWD request, or choose to give up on trying to cache the file. The PWD request will incur a network latency quantum. Giving up risks missing a later cache hit opportunity. It would just be a caching policy decision tradeoff. -> it is symmetric with the TVFS-> "SHOULD" return fully qualified pathname spec for MLST CRLF (ie no argument specified in request) already in d-10, 7.3.1 (if my reading is correct). [Virtually all the arguments against having TVFS-> "SHOULD" return fully qualified pathname for the MLST case appear to apply just as much to this case too. If so, the same level of recommendation (whether should, may, or must) might logically be applicable to the other, analogous cases, or at least so it would appear.] -> implementors that go against SHOULD in this case incur the potential risks of either supporting extra RETR requests that could otherwise have been cached, or getting extra PWD requests. Assuming (?) that 80% of the ftpd folks follow the SHOULD recommendation were it to be specified, then 80% of the time, the ftp proxy server <-> ftp server interaction would be "optimal" 80% of the time. This might look something like the following (additions/changes are boxed) 7.3.1. Notes about the Filename The filename returned in the MLST response should be ---------------------------------- | , in the case in which TVFS is not supported, | ---------------------------------- the same name as was specified in the MLST command, or, where TVFS is supported, a fully qualified TVFS path naming the same file. Where no argument was given to the MLST command, the server-PI may either include an empty filename in the response, or it may supply a name that refers to the current directory, if such a name is available. Where TVFS is supported, a fully qualified path name of the current directory SHOULD be returned. ... If the server-FTP process is able, and the "type" fact is being returned, it MAY return in the MLSD response, an entry whose type is "cdir", which names the directory from which the contents of the listing were obtained. Where TVFS is supported, the name MAY XXX XXX XXX ---------------------------------------- | the cdir fact SHOULD be returned and the name SHOULD | ---------------------------------------- be the fully qualified path name of the directory, or MAY be XXX XXX XXX --------------- | and otherwise is | --------------- any other path name which is valid to refer to that directory from the current working directory of the server-FTP. I imagine other alternative wordings are possible. If it is OK to take a quick (unofficial) canvass, does anyone have big problems with this? I don't have any formal ties to this wg so the notion can stand or fall based on whatever you all think. If it is wildly unpopular, or some procedural issue gets in the way, at least it could be said that the idea was aired but not acted on. BTW there are some possible problems with "pipelining" requests on the control channel: * it might cause less carefully written ftp servers to barf; and * if the ftp server does two sends to the TCP level and the Nagle algorithm is not disabled, TCP might insert a delay. thanks (again) to Alun for noting these potential problems with this. -s From ftp-wg-owner@hethmon.com Thu Jun 15 05:40:31 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA25554 for ; Thu, 15 Jun 2000 05:40:30 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000615043733-28236-8 ; Thu, 15 Jun 2000 04:37:33 -0500 Received: from hot.securesoft.co.kr (210.205.15.15 [210.205.15.15]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000615043710-27641-6 ; Thu, 15 Jun 2000 04:37:29 -0500 Received: from iss.co.kr (gate.securesoft.co.kr [210.205.15.254]) by hot.securesoft.co.kr with SMTP (8.7.1/8.7.1) id LAA28776; Fri, 9 Jun 2000 11:43:40 +0900 (JST) Message-Id: <200006090243.LAA28776@hot.securesoft.co.kr> Date: Thu, 15 Jun 2000 04:37:31 -0500 X-OldDate: Thu, 15 Jun 00 05:27:02 EST Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Magic@mx-88.fsnet.co.uk To: Magic@yahoo.com Subject: Ftp-WG: Search Engine Secrets Discovered "Amazing Search Engine Secrets Discovered By A Computer Illiterate Man in Massachusetts Can Practically Hand You the Top Search Engine Positions...And Add 1,550 Hits a Day to Web Site Overnight!" Dear Friend, Remember the first time you built a web site. You stayed up until the early morning working it out so that it would be just perfect. Then, you were finally done and you sat back and thought, "The World is Good." After that, you've dreamed of all the visitors your site would have, how they would all see your ad and buy your product. Then it hit you, like a ton of bricks....How was anyone going to find your web site? You thought about it for a while and eventually thought you had the answer....submit your site to the search engines. But after you submitted your site you checked it out and couldn't find it. So you waited a few days.....and still nothing You couldn't even find your site if you looked up your own name!!! Then, you got discouraged....after all that hard work NOTHING?!?!? And this is where most people give up..... BUT You Don't Have To... You can achieve top 20 positioning for your web site...and the tens of thousands of hits which come with it...if you have the "Right" information available to you. For Example, did you know: * Infoseek, Alta Vista, and HotBot ban web sites which break their rules (many of the 'insider' techniques most experts recommend will get you banned faster than you could imagine). * Many search engines limit the number of pages you can submit from your domain (some only allow you to submit one page for best results), although we can show you a technique we use to get hundreds of our pages listed. * Yahoo only lists about 1% of the web in their actual directory. To even get your page listed, you may have to use the "backdoor". * Using a so-called search engine submission software that submits your site to 1,000 or more search engines could actually get your page deleted from the major search engines. * 95% of Internet traffic originates at one of the 10 major search engines...If you're not listed, you might as well not even have a web site! * Choosing the most effective 'keywords' is one of the major keys to a successful web site submission...Pick the right ones and your web site will look like Grand Central Station during rush hour! It has taken us over 2 years to learn how to consistently and without fail place any type of web site in the top 20 of the major search engines. Normally, we charge $500 per keyword that you want a top ranking on (plus a monthly fee of $150 for keeping that rank), but we have found we just don't have enough time for all of the clients that desperately need our services... So, we have produced a "Search Engine Magic" interactive CD-ROM that will show you step by step how to create pages which storm the search engines and lay hold to the precious Top 20 positions that millions of people are trying to reach. The Search Engine Magic CD-ROM consists of 21 interactive video and audio lessons that will run on any IBM compatible computer showing you the exact step-by-step process we use to traffic thousands of visitors to our web sites every single day. You will learn: * Three Different Methods We Use to Pick the Best Traffic Producing Keywords for any web site...and how you can have a list of hundreds of popular keywords in only a few minutes. * How Quick and Easy it is to Create 'Doorway' and 'Hallway' pages for the search engines so that you could possibly have thousands of different pages on your domain all pulling in visitors for your site 24 hours a day 7 days a week. * The Secret Weapon that gives you an "Unfair Advantage" over your competition...and virtually assures you will reach the top positions (don't let your competitors hear about this one first or you will be in trouble). * How to Submit Your Pages to the Search Engines and assure that every single one of them gets listed. (if you listen to one of those amateurs tell you how to list your site, you may just get banned for life). * How to Use Pay-Per-Click search engines to receive over 10,000 visitors for only $100 * The Infamous Yahoo backdoor...You can get listed and we will show you the quickest and easiest method for doing so! * And much, much more... Even Better, You'll Get the Same Results For A Fraction of What Everyone Else Had to Pay! Listen: A lot of people all over the world are gonna be furious with me for sharing these "Insider Secrets" with you...especially since you won't be paying even part of what they had to shell out for one top positioning page! That's just too bad. It's been a secret for too long. So, let me tell you what the deal is.... Contact us today using the below Risk-Free Response Form and you can have all of our secrets for only $139.00. This price wouldn't even buy you 10 minutes of our time at our regular submission fees, but you can own the top search engine positions for less than the cost of a few classified ads! You will be learning everything we know about top positioning! That, my friend, is the bargain of a lifetime for a serious Internet marketer like yourself. What’s more, the money is actually irrelevant, because... You Also Get a 90 Day No-Risk 100% Money-Back Guarantee! Here's how it works. Order your personal copy of this CD-ROM, and use it like you own it. If...For any reason or no reason at all, you aren't completely satisfied after 90 days (by which I had over 47 Top 20 positions for my own web site), just send the CD-ROM back in any condition, and I personally guarantee you to get a complete refund of your purchase price. No questions asked. No problems or forms to fill out. No problems at all. PLUS, You Will Also Receive What is Considered to be by most experts as the "Ultimate Bonus!" For the first 50 people who fill out the below response form and send it in, you will also receive UNLIMITED REPRINT AND REPRODUCTION RIGHTS to this CD-ROM for LIFE! I am not going to allow this CD-ROM to become like many of those over-advertised products you see out there, so only the first 50 will receive these rights. This means that you will be able to use this exact same sales letter, copy the CD-ROM yourself, and sell it For $139.00 a copy, one sell will have breaking even. Sell two copies and you will be in profit.This isn't even counting what the CD-ROM package will do for you! Since only 50 people are going to have these rights... you must take action today! Yours in Success, Michael Burgess To rush order this "Search Engine Magic CD-ROM" simply fill out the order form below and fax it to our 24 hour order line at: FAX ORDER LINE: 1 (212) 504-8032 Regular Mail to: Financial Systems P.O. Box 301 Orange, Ma 01364 ORDER FORM #MB-Smic1 -------------------------------------------------------- Please send to: Your Name: _____________________________________________ Your Address: __________________________________________ Your City: _____________________________________________ State / Zip: ___________________________________________ Your Country: __________________________________________ Phone #: _______________________________________________ (For problems with your order only. No salesmen will call.) Email Address: ___________________________________________ We Accept Checks or Money Orders along with all Major Credit Cards including Visa, MasterCard, American Express and Discover. (NOTE - We only ship to the address listed on the credit card) (Please Fill Out Below Section and Make sure that the above name and address are listed as it appears on the card) for $144 ($139 + 5.00 Shipping) Credit Card Number:________________________________ Expiration Date:___________________________ Signature:_________________________ Date:____________________ * Please check one of the following payment options: [ ] I am faxing a check (Do not send original, we will make a draft from the faxed check) [ ] I am faxing or mailing my credit card number. (Note your card will be charged for $144.00 and we only ship to the address on the card) [ ] I am enclosing a check or money order for $144.00! Note - If ordering outside continental US, please add $5 to S&H P.S. If you send in your order and you are not one of the first 50 to receive the Reprint and Reproduction Rights, I will notify you immediately and give you the opportunity to cancel your order. _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ If you have received this message in error and would like to be removed from future mailings, please reply with the word remove in the subject. x _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From ftp-wg-owner@hethmon.com Wed Jun 21 06:26:35 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA25497 for ; Wed, 21 Jun 2000 06:26:34 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000621052102-64103-7 ; Wed, 21 Jun 2000 05:21:02 -0500 Received: from inetsrv0.sohard.ch (dnssohard1.sohard.ch [194.230.67.5]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000621052057-35580-6 ; Wed, 21 Jun 2000 05:20:58 -0500 Message-Id: <20000621052057-35580-6@mail.hethmon.com> Received: from iduhah9 (98-pool1.ras10.midea.agisdial.net [209.14.80.98]) by inetsrv0.sohard.ch with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id NK9KKSW3; Wed, 21 Jun 2000 12:14:31 +0200 Date: Wed, 21 Jun 2000 05:20:59 -0500 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: To: vacationnow9@hotmail.com Subject: Ftp-WG: FREE: Tropical Caribbean Trip & Deluxe Hotel


WEALTH IN THE NEW MILLENNIUM

The Internet and new technology are creating more 7 Figure ($1,000,000)
incomes than any time in history. If you feel you are not being paid what
your worth, please visit our web site. The information is FREE.

HUGE COMPENSATION AVAILABLE!
This is your chance to get in on the ground floor of the
Multi-Billion-Dollar Home Based Business Revolution.

PLUS, RECEIVE A COMPLIMENTARY GIFT WHEN VISITING OUR WEB SITE.

Click Here For FREE Vacation





To Be Removed from out list: Click here
From ftp-wg-owner@hethmon.com Wed Jun 21 18:23:33 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14061 for ; Wed, 21 Jun 2000 18:23:33 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000621172317-27976-7 ; Wed, 21 Jun 2000 17:23:17 -0500 Received: from mail.eskilstryckeri.se (195.67.72.3 [195.67.72.3]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000621172116-41842-6 ; Wed, 21 Jun 2000 17:23:13 -0500 Received: from 195.67.72.11 (root@styx2-gw [192.10.11.200]) by mail.eskilstryckeri.se (8.9.1/8.9.1) with SMTP id XAA18710; Wed, 21 Jun 2000 23:30:08 +0200 Received: from 99881117766@hehe.com by 99881117766@hehe.com (8.8.5/8.6.5) with SMTP id GAA01112 for <>; Wed, 21 Jun 2000 17:33:43 -0600 (EST) Message-ID: Comments: Authenticated sender is <99881117766@hehe.com> Date: Wed, 21 Jun 2000 17:23:15 -0500 X-OldDate: Wed, 21 Jun 00 17:33:43 EST Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: cbr1900@ureach.com To: Friend@public.com Subject: Ftp-WG: FIND OUT ANYTHING ON ANYONE!!!! THE INTERNET SPY DISC!!! Learn EVERYTHING about your friends, neighbors, enemies, employees, co-workers, even your boss, even yourself! Here's An Idea Of The SECRETS you will discover: Get anyone's name and address with just a license plate number! - (Find that *!%$ who cut you off!) Get anyone's address, driving record, Social Security Number - with just a name! Trace anyone by his or her social security number! Unlisted phone numbers! Get anyone's phone number with just a name-even unlisted numbers! Find people using their phone number Bank account information Tax liens Locate! Long lost friends, relatives, and a past lover who broke your heart! Send anonymous e-mail completely untraceable! Dirty secrets! Discover dirty secrets your in-laws don't want you to know! Investigate anyone! Use the sources that private investigators use (all on the Internet) secretly! Ex-spouse! Learn how to get information on an ex-spouse that will help you win in court! - (Dig up the old skeletons in someone's closet) Criminal search-Background checks! Find out about your daughter's boyfriend! (or her husband) Create a map showing directions right to a person's door Education verification! Did he really graduate college? Find out! If you are being investigated! Learn all about your mysterious neighbors! People you work with! - Be astonished by what you'll learn about people you work with! Find out almost anything. Find out what they have to hide! Order your copy of The Internet Spy for only $10.00 + $2.00 for shipping & handling ($12.00) while supplies last. Get yours today!!! I currently accept concealed cash money orders or personal checks. Please send concealed cash, check, or money order for your purchase of the above disc to: Charles Vogl RR1 Box 45 Effort, PA 18330 U.S.A. Thank You & Have a Nice Day :o) We apoligize for any incovienience hitting the delete key has caused if you did not wish to recieve this message. This message is being sent to you in compliance with the proposed Federal legislation for commercial e-mail (S.1618 - SECTION 301). "Pursuant to Section 301, Paragraph (a)(2)(C) of S. 1618, DUE TO CERTAIN RESTRICTIONS, THIS PRODUCT IS NOT AVAILABLE IN THE STATES OF WASHINGTON, CALIFORNIA, & VIRGINIA. From ftp-wg-owner@hethmon.com Thu Jun 22 11:10:43 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07815 for ; Thu, 22 Jun 2000 11:10:41 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000622100929-50583-8 ; Thu, 22 Jun 2000 10:09:29 -0500 Received: from wwwserver (212.30.90.73 [212.30.90.73]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000622100923-22841-7 ; Thu, 22 Jun 2000 10:09:24 -0500 Received: from 32.100.170.166 by wwwserver ([212.30.90.73] running VPOP3) with SMTP; Thu, 22 Jun 2000 16:59:03 +0200 Message-ID: X-Server: VPOP3 V1.3.5 - Registered to: CC-Line d.o.o. Date: Thu, 22 Jun 2000 10:09:26 -0500 X-OldDate: 22 Jun 00 10:12:48 AM Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: TkF9B7C64@isle.ne.jp Subject: Ftp-WG: thriving online business Build a residual income from time you spend on the Internet placing FREE advertisements like this. Successful Internet company wants you to help them market their products and services online. Place FREE pre-written ads and get paid commissions on any sales that you bring to the company. A FREE Web Site, and complete training and instructions will be provided to you. To Register with the program and to begin receiving instructions, simply mailto:helenk@england.com?subject=RegisterMe AND INSERT YOUR FIRST AND LAST NAME AS TEXT to be removed from this list mailto:24remo@england.com.com?subject=remove From ftp-wg-owner@hethmon.com Thu Jun 22 17:14:08 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15784 for ; Thu, 22 Jun 2000 17:14:07 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000622161215-2394-11 ; Thu, 22 Jun 2000 16:12:16 -0500 Received: from www7.dns.ne.jp (www7.dns.ne.jp [210.155.3.37]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000622161204-2587-7 ; Thu, 22 Jun 2000 16:12:11 -0500 Received: from www7.dns.ne.jp (05-076.dial.008.popsite.net [209.69.13.76] (may be forged)) by www7.dns.ne.jp (8.9.2/[NAKORURU/SAKURA-99/2/9]) with SMTP id FAA13736; Fri, 23 Jun 2000 05:48:07 +0900 (JST) (envelope-from otcnewslttr8@yahoo.com) Message-ID: <1967542lkd64sre1@154jsy363kj4@watagashi.bekkoame.or.jp> Date: Thu, 22 Jun 2000 16:12:13 -0500 X-OldDate: Thu, 22 Jun 00 16:45:34 EST Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: otcnewslttr8@yahoo.com To: mem0294@watagashi.bekkoame.or.jp Subject: Ftp-WG: INJX (otcbb) - Revolutionary needle-free injection system Subscriber: Thursday June 22, 2000 Symbol: INJX Price: $5 per share 52 week high: $9.00/shr Float: 6.1mil We consider INJX a STRONG BUY Press Release: WESTFORD, Mass.--(BW HealthWire)--June 22, 2000-- EQUIDYNE CORPORATION (OTCBB:INJX - news) announced today its intention to immediately begin the process necessary to receive FDA approval to market the INJEX(TM) needle-free injection system for ``over the counter'' use. The INJEX(TM) needle-free injector is a compact, uncomplicated device that delivers a virtually painless injection through the skin in a fraction of a second, and eliminates needle stick and isposal problems. For medications requiring injection, we believe the INJEX(TM) System is by far the most comfortable and economical product on the market. Please see complete press release at: http://biz.yahoo.com/bw/000622/ma_equidyn.html This message is for informational purposes. As always do your own due diligence before making any investments of any kind. We are a small independent group of investors who feel very positive about this company and do hold a long position. From ftp-wg-owner@hethmon.com Fri Jun 23 12:50:08 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14927 for ; Fri, 23 Jun 2000 12:50:03 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000623114417-32400-7 ; Fri, 23 Jun 2000 11:44:17 -0500 Received: from mail.eskilstryckeri.se (195.67.72.3 [195.67.72.3]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000623114150-43029-6 ; Fri, 23 Jun 2000 11:44:12 -0500 Received: from 195.67.72.11 (root@styx2-gw [192.10.11.200]) by mail.eskilstryckeri.se (8.9.1/8.9.1) with SMTP id QAA30314; Fri, 23 Jun 2000 16:14:52 +0200 Received: from 99881117766@hehe.com by 99881117766@hehe.com (8.8.5/8.6.5) with SMTP id GAA00816 for <>; Fri, 23 Jun 2000 10:15:38 -0600 (EST) Message-ID: Comments: Authenticated sender is <99881117766@hehe.com> Date: Fri, 23 Jun 2000 11:44:13 -0500 X-OldDate: Fri, 23 Jun 00 10:15:38 EST Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: cbr1900@ureach.com To: Friend@public.com Subject: Ftp-WG: HOW WOULD YOU LIKE TO MAKE ALOT OF MONEY??? THIS MAY BE THE MOST SIGNIFICANT LETTER YOU RECEIVE THIS YEAR!! DO NOT DELETE!!! PRINT IT, READ IT AND MAKE SOME BIG BUCKS. IT HAS WORKED SO WELL, THIS IS MY THIRD TIME AROUND. I QUIT MY BORING JOB AND WORK AT THIS ABOUT ONE TO TWO HOURS A DAY PROCESSING ORDERS, INCLUDING MY DRIVE TO THE BANK! SO GO FOR IT, YOU WILL BE GLAD YOU DID! YOU CAN EARN $150,000+ PER YEAR SENDING E-MAIL!!! Dear Friend, You can earn $50,000 or more in next the 90 days sending e-mail. Seem impossible? Read on for details; is there a catch; NO, there is no catch, just send your emails and be on your way to financial freedom. "AS SEEN ON NATIONAL TELEVISION" Thank you for your time and Interest. This is the letter you've been reading about in the news lately. Due to the popularity of this letter on the Internet, a major nightly news program recently devoted an entire show to the investigation of the program described below to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for all that there are, absolutely no laws prohibiting the participation in the program. This has helped to show people that this is a simple, harmless and fun way to make some extra money at home. The results of this show have been truly remarkable. So many people are participating that those involved are doing, much better than ever before. Since everyone makes more as more people try it out, its been very exciting to be a part of lately. You will understand once you experience it. TESTIMONIAL: RUNNING A SUCCESSFUL ONLINE BUSINESS RIGHT FROM HOME I Never Thought I'd Be the One Telling You This: I Actually Read a Piece of E-Mail & I'm Going to Europe on the Proceeds! Hello! My name is Karen Liddell; I'm a 35-year-old mom, wife, and part-time accountant. As a rule, I delete all unsolicited "junk" e-mail and use my account primarily for business. I received what I assumed was this same e-mail countless times and deleted it each time. About two months ago I received it again and, because of the catchy subject line, I finally read it. Afterwards, I thought , "OK, I give in, I'm going to try this. I can certainly afford to invest $20 and, on the other hand, there's nothing wrong with creating a little excess cash." I promptly mailed four $5 bills and, after receiving the reports, paid a friend of mine a small fee to send out some e-mail advertisements for me. After reading the reports, I also learned how easy it is to bulk e-mail for free! I was not prepared for the results. Everyday for the last six weeks, my P.O. box has been overflowing with $5 bills; many days the excess fills up an extra mail bin and I've had to upgrade to the corporate-size box! I am stunned by all the money that keeps rolling in! My husband and I have been saving for several years to make a substantial downpayment on a house. Now, not only are we purchasing a house with 40% down, we're going to Venice, Italy to celebrate! I promise you, if you follow the directions in this e-mail and be prepared to eventually set aside about an hour each day to follow up (and count your money!), you will make at least as much money as we did. You don't need to be a wiz at the computer, but I'll bet you already are. If you can open an envelope, remove the money, and send an e-mail message, then you're on your way to the bank.Take the time to read this so you'll understand how easy it is. If I can do this, so can you! "HERE IT IS BELOW. THIS IS THE $50,000 PROGRAM IN FULL" ========================================================== *** Print This Now For Future Reference *** The following income opportunity is one you will be interested in taking a good look at. It can be started with VERY LITTLE INVESTMENT and the income return is TREMENDOUS!!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ THIS IS A LEGITIMATE, LEGAL, MONEY-MAKING OPPORTUNITY. It does Not require you to come into contact with people, do any hard work, And best of all, you never have to leave the house except to get the mail. If you believe that someday you'll get that big break that you've been waiting for, THIS IS IT! Simply follow the instructions, and your dreams will come true. This Multi-level e-mail order marketing program works perfectly 100% EVERY TIME. E-mail is the sales tool of the future. Take advantage of this non-commercialized method of advertising NOW! The longer you wait, the more people will be doing business using email. Get your piece of this action!!! You are about to embark on the most profitable and unique program you may ever see. Many times over, it has demonstrated and proven its ability to generate large amounts of cash. This program is showing fantastic appeal with a huge and ever-growing on-line population desirous of additional income. This truly is that lucky break you've been waiting for! Simply follow the easy instructions in this letter, and your financial dreams will come true! When followed correctly, this electronic, multi-level marketing program works perfectly ...100% EVERY TIME! Thousands of people have used this program to: - Raise capital to start their own business - Pay off debts - Buy homes, cars, etc., - Even retire! --------------------------------------------------------- OVERVIEW OF THIS EXTRAORDINARY ELECTRONIC MULTI-LEVEL MARKETING PROGRAM --------------------------------------------------------- HERE'S HOW THIS AMAZING PROGRAM WILL MAKE YOU THOUSANDS OF DOLLAR$ This method of raising capital. REALLY WORKS 100% EVERY TIME. I Am sure that you could use up to $50,000 USD or more in the next 90 days. Before you say "BULL... ", please read this program carefully. This is not a chain letter, but a perfectly LEGAL money making opportunity. Basically, this is what you do. As with all multi-level businesses, we build our business by recruiting new partners and selling our products. Every state in the USA allows you to recruit new multi-level business partners, and we offer a product for EVERY dollar sent. YOUR ORDERS COME BY MAIL AND ARE FILLED BY E-MAIL, so you are not involved in personal selling. You do it privately in your own home, store or office. This is the GREATEST Multi-Level Mail Order Marketing anywhere: This is what you "MUST" do: FOLLOW THE INSTRUCTIONS TO THE LETTER AND BE PREPARED TO REAP THE STAGGERING BENEFITS! ********************************** I N S T R U C T I O N S ********************************** This is what you MUST do: 1. Order all 4 reports shown on the list below (you can't sell them if you don't order them). * For each report, send $5.00 CASH, The NAME & NUMBER OF THE REPORT YOU ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR RETURN POSTAL ADDRESS (in case of a problem) to the person whose name appears on the list next to the report. * When you place your order, make sure you order each of the four reports. You will need all four reports so that you can save them on your computer and resell them. * Within a few days you will receive, via e-mail, each of the four reports. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. 2. IMPORTANT-- DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than is instructed below in steps "a" through "f" or you will lose out on the majority of your profits. Once you understand the way this works, you'll also see how it doesn't work if you change it. Remember this method has been tested, and if you alter it, it will not work. a. Look below for the listing of available reports. b. After you've ordered the four reports, take this Advertisement and remove the name and address under REPORT #4. This person has Made it through the cycle and is no doubt counting their $50,000! c. Move the name and address under REPORT #3 down to REPORT #4. d. Move the name and address under REPORT #2 down to REPORT #3. e. Move the name and address under REPORT #1 down to REPORT #2. f. Insert your personal or business name/address in the REPORT #1 position. You're now at the top of the list. Please make sure you copy everyone's name and address ACCURATELY!!! 3. Take this entire letter, including the modified list of names, and save it to your computer. Make NO changes to the instruction portion of this letter. 4. Now you're ready to start an advertising campaign on the WORLDWIDE WEB! To assist you with marketing your business on the internet, the 4 reports you purchase will provide you with invaluable marketing information which includes how to send bulk e-mails, where to find thousands of free classified ads and much, much more. These reports show you TO OPERATE THIS BUSINESS! 5. For every $5.00 you receive, all you must do is e-mail them the report they ordered. THAT'S IT! ALWAYS PROVIDE SAME-DAY SERVICE ON ALL ORDERS! This will guarantee that the e-mail THEY send out, with YOUR name and address on it, will be prompt because they can't advertise until they receive the report! ------------------------------------------ AVAILABLE REPORTS ------------------------------------------ ***Order Each REPORT by NUMBER and NAME*** Notes: - ALWAYS SEND $5 CASH FOR EACH REPORT - ALWAYS SEND YOUR ORDER VIA FIRST CLASS MAIL - Make sure the cash is concealed by wrapping it in at least two sheets of paper - On one of those sheets of paper, include: (a) the number & name of the report you are ordering, (b) your e-mail address, and (c) your postal address. _________________________________________________________________ REPORT #1 "HOW TO MAKE $250,000 THROUGH MULTI-LEVEL SALES" ORDER REPORT #1 FROM: Charles Vogl RR1 Box 45 Effort, PA 18330 _________________________________________________________________ REPORT #2 "MAJOR CORPORATIONS AND MULTI-LEVEL SALES" ORDER REPORT #2 FROM: Patricia Calderone PO Box 205 Brodheadsville, PA 18322-205 ______________________________________________________________ REPORT #3 "SOURCES FOR THE BEST MAILING LISTS" ORDER REPORT #3 FROM IPS Network 355-2252 Kingsway Vancover B.C. Canada V5N5X6 _________________________________________________________________ REPORT #4 "EVALUATING MULTI-LEVEL SALES PLANS" ORDER REPORT #4 FROM: SC PUBLISHING P.O. BOX 6202 PLYMOUTH, MA 02362 _________________________________________________________________ HERE'S HOW THIS AMAZING PLAN WILL MAKE YOU $MONEY$ _________________________________________________________________ Let's say you decide to start small just to see how well it works. Assume your goal is to get 10 people to participate on your first level. (Placing a lot of FREE ads on the internet will EASILY get a larger response.) Also assume that everyone else in YOUR ORGANIZATION gets ONLY 10 downline members. Follow this example to achieve The STAGGERING results below. 1st level--your 10 members with $5...........................$50 2nd level--10 members from those 10 ($5 x 100)............$500 3rd level--10 members from those 100 ($5 x 1,000).......$5,000 4th level--10 members from those 1,000 ($5 x10,000).....$50,000 YOU HAVE JUST MADE.......$55,550 Remember friends, this assumes that the people who participate only recruit 10 people each. Think for a moment what would happen if they got 20 people to participate! Most people get 100's of participants! You can, too! THINK ABOUT IT! Your cost to participate in this is practically nothing (surely you can afford $20). You obviously already have an internet connection and e-mail is FREE!!! REPORT #3 shows you the most productive methods for bulk e-mailing and purchasing e-mail lists. Some list & bulk e-mail vendors even work on trade! Now, over 50,000 new people get online every day! And more and more of these people are looking for ways to make money from the internet. You have a very large, expanding market here, ideal for this program! *******TIPS FOR SUCCESS******* * TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow the directions accurately. * Send for the four reports IMMEDIATELY so you will have them stored on your computer when the orders start coming in because: "When you receive a $5 order, you MUST send out the requested product/report to comply with the U.S. Postal & Lottery Laws, Title 18,Sections 1302 and 1341 or Title 18, Section 3005 In the U.S. Code, also Code of Federal Regs. vol. 16, Sections 255 And 436, which state that "a product or service must be exchanged for money received." * ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. * Be patient and persistent with this program. If you follow the instructions exactly, the results WILL undoubtedly be SUCCESSFUL! * ABOVE ALL, HAVE FAITH IN YOURSELF AND KNOW YOU WILL SUCCEED! *******YOUR SUCCESS GUIDELINES******* Follow these guidelines to guarantee your success: If you don't receive 20 orders for REPORT #1 within two weeks, continue advertising or sending e-mails until you do. Then, a couple of weeks later you should receive at least 100 orders for REPORT#2. If you don't, continue advertising or sending e-mails until you do. Once you have received 100 or more orders for REPORT #2, YOU CAN RELAX, because the system is already working for you, and the cash will continue to roll in! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you are placed in Front of a DIFFERENT report. You can KEEP TRACK of your PROGRESS by Watching which report people are ordering from you. If you want to generate more income, send another batch of e-mails or continue placing ads and start the whole process again! There is no limit to the income you will generate from this business! Before you make your decision as to whether or not you participate in this program. Please answer one question. DO YOU WANT TO CHANGE YOUR LIFE? If the answer is yes, please look at the following facts about this program: 1. YOU ARE SELLING A PRODUCT WHICH DOES NOT COST ANYTHING TO PRODUCE! 2. YOU ARE SELLING A PRODUCT WHICH DOES NOT COST ANYTHING TO SHIP! 3. YOU ARE SELLING A PRODUCT WHICH DOES NOT COST YOU ANYTHING TO ADVERTISE! 4. YOU ARE UTILIZING THE POWER OF THE INTERNET AND THE POWER OF MULTI-LEVEL MARKETING TO DISTRIBUTE YOUR PRODUCT ALL OVER THE WORLD! 5. YOUR ONLY EXPENSES OTHER THAN YOUR INITIAL $20 INVESTMENT IS YOUR TIME! 6. VIRTUALLY ALL OF THE INCOME YOU GENERATE FROM THIS PROGRAM IS PURE PROFIT! 7. THIS PROGRAM WILL CHANGE YOUR LIFE FOREVER. *******T E S T I M O N I A L S******* This program does work, but you must follow it EXACTLY! Especially the rule of not trying to place your name in a Different position, it won't work and you'll lose a lot of potential income. I'm living proof that it works. It really is a great opportunity to make relatively easy money, with little cost to you. If you do choose to participate, follow the program exactly, and you'll be on your way to financial security. Sean McLaughlin, Jackson, MS My name is Frank. My wife, Doris, and I live in Bel-Air, MD. I am a cost accountant with a major U.S. Corporation and I make pretty good money. When I received the program I grumbled to Doris about receiving "junk mail." I made fun of the whole thing, spouting my knowledge of the population and percentages involved. I "knew" it my supposed intelligence and jumped in with both feet. I made merciless fun of her, and was ready to lay the old "I told you so" on her when the thing didn't work... well, the laugh was on me! Within two weeks she had received over 50 responses. Within 45 days she had received over $147,200 in $5 bills! I was shocked! I was sure that I had it all figured and that it wouldn't work. I AM a believer now. I have joined Doris in her "hobby." I did have seven more years until retirement, but I think of the "rat race" and it's not for me. We owe it all to MLM. Frank T., Bel-Air, MD I just want to pass along my best wishes and encouragement to you. Any doubts you have will vanish when your first orders come in. I even checked with the U.S. Post Office to verify that the plan was legal. It definitely is! IT WORKS!!! Paul Johnson, Raleigh, NC The main reason for this letter is to convince you that this system is honest, lawful, extremely profitable, and is a way to get a large amount of money in a short time. I was approached several times before I checked this out. I joined just to see what one could expect in return for the minimal effort and money required. To my astonishment, I received $36,470.00 in the first 14 weeks, with money still coming in. Sincerely yours, Phillip A. Brown, Esq. Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative that I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back. Boy, was I surprised when I found my medium-size post office box crammed with orders! For while, it got so over-loaded that I had to start picking up my mail at the window. I'll make more money this year than any 10 years of my life before. The nice thing about this deal is that it doesn't matter where in the U.S. the people live. There simply isn't a better investment with a faster return. Mary Rockland, Lansing, MI I had received this program before. I deleted it, but later I wondered if I shouldn't have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed another program...11 months passed then it came...I didn't delete this one!...I made more than $41,000 on the first try!! D. Wilburn, Muncie, IN This is my third time to participate in this plan. We have quit our jobs, and will soon buy a home on the beach and live off the interest on our money. The only way on earth that this plan will work for you is if you do it. For your sake, and for your family's sake don't pass up this golden opportunity. Good luck and happy spending! Charles Fairchild, Spokane, WA PLEASE NOTE: If you need help with starting a business, registering a business name, learning how income tax is handled, etc., contact your local office of the Small Business Administration (a Federal agency) 1-(800)827-5722 for free help and answers to questions. Also, he Internal Revenue Service offers free help via telephone and free seminars about business tax requirements. Your earnings and results are highly dependant on your activities and advertising. This letter constitutes no guarantees stated nor implied. In the event that it is determined that this letter constitutes a guarantee of any kind, that guarantee is now void. Any testimonials or amounts of earnings listed in this letter may be factual or fictitious. If you have any question of the legality of this letter contact the Office of Associate Director for Marketing Practices Federal Trade Commission Bureau ofConsumer Protection in Washington DC. ***************************************************************** **** ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO FINANCIAL FREEDOM!!! From ftp-wg-owner@hethmon.com Sun Jun 25 03:16:35 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01737 for ; Sun, 25 Jun 2000 03:16:34 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000625021318-2839-6 ; Sun, 25 Jun 2000 02:13:18 -0500 Received: from domainmail.ionet.net (domainmail.ionet.net [206.41.128.18]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000625020813-38439-6 ; Sun, 25 Jun 2000 02:13:13 -0500 Received: from 209.178.164.86 (pool0086.cvx7-bradley.dialup.earthlink.net [209.178.164.86]) by domainmail.ionet.net (8.9.1a/8.7.3) with SMTP id BAA02291; Sun, 25 Jun 2000 01:43:25 -0500 (CDT) Message-ID: <0000078f3839$0000157b$00000f70@> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Outlook Express Date: Sun, 25 Jun 2000 02:13:16 -0500 X-OldDate: Sat, 24 Jun 2000 23:38:41 -0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: cardaccount2500@hotmail.com To: Subject: Ftp-WG: Merchant Account - No Setup Fees 3952 HOW TO SUBSTANTIALLY INCREASE SALES: Easily accept major credit cards right away! Act now and all Setup & App. fees waived ******************************************************** For Free Setup DOUBLE CLICK ON: mailto:cardacct1@mailcity.com?subject=merchant_account Include your name, phone number and best time to call. Or you can call 1(888) 242-8260 now! Our courteous customer care reps are anxious to help you get your merchant account today. ******************************************************** Merchant Status will help you increase sales by an incredible 50% to 400%. Stop losing valuable sales! With one phone call you can be: Accepting all major credit cards! Accepting checks over the net or by Fax! Accepting real time processing for member sites! Gaining costumer loyalty and trust! Close the sale now. No more wondering if "The check is in the mail" We specialize in helping those entrepreneurs who are just starting out: no credit, poor credit, or even if you have great credit. Almost everyone is approved! For the next 5 days we will waive all Setup & App. fees! (other companies charge $200 to $500 to set up) In Business since 1992 ******************************************************** For Free Setup DOUBLE CLICK ON: mailto:cardacct1@mailcity.com?subject=merchant_account Include your name, phone number and best time to call. Or you can call 1(888) 242-8260 now! Our courteous customer care reps are anxious to help you get your merchant account today. ******************************************************** This email has been delivered to you by the OPT IN PLUS email delivery service. If you feel that this has reached you in error please DOUBLE CLICK ON mailto:remo24@beer.com?subject=unsubscribe We will insure that your email address is removed from our database immediately. Thank you for participating in OPT IN PLUS! We value your membership. HOW TO SUBSTANTIALLY INCREASE SALES: Easily accept major credit cards right away! Act now and all Setup & App. fees waived From ftp-wg-owner@hethmon.com Sun Jun 25 06:09:34 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06715 for ; Sun, 25 Jun 2000 06:09:34 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000625050919-56171-11 ; Sun, 25 Jun 2000 05:09:19 -0500 Received: from icx.net (mailhub.icx.net [206.96.250.12]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000625050914-39377-7 ; Sun, 25 Jun 2000 05:09:14 -0500 Received: from mta106.mail.yahoo.com (ip57.phoenix8.az.pub-ip.psi.net [38.29.61.57]) by icx.net (IDG-2.7/1.3nr) with SMTP id GAA04856; Sun, 25 Jun 2000 06:05:17 -0400 (EDT) Message-ID: <> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Sun, 25 Jun 2000 05:09:16 -0500 X-OldDate: Sun, 25 Jun 2000 02:25:14 -0400 (EDT) Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: "a_z3818763@yahoo.com" Subject: Ftp-WG: Loans Up to 130% of Home's Value Content-Transfer-Encoding: 7bit For Homeowners Only Save Now! Are you in debt? Need extra cash? We can get you the loan you need. Regardless of whether you have good or bad credit, we can help you. We specialize in First and Second Mortgages, including loans that other lenders turn down. Funding borrowers with less than perfect credit is our specialty. We have loan programs that are unheard of. Our loan programs can get you the cash you need for: Debt Consolidation Needs Home Improvements Dream Vacations New Car College Tuition ..and much, much more. Incredibly low monthly payments Loans if you have hard to prove (Self-Employed) income Loans if you have collections, foreclosures, BKs or tax debts Loans if you're behind on your mortgage Loans up to 130% of your home's value Fill out the fax application below for fastest service. You will receive immediate attention to lower your payments, help you get the cash you need or consolidate your debts. We can get you the kind of loan you are looking for. Whether your credit is good or bad, if you are serious about improving your lifestyle and need a loan for any reason, contact us now because we can get you the cash you need. We make the loans that other lenders turn down. This form must be completely filled out. Please enter NA in those fields which do not apply. FAX TO:(509) 463-0799 Applicant First and Last Name: _______________________________ Co-Applicant First and Last Name: _______________________________ Address: __________________________________________________ City, State: __________________________________ Zip Code: _______________ Home Phone: ______________________ Work Phone: _____________________ Property Type: Single Family Residence Purchase Price: ____________________________ Year Property was Acquired: _________________ Present Value of Property: ___________________ Amount Owed on 1st Mortgage: _________________ Current Interest Rate on 1st: ___________________ Fixed or Adjustable? ______________ Monthly Payment: ________________________ Second Mortgage Balance (if any): _____________________ Current Employer: ___________________________________ Years with Current Employer: _________________________ Yearly Income: __________________________ How would you describe your credit? Excellent/Good/Fair/Poor Best Time to Contact You: ____________________________ Type of Loan Desired: ________________________________ Loan Amount Desired: _____________________ Email Address: ______________________________________ OFFICE USE: INT00002 ************************** From ftp-wg-owner@hethmon.com Sun Jun 25 08:56:59 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07613 for ; Sun, 25 Jun 2000 08:56:58 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000625075727-51771-7 ; Sun, 25 Jun 2000 07:57:28 -0500 Received: from n2-237.dialup.co.ru (n2-237.dialup.co.ru [194.85.151.237]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000625075721-23006-6 ; Sun, 25 Jun 2000 07:57:24 -0500 Message-ID: <22543765033715810@n2-237.dialup.co.ru> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Sun, 25 Jun 2000 07:57:25 -0500 X-OldDate: Βρ, 25 θών 2000 16:43:49 +0400 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: To: Subject: Ftp-WG: Hi, its for you ! Content-Transfer-Encoding: 7bit Hi! We are Russian girls - Nadegda, Natasha, Ekaterina. We would like to correspond with you. Visit our site and see our photos. http://www.rusladies.narod.ru/ With interest, Nadegda, Natasha, Ekaterina. P.S. (This is not spam. You can unsubscribe at any time by sending an email to prettylady@freemail.ru with the subject UNSUBSCRIBE.) From ftp-wg-owner@hethmon.com Mon Jun 26 23:02:26 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA20590 for ; Mon, 26 Jun 2000 23:02:25 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000626215454-19168-17 ; Mon, 26 Jun 2000 21:54:54 -0500 Received: from ralph.fdd.co.uk (fdd0150.fdd.co.uk [212.158.46.150]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000626215432-1185-16 ; Mon, 26 Jun 2000 21:54:49 -0500 Received: from yo (1Cust223.tnt2.flagstaff.az.da.uu.net [63.11.235.223]) by ralph.fdd.co.uk (8.9.3/8.9.3) with SMTP id DAA28560; Tue, 27 Jun 2000 03:56:45 GMT Message-Id: <200006270356.DAA28560@ralph.fdd.co.uk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_1DB8_0000368B.000028F1" X-Priority: 3 X-MSMail-Priority: Normal Date: Mon, 26 Jun 2000 21:54:52 -0500 X-OldDate: Mon, 26 Jun 2000 18:00:04 -0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: career@bedwell.co.uk To: Subject: Ftp-WG: Home Career Opportunity ------=_NextPart_000_1DB8_0000368B.000028F1 Content-Type: text/html; LOOKING FOR GEMS!

It's So Simple To Earn $2,000 - $5,000 Per Week Nowadays...
We're searching for only 10 elite individuals with the work ethic necessary to generate a cash-flow for themselves of $2,000 - $5,000per week, and to increase that to over $20,000 per month, in as little as four to six months. And you know what? If you really have a burning desire and commitment, we guarantee you that you'll reach this explosive income!

Can you read a short script to our qualified leads, and then turn the interested prospects over to our electronic sales medium? (you will not be required to do any selling.)Do you have the self-discipline to ignore the TV for a couple of hours per day? Are you looking for a legitimate home-based business opportunity, that is not multi-level marketing, or a chain-letter scheme?

If you would like to build an amazing income that will grow lightning-fast and have you profit $1,000.00 every time only one prospect makes a purchase, then this is for you! You can build the business under our guidance and support without having to attend meetings or sell people things they don't need.

Call NOW our TOLL FREE, PRE-RECORDED Message: 1-800-320-9895 ext. 6396

We market a real product, that pays real commissions to you,$1,000.00 per sale, just for making the initial contacts. With our turn-key lead generation systems you'll always talk to people who actually WANT to talk to you.

You have nothing to lose, there's no risk involved, nor is there any obligation whatsoever, and you may be qualified to earn thousands of extra dollars per month! So call now!

The call is FREE, and there is absolutely no obligation, So what have you got to lose?

Call Toll Free 1-800-320-9895 ext. 6396

P.S. You literally have a once-in-a-lifetime opportunity to GET INVOLVED NOW! Don't let this one go by. You have absolutely nothing to lose! This could be the most fascinating and profitable business of your life!

Please, serious inquiries only.







To be removed from future mailings send a blank email with remove in the subject line and
the email address or addresses to be removed in the body to
career@bedwell.co.uk
------=_NextPart_000_1DB8_0000368B.000028F1-- From ftp-wg-owner@hethmon.com Tue Jun 27 19:12:09 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26274 for ; Tue, 27 Jun 2000 19:12:09 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000627181131-60876-13 ; Tue, 27 Jun 2000 18:11:31 -0500 Received: from www.magnos.it (mail.alphanetsnc.com [212.54.225.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000627181126-27625-7 ; Tue, 27 Jun 2000 18:11:26 -0500 Message-Id: <20000627181126-27625-7@mail.hethmon.com> Received: from www.magnos.it ([38.31.170.224]) by www.magnos.it (Post.Office MTA v3.5.3 release 223 ID# 506-58429U1000L100S0V35) with SMTP id it; Tue, 27 Jun 2000 22:03:14 +0200 Date: Tue, 27 Jun 2000 18:11:28 -0500 X-OldDate: Tue, 27 Jun 00 15:36:53 EST Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: hotspickerz@yahoo.com To: subscriber019@maila.unige.ch Subject: Ftp-WG: HOT STOCK: SKRM (otc) ($3/shr) TECHNOLOGY BREAKTHROUGH! PM-R-release. ATTN Subscriber: COMPUTER TECHNOLOGY BREAKTHROUGH otc symbol: SKRM $3 per share our Short Term Target: $12 - $15 we rate SKRM a STRONG BUY Skreem's Software Tests By KeyLabs Show Up To 300% Spee Increases Skreem's Software Tested by the Nation's Largest Independent Software Testing Firm. WINTER PARK, Fla., June 27 /PRNewswire/ -- Skreem Corporation (OTC Bulletin Board: SKRM - news) announced today that its first software release, Skreem Fast!, has successfully been tested by KeyLabs, Inc., the largest independent software testing company in the US. KeyLabs is one of the industry's most reputable testing firms, having tested software for companies such as: Microsoft, Novell, IBM, Compaq, Sun Microsystems, Hewlett Packard, Intel, Samsung and Gateway 2000. Jacob Nguyen, Vice President of Skreem, stated, ``We are very excited about the performance testing results from KeyLabs. This third-party testing has shown that our Skreem Fast! computer acceleration software makes computers clock in up to 300% faster on many every day PC operations. KeyLabs performed industry standard and custom benchmark testing using various PC platforms, independently verifying and validating each functioning component of the Skreem Fast! software. We've found that, on average, Pentium computers can perform at Pentium II speeds after Skreem Fast! was installed and Pentium II computers can perform at Pentium III levels after Skreem Fast! Even the latest Pentium III computers have shown marked improvements, often increasing by up to 200% in performance in many testing categories.'' Mr. Nguyen continued, ``By using customized topologies and design configurations, KeyLabs also tested Skreem Fast's architectural limits. Our analysis of the test results shows that the product has immense scalability. Whether a consumer uses an older Pentium PC with 32 megs of RAM or a newer Pentium III, they will notice dramatic performance and stability enhancements through Skreem Fast!' About KeyLabs, Inc. KeyLabs utilizes more than 1300 computer systems, disk imaging automation tools and professional rips with some of the industry's leading hardware and software vendors. With a 40,000 square foot facility wired with 62 miles of the fastest available enhanced Cat-5 data cable, KeyLabs has the most state-of-the art facility for testing software products that is available in the industry today. KeyLabs is a subsidiary of Exodus Communications, Inc. (Nasdaq: EXDS - news), a leader in complex Internet hosting and managed services. About Skreem Corporation Skreem is a fully reporting technology-driven marketing firm with two divisions: Skreem Technologies and Skreem Consulting. Thomas Tedrow, President of Skreem, stated, ``The Company is a new breed technology firm focused on the fundamentals. In the past year, by controlling our costs, we acquired a software firm, opened our office and R&D facility, created five hot new software products, have two pending acquisitions and still have almost half of our shareholders' original million-dollar investment set aside. This doesn't even include the success of our Skreem Consulting division's portfolio of consulting fees which we've taken in equity from the firms we've worked with.'' Skreem will soon be launching additional software products, such as Skreem MP3, Skreem Net Jet and Skreeming Media. Safe Harbor Statement Under The Private Securities Litigation Reform Act of 1995: The statements in the press release that relate to the company's expectations with regard to the future impact on the company's results from new products in development are forward-looking statements within the meaning of the Private Securities Litigation Reform Act of 1995. The results anticipated by any or all of these forward-looking statements may not occur. _______________________________________________ This message is for informational purposes. As always do your own due diligence before making any investments of any kind. We are a small independent group of investors who feel very positive about this company and do hold long position. From ftp-wg-owner@hethmon.com Wed Jun 28 19:05:55 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA06140 for ; Wed, 28 Jun 2000 19:05:53 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000628180301-13635-21 ; Wed, 28 Jun 2000 18:03:01 -0500 Received: from havoc.entera.com (havoc.entera.com [206.165.109.130]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000628180258-63480-20 ; Wed, 28 Jun 2000 18:02:58 -0500 Received: from entera.com ([208.48.116.174]) by havoc.entera.com (Post.Office MTA v3.5.3 release 223 ID# 0-61971U200L100S0V35) with ESMTP id com for ; Wed, 28 Jun 2000 15:58:01 -0700 Message-ID: <395A8363.EB0CE229@entera.com> Organization: Entera, Inc. X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.7 i86pc) X-Accept-Language: en MIME-Version: 1.0 References: <23432.960838038@mundamutti.cs.mu.OZ.AU> <4.3.2.7.2.20000612154117.00b3b100@mail.io.com> <394677C5.18CB4CE7@entera.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 28 Jun 2000 18:02:59 -0500 X-OldDate: Wed, 28 Jun 2000 15:59:47 -0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Stephen Head To: ftp-wg@hethmon.com Subject: Ftp-WG: Re: thoughts on MSLx and MAY/SHOULD for fqpathnames Content-Transfer-Encoding: 7bit I have received no objections to the thoughts I had on this topic in response to my request for same. Perhaps this is a good omen. I will be moving on from my current Silicon Valley anthill to the next, so if anyone has any questions for me feel free to reach me at eclectix _AT_ pacbell _DOT_ net Thanks to all for their patience and good luck, Steve Head Entera ----- Stephen Head wrote: > I had some offline discussions about the comparative merits of changing > some wording in some cases in 7.3.1 to make reporting the fully qualified > pathname always recommended (ie SHOULD), versus required (MUST), > versus other possible options for the TVFS case. SHOULD already > seems to apply for the TVFS MLST CRLF case (ie no argument in request). > ... From ftp-wg-owner@hethmon.com Wed Jun 28 19:34:02 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA06482 for ; Wed, 28 Jun 2000 19:34:02 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000628182852-48676-12 ; Wed, 28 Jun 2000 18:28:52 -0500 Received: from mail.firmnet.ch (mail.firmnet.ch [193.192.234.196]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000628182848-34779-6 ; Wed, 28 Jun 2000 18:28:49 -0500 Message-Id: <20000628182848-34779-6@mail.hethmon.com> Received: from liahs12 (detroit-ip-9-232.dynamic.ziplink.net [209.206.123.232]) by mail.firmnet.ch with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id N5Q1TGB5; Thu, 29 Jun 2000 01:29:33 +0200 Date: Wed, 28 Jun 2000 18:28:50 -0500 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: To: satsystems@hotmail.com Subject: Ftp-WG: Get a FREE Deluxe Satellite T.V. System ... FREE SATELLITE T.V. SYSTEM

Watch over 500 channels of Digital Broadcast quality television on
your own FREE satellite television system. These new Digital satellite
systems use the new 18 inch satellite dish antenna.

For a limited time we'll give you this top of the line
Digital Satellite System for FREE!
We'll even include Free installation!

This is a top of the line system with features like on screen graphics, 2
dual LNB's, stereo receiver and infrared remote.

All you have to do is call us to arrange delivery and order the channels you
want to receive. The monthly cost of satellite television is usually
much less than cable T.V and satellite television offers over 500
channels of all digital broadcast video quality and CD audio sound.
You even get local channels now. Don't miss this offer it's only available
while supplies last.


For your Free Satellite System call 888-514-6881
24 hours a day.



Click Here to be removed. From ftp-wg-owner@hethmon.com Wed Jun 28 21:58:55 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA08323 for ; Wed, 28 Jun 2000 21:58:54 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000628205851-62555-11 ; Wed, 28 Jun 2000 20:58:51 -0500 Received: from ktcfweb.ktcf.co.kr (203.229.144.140 [203.229.144.140]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000628205844-34068-7 ; Wed, 28 Jun 2000 20:58:48 -0500 Received: from mail.minmsecretss.com (ktcffw [10.10.10.1]) by ktcfweb.ktcf.co.kr (8.9.3+Sun/8.9.1) with SMTP id KAA06347; Thu, 29 Jun 2000 10:49:19 +0900 (KST) Message-ID: <00002c274fe9$000048f3$00005e92@mail.nmssoftspy.com> X-Priority: 3 X-MSMail-Priority: Normal Date: Wed, 28 Jun 2000 20:58:48 -0500 X-OldDate: Wed, 28 Jun 2000 20:33:12 -0500 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: aralexandra@mail.infoquelle.de To: Subject: Ftp-WG: A Million Dollars? 2 Ways To Get It... $$$ A MILLION DOLLARS? $$$ 2 WAYS TO GET IT - THE SIMPLE FACT IS YOU CAN WIN IT OR WORK FOR IT! THIS E-MAIL PROVIDES INFORMATION ON BOTH METHODS PLUS PLENTY OF FREE BONUSES! CHECK YOUR AREAS OF INTEREST: -- You are receiving this message because you were referred or requested additional information from our Opt In Mailing List. If you would like to have your address removed from our Opt In listserver, see the end of this message. ** Check boxes of interest and fax back to 770/234-5340 ** [ ] Show me where to register on line (for free!) where I can win a million dollars in prizes [ ] Tell me how I can make money part time in a home based business with little or no risk. Best time to call me is ______am or ______pm [ ] How can I get a free website and information on a visa/mc merchant account [ ] Send me your list of free special money making reports [ ] Where can I receive unlimited long distance calls for less than $60 per month with direct dial access [ ] I am a serious bus opp seeker, if you have a legitimate opportunity to make immediate and residual income contact me ASAP. For the right business, I have $_________to invest. My current profession is ________________________________________________________. $$ Fax Back For Immediate Response to: 770/234-5340 $$ Name______________________________________________ Phone_______________________Fax____________________ E-Mail_____________________________________________ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To be taken off of this listserver, Please include the word R in the subject header to: zestful5@china.com From ftp-wg-owner@hethmon.com Thu Jun 29 03:56:53 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24089 for ; Thu, 29 Jun 2000 03:56:52 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000629025257-57037-8 ; Thu, 29 Jun 2000 02:52:57 -0500 Received: from kc.ac.kr (210.100.244.1 [210.100.244.1]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000629025248-29773-8 ; Thu, 29 Jun 2000 02:52:52 -0500 Received: by kc.ac.kr id AA09363; Thu, 29 Jun 2000 16:36:05 +0900 Received: from guidespy4u28@juno.com by guidespy4u29@juno.com (8.8.5/8.6.5) with SMTP id GAA04468 for ; Thu, 29 Jun 2000 02:09:00 -0600 (EST) Message-Id: <> Date: Thu, 29 Jun 2000 02:52:55 -0500 X-OldDate: Thu, 29 Jun 00 02:09:00 EST Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: guidespy4u28@juno.com To: guidespy4u29@juno.com Subject: Ftp-WG: INTERNET SPY GUIDE finds info! READY TO KNOW? CONFIDENTIAL! The SOFTWARE They Want BANNED In all 50 STATES. Why? Because these secrets were never intended to reach your eyes... Get the facts on anyone! Locate Missing Persons, find Lost Relatives, obtain Addresses and Phone Numbers of old school friends, even Skip Trace Dead Beat Spouses. This is not a Private Investigator, but a sophisticated SOFTWARE program DESIGNED to automatically CRACK YOUR CASE with links to thousands of Public Record databases. Find out SECRETS about your relatives, friends, enemies, and everyone else! Even your spouse! With the New, INTERNET SPY AND YOU! It's absolutely astounding! Here's what you can learn. License plate number! Get anyone's name and address with just a license plate number! (Find that girl you met in traffic!) Driving record! Get anyone's driving record! Social security number! Trace anyone by social security number! Address! Get anyone's address with just a name! Unlisted phone numbers! Get anyone's phone number with just a name even unlisted numbers! Locate! Long lost friends, relatives, a past lover who broke your heart! E-mail! Send anonymous e-mail completely untraceable! Dirty secrets! Discover dirty secrets your in-laws don't want you to know! Investigate anyone! Use the sources that private invesigators use (all on the Internet) secretly! Ex-spouse! Learn how to get information on an ex-spouse that will help you win in court! (Dig up old skeletons)! Criminal search Background check! Find out about your daughter's boyfriend! Find out! If you are being investigated! Neighbors! Learn all about your mysterious neighbors! Find out what they have to hide! People you work with! Be astonished by what you'll learn about people you work with! Education verification! Did he really graduate college? Find out! Internet Spy and You! Software will help you discover ANYTHING about anyone, with clickable hyperlinks and no typing in internet addresses! Just insert the floppy disk and Go! You will be shocked and amazed by the secrets that can be discovered about absolutely everyone! Find out the secrets they don't want you to know! About others, about yourself! It's INCREDIBLE what you can find out using Internet Spy and You and the Internet! You'll be riveted to your computer screen! Get the software they're trying to ban! Before it's too late! LIMITED TIME OFFER ORDER TODAY! Only $24.95 We will RUSH YOU our Internet Spy and You SOFTWARE so you can begin discovering all the secrets you ever wanted to know! You can Know EVERYTHING about ANYONEwith our Internet Spy and You Software. Works with all browsers and all versions of AOL! ORDER TODAY. SEND ONLY $24.95 US CASH, CHECK, OR CREDIT CARD (you may also send one of your own address labels for accuracy if you have one). Foreign money orders must be payable on a US BANK AND IN US FUNDS! NO EXCEPTIONS! DON'T WAIT TO GET STARTED...It's as easy as 1, 2, 3. STEP 1 - Print the order form text below. STEP 2 - Type or print your order information into the order form section. STEP 3 - Mail order form and payment to the address below. Send to: INFORMATION PLUS PO BOX 9889 PCBEACH, FL 32417 U.S.A. FUNDS Name: ________________________________________ Address: _______________________________________ City/State/Zip: ___________________________________ FOR CREDIT CARD ORDERS ONLY! Account Number: ____________________________________ Exp. Date: ________________________ DISCLAIMER: The seller of this powerful software resource will not be held responsible for how the purchaser chooses to use it's resources. To be removed from our mailing list rspot@dcemail.com and put remove in the subject. Thank you From ftp-wg-owner@hethmon.com Thu Jun 29 04:33:44 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA24470 for ; Thu, 29 Jun 2000 04:33:43 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000629033248-57836-13 ; Thu, 29 Jun 2000 03:32:48 -0500 Received: from bios1 (bios1.quimicae.unam.mx [132.248.125.20]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000629033244-29270-6 ; Thu, 29 Jun 2000 03:32:45 -0500 Received: from mail.undercovernms.com by bios1 via SMTP (940816.SGI.8.6.9/940406.SGI) id DAA08090; Thu, 29 Jun 2000 03:24:18 -0700 Message-ID: <0000101a74c3$00002be9$00005fc5@mail.spystuffnms.com> X-Priority: 3 X-MSMail-Priority: Normal Date: Thu, 29 Jun 2000 03:32:46 -0500 X-OldDate: Thu, 29 Jun 2000 02:09:15 -0500 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: naomi12a@im.cti.br To: Subject: Ftp-WG: A Million Dollars? 2 Ways To Get It... $$$ A MILLION DOLLARS? $$$ 2 WAYS TO GET IT - THE SIMPLE FACT IS YOU CAN WIN IT OR WORK FOR IT! THIS E-MAIL PROVIDES INFORMATION ON BOTH METHODS PLUS PLENTY OF FREE BONUSES! CHECK YOUR AREAS OF INTEREST: -- You are receiving this message because you were referred or requested additional information from our Opt In Mailing List. If you would like to have your address removed from our Opt In listserver, see the end of this message. ** Check boxes of interest and fax back to 770/234-5340 ** [ ] Show me where to register on line (for free!) where I can win a million dollars in prizes [ ] Tell me how I can make money part time in a home based business with little or no risk. Best time to call me is ______am or ______pm [ ] How can I get a free website and information on a visa/mc merchant account [ ] Send me your list of free special money making reports [ ] Where can I receive unlimited long distance calls for less than $60 per month with direct dial access [ ] I am a serious bus opp seeker, if you have a legitimate opportunity to make immediate and residual income contact me ASAP. For the right business, I have $_________to invest. My current profession is ________________________________________________________. $$ Fax Back For Immediate Response to: 770/234-5340 $$ Name______________________________________________ Phone_______________________Fax____________________ E-Mail_____________________________________________ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To be taken off of this listserver, Please include the word R in the subject header to: zestful5@china.com From ftp-wg-owner@hethmon.com Thu Jun 29 18:46:57 2000 Received: from mail.hethmon.com ([208.147.156.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21786 for ; Thu, 29 Jun 2000 18:46:57 -0400 (EDT) Received: from mail (208.147.156.32 [208.147.156.32]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000629174631-58894-8 ; Thu, 29 Jun 2000 17:46:31 -0500 Received: from kc.ac.kr (210.100.244.1 [210.100.244.1]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20000629174626-31621-6 ; Thu, 29 Jun 2000 17:46:27 -0500 Received: by kc.ac.kr id AA14260; Fri, 30 Jun 2000 07:33:19 +0900 Received: from increasesales2day@yahoo.com by increasesales@yahoo.com (8.8.5/8.6.5) with SMTP id GAA05462 for ; Thu, 29 Jun 2000 17:15:26 -0600 (EST) Message-Id: <> Date: Thu, 29 Jun 2000 17:46:28 -0500 X-OldDate: Thu, 29 Jun 00 17:15:26 EST Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: increasesales2day@yahoo.com To: increasesales@yahoo.com Subject: Ftp-WG: INCREASE BUSINESS SALES! HELLO: THIS IS AN ADVERTISEMENT FOR 50 MILLION E-MAIL ADDRESSES ON CD-ROM. IF YOU HAVE NO INTEREST IN THIS INFORMATION, PLEASE CLICK DELETE. THANK YOU. Dear Consumer, Increase your business sales! How?? By targeting millions of buyers via e-mail !! We are offering over 50 million FRESH, DELIVERABLE, e-mail addresses on CD-ROM. The cd-rom includes targeted addresses, such as business opportuinty seekers, sports buffs, mlm, impulsive buyers and investors. The cd-rom also includes general internet, United States, United kingdom, mixed domains, International, Canadian, earthlink, aol, compuserve, misc and much more. The list's are divided into groups and are compressed. This will allow you to uses the names right off the cd. ORDER IN THE NEXT 7 DAYS AND RECEIVE TWO FREE BONUSES!!! RECEIVE AN ADDITIONAL CD-ROM WITH MILLIONS OF DELIVERABLE E-MAIL ADDRESSES AND THE MASS MAILER BULKING SOFWARE FREE !! THE BONUSES ALONE ARE WORTH ACTING NOW! DON'T MISS THIS SUPER SALE!! ACT NOW!! The bonus cd-rom contains such address as general internet, msn, aol, compuserve, delphi and much more. The Mass mailer bulking software is designed for speed. THIS PACKAGE IS WORTH HUNDREDS OF $$ DOLLARS!! ACT NOW WHILE SUPPLIES LAST! ACT NOW AND RECEIVE ALL THIS FOR A ONE TIME UNBELIEVEABLE LOW, LOW PRICE OF ONLY $99.95 ! THAT'S RIGHT ONLY $99.95 SIMPLY SEND $99.95, check or money order, PAYABLE TO: R GOODWIN SHIP TO: MARKETING AND MORE PO BOX 1862, SANTA ROSA BEACH, FL 32459 ----------------------------------------------------------------------------------------- FOR CREDIT CARD ORDERS print and mail form to the above address You may charge my account for $99.95 for the cd-rom and 2 bonuses. ACCOUNT NUMBER__________________________________ EXPIRATION DATE_________________________________ NAME______________________________________________ ADDRESS___________________________________________ CITY/STATE/ZIP______________________________________ PHONE NUMBER(_____)______________________________ If we have reached you in error, and you would like to be removed ronaldp@china.com