More error-status codes on SNMPv1?
Hi all, We are working on SNMP interfaces for a product named Flash600 ( ADX, Layer2 switching, ATM) for FNC Inc. We are using SNMPv1 framework , but, unfortunately SNMPv1 supports only following error-status codes: noError(0): no error in the requested PDU. toobig(1): The get-response message is bigger than that the local implementation can handle. noSuchName(2): one of the requested objects does not match anything in the relevant MIB view that can be returned. badValue(3): The set-request asked the agent to write an inappropriate value. readOnly(4): A set-request tried to write a value that the operator is not allowed to write.Either the access specified is READ-ONLY or the the variable MIB definition does not permit write access. genErr(5): A variable cannot be retrieved for reasons outside the ones listed above. This provides very little granularity for the User to decide what went wrong. Is there any other way we can add more error-status codes without violating v1 compliance? We don't want to move over to SNMPv2 ,but, still want to add more error-status codes? Can we add more error-status codes? If so, how? Thanks regards, Abhishek Abhishek Bagchi Wipro Technologies-Telecom Solutions #72,Electronics City,Bangalore-29, India Tel:91-80-8520408/0416 Ext-2108 Fax:91-80-8520478 --- Applying Thought
Re: More error-status codes on SNMPv1?
Hi - Message-ID: [EMAIL PROTECTED] Date: Thu, 30 Mar 2000 13:51:09 +0530 From: "Abhishek Bagchi" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: More error-status codes on SNMPv1? ... Is there any other way we can add more error-status codes without violating v1 compliance? At the level of the protocol, no. We don't want to move over to SNMPv2 ,but, still want to add more error-status codes? Can we add more error-status codes? If so, how? ... I would suggest using SNMPv3. Randy Presuhn [EMAIL PROTECTED] http://www.bmc.com/ Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 2141 N. First Street Fax: +1 408 965-0359 San Jose, California 95131 USA Any relationship between my opinions and BMC's should be coincidental.
Carry IP Packet in Ethernet Frame in IEEE 802.3 LLC Encapsulation Format
Dear Friends, I never see or heard any product use 802.3 LLC frame format to carry IP packet. But I am not sure I am correct. Does anyone knows that some product does use the LLC frame to carry IP packets and why? There are 2 type of Ethernet frames: Ethernet Version 2 Frame: | destination | source | type | data | fcs| IEEE 802.3 LLC frame: | destination | source | length | LLC | org code | type | data | fcs| The key difference is the 2 bytes behind the source MAC address. Using Ethernet Version 2 Frame, the type field value will large than the maximum Ethernet frame length 1518. For frames carrying IP packet the type field value is 0x0800. The interface device driver will check this field and realize that this frame carries IP packet. It will send the packet to the IP module for father processing. Thanks David
Re: HTML forms
Harald, Thanks for your message: There is no procedure to "suspend control of aspects" of a specification, The proposal would involve ammending the registration of the text/html media type, incorporating the W3C standards extended with two attributes of the INPUT element, DEVICE and MAXTIME. ... the IETF is of the opinion that HTML is not under our control anyway. I understand that. There might be substantial benefits from reconsidering those opinions. Within the IETF, public debate is assured on almost all controversial matters. The W3C, however, constrains meaningful debate to those willing and able to pay US$50,000 per year. I agree that there was a point in the early development of web standards when that constraint was beneficial. Now, however, with Netscape owned by a company shipping MSIE, and the stagnation or regression of the core HTML standards, along with the concerns raised in Norman Solomon's article, I believe the time has come to return certain aspects of the control of HTML to the IETF. Even if that view is not shared by the IETF, I the only way I would not be certain that a debate on the topic would be healthy for the Internet communty would be if the W3C were to take an affirmative stand on issues involving microphone upload for language instruction and asyncronous audio conferencing. Cheers, James
Re: HTML forms
On Thu, 30 Mar 2000 13:03:07 PST, "James P. Salsman" said: is assured on almost all controversial matters. The W3C, however, constrains meaningful debate to those willing and able to pay US$50,000 per year. I agree that there was a point in the early development of web standards when that constraint was beneficial. Now, however, with Netscape owned by a company Why was it beneficial then? shipping MSIE, and the stagnation or regression of the core HTML standards, along with the concerns raised in Norman Solomon's article, I believe the time has come to return certain aspects And why is it non-beneficial now, given the apparent complexity of getting a product shipped (look at the current state of Mozilla)? Let's face it - anybody who intends to ship a working browser will need to have enough programmers that the $50K is the least of the problems. Yes, this cuts Mozilla out unless somebody pays for their membership. On the other hand, are there any other *real* contenders for whom $50K would be a hardship? of the control of HTML to the IETF. Even if that view is not shared by the IETF, I the only way I would not be certain that a debate on the topic would be healthy for the Internet communty would be if the W3C were to take an affirmative stand on issues involving microphone upload for language instruction and asyncronous audio conferencing. Umm.. Microphone upload is the *least* of the many challenges facing HTML at the current time. -- Valdis Kletnieks Operating Systems Analyst Virginia Tech
Re: HTML forms
Valdis, Thank you for your reply to my message: ... The W3C... constrains meaningful debate to those willing and able to pay US$50,000 per year. I agree that there was a point in the early development of web standards when that constraint was beneficial Why was it beneficial then? There was a lot of concern that a consensus would be too dificult to achieve unless there were some entry barriers. The other reasons involved mutual nondisclosure and similar features of quickly-emerging technology companies. None of those reasons should have ever been assumed to be perminant. Another benefit was that the membership fees established a great infrastructure of facilities and staff for the W3C And why is it non-beneficial now...? Well, I've already given a couple reasons beyond those of Normon Solomon's, but consider this: The W3C has over 400 members! http://www.w3.org/Consortium/Member/List That's over US$20 million in annual membership fees. Typical W3C members don't even seem to realize they are part of the consortium. For example, TIAA-CREF and Recording for the Blind and Dyslexic are both members. But after days on the phone and over email, nobody I've reached within those organizations has any idea who their W3C Advisory Committee representative is. Recording for the Blind asks me for money every few months, and I've given to them in the past, but knowing that they spend $50K a year without any idea who their AC rep. is makes it a lot less likely for me to want to donate anything else to them. It would be different if their AC rep. stood up for their interests, but nobody at Recording for the Blind and Dyslexic with whom I've spoken had even the faintest idea what microphone upload was or how it could benefit them. Same with TIAA-CREF, supposedly representing the interests of tens of thousands of language teachers. On the other hand, are there any other *real* contenders for whom $50K would be a hardship? Absolutly. The foremost are probably the developers of Emacs' w3-mode, but I'm sure I could name a dozen tiny browser-developing projects of one kind or another, if you're interested. How about the developers of LWP.pm and CGI.pm -- do you expect them to plop down 50 grand anytime soon? Cheers, James
Re: HTML forms
On Thu, 30 Mar 2000 18:06:44 PST, "James P. Salsman" said: audio conferencing. If you wanted to provide for students on several different platforms, you would have to provide a microphone capture application for each of them. Then, Sounds like a straw man to me. When was the last time you bought a microphone/audio card for a system that didn't include at least basic software to do this sort of thing? And I'm the one who always complains that vendors don't ship support for AIX (Macromedia Flash, RealAudio, and StarOffice being at the top of my wish list this week). Only a few mail user agents provide that capability. Back Well, the MIME spec came "out of the box" with audio MIME types. Put the blame squarely on the MUA developers, the protocol supported it - in fact, I believe one of the early MIME 'stress test' messages included an audio clip, while RFC1341 was still at I-D status. in late 1996 some language instructors on one of the distance education lists (DEOS?) or newsgroups were claiming that voice-email presents more trouble than it is worth, at least for some students. There are those who find VCR's challenging. It isn't NTSC's or PAL's fault... On Thu, 30 Mar 2000 18:37:59 PST, "James P. Salsman" said: There was a lot of concern that a consensus would be too dificult to achieve unless there were some entry barriers. The other reasons involved mutual nondisclosure and similar features of quickly-emerging technology companies. None of those reasons And you're claiming that with MORE voices, consensus would be easier to achieve now? Also, I've heard from several people "I have browser XYZ written by 3 or 4 people, it's tiny, fast, and implements most stuff". Which, actually, was my point - it's pretty easy to write a browser that will implement MOST stuff. However, by the time you do full HTML 4, Javascript, SSL, CSS, Java, and whatever else, you're looking at a pretty big pile of code, unless you're just in the "Let's see how far into the wilderness we can push feature XYZ at the cost of other support" game. Sure, 2-3 programmers can get a basic minimal browser done - but 2-3 programmers are probably not going to implement *enough* of the esoteric stuff that they will start needing to worry about what partially-specified feature XYZ really means, unless feature XYZ is already widely acknowledged to be defined in a brain-dead manner... -- Valdis Kletnieks Operating Systems Analyst Virginia Tech
RE: Standards development (was HTML forms)
In my experience, the proper way to develop standards is to begin with a private implementation. Only with practical experience can sufficient understanding be achieved to enable the writing of a good standard. Nearly all prevalent standards have followed this course, including HTML. An example of writing the standard first is OSI. Jony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of [EMAIL PROTECTED] Sent: Thursday, March 30, 2000 11:47 PM To: James P. Salsman Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: HTML forms On Thu, 30 Mar 2000 13:03:07 PST, "James P. Salsman" said: is assured on almost all controversial matters. The W3C, however, constrains meaningful debate to those willing and able to pay US$50,000 per year. I agree that there was a point in the early development of web standards when that constraint was beneficial. Now, however, with Netscape owned by a company Why was it beneficial then? shipping MSIE, and the stagnation or regression of the core HTML standards, along with the concerns raised in Norman Solomon's article, I believe the time has come to return certain aspects And why is it non-beneficial now, given the apparent complexity of getting a product shipped (look at the current state of Mozilla)? Let's face it - anybody who intends to ship a working browser will need to have enough programmers that the $50K is the least of the problems. Yes, this cuts Mozilla out unless somebody pays for their membership. On the other hand, are there any other *real* contenders for whom $50K would be a hardship? of the control of HTML to the IETF. Even if that view is not shared by the IETF, I the only way I would not be certain that a debate on the topic would be healthy for the Internet communty would be if the W3C were to take an affirmative stand on issues involving microphone upload for language instruction and asyncronous audio conferencing. Umm.. Microphone upload is the *least* of the many challenges facing HTML at the current time. -- Valdis Kletnieks Operating Systems Analyst Virginia Tech
