Dan@dna.lth.se (Dan Oscarsson) (01/06/91)
Is X.400 good for international mail?
Some of the things I think is needed:
The body of the mail but be able to contain anything.
How is this in X.400?
Are there some standard formats of the contents?
Is there a standard character set that can take all
characters in the world? Like ISO 10646.
Any standard for binary files, inclusion of sound or images?
The "headers" must accept any characters in the world.
Does X.400 allow anything except ASCII and T.61?
Why not an international character set like ISO 10646?
The address must be as global as possible without references to a path.
That is, I do not want to tell what company is going to
deliver my mail! I want just to send it like I do on the Internet,
the mail routers (MTA) have do find the way to deliver the mail.
Dan
--
Dan Oscarsson Department of Computer Science
Lund Institute of Technology
e-mail: Dan@dna.lth.se Box 118
S-221 00 Lund, SwedenJPALME@qz.qz.se (Jacob Palme QZ) (01/07/91)
> From: Dan Oscarsson > Is X.400 good for international mail? > > Some of the things I think is needed: > > The body of the mail but be able to contain anything. > How is this in X.400? An X.400 message can consists of several bodies. Each body must have a body type. The body type for each body is identified by an object identifier. This means that anyone can define any body type with his special kind of content. The X.400 standard contains a number of pre-defined body types. A user, user group or standards organization who needs some additional body type can define it, and choose an object identifer to identify it. > Are there some standard formats of the contents? Yes, there are a number of standardized content formats. The most important of them are IA5 (=ISO 646), Teletex (=T.61), voice and fax. New types are being defined, for example will the 1992 version contain special types for "file transmission" based on the file types defined in FTAM. > Is there a standard character set that can take all > characters in the world? Like ISO 10646. I am not sure of ISO 10646 is a standard yet. But when it becomes a standard, one can expect that there will be defined an X.400 body type for it. There is an X.400 body type defined by ISO called "general string". It allows any character set registered by ISO, and assumes that the string begins with an ISO 2022 escape sequence which defines which character set is used in the rest of the string. The character set can, with this body type, also switch in the middle of a string via additional ISO 2022 escape sequences. > Any standard for binary files, inclusion of sound or images? There is a body type for images in telefacsimile format. There will be body types for binary files and sound in the 1992 version of X.400. The present version already has a body type for sound, but does not define which sound encoding to use. > > The "headers" must accept any characters in the world. > Does X.400 allow anything except ASCII and T.61? > Why not an international character set like ISO 10646? X.400 allows two variants of names in headers (a name can be given in both variants). One for international use, with a restricted character set which it is expected that any imaging device anywhere can render, and any keyboard can produce, and one for national use within a country. X.400 uses T.61 for the national character set. ISO 10646 was not known when X.400 was defined. I can see problems with using ISO 10646 in headers, since it will only work if all users have terminals (screens=imaging devices, and keyboards) which can handle this very wide character set. This will probably not occur for a long time. With T.61, every country is expected to define its own subset for national use, which can be handled by the terminals used within that country. > The address must be as global as possible without references to a path. > That is, I do not want to tell what company is going to > deliver my mail! I want just to send it like I do on the Internet, > the mail routers (MTA) have do find the way to deliver the mail. What you are talking about seems to be what in X.400 is called a "name" and not an "address". An OR-name in X.400 can consist of two parts. One part called the directory name, which is the kind of name you like, and one part called OR-address, which is somewhat more path-oriented. The concept of domain in internet is more similar to the concept of "organization" in X.500 and X.400, than to the concept of domain in X.400. The Internet mail routers use so-called name-servers to translate a domain into a path. This means that the same path must be used for all names with the same domain. In X.400, different pathes can be used for different names within the same organisation.
JPALME@qz.qz.se (Jacob Palme QZ) (01/07/91)
> From: Tim Kehres <kehres@touch.COM> > Subject: Re: Is X.400 good for international mail? > ------------------------------------------------------------ > In your message, you write: > > The Internet mail routers use so-called name-servers to translate > > a domain into a path. This means that the same path must be used > > for all names with the same domain. > > This is not entirely true. Intenet mail routers are supposed to check > for MX (Mail Exchange) records first rather than Address records for > mail routing. Associated with MX records are relative priorities, making > it possible to have multiple MX records for a given host or domain. It > is then up to the routing software to choose which path to use based > upon this data. What I meant was that Internet mailers normally choose the path by looking up the domains of the recipient in the name servers. X.400 mailers are supposed to look up the whole name of the recipient in the Directory System (X.500 system) in order to translate the name into a path. I have heard it argued that this is an advantage with the Internet way of handling mail, since the directory data bases need not be so large if they only list domains, and not the individual names of all users. On the other hand, it might be possible to define X.500 directory systems to use only the domains when translating a name into a delivery path.
nazgul@alfalfa.COM (Kee Hinckley) (01/08/91)
In article <584410*JPALME@QZ.qz.se> JPALME@qz.qz.se (Jacob Palme QZ) writes: >The X.400 standard contains a number of pre-defined body types. >A user, user group or standards organization who needs some >additional body type can define it, and choose an object identifer >to identify it. Ah, you make it sound so easy. We have an X.400 mail product right now that allows you to mail arbitrary enclosures, and of course we want to define some standard ones (e.g. Frame documents, Lotus 123 files, GIF images, X bitmaps...). But finding someone who's dispensing object identifiers for such purposes (and it really wants to be a world-wide directory of them) is a bit difficult. Any ideas? >for a long time. With T.61, every country is expected to define >its own subset for national use, which can be handled by the >terminals used within that country. Who is doing this in the U.S.? (This stuff all seems so easy when you are talking about countries where the Post Office is the Phone Company is the sole provider of such services. It's not that neat here.) -kee -- Alfalfa Software, Inc. | motif-request@alfalfa.com nazgul@alfalfa.com |----------------------------------- 617/646-7703 (voice/fax) | Proline BBS: 617/641-3722 I'm not sure which upsets me more; that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
Stef@ICS.UCI.EDU (Einar Stefferud) (01/08/91)
>>The X.400 standard contains a number of pre-defined body types. >>A user, user group or standards organization who needs some >>additional body type can define it, and choose an object identifer >>to identify it. >Ah, you make it sound so easy. We have an X.400 mail product right >now that allows you to mail arbitrary enclosures, and of course we >want to define some standard ones (e.g. Frame documents, Lotus 123 >files, GIF images, X bitmaps...). But finding someone who's dispensing >object identifiers for such purposes (and it really wants to be a >world-wide directory of them) is a bit difficult. Any ideas? What you aree asking for is that LOTUS and other vendors get themselves in gear and define their objects in ASN.1 and assign Object Indentifiers to them. This has to be done by the "ouwners" of the objects, such as LOTUS, et al. The standards specify how this should be done, and enable the "owners" to do it. Next, they only have to do it, and advertise the OIDs and the ASN.1 definitions. (Doing it and not advertising the OID and ASN.1 is a no-op!) >>for a long time. With T.61, every country is expected to define >>its own subset for national use, which can be handled by the >>terminals used within that country. >Who is doing this in the U.S.? (This stuff all seems so easy when >you are talking about countries where the Post Office is the Phone >Company is the sole provider of such services. It's not that neat >here.) I expect that it is already done in the US, since the US uses IA5 (ASCII). So, what do you want someone to do? A more interestinng question is: "How are we in the US going to deal with allll those none ASCII characters that need to be displayed in mail from our foreign correspoondents, and need to be typed on our ASCII-only keyboards in order to send mail to them?" Reminds me of the stories of the Tower of Babel...\Stef
hagens@cs.wisc.edu (Robert Hagens) (01/08/91)
> In article <584410*JPALME@QZ.qz.se> JPALME@qz.qz.se (Jacob Palme QZ) writes: > >The X.400 standard contains a number of pre-defined body types. > >A user, user group or standards organization who needs some > >additional body type can define it, and choose an object identifer > >to identify it. > Ah, you make it sound so easy. We have an X.400 mail product right > now that allows you to mail arbitrary enclosures, and of course we > want to define some standard ones (e.g. Frame documents, Lotus 123 > files, GIF images, X bitmaps...). But finding someone who's dispensing > object identifiers for such purposes (and it really wants to be a > world-wide directory of them) is a bit difficult. Any ideas? > -kee Just call OIDs-R-Us! They are a chain of discount OID suppliers. Their slogan is "It may not be known worldwide, but its known pretty far!" I got OIDs there for everyone in my family for Christmas. They take VISA/MC too! 1-800-222-1234 (specify sort-of-known, well-known, or world-wide unique -- note, they might be out of stock of those last ones). Rob Hagens p.s. I have no affiliation with OIDs-R-US other than being a satisfied customer.
nazgul@alfalfa.COM (Kee Hinckley) (01/08/91)
> What you aree asking for is that LOTUS and other vendors get themselves > in gear and define their objects in ASN.1 and assign Object Indentifiers > to them. This has to be done by the "ouwners" of the objects, such as > LOTUS, et al. First of all, most of the owners have never *heard* of Object Identifiers and could care less, so it's going to be a long time if we wait for them. Our customers need the identifers *now*. So we're just going to have to do it ourselves somehow. (BTW, I don't think it's necessary to define the objects in ASN.1, I forget the phrase (I haven't been dealing with the X.400 side of things that much) but I believe there's some way of saying that it's simply an object known at both ends and unspecified in the middle. Otherwise we'll *never* get Object Identifiers for those things.) > The standards specify how this should be done, and enable > the "owners" to do it. At some point in the system you need to get an object identifier to start with. You can't just gen it up out of thin air, since it might conflict with someone elses. Who do you go to in the US to get that identifier? > > >>for a long time. With T.61, every country is expected to define > >>its own subset for national use, which can be handled by the > >>terminals used within that country. > >Who is doing this in the U.S.? (This stuff all seems so easy when > >you are talking about countries where the Post Office is the Phone > >Company is the sole provider of such services. It's not that neat > >here.) > > I expect that it is already done in the US, since the US uses IA5 > (ASCII). So, what do you want someone to do? Okay, that's fine. > > A more interestinng question is: "How are we in the US going to deal > with allll those none ASCII characters that need to be displayed in mail > from our foreign correspoondents, and need to be typed on our ASCII-only > keyboards in order to send mail to them?" Got me, I don't do dumb terminals (yet). I do X, and _most_ of that is being done in X11R5 (except that they still haven't got the right-to-left stuff covered very well yet). But I thought that wasn't a problem for headers, just body parts? My understanding was that headers have a limited character set (otherwise known as "screw the foreigners"). That actually hasn't seemed to bother the Japanese people we've talked to, except that they'd really like to have Kanji subject lines. Caveat. As I said, I haven't been dealing with the X.400 mechanics myself, just the user interface to them.
pv@eng.sun.COM (Peter Vanderbilt) (01/09/91)
> First of all, most of the owners have never *heard* of Object Identifiers > and could care less, so it's going to be a long time if we wait for them. > Our customers need the identifers *now*. So we're just going to have to > do it ourselves somehow. Unfortunately, you may be right. It doesn't really matter where an OID (object identifier) comes from as long as it's well defined. However, I am concerned about lack of communication about particular OID definitions. If you send a Lotus spreadsheet to me, I want you to be using an OID that my system knows about. Perhaps announcing your OID definition on this list may be enough. Better would be some kind of living document available on the net that was a repository for body part definitions. Anybody have any ideas on how to make this happen? Conceivably X.500 could be used to map OIDs to human readable descriptions. > BTW, I don't think it's necessary to define the > objects in ASN.1, I forget the phrase (I haven't been dealing with the X.400 > side of things that much) but I believe there's some way of saying that > it's simply an object known at both ends and unspecified in the middle. Right, just specify that the data is octet-aligned (but not ASN.1 BER). You do need to specify the format of the data (defining such things as as the byte ordering of ints (if any) and whether lines are terminated by CRLF, LF or either (I recommend the last)). > Who do you go to in the US to get that [root] > identifier? Call Beth Somerville at ANSI ((212) 642-4976) for an application. The fee is $1000. > But I thought that wasn't a problem for > headers, just body parts? My understanding was that headers have a limited > character set (otherwise known as "screw the foreigners"). Not really. The subject field has used an international char set (T.61) since 1984 (although I've never seen it used for anything other than ASCII) and 1988 X.400 introduced T.61 components into addresses. Pete
hagens@cs.wisc.edu (Robert Hagens) (01/09/91)
> Better would be some kind of living document available on the net that > was a repository for body part definitions. Anybody have any ideas on > how to make this happen? Conceivably X.500 could be used to map OIDs > to human readable descriptions. The NSF Pilot X.400 project at the University of Wisconsin is operating the first X.400 pilot in the Internet. We would be happy to keep track of OIDs in use in X.400 and provide the list via ftp and mail servers. This issue is also of interest to the IETF X.400 operations working group. Rob Hagens
Allan.Cargille@pilot.cs.wisc.edu (Allan Cargille) (01/10/91)
} From: "Peter Vanderbilt" <pn=pv/ou=sun/ou=eng/o=com/prmd=xnren/c=us> } Subject: Re: Is X.400 good for international mail? } > First of all, most of the owners have never *heard* of Object Identifiers } > and could care less, so it's going to be a long time if we wait for them. } > Our customers need the identifers *now*. So we're just going to have to } > do it ourselves somehow. } } Unfortunately, you may be right. It doesn't really matter where an OID } (object identifier) comes from as long as it's well defined. However, } I am concerned about lack of communication about particular OID } definitions. If you send a Lotus spreadsheet to me, I want you to be } using an OID that my system knows about. } } Perhaps announcing your OID definition on this list may be enough. } } Better would be some kind of living document available on the net that } was a repository for body part definitions. Anybody have any ideas on } how to make this happen? Conceivably X.500 could be used to map OIDs } to human readable descriptions. Hello all, I think that it could be a useful step forward to establish an interim OID registry. However, isn't it correct that such an OID registry must be globally known, and otherwise it is worthless? By "globally known" I mean known or accessible in the worldwide community of X.400 implmentors. Therefore I do not think that simply announcing it on this list would work, or even maintaining a living document on the net. Instead I think that some global concensus much be achieved for the use of OIDs, even ones that have not been formally registered by the owner of the data item or product. What about having the new IETF OSI X.400 Operations working group and the RARE MHS Project (in Europe) maintain a joint listing of adopted OIDs? Would it be better to have them jointly defined by the NIST X.400 Interoperability working group, and its peer groups in Europe and Asia? I'd like to see more discussion on this, because I think that we could make positive progress in this area. Cheers, allan -- Allan Cargille Computer Sciences Department Associate Researcher University of Wisconsin-Madison Fax +1 (608) 262-9777 1210 West Dayton Street Voice +1 (608) 262-5084 Madison, WI 53706 USA cargille@cs.wisc.edu BITNET: cargille%cs.wisc.edu@INTERBIT X.400 C=us; ADMD= ; PRMD=xnren; O=uw-madison; OU=cs; S=cargille
Stef@ICS.UCI.EDU (Einar Stefferud) (01/10/91)
That ideal situation will be where there is ONE, AND ONLY ONE OID for EACH SPECIFIC OBJECT that is to be carried as an X.400 Body Part or Content Type. Lets limit this discussion to carriage as Body Parts, inside P2 envelopes. This OID would (ideally) be registered under some duly constituted Registration Authority, ONCE, and ONLY ONCE, but its OWNER, whoever that may be. LOTUS owns its objects, and LOTUS owes it to its customers to register its object for carriage in X.400. This does not suggest taht teh INTERNET should set up a registry, though it might want to set up a database of OIDs registered by the owners of registered objects. If different people and organizations go off and register the same object for carriage in X.400 in different ways, we will make a mess, so let's not do that. Let's find a way to get each such object registered once, and only once by its proper owner. I don't believe that LOTUS is unaware of this need, but I also don't think that their marketing people have heard from anyone that their customers want to know what their X.400 Body Part OID is. So, my suggestion is that all you complaining customers get on your sales reps and ask for information about the X.400 Body Part OIDs that should be assigned to the objects of your choice. It is well known that companies often (if they are any good) listen to their customers, especially when they hear it through sales folk who are faced with sales resistance related to such matters. We should all note that the OID and its ASN.1 Definition for carriage as an X.400 P2 Body Part is not the same things a full open definition in ASN.1 of the internal structure of all the information inside the object. It is an ASN.1 specification of the X.400 Body Part containing the object, not the definition of the object itself. The contained object may be expressed as a string of ASCII characters, a bitstring, a byte string, or whatever it makes sense to define it to be, so as to maximize on the value of transporting it via X.400, whatever that might mean. But, it is a really bad idea to have more than one OID for the same definition of any object, because if there is more than one, then all implementations must be coded to deal with all the known OIDs for the same definition. Further, it is even worse to have more than one definition for the same OID. That is why this is prohibited in the standards. The best way to have one and only one OID per definition, and one and only one definition per OID, is to have one and only one entity do the registration. ANSI has finally stepped up to the job of issuing OIDs to organizations (such as LOTUS) so they can become duly registered registration sub-authorities. ANSI will also provide any one who asks with information (or at least point you to information) about how to use their OID to establish a registration authority under you they can register all the objects you amy wish to register. The ANSI contact is: Beth Somerville American National Standards Institute 1430 Broadway, New York, NY 10018 FON: +1 212 642 4976 FAX: +1 212 302 1286 TELEX: 42 42 96 ANSI UI Feel free to mention my name if you wish, thopugh it will not help you to get a better seat. Best...\Stef
nazgul@alfalfa.COM (Kee Hinckley) (01/11/91)
> This OID would (ideally) be registered under some duly constituted > Registration Authority, ONCE, and ONLY ONCE, but its OWNER, whoever that > may be. LOTUS owns its objects, and LOTUS owes it to its customers to > register its object for carriage in X.400. I assume that "but" means "by"? This is certainly good in theory, however it is not all that easy to call up some random company and tell them that they really need to pay ANSI $1000, generate some OIDs (something which they've never heard of) and then publicize them. It's definitely the right way, but it won't always work. Furthermore, there are a large number of things I'd like to mail which don't have owners, or at least not owners who are going to get their own OID. Take the PBM/PPM/PGM bitmap formats, or the dozens of Tagged Interchange File Formats, etc.. We've already gone to some vendors and asked them about OIDS and the response has been "What!?" In that case it seems like the best thing for us to do is contact the company, ask them if they have one, if they don't, ask if they mind if we generate one for them, and then notify them of it when we have. Even this isn't great, because when you call that company several months later you still aren't likely to find anyone who knows what you're talking about, so some kind of informal database on the Internet and elsewhere is probably a good idea too. -kee (Please cc me, as I'm not on this list)
Stef@ICS.UCI.EDU (Einar Stefferud) (01/12/91)
I really don't think that all those companies are as ignorant as you make them out to be. So, lets try an experiemnt with LOTUS by sending them some mail to ask the primary question about when LOTUS will offer an OID for the carriage of LOTUS product objets in X.400. What I will do is forward this discussion thread to him to see what he thinks of it all. Remember that X.400(84) does not allow the use of arbitrary OIDs as Body Part Identifiers in P2. This is new in X.400(88). X.400(84) only allows the use of specified integer type identifiers for body parts, and all of them have been assigned, aadn no new ones are being assigned for X.400(84). So, I am not sure why LOTUS should be so all fired interested in rushing to enbale you to use their OIDs in non-existant X.400(88) systems. Remember that X.400 is not backward compatible because of the way CCITT does things. Cheers...\Stef
PWW@bnr.ca (Peter Whittaker (P.W.) ) (01/12/91)
> We've already gone to some vendors and asked them about OIDS and the > response has been "What!?" In that case it seems like the best thing > for us to do is contact the company, ask them if they have one, if they > don't, ask if they mind if we generate one for them, and then notify > them of it when we have. Even this isn't great, because when you call > that company several months later you still aren't likely to find anyone > who knows what you're talking about, so some kind of informal database > on the Internet and elsewhere is probably a good idea too. Frankly, I think this is a downright bad idea: if the company says "go ahead", without being aware of the issues involved, they may find themselves with an OID generated (in good faith) by an organization they might any associations with. For the LOTUS example, they may well want to register with ANSI, but they might want to regiter with RARE. They might also not want to receive a number from the IAB under any circumstances. OIDs should be a technical issue, but they quickly become a political issue when you realize that your product's OIDs may have potential competitors in them (i.e. if the IAB decides that 2.4.1001.45.76 is good for a LOTUS spreadsheet, and 45 happens to belong to WIDGET, INC, who has given the IAB proxy for OID assignment, LOTUS might say "But we're not part of WIDGET!"). Okay, so it is farfetched! :-> :-> The point is, no matter how frustrating it is for users/customers, companies must be allowed to seek 'de jure' OIDs for their products rather than being forced into 'de facto' ones. Put pressure on the organization: write to the P, or technical VP, describing the situation. Tell your local service people. Flood their mailing lists until they respond :->, but don't do the registration for them. The surest way to get someone to close their brain and refuse to understand something is to force that something (or even a part of it, such as an OID) upon them. While it is unfortunate, a lot of the functionality and features we want from OSI/CCITT standards is going to have to be provided by bilateral agreements until the standards settle and become ubiquitous. I would suggest a hack: until each company has properly registered OIDs, the Internet community should agree to use an '84 OID with some sort of indicator in the subject line (i.e. L123SS-T5, or WP5.1PSDOC (*) ) as to actual data type contained therein. It's a really ugly idea. Alternatives? (*) L123SS-T5: Lotus 1-2-3 spreadsheet type 5 (whatever - I dunno LOTUS). WP5.1PSDOC: WordPerfect 5.1 PostScript file (whatever - I dunno WP). Peter Whittaker [~~~~~~~~~~~~~~~~~~~~~~~~~~] Open Systems Integration pww@bnr.ca [ Does Bo know Lotus? ] Bell Northern Research Ph: +1 613 765 2064 [ Does Bo Care? ] P.O. Box 3511, Station C FAX:+1 613 763 3283 [__________________________] Ottawa, Ontario, K1Y 4H7
pv@eng.sun.COM (Peter Vanderbilt) (01/15/91)
hsnews@ICS.UCI.EDU > From: Kee Hinckley <nazgul@alfalfa.COM> > We've already gone to some vendors and asked them about OIDS and the > response has been "What!?" In that case it seems like the best thing > for us to do is contact the company, ask them if they have one, if they > don't, ask if they mind if we generate one for them, and then notify > them of it when we have. Right on. > From: Peter Whittaker (P.W.) <PWW@bnr.ca> > OIDs should be a technical issue, but they quickly become a political issue > when you realize that your product's OIDs may have potential competitors > in them (i.e. if the IAB decides that 2.4.1001.45.76 is good for a LOTUS > spreadsheet, and 45 happens to belong to WIDGET, INC, who has given the IAB > proxy for OID assignment, LOTUS might say "But we're not part of WIDGET!"). So, what's the problem? An OID, once allocated, is a structureless token -- the fact that WIDGET helped out with the registration of a LOTUS thing doesn't imply any commercial relation whatsoever. It doesn't matter where an OID comes from so long as it's well defined. Should we hold up progress just so that ignorant people won't jump to invalid conclusions? > From: Einar Stefferud <Stef@ics.uci.edu> > I really don't think that all those companies are as ignorant as you > make them out to be. So, lets try an experiemnt with LOTUS by sending > them some mail to ask the primary question about when LOTUS will offer > an OID for the carriage of LOTUS product objets in X.400. OK, Stef. The clock is running. Let's see how long it takes. > So, I am not sure why LOTUS should be so all > fired interested in rushing to enbale you to use their OIDs in > non-existant X.400(88) systems. 88 systems are starting to pop up. Also, we may see a "chicken and the egg" problem here: one of the nicest things about the 88 protocols is the ability to carry data identified by OIDs. Are 88 systems going to catch on if no OIDs are defined? If 88 systems haven't caught on, will third parties bother getting an OID (especially if it costs 1000 bucks)? Pete
nazgul@alfalfa.COM (Kee Hinckley) (01/15/91)
> > So, I am not sure why LOTUS should be so all > > fired interested in rushing to enbale you to use their OIDs in > > non-existant X.400(88) systems. > > 88 systems are starting to pop up. Also, we may see a "chicken and the > egg" problem here: one of the nicest things about the 88 protocols is > the ability to carry data identified by OIDs. Are 88 systems going to > catch on if no OIDs are defined? If 88 systems haven't caught on, will > third parties bother getting an OID (especially if it costs 1000 > bucks)? In particular, we are using 88 OIDS even on 84 X.400. We currently send all types that aren't defined in 84 as a bilaterally-defined enclosure, and within that we use our own format to encode the OID. We still want the OID to be legit in case someone on the other side (other then ourselves) might want to use the format as well, and so we don't have to tell all of our customers to change their config files when we move to 88 X.400. If you want more details, look for us at Uniforum. We'll be in the Bull and CrossWind booths and possibly some others. -kee Alfalfa Software, Inc. | Poste: The EMail for Unix nazgul@alfalfa.com | Send Anything... Anywhere 617/646-7703 (voice/fax) | info@alfalfa.com I'm not sure which upsets me more; that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
Stef@ICS.UCI.EDU (Einar Stefferud) (01/15/91)
Well, it is all well and good to go off doing bilateral registration solutions, but you must realize that this does not scale, and leads in the end to having many many more OIDs and defintitions for the same objects than we can ever want or need. If you have a way to carry 88 style OID body parts in *$ style integer identifier body parts, and it is senerally useful, you might want to propoose it as an Implementors Agreement and achieve broader support and wider use. Cheers...\Stef
pv@eng.sun.COM (Peter Vanderbilt) (01/15/91)
> From: Allan Cargille <Allan.Cargille@pilot.cs.wisc.edu> > } Better would be some kind of living document available on the net that > } was a repository for body part definitions. [...] > I think that it could be a useful step forward to establish an interim > OID registry. However, isn't it correct that such an OID registry must > be globally known, and otherwise it is worthless? By "globally known" I > mean known or accessible in the worldwide community of X.400 > implmentors. Therefore I do not think that simply announcing it on > this list would work, or even maintaining a living document on the > net. I agree except that I fear someone may take away from this the notion that all 88 OIDs would have to be under an OID subtree assigned to some "global" group such as IETF X.400 OPS, RARE, OIW or EWOS/ETSI. Let's keep in mind that definition, registration, and advertisement are three different things. By "definition" I mean the act of setting down the rules for conveyance of a particular kind of document. By "registration", I mean the act of assigning a particular OID to a definition. By "advertisement", I mean the act of making known that OID and definition. I think it's possible to have definition and registration be done by an individual as long as advertisement is global. > [...] I think that some global concensus [must] be achieved for the > use of OIDs, even ones that have not been formally registered by the > owner of the data item or product. This is a very important point. Consensus is necessary. What we don't want is many different, incompatible definitions for the same thing. We also don't want definitions that are not well defined (one's that permit incompatible implementations). The danger with what I suggested above is that an individual, working alone, may create a definition that is inappropriate or inconvenient in some way, thus causing others to create an alternative definition. This may also be a problem if the "owners" of objects create definitions without really understanding things, such as X.400, ASN.1 and character set issues. (A vendor such as LOTUS may be smart enough to do the right thing, but will most? They are usually in a completely different business and don't know (and don't want to know) anything about X.400 ). Some of the areas I see as potentially causing problems are: Defining a format that relies on ASN.1 encoding of the data (rather than simply using the octet-aligned option). Defining a format that relies on the parameters part. Inclusion of data whose format is machine dependent (such as ints). Requiring the use of one of CRLF or LF as line delimiters (rather than allowing both). Not allowing for international character sets. (My hope is to define formats that correspond to the way the data is used by the application -- I'd like to avoid application-specific filters for translating between network form and application form.) > What about having the new IETF OSI > X.400 Operations working group and the RARE MHS Project (in Europe) > maintain a joint listing of adopted OIDs? Would it be better > to have them jointly defined by the NIST X.400 Interoperability > working group, and its peer groups in Europe and Asia? I'd like to see these groups create guidelines for body part definitions such that anyone following these guidelines would have a good chance of having that definition widely accepted. (The MHS SIG of OIW (NIST) has done some work along these lines.) They should also agree on mechanisms for advertising definitions. I'd rather not have these groups actually doing the definitions because I think the process may be too slow. Pete
S.Kille@cs.ucl.ac.UK (Steve Kille) (01/16/91)
A VERY useful job for someone to do would be to collect all "known" OIDs which have been assigned (or agreed on the basis of someone elses assignment) by the owner of the format. These should be published in some way (RFC? NIST/OIW DOcument? Message sent at intervals to this list?). The existence of this document will have two benefits: 1) It will allow many of us to co-ordinate experiments 2) It will allow for ad hoc assignments to be resolved 3) The document will be seen by many, and this will spur on new assignements, particularly for well known and useful formats (we hope!) Suggestion: How about Kee Hinckley taking his list and formatting it as in Internet Draft. Then circulate to this list ans submit by the usual procedures. There should be a table of: OID Document format (as clear a definition as possible, including version numbers) Authority of assignment (e.g., by format owner, agreed by format owner, format owner informed) (If Kee doesn't want to do this, are there any other volunteers?) Steve