Re: email document delivery service
--On Thursday, February 03, 2005 7:57 PM -0500 stanislav shalunov [EMAIL PROTECTED] wrote: Internet-draft announcements, as they are currently generated, include a MIME-based mechanism to request internet-drafts via email. Do you use this feature? If you do, could you please let me know? Background: the IETF Tools team is working on a draft, draft-ietf-tools-notification-03.txt, that specifies the requirements for a document notification service. We'd like to better understand how email document delivery is actually used. Please be a little bit careful about how and where this question is asked. Most of the active participants in the IETF have reasonably good, online, access to the Internet with cost-effective bandwidth (at least much of the time). But there are people for whom those things are not the case, but who want to track our work and should be able to do so. They may or may not read the open IETF list but, given recent volume surges, I'd guess most of them do not. For them, the email access, and maybe even the remote-body-part access, can be important features -- more important, perhaps, for RFC retrieval than for I-D retrieval, but important nonetheless. While I'm on the subject, --On Friday, February 04, 2005 8:41 AM + Tim Chown [EMAIL PROTECTED] wrote: Hi, Our anti-virus system tags all IETF draft announcements as being potentially dangerous. I suspect because of the unusual options to fetch the data that are encoded in the MIME header. We would certainly like to see that feature removed from IETF announcements, as it seems archaic. This may not be within the remit of your draft, but you may wish to consider what effect various MIME options have on anti-virus systems, and potential vulnerabilities that lie within them. Hmm. There is a case to be made that those external body part options are as safe, or safer, than a delivered attachment: you can, in principle, inspect either before opening or executing it, but I can easily imagine one of those a good/fun user experience is more important than security or bullet-proof-ness MUAs being designed to provide better access for an actual virus-checker for the external body parts. Certainly an external body part is as safe and probably safer than an imbedded URL, especially in an MUA that opens those URLs automatically. So my instinctive response to that request is have you considered getting your anti-virus software fixed?. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Something to look forward to at the meeting
Maybe the story that URL points to is not the one you intended, or I am missing something here, or misinterpreting. In which case I apologise in advance. http://www.startribune.com/stories/368/5217727.html So the trains have to slow down for a minute or two. Your point is? Why has it become the in-thing to find any little niggle against the places the meetings are being arranged in? An exceptional summer two years ago in Paris, a small leak in a tunnel. The fact that some places are in the US. The fact that others aren't. I'm not in the US, but if IETF meetings were to cycle between Salt Lake City, Minneapolis and some other place for the rest of time it wouldn't bother me too much. Given how many people find it difficult to leave the hotel for the week of the meeting, I'm suprised anybody really cares where the meetings actually are. I'd like to thank Foretec and the secretariat for all the work that goes into the meetings. It must be tough trying to keep even some of us happy some of the time. :-) Regards, Rob ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Implementations of RFC 3460 or 3060
I want to try out in the lab some implementations (products or lab/research versions) of Policy Framework as in RFC 3460 or 3060. However I can not find any such implementations. If you are aware of some, I will appreciate any information or pointers. There is PONDER tool for policy specification from Imperial College, UK. It is desired to inter work PONDER with RFC implementations. PONDER can output policies in XML and Java. My thanks and regards. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: email document delivery service
Hi, Our anti-virus system tags all IETF draft announcements as being potentially dangerous. I suspect because of the unusual options to fetch the data that are encoded in the MIME header. We would certainly like to see that feature removed from IETF announcements, as it seems archaic. The arhaic feature you refer to is how I customarily fetch drafts to look at. I wouldn't look at nearly as many if it were removed. I suspect I'm not alone in this. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: email document delivery service
John C Klensin wrote: --On Friday, February 04, 2005 8:41 AM + Tim Chown wrote: Our anti-virus system tags all IETF draft announcements as being potentially dangerous. I suspect because of the unusual options to fetch the data that are encoded in the MIME header. Hmm. There is a case to be made that those external body part options are as safe, or safer, than a delivered attachment: you can, in principle, inspect either before opening or executing it, but I can easily imagine one of those a good/fun user experience is more important than security or bullet-proof-ness MUAs being designed to provide better access for an actual virus-checker for the external body parts. Certainly an external body part is as safe and probably safer than an imbedded URL, especially in an MUA that opens those URLs automatically. So my instinctive response to that request is have you considered getting your anti-virus software fixed?. Our firewall software here also briefly tagged message/external-body attachments as dangerous. Instead of just removing the attachment, the software deleted the entire message and sent a note saying that they had done so. Whoever had installed the software just didn't get it; it took us a bit to get them to fix it. Even more fearful, I have a feeling that they were just following instructions provided by the firewall software people, who SHOULD know better. Tony Hansen ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: email document delivery service
[tangent alert!] On Fri, 04 Feb 2005 13:43:56 -0500, Tony Hansen [EMAIL PROTECTED] wrote: Even more fearful, I have a feeling that they were just following instructions provided by the firewall software people, who SHOULD know better. Heh. You're giving quite a bit of credit to a class of people (firewall software people) who shipped a default set of rules for our stateful-inpsection firewall that included a rule TCP packets on the FTP control channel must end with CRLF. So much for being able to connect to any site that has a welcome banner larger than the MSS... Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: 1918bis
Tony == Tony Hain [EMAIL PROTECTED] writes: Tony and now the replacement ULA space is unable to be published Tony as it is dragging out in an interminable discuss state. I see no discusses on draft-ietf-ipv6-unique-local-addr. I have not been following the document though since I cleared my discuss on Jan 24. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Internet-Draft Submission Cutoff Dates for the 62nd IETF Meeting in Minneapolis, MN
There are two (2) Internet-Draft cutoff dates for the 62nd IETF Meeting in Minneapolis, MN: February 14th: Cutoff Date for Initial (i.e., -00) Internet-Draft Submissions All initial Internet-Drafts (-00) must be submitted by Monday, February 14th at 9:00 AM ET. As always, all initial submissions (-00) with a filename beginning with draft-ietf must be approved by the appropriate WG Chair before they can be processed or announced. WG Chair approval must be received by Monday, February 7th at 9:00 AM ET. February 21st: Cutoff Date for Revised (i.e., -01 and higher) Internet-Draft Submissions All revised Internet-Drafts (-01 and higher) must be submitted by Monday, February 21st at 9:00 AM ET. Initial and revised Internet-Drafts received after their respective cutoff dates will not be made available in the Internet-Drafts directory or announced, and will have to be resubmitted. Please do not wait until the last minute to submit. The Secretariat will begin accepting Internet-Draft submissions starting Monday, March 7th at 9:00 AM ET, but may not post or announce them until Monday, March 14th. Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to [EMAIL PROTECTED] The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 62nd IETF Meeting can be found at http://www.ietf.org/meetings/IETF-62.html. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
62nd IETF - Overflow Hotels
We have a group rate at the following hotels for the 62nd IETF Meeting: Marquette Hotel Minneapolis Doubletree Information on these hotels can be obtained on our website at: http://www.ietf.org/meetings/hotels_62.html Doubletree Guest Suites Minneapolis 1101 LaSalle Avenue Minneapolis, MN 55403 Tel: 1-612-332-6800 Fax: 1-612-332-8246 Website: Go to Minneapolis Doubletree Website Click on On-line reservation, Group/Convention code IET. Room rates: - Single/Double: USD 139.00* - Triple: USD 159.00* - Quad: USD 179.00* * All rates are subject to 13% tax. Check-In: after 15:00 CST; Check-Out: prior to 12:00 CST Specify: Internet Engineering Task Force or IETF Airport Transportation: Express Shuttle services the hotel 5 minutes to the hour and 25 minutes after the hour to the hotel and back: Sunday-Saturday from 06:30 - 22:30. Location: The hotel is located in the heart of Downtown Minneapolis and a 2 blocks from the Minneapolis Hilton Hotel. Van transportation in the Downtown is available bas ed on availability and is at no cost to the Hotel guests. The Marquette Hotel-Minneapolis 710 Marquette Avenue Minneapolis, MN USA 55402-2368 Tel: 1-612-376-7400 or 1-800-328-4782 Fax: 1-612-288-2188 Email: [EMAIL PROTECTED] Room rates: (a block of rooms have been reserved until Friday, February 18, 2005) USD 149.00 - Deluxe Single/Double Occupancy USD 169.00 - Corner Room Single/Double Occupancy USD 189.00 - Executive Floor Single/Double Occupancy *These rates do not include sales tax on guest rooms which is currently 13%. This is subject to change without notice. Check-In: 15:00 CST; Check-Out: 12:00 CST Specify: IETF or Internet Engineering Task Force Meeting Reservation Procedure: Reservation should be made Monday through Friday, 08:00 to 18:00 Central Standard Time. Reservations must be made directly to the hotel at 1-612-376-7400 or 1-800-328-4782. Attendees must specify the name of the meeting in order to assure the group rate. You can also fax your reservation: 1-612-288-2188 or email: [EMAIL PROTECTED] Guarantee policy: The hotel requires a major credit card, payment in advance of the first night full room charge, or organization guarantee based on approved direct billing status in order to guarantee all reservations. Costs attributable to any room reservation not canceled 72 hours (local hotel time) prior to the specified day of arrival will be charged 1st night room and tax. Departure date can be modified until arrival, after which USD 50.00 charge will apply for early departure. Incidental Charges: Individuals will be responsible for their own incidental charges. Incidental charges which are not cleared by guests upon check-out will be charged to the individual credit card. Please be aware that some charges, especially mini bar, phone charges, and breakfast on day of check-out, may not be caught at the time of guest check-out will be charged later. Location: The hotel is about a 3 blocks from the Minneapolis Hilton and is walkable through the skyway system. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 3984 on RTP Payload Format for H.264 Video
A new Request for Comments is now available in online RFC libraries. RFC 3984 Title: RTP Payload Format for H.264 Video Author(s): S. Wenger, M.M. Hannuksela, T. Stockhammer, M. Westerlund, D. Singer Status: Standards Track Date: February 2005 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 83 Characters: 205093 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-ietf-avt-rtp-h264-11.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc3984.txt This memo describes an RTP Payload format for the ITU-T Recommendation H.264 video codec and the technically identical ISO/IEC International Standard 14496-10 video codec. The RTP payload format allows for packetization of one or more Network Abstraction Layer Units (NALUs), produced by an H.264 video encoder, in each RTP payload. The payload format has wide applicability, as it supports applications from simple low bit-rate conversational usage, to Internet video streaming with interleaved transmission, to high bit-rate video-on-demand. This document is a product of the Audio/Video Transport Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc3984.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
