Re: Last Call: An Extension to the Selective Acknowledgement(SACK) Option for TCP to Proposed Standard
The IESG wrote: The IESG has received a request from the Working Group to consider An ^tsvwg Extension to the Selective Acknowledgement (SACK) Option for TCP draft-floyd-sack-00.txt as a Proposed Standard. I thought this was originally proposed as an Experimental RFC - the minutes from the tsvwg DC meeting confirm that. When, how and why was this changed? I didn't see any discussion on the mailing list. jonathan
IETF List maintenance
To remove yourself from the IETF discussion list, send a message to [EMAIL PROTECTED] Enter just the word unsubscribe in the body of the message. NOTE: List requests do not take effect until the next day, and there are always messages in the outbound queue. As such, you may continue receiving messages for a short while after successfully unsubscribing from the list. The IETF discussion list serves two purposes. It furthers the development and specification of Internet technology through discussion of technical issues. It also hosts discussions of IETF direction, policy, and procedures. As this is the most general IETF mailing list, considerable latitude is allowed. Advertising, whether to solicit business or promote employment opportunities, falls well outside the range of acceptable topics, as do discussions of a personal nature. This list is meant for initial discussion only. Discussions that fall within the area of any working group or well established list should be moved to such more specific forum as soon as this is pointed out, unless the issue is one for which the working group needs wider input or direction. In addition to the topics noted above, appropriate postings include: o Last Call discussions of proposed protocol actions o Discussion of technical issues that are candidates for IETF work, but do not yet have an appropriate e-mail venue o Discussion of IETF administrative policies o Questions and clarifications concerning IETF meetings. Inappropriate postings include: o Unsolicited bulk e-mail o Discussion of subjects unrelated to IETF policy, meetings, activities, or technical concerns o Unprofessional commentary, regardless of the general subject. The IETF Chair, the IETF Executive Director, or a sergeant-at-arms appointed by the Chair is empowered to restrict posting by a person or of a thread as they deem appropriate to limit abuse. Complaints regarding their decisions should be referred to the IAB [EMAIL PROTECTED]
Re: Device upload for all platforms -- the official HTML WG position
Dear Dr. Pemberton, Thanks for your message: There is nothing in HTML 4 that excludes any platform. Just look at Opera, which is being implemented on BeOs, Epoc, Linux, Mac Os, OS/2 and Windows. Device upload -- of any kind -- has not yet been implemented in Opera. You know that the CTO of Opera software has said they will wait for a W3C Recommendation (or Working Draft) on device upload. Opera, even on Windows, will not interpret MSIE OBJECT or Netscape EMBED tags which are used for microphone upload on those browsers under Windows. There is simply no browser on Mac or Linux (other than my experimental build of pre-gecko Mozilla) which is capable of even microphone upload. If you had listened to the comments to your proposal when you submitted it, you could have corrected it, and it would be a non-issue. Since 1997, there have been eight revisions, incorporating the useful suggestions from anyone who cared to review and comment on the draft. The basic idea and method remained the same throughout; the significant changes mostly concerned the names of devices. In your case we pointed out there are fundamental flaws in your approach, and indicated how you could fix them. I am sure we both want to resolve this. Would you please list all the flaws of which you are aware -- with as little or as much detail as you have time for -- along with, when available, how they could be fixed? I promise you I will devote my efforts to your comments until you are satisfied that they are resolved, but I do need your help to understand which issues you consider flaws. I will start by addressing the question of whether ACCEPT alone is sufficient for device upload, when used with the INPUT TYPE=FILE element. The problem occurs when an image is requested on a system with both a camera and a scanner. Having a DEVICE attribute allows for the selection of a default, which is reasonable because some conferencing applications might always expect camera input whereas OCR applications would usually expect scanner input. And, as others have pointed out, in compressed media the MAXLENGTH limitation is not as practical as the MAXTIME limitation, in the case where an upload needs to be restricted in size. Does anyone think that this justification is inadequate? Cheers, James
Re: Device upload for all platforms -- the official HTML WG position
Why is this thread being run on the IETF mailing list? The IETF handed off responsibility for HTML to the W3C long ago. If the reason is to show people that someone has a beef with the way that the W3C is handling HTML, that point has been made. (I can already picture certain IETF folks starting to deluge W3C mailing lists when IAB appeals don't go their way...) --Paul Hoffman, Director --Internet Mail Consortium
Re: Device upload for all platforms (why on IETF list?)
Paul, Thanks for your message: Why is this thread being run on the IETF mailing list? Some messages to the W3C lists described as "public" did not appear until my request for endorsements of the device upload draft appeared here. The W3C filters out messages from non-subscribers, but as the archive for the "public" [EMAIL PROTECTED] list shows, they also filter messages that they do not wish to have distributed. Please be patient. The IETF attention to this issue has already been very helpful. We all hope for a resolution soon. Cheers, James
Re: Device upload for all platforms -- the official HTML WG position
On Wed, 01 Mar 2000 22:16:36 GMT, Lloyd Wood said: When did the IETF ever have responsibility for HTML, exactly? Well, searching for 'html' or 'hypertext' in rfc-index.tct, I find: 1866 Hypertext Markup Language - 2.0. T. Berners-Lee, D. Connolly. November 1995. (Format: TXT=146904 bytes) (Status: PROPOSED STANDARD) 1867 Form-based File Upload in HTML. E. Nebel, L. Masinter. November 1995. (Format: TXT=26183 bytes) (Status: EXPERIMENTAL) 1942 HTML Tables. D. Raggett. May 1996. (Format: TXT=68705 bytes) (Status: EXPERIMENTAL) 1945 Hypertext Transfer Protocol -- HTTP/1.0. T. Berners-Lee, R. Fielding H. Frystyk. May 1996. (Format: TXT=137582 bytes) (Status: INFORMATIONAL) 1980 A Proposed Extension to HTML : Client-Side Image Maps. J. Seidman. August 1996. (Format: TXT=13448 bytes) (Status: INFORMATIONAL) 2070 Internationalization of the Hypertext Markup Language. F. Yergeau, G. Nicol, G. Adams, M. Duerst. January 1997. (Format: TXT=91887 bytes) (Status: PROPOSED STANDARD) 2110 MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML). J. Palme, A. Hopmann. March 1997. (Format: TXT=41961 bytes) (Obsoleted by RFC2557) (Status: PROPOSED STANDARD) 2557 MIME Encapsulation of Aggregate Documents, such as HTML (MHTML). J. Palme, A. Hopmann, N. Shelness. March 1999. (Format: TXT=61854 bytes) (Obsoletes RFC2110) (Status: PROPOSED STANDARD) 2659 Security Extensions For HTML. E. Rescorla, A. Schiffman. August 1999. (Format: TXT=8134 bytes) (Status: EXPERIMENTAL) 2731 Encoding Dublin Core Metadata in HTML. J. Kunze. December 1999. (Format: TXT=42450 bytes) (Status: INFORMATIONAL) Obviously we care enough to issue RFCs about them - some are even Proposed Standard.. I've left rfc2324 out of the list.. ;) -- Valdis Kletnieks Operating Systems Analyst Virginia Tech
RE: Device upload for all platforms -- the official HTML WG position
James / Steven: I would encourage both of you to take your "fight" in one-on-one email traffic; I am sure there are lot of people in the ietf www-html mailing lists who are least interested in watching you two taking shots at each other; please show some civility in using group mailing lists. If I see one more email of this nature cluttering my mailbox, I might call CyberCop!!! Thanks -Original Message- From: James P. Salsman [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 01, 2000 2:33 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Device upload for all platforms -- the official HTML WG position Dear Dr. Pemberton, Thanks for your message: There is nothing in HTML 4 that excludes any platform. Just look at Opera, which is being implemented on BeOs, Epoc, Linux, Mac Os, OS/2 and Windows. Device upload -- of any kind -- has not yet been implemented in Opera. You know that the CTO of Opera software has said they will wait for a W3C Recommendation (or Working Draft) on device upload. Opera, even on Windows, will not interpret MSIE OBJECT or Netscape EMBED tags which are used for microphone upload on those browsers under Windows. There is simply no browser on Mac or Linux (other than my experimental build of pre-gecko Mozilla) which is capable of even microphone upload. If you had listened to the comments to your proposal when you submitted it, you could have corrected it, and it would be a non-issue. Since 1997, there have been eight revisions, incorporating the useful suggestions from anyone who cared to review and comment on the draft. The basic idea and method remained the same throughout; the significant changes mostly concerned the names of devices. In your case we pointed out there are fundamental flaws in your approach, and indicated how you could fix them. I am sure we both want to resolve this. Would you please list all the flaws of which you are aware -- with as little or as much detail as you have time for -- along with, when available, how they could be fixed? I promise you I will devote my efforts to your comments until you are satisfied that they are resolved, but I do need your help to understand which issues you consider flaws. I will start by addressing the question of whether ACCEPT alone is sufficient for device upload, when used with the INPUT TYPE=FILE element. The problem occurs when an image is requested on a system with both a camera and a scanner. Having a DEVICE attribute allows for the selection of a default, which is reasonable because some conferencing applications might always expect camera input whereas OCR applications would usually expect scanner input. And, as others have pointed out, in compressed media the MAXLENGTH limitation is not as practical as the MAXTIME limitation, in the case where an upload needs to be restricted in size. Does anyone think that this justification is inadequate? Cheers, James
Re: 47th IETF: ITRACE BOF
For those who are interested in the ITRACE BoF, there is a mailing list [EMAIL PROTECTED] Subscribe by sending the message body subscribe to [EMAIL PROTECTED] --- ICMP Traceback BOF (itrace) Thursday, March 30 at 1530-1730 === CHAIR: Steve Bellovin [EMAIL PROTECTED] DESCRIPTION: The purpose of the BoF is to look at a mechanism to help address the problem of tracing back denial of service attacks. The suggested mechanism is that with low probability (order 1/20,000), a router seeing a packet would send to the destination an ICMP message giving as much information as it knows about the immediate previous hop of that packet. With enough of these messages -- and if one is being flooded, by definition there will be a lot of traffic, so that the low probabilities will still result in a reasonably complete set of traceback packets. Such a mechanism has other uses as well. It lets people trace down the source of accidentally-emitted bogus packets, i.e., those with RFC1918 addresses. It helps characterize the reverse path, which traceroute does not do. The output will be a standards-track RFC describing the packet format, and the conditions under which it should be sent. Issues include authentication, router load, and host load. AGENDA: Introduction, motivation15 min Marcus Leech's prototype20 min Open issues list30 min Charter 20 min --Steve Bellovin
Re: 47th IETF: ITRACE BOF
"Steven M. Bellovin" writes: For those who are interested in the ITRACE BoF, there is a mailing list [EMAIL PROTECTED] Subscribe by sending the message body subscribe to [EMAIL PROTECTED] I love sending followups to my own notes... The body of the message should, of course, be subscribe ietf-itrace --Steve Bellovin
