RE: Where is the OID dot convention spelled out?
Title: RE: Where is the OID dot convention spelled out?
Right,
OID string representation is not part of the ASN.1 languange specification.
ASN.1 is used for specification of protocols, mostly in OSI, and ITU-T standards.
I think you should take a look at the RFCs dealing with string representation syntaxes.
In particular RFCs related to X.500 and LDAP technology.
Panagiotis Tsigaridas
IT Architecture Manager
-Original Message-
From: Christian Huitema [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 23, 2000 4:07 AM
To: 'Peter Furniss'; '[EMAIL PROTECTED]'; 'Michael Mealling'
Subject: RE: Where is the OID dot convention spelled out?
The notation of OID strings as 1.3.6.1.4.1 started appearing in the ISODE
ASN.1 compiler, in the late 80's. It was not part of the ASN.1 standard; in
fact, ASN.1 defines its own set of format, that can mix numbers and
litterals. In ASN.1, this was called a value notation. A standard ASN.1
textual representation would have been, for example, {1 3 6 1 4 1}, or {1 3
6 foo(1) bar(4) 1}, as in
fooBar OBJECT IDENTIFIER ::= {1 3 6 foo(1) bar(4) 1}
Why the ASN.1 representation never really caught up in user interfaces is
left as an exercize for the reader...
-Original Message-
From: Peter Furniss [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 22, 2000 4:13 PM
To: '[EMAIL PROTECTED]'; 'Michael Mealling'
Subject: RE: Where is the OID dot convention spelled out?
Michael Mealling sent :
For all the ASN.1 folks out there:
I'm in the midst of writing up the OID URN namespace document
(see
http://www.ietf.org/internet-drafts/draft-mealling-oid-urn-00.txt)
and it has come to my attention that none of the ASN.1 standards
define the dot-notation that we use in all sorts of RFCs.
I'm specifically
referring to the practice of inserting dots in between each
arc as in:
1.3.6.1.4.1
Is anyone aware if this is actually spelled out somewhere? I don't
have the newest ASN.1 docs in front of me so if the're in there
a page reference would be great.
It is an IETF convention, not one defined in the ASN.1
standards. It is used at least as early as RFC 1157 (snmp),
which refers to the familiar dot notation - familiar, I'd
assumed, in the dot notation of IP addresses. (which seems to
be first mentioned in RFC 790, though it says it was already
in use then (and had leading zeros)
The ASN.1 standards use spaces between the fields and
{braces} round the whole lot in text representations. They
also use name(number) to identify what the fields are, and
the first part of a text representation can also be an
assigned asn.1 value (so a whole subtree can be specified
without repeating the value of the root all over the place)
Peter Furniss
ISO/IEC JTC1 OSI Maintenance Rapporteur (on behalf of BSI)
OSI Maintenance website: http://www.furniss.co.uk/maint
DoubleTree Cancellations
I just had a call from the DoubleTree Hotel in Pittsburgh -- they are canceling a number of (70+) confirmed reservations for the next IETF meeting due to overbooking. They're trying to arrange for alternative accommodations, but if you had a confirmed reservation at the DoubleTree you might want to check your confirmation status to be sure your reservation is still valid. Scott Hollenbeck Network Solutions, Inc. Registry
Please help share your 802.11 multivendor interop experience
[Please keep 802.11 CC'ed; see [1] at bottom for more.] There's a huge amount of fuzz when it comes to figuring out whether any given 802.11b (direct-sequence, 11MBit/sec, RF) card or base station will actually work with each other, or when roaming, etc. Fixing this could help both IETF meeting hosts and members who want to use wireless networking at meetings, not to mention the projects suggested below. I've asked quite a number of people who -should- know, and nobody seems to know the whole story, or know what entity -would- know. The www.wi-fi.com website (which claims to address such issues) is less than impressive, and has little useful information on it. So I'm trying to find actual operational experience. Please help! You'll be helping several different projects: (a) I'm working with some well-known-to-IETF folks to figure out what to specify for a fast-deployment, temporary net for the Oregon Country Fair in Eugene, which happens in early July. This will serve as a beta-test for a later setup (in late August) on the playa at Black Rock City, Nevada, as part of Burning Man, for use by everyone there. Both installations are part of events that last only a few days and cover a few square kilometers at which up to 20,000 people may be present. (b) There may be a sufficient density of people in the Davis Square area of Somerville, MA (and maybe elsewhere) to make an ad-hoc bunch of cells---enough that it might be quite likely that any given laptop will be near enough someone's cell to see the greater Internet. [2] [I'm using Davis Square as an example because that's where I live, and that's where a lot of other Boston-area geeks live.] The end results of this survey discussion will hopefully be: (a) Archives for people to read later (b) A set of web pages describing what to buy and how to configure it (c) Whatever else we all want to generate Here are the things we need to figure out. (a) Exactly how interoperable is any given 802.11 DS, 11MBit/sec card with any base station? Any known losing combos? (b) Which cards roam properly with which base stations? For any given card from vendor X and base station from vendor Y, which ones roam correctly, and which do not? How does this answer change if both cards and base stations are from the same vendor? (c) Which cards and base stations are easiest or hardest to retrofit other antennas? Are there unusually difficult-to-obtain connectors on particular cards or base stations? [The installations in the middle of nowhere, surrounded by mountains, might use unusual techniques; installations in Somerville must of course stay under FCC limits.] (d) Do any particular cards have driver problems, for either *BSD, Linux, or Windows? How does roaming affect this issue? How available are drivers? (e) Do any base stations allow roaming -without- requiring bridging? (f) For operation at very low signal strengths (e.g., to extend range), can we step down to 2Mbps? Does this have to be decided in advance, for all users of the net? Is there a good source for such antennas? For an installation in the middle of the desert, should we consider linears? From what source? How do we cope with the power asymmetry between base stations and laptops? (g) A big, spread-out net, with either directional antennas or roaming, might mean that not all mobiles can hear each other to avoid collisions. How big a problem might this be? (i) Crypto---how easy is it to use 128-bit keys? Must everyone on the net have the same key, or can we key per-user somehow? Has anyone evaluated the cryptographic strength of whatever PNRG is generating the keys? (h) What other problems might we expect? What questions -should- I be asking? [1] This message is being sent, separately, to several small lists and a few individuals. This keeps cross-discussion on each individual list. If you'd like to see what everyone has said, add yourself to the new 802.11 interop mailing list by sending "help" in body or subject to [EMAIL PROTECTED] I will announce any results, web pages, etc, that come out of this to the [EMAIL PROTECTED] list. Also, -please- keep 802.11 CC'ed on replies! Doing so means that everyone's replies to the various lists all wind up in a common archive that people can read. See also http://lcs.www.media.mit.edu/projects/802.11/. [2] There are a number of obvious issues here, which will be explored in a separate mailing list; send "help" to [EMAIL PROTECTED] or see http://lcs.www.media.mit.edu/projects/Davis-Net/ for more details.
Re: Where is the OID dot convention spelled out?
See RFC 1778, 2.15: Values of type objectIdentifierSyntax are encoded according to the following BNF: oid ::= descr | descr '.' numericoid | numericoid descr ::= keystring numericoid ::= numericstring | numericstring '.' numericoid In the above BNF, descr is the syntactic representation of an object descriptor. When encoding values of type objectIdentifierSyntax, the first encoding option should be used in preference to the second, which should be used in preference to the third wherever possible. That is, in encoding object identifiers, object descriptors (where assigned and known by the implementation) should be used in preference to numeric oids to the greatest extent possible. For example, in encoding the object identifier representing an organizationName, the descriptor "organizationName" is preferable to "ds.4.10", which is in turn preferable to the string "2.5.4.10". This was refined in RFC 2252, 4.1. In particular, it eliminates the "ds.4.10" form.
RE: Where is the OID dot convention spelled out?
try http://www.alvestrand.no/objectid/top.html Not spelled out, but a good starting spot (Thanks Harald!)
RE: WAP Is A Trap -- Reject WAP
On Wed, 21 Jun 2000 11:05:43 -0400, "Brijesh Kumar" [EMAIL PROTECTED] said: Brijesh PS: By the way, ReFLEX is perfectly fine for two way messaging Brijesh applications. Mohsen No. Mohsen Mohsen ReFLEX is not perfectly fine. Mohsen Mohsen It is not IP based. Brijesh Hi Mohsen, Brijesh What kind of argument is this? You used the words "ReFLEX is perfectly fine for ...". I could have challenged that claim based on any of several points that you yourself mentioned. I chose the IP argument because it is the most powerful and least obvious one in the case of ReFLEX. ReFLEX is not IP based and it could have been IP based. Brijesh If it is not IP based it is not good ! This is an emotional response, Brijesh not a technical one. Using the same arguments, the whole phone system Brijesh isn't good because it has nothing to do with IP (or at least was true Brijesh till VoIP came), and same is true of all G2 TDMA, CDMA and GSM Brijesh cellular systems (and don't forget AMPS, CDECT and many other wireless Brijesh standards). The networks that you have mentioned above were in place before IP's power became clear. That is a legitimate excuse for their non IP nature. I would say the knee of the curve was in 1992. ReFLEX on the other hand can not use that excuse because it came after 1992. ReFLEX's Narrowband PCS licenses came out in 1995. The remaining excuse for ReFLEX not being IP based is efficiency. It is very feasible and reasonable to build a highly efficient IP based slow wireless network. An initial such attempt using the Narrowband PCS spectrum (same as ReFLEX) was called pACT. The failure of pACT was due to ATT's business withdrawal in 1997 -- not technology. pACT could have been real competition for ReFLEX. Derivatives of pACT related work are in use in bandwidth constrained environments. The last leg of IP in wireless environments can be made highly efficient. In this day and age, citing efficiency as a rationale for building a non-IP based network is a lame excuse. Later you said: On Thu, 22 Jun 2000 11:39:11 -0400, "Brijesh Kumar" [EMAIL PROTECTED] said: Brijesh Let us take case of a CDPD device that has a IP address. CDPD has one Brijesh of the largest coverage in US and is geared for data communication. Brijesh Now CDPD works at 19.2 Kbps, and uses spare capacity from AMPs Brijesh channel, and when no channel is available that a device looks for Brijesh voice gaps in other channels to send data. I am one of the primary architects of the CDPD Specifications -- starting with rev. 0.3 in Dec. 92. I would like to believe that the main reason why CDPD is IP based is because of my involvement. Prior to my involvement it was not IP based. Brijesh With these kind of losses TCP Brijesh throughput tanks!. So we need a wireless medium aware version of TCP Brijesh or some hacks for TCP to be efficient under losses (see relevant Brijesh literature). Others (Steve Deering, Vernon Schryver, ...) have already pointed out that above layer 3, wirelessness is irrelevant. When it comes to wirelessness, above layer 3 the name of the game is "EFFICIENCY" -- and all dimensions of it. There is a place for something else in addition to TCP, but not for the reasons that you mentioned. More on this later. ...Mohsen.
RE: WAP and IP
From: Mohsen BANAN-Public [EMAIL PROTECTED] ... There is a genuine need for a reliable efficient transport that accommodates *short* and *occasional* exchanges. There are many occasions where UDP is too little and TCP is too much. I've often heard that from telephant advocates, but I've never seen anything plausible from them. It's not that I can't believe it, since I'm currenting coding something that needs more than UDP and less than TCP, and that involves short and often only occassional exchanges. Such applications have been common in the IP world for decades. The problem is that the new wireless folks talk only about ridiculous applications such as WWW browsing using screens with 60x80 pixels were each pixel is one whole dark grey vs. light grey bit. IETF/IESG/IAB folks keep saying TCP is good enough for everything. You're not listening or you're listening to the wrong I* folks. No one with a clue says TCP is good enough for everything or even that TCP and UDP are good enough for everything. Perhaps your complaint is that acknowledging the limits of TCP doesn't confer automatic support for the latest consortium braincloud. Maybe you could get sympathy from the former ATM advocates here, who in the early 1990's told us that IP was obsolete and would soon be replaced by ATM to the desktop. Or the ISO-OSI advocates of the mid- and late 1980s. Both groups had a lot of telephant employees and suppliers. And they interfere with the work of others addressing the efficient applications domain. And how do they interfere with anything except foolish advertising and advocacy that is obviously contrary to reality? I've argued forceful elsewhere against the religion that says that the ends of the IP path must be defined as the webphones. There is just as much silliness as WAP in trying to make HTTP/TCP/IP run on the last 1000 bit/sec, 1E5 BER wireless 500 meters to 1 MHz computers with 1000 pixel screens. WAP is based on the right insight given those bogus limits, but amazingly backwards. It's as if the telephants are afraid of the obvious solution, which involves them running real computers and treating webphones as semi-dumb terminals. ... Efficient application protocols is a new topic for most. Go to your favorite RFC repository and search for "efficient" in the title field. See what you get. We are now moving beyond "Simple Protocols," and "Efficient Protocols" are in big demand. That's more of an observation about the evolution of standards outfits than the current market, computers, or anything else. The later works of committees are always at best bigger and usually much worse than merely bigger. It becomes silly even to insiders to claim their efforts are "simple." "Efficient" is more nebulous. Thus the great protocol disasters have all been paragons of efficiency. Consider the ISO OSI suite and FDDI. ... While the right implementations of TCP are just fine for transfer of larger pieces of information in most (if not all) wireless environments, transfer of occasional short messages is a different matter. Yes, TCP is not always the right solution. This is has not been news to anyone with any sense for more than 20 years. Can't you name several familiar applications that fit your profile? Isn't DNS about the "transfer of occasional short messages?" Other old examples include PPP (LCP), NTP, NNTP (for reading not feeds), and many RPC applications including YP/NIS. ... In order to do anything beter than 5 PDU exchanges we need something other than TCP. The combination of ESRO and EMSD can do the job in 3 PDU exchanges most of the time. EMSD (Efficient Mail Submission and Delivery) has been published as RFC-2524. More information on the above example is available at http://www.emsd.org/ I disagree with your packet counts, but never mind. You're solving the 60x80x1 resolution webphone problem of the 20th Century, and no one with any sense cares. (And no one notices that you're solving it with protocols you say are "efficient" instead of "simple," have amazingly long descriptions, and packet formats with lots of "unused" bits.) When webphones have enough screen real estate to be usable, they'll need enough raw bandwidth to paint their Mpixel displays, and then you're in the familiar regime of Internet of 1995 - 2005, and you don't want WAP. On the other hand, if webphones never have more than several 100 monochrome pixels, they'll never be used for anything useful to more than a handful of people, and you still don't want WAP. Talk a walk on the wild side, and see what the general public says about the new webphones with their uselessly tiny screens. Do some engineering to estimate the minimum required resolution, or just look at the "palm-top"products that have been mentioned here. But who cares? You're not going to convince me to run out and get a lobotomy. And if you did, so what. As I said before, WAP will fail on its on merits.
