Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.toronto.edu!ietf-distribution-owner Message-ID: Original-To: clw@merit.edu, mak@merit.edu, ietf@ISI.EDU Subject: draft-osids-resdescripx500 Date: Tue, 18 Jun 1991 02:55:13 -0400 From: emv@ox.com (Edward Vielmetti) Newsgroups: list.ietf Distribution: list Sender: list-admin@cs.toronto.edu Approved: list.ietf@mail.cs.toronto.edu Lines: 71 i'm not fond of this document, and i'd like to try to figure out why. first problem is that there's already a perfectly good protocol (Z39.50) for accessing structured data in MARC-like tagged formats. it's extensible, much more so than any ASN.1 encoding is going to be, and there are appropriate tools now being built that use this information. throwing all of this information into X.500 seems to be a step backwards, since you're losing all of the good properties of the tagged datastream. i'd think you'd expect to look up internet resources in the card catalog, not in the phone book. some quibbles with the individual fields: it's a shame that they need to be fixed length. i don't know where you picked the numbers from but it's not hard to believe that some reasonable resources are going to want or need more than the size of the field you have available. the schema are too loosely defined to be of much value for automatic processing. for instance, it would be ideal if the entry for the t-shirt server gave enough of a precisely detailed description of what commands needed to be sent where that it would be possible for the system to connect you to it at the touch of a key. descriptions like "a string describing how to access the resource" make it sound like this field is going to be useless for automatic processing, and the unfortunate user is going to have to negotiate their way through the inevitable cryptic prompts on their own. similar problems arise with the alternateProviders string (a good scheme would also encode enough detail for you to select one), costOfUse (measured in what? dollars? rubles?), sourceMachine (subject to the same problmes as the internet HINFO record, and not necesarily relevant), i could go on. the costOfUse field is almost certainly too small -- 128 characters doesn't even begin to address all of the possible variations on charging policies (by time of day, quality of service, different for commercial or educational users). it's not going to be useful. the real problem is if you expect people are actually going to fill in all of this data for new resources they bring on line, or that you're going to find willing volunteers. this data is expensive to collect, unimaginably bureaucratic, and largely useless to the potential customer of these services. I suspect that services based on these schema will get voluntary compliance rates on the order of the 3-5% that the Internet Resource Guide gets for archives -- only the people who are the most dedicated to self-promotion will bother to fill out and verify the 39 separate data items involved. I have even less confidence that they will keep the resources up to date. I hope i'm not sounding too negative :-). it's important to look at standardizing the way we describe internet resources, and to provide people browsing through internet directories with easy access to the resources they run across or are looking for. X.500 appears to be an artificial choice to store this information in, and the description of the tables for each resource are not adequately defined to make them usable by automatic processses. Other existing protocols, namely Z39.50, provide a more natural structure for which to approach this problem. -- Edward Vielmetti, moderator, comp.archives, MSEN Inc. emv@msen.com "With all of the attention and publicity focused on gigabit networks, not much notice has been given to small and largely unfunded research efforts which are studying innovative approaches for dealing with technical issues within the constraints of economic science." RFC 1216