flying pigs considered harmful
> The only > way to obtain device upload does not even involve the INPUT tag > (on Windows' MSIE, the OBJECT tag is used with an insecure > "ActiveX" binary; on Netscape Navigator under Windows, the EMBED > tag is used with a similarly insecure arrangement where the user > must "Grant All" system privleges to the EMBEDed binary code.) Yes, well, one could probably use OBJECT/EMBED to make pigs fly if one were so inclined and prepared to waive the relevant security precautions. Such implementations are interesting in that they demonstrate the availability of the technology, but the applicability of their syntax to a general purpose mechanism for a specific need is low to nil. This situation is by no means unique to device upload, nor is it a particularly surprising outcome. > This complex state of affairs need not be so. > > If the W3C would just take a stand, and tell the browser vendors > that in order to be compliant with the W3C Recommendations, if > device upload is implemented then it should be available in a > certain way, then they would probably conform to stay compliant. The W3C has defined conformance terms for HTML 4, CSS1, CSS2... And how many browsers conform to date? I'm a little bit skeptical that having the W3C stomp its feet would do a bit of good.
Re: flying pigs considered harmful
Line noise transmitted the message below unattributed; my apologies to Braden McDaniel. >> [JPS:] The only >> way to obtain device upload does not even involve the INPUT tag >> (on Windows' MSIE, the OBJECT tag is used with an insecure >> "ActiveX" binary; on Netscape Navigator under Windows, the EMBED >> tag is used with a similarly insecure arrangement where the user >> must "Grant All" system privileges to the EMBEDed binary code.) > > [BNM:] Yes, well, one could probably use OBJECT/EMBED to make pigs > fly if one were so inclined and prepared to waive the relevant > security precautions. The security concerns are actually more significant than the "it won't run on my Mac/Unix workstation" -- at least for the majority that don't have Mac or Unix workstations. Promiscuous use of insecure binary plug-in applications is another reason against OBJECT and EMBED. >> If the W3C would just take a stand, and tell the browser vendors >> that in order to be compliant with the W3C Recommendations, if >> device upload is implemented then it should be available in a >> certain way, then they would probably conform to stay compliant. > > The W3C has defined conformance terms for HTML 4, CSS1, CSS2... And how > many browsers conform to date? I'm a little bit skeptical that having the > W3C stomp its feet would do a bit of good. It is completely reasonable for the W3C to act in the general interest of web users. Supporting device upload would be in their interest because of the reduced security concerns, the more widespread accessibility on a diversity of platforms, and the general utility of the services enabled for education, commerce and industry. I believe the W3C will try to hold on to its leadership role in consumer protection pertaining to browser technology. Cheers, James
Re: 1601bis -03: Still Vague
At 03:32 PM 3/3/00 +0800, Rahmat M. Samik-Ibrahim wrote: >The role descriptions of section 2 remains vague. Thus, the relation >with IANA and the RFC Editor will remain vague. It seems quite clear to me. You might want to suggest alternative wording that you think is clearer. > No wonder, if the >RFC Editor once has claimed: >"The RFC Editor is chartered by the Internet Society (ISOC) > and the Federal Network Council (FNC)" >(http://www.faqs.org/rfcs/rfc-editor/what-is-rfc-editor.html) That might have been true at one point, and things have changed. What's the problem with that? --Paul Hoffman, Director --Internet Mail Consortium
4th IEEE International Workshop on Systems Management
Call for Papers - We apologize if you receive this message more than once. This represents a change of dates due to e-mail distribution problems. ***New date for submissions is April 3, 2000*** IEEE 4th International Workshop on Systems Management (Theme: Exploitation of Data Mining and Visualization Age) Montreal Quebec, Canada June 28-30, 2000 This workshop is the fourth in a series of highly successful forums for the discussion of research in the area of systems management. Previous workshops have been held in Los Angeles, California, Toronto, Ontario, and Newport, RI. This year the scope of this workshop is mining, visualization, management, and acquisition of data for network and systems management. With the widespread adoption of standards for data collection (e.g., SNMP in data networks CMIP in telecommunications networks) and the growing acceptance of technologies for information modeling (e.g., UML, XML, and CIM), the next challenge for network and systems management is interpreting the data. These interpretations should be task oriented, such as for problem detection, problem diagnosis, and planning. The purpose of this workshop is to bring together researchers with in-depth knowledge of data interpretation and presentation to focus on challenges of network and systems management. These challenges include: heterogeneous data semantics, dealing with large data volumes, noisely data, high dimensional data, dearth of labelled data for supervised learning, and the exploitation of underlying structure (e.g., based on network topologies). To aid in our objective, several data sets will be provided in advance of the workshop, along with some background about the kinds of information that should be extracted. Workshop participants are encouraged to submit papers (or extended abstracts) that apply their techniques to these data. The URL for our site is http://www.csd.uwo.ca/SMW4. WORKSHOP FORMAT --- Three kinds of participation are possible. The first are presenters of full papers that fall within the topic areas considered by this workshop. The second are those who report on the results of mining and/or visualizing network and systems management data made available for this workshop, which can be found under Dataset Information at http://www.csd.uwo.ca/SMW4/. This data has been provided by Cooperative Association for Internet Data Analysis (CAIDA). Also encouraged is participation by individuals seeking information on recent advances in the application of data mining and visualization to network and systems management. An award will be presented to the best paper that provides the best insight into the analysis (visualisation or patterns) of the skitter data (please see "Dataset Information" at http://www.csd.uwo.ca/SMW4/). CALL FOR PARTICIPATION -- All submitted papers will be reviewed by experts in the area of submission. Individuals presenting the results of analyses of the data sets provided by this workshop should submit an extended abstract summarizing their methodology and results. All accepted contributions (including extended abstracts) will be eligible for publication in the bound proceedings of the workshop. At least one of the authors of each paper must register for the workshop to present the paper. Papers are to be submitted in English. The cover page should include paper title, author(s) full name, affiliations, complete address(es), telephone number(s), and electronic mail address(es). Full-length papers should have a brief abstract and be no longer than 12 pages (6,000 words), including references and figures. Extended abstracts should be in the format of an extended abstract that is no longer than 2 pages (1,000 words), excluding figures. Proposals for panel discussions are also solicited. Panels are scheduled for 1.5 hours. Proposals should specify the topic, panel chair, and participants. Please include a two page abstract that highlights key points for discussion and areas of controversy that will be addressed. SUBMISSION -- All submissions should be sent by email in postscript or pdf form to [EMAIL PROTECTED] with the subject line "SMW4 Paper Submission: ," where indicates the compression used if any (e.g., paper.ps.gz). If electronic submission is not possible, please submit 4 paper copies to the following address: Professor Hanan Lutfiyya Department of Computer Science The University of Western Ontario London, Ontario CANADA N6A 5B7 TOPICS -- Application of data mining algorithms to network and systems management Scalable and effective visualizations for management tasks Efficient techniques for on-line pattern recognition (e.g., for detecting performan
Re: Who is interested in wireless cards for the Adelaide IETF meeting?
At 12:57 PM 2/15/00 +1030, Mark Prior wrote: >The package being offered is a WaveLAN IEEE Turbo 11Mbps PC card for >AU$276.36 (approx US$175). Drivers are available from Lucent for (at >least) Windows 95, 98, NT, CE, 2000, MacOS and Linux. Searching for "WaveLAN" at a catalog site shows (prices are in US$): LUCENT TECHNOLOGIES WaveLAN Turbo 11Mbps Wireless PC Card Silver; WEP $159.95 LUCENT TECHNOLOGIES WaveLAN Turbo 11Mbps Wireless PC Card Gold; 128RC4 $176.95 LUCENT TECHNOLOGIES WaveLan Wireless Bronze PC Card *While Supplies Last $235 LUCENT TECHNOLOGIES WaveLAN IEEE Bronze PC Card *Special Order $239.95 Could someone explain the differences between these? Is the first one the same as what is being offered? If so, it appears to be cheaper to buy it in the US.
Re: Who is interested in wireless cards for the Adelaide IETF meeting?
> At 12:57 PM 2/15/00 +1030, Mark Prior wrote: > >The package being offered is a WaveLAN IEEE Turbo 11Mbps PC card for > >AU$276.36 (approx US$175). Drivers are available from Lucent for (at > >least) Windows 95, 98, NT, CE, 2000, MacOS and Linux. I'm certainly not an expert on this stuff, but as it happens I've been playing around with a bunch of it recently both at home and at work. My comments below are based on this experience. > Searching for "WaveLAN" at a catalog site shows (prices are in US$): > LUCENT TECHNOLOGIES > WaveLAN Turbo 11Mbps Wireless > PC Card Silver; WEP > $159.95 This is the same card as an Apple Airport. It is 802.11 DS, 11Mbps, and supports Wire Equivalent Privacy (WEP). The idea here is that you need a key to get on the network, but once you're on you can see all the traffic "on the wire" that you care to. The Apple softare only lets you set a 40 bit key (actually what you do is enter a passphrase that is hashed down to 40 bits), but I believe a 64 bit key is supported by the underlying hardware. I don't know what the underlying crypto is -- probably DES, which of course means the key length is really only 56 bits... Unfortunately the Windows 2000 driver for this card doesn't yet support WEP. They say they are working on it. Amusingly, the Windows 95/98 driver does support WEP and it works just fine with an Apple Airport Base Station as long as you have a Mac with an Airport card to set up the base station to begin with. (Actually, even that probably isn't required unless you want to enable WEP or DHCP or NAT or some other option.) All this stuff about security probably isn't relevant in the IETF context, of course, but it nice if you what you get also is useful at home where network security may matter a bunch. $159 is about the same price I've seen for this card in the US. > LUCENT TECHNOLOGIES > WaveLAN Turbo 11Mbps Wireless > PC Card Gold; 128RC4 > $176.95 I believe this is the same as the Silver except the crypto is 128 bit. > LUCENT TECHNOLOGIES > WaveLan Wireless Bronze PC Card > *While Supplies Last > $235 I believe this card only operates at the slower 1-2 MBps rate. This is supposed to be compatible with the faster cards but I have not tried one to make sure. I believe some of these cards support WEP, but only at 40 bits. The price here seems way too high -- why not get a silver card instead? > LUCENT TECHNOLOGIES > WaveLAN IEEE Bronze PC Card > *Special Order > $239.95 I don't know what the difference between this and the previous card is, if any. > Could someone explain the differences between these? Is the first one the > same as what is being offered? If so, it appears to be cheaper to buy it > in the US. I hope this helps some. Ned
Re: Who is interested in wireless cards for the Adelaide IETF meeting?
In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writ es: > > This is the same card as an Apple Airport. It is 802.11 DS, 11Mbps, and > supports Wire Equivalent Privacy (WEP). The idea here is that you need a key > to > get on the network, but once you're on you can see all the traffic "on the > wire" that you care to. The Apple softare only lets you set a 40 bit key > (actually what you do is enter a passphrase that is hashed down to 40 bits), > but I believe a 64 bit key is supported by the underlying hardware. I don't > know what the underlying crypto is -- probably DES, which of course means > the key length is really only 56 bits... It's RC4, so the key length can be any integral number of bytes. --Steve Bellovin
Re: 1601bis -03: Still Vague
Hello: First of all, it is not over until the RFC-Editor sings :^. Paul Hoffman / IMC wrote: >> The role descriptions of section 2 remains vague. Thus, the relation >> with IANA and the RFC Editor will remain vague. > It seems quite clear to me. You might want to suggest alternative wording > that you think is clearer. It is not about wordsmithing, but more about the fundamentals of section 2. Sub-section 2.1 is about "architectural oversight in more detail". However, it is not clear on how to measure the effectiveness of that sub-section. Thus, it will be not so easy for a NomCom member to evaluate the performance of the IAB. The only clue is perhaps the IAB's long queue of work-in-progress. For example, 1601bis has been more than 4 years in queue. Therefore, the nature of revising 1601bis must not be easy. Nonetheless, there will be no organizational improvement until the IAB is willing continuously to improve itself. See also "Managing The Non-Profit Organization -- Practices and Principles" (Peter F. Drucker, 1990) for more details. >> "The RFC Editor is chartered by the Internet Society (ISOC) >>and the Federal Network Council (FNC)" > That might have been true at one point, and things have changed. > What's the problem with that? Not much, just $1,295,517 regards, -- - Rahmat M. Samik-Ibrahim -- VLSM-TJT -- http://rms46.vlsm.org/ - Here we are,poised on the precipice of suicide slope-Calvin 20Feb89
