From owner-ietf-schema-reg Wed May 14 16:39:59 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA07910 for ietf-schema-reg-bks; Wed, 14 May 1997 16:39:59 -0700 (PDT) Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id QAA07906 for ; Wed, 14 May 1997 16:39:57 -0700 (PDT) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 14 May 1997 16:40:50 -0700 To: ietf-schema-reg@imc.org From: "Paul E. Hoffman" Subject: Starting the imc-schema-reg mailing list Sender: owner-ietf-schema-reg@imc.org Precedence: bulk The mailing list is now open. If people have long documents they want to be made available to the list but don't want to mail them to everyone, feel free to send them to me, and I'll put them on the list's Web site . You can then just send out a URL. --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-schema-reg Mon May 19 15:14:51 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA04620 for ietf-schema-reg-bks; Mon, 19 May 1997 15:14:51 -0700 (PDT) Received: from sjf.novell.com (beast.sjf.novell.com [130.57.248.16]) by mail.proper.com (8.8.5/8.7.3) with SMTP id PAA04611 for ; Mon, 19 May 1997 15:14:48 -0700 (PDT) Received: from beauty.sjf by sjf.novell.com (SMI-8.6/SMI-SVR4) id PAA15457; Mon, 19 May 1997 15:10:01 -0700 Received: from bgg.sjf.novell.com by beauty.sjf (SMI-8.6/SMI-SVR4) id PAA03440; Mon, 19 May 1997 15:09:47 -0700 Message-Id: <1.5.4.32.19970519221513.006bfda4@beauty.sjf.novell.com> X-Sender: bgg@beauty.sjf.novell.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 19 May 1997 15:15:13 -0700 To: ietf-schema-reg@imc.org From: Bruce Greenblatt Subject: inetorgperson Sender: owner-ietf-schema-reg@imc.org Precedence: bulk OK. I'll start off ... The inetOrgPerson object class is defined in http://info.internet.isi.edu:80/0/in-drafts/files/draft-ietf-asid-inetorgper son-00.txt. It is a structural object class that is defined as a subclass of organizationalPerson, and several things about it aren't clear to me. - why isn't this an auxiliary object class so that residentialPerson objects can have this information as well? - why does this object class have a userCertificate attribute? This can be added to any object by making use of the strongAuthenticationUser object class. - why does this object class have a labelledURI attribute? Can't this be done with the labelledURI auxiliary object class defined in http://info.internet.isi.edu:80/0/in-drafts/files/draft-ietf-asid-schema-pil ot-00.txt? The last two items raise the more general question of what are we really doing with auxiliary classes? Are they seen as useful, and a way to add attributes to objects that exist in the tree? Or are they seen as confusing and complicated, and it will be expected to have numerous overlapping object class definitions? Bruce ============================================== Bruce Greenblatt bgg@novell.com Internet Directory Services (408) 577-7688 Novell, Inc. Personal: bruceg@megamed.com 2180 Fortune Dr. http://www.megamed.com/~bruceg San Jose, CA 95131 ---> Check out http://www.nldap.com (Novell's LDAP Server for testing) ============================================== From owner-ietf-schema-reg Mon May 19 16:34:04 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA05374 for ietf-schema-reg-bks; Mon, 19 May 1997 16:34:04 -0700 (PDT) Received: from i.control.att.com ([135.205.52.126]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id QAA05370 for ; Mon, 19 May 1997 16:34:01 -0700 (PDT) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Mon, 19 May 1997 19:34:34 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for steve.fisher@worldnet.att.net; Mon, 19 May 1997 19:34:30 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Mon, 19 May 1997 19:34:30 -0400 (EDT) From: capple@master.control.att.com (Christopher Walon Apple) To: Bruce Greenblatt , ietf-schema-reg@imc.org, ietf-asid@umich.edu, ietf-ids@umich.edu Cc: master.control.att.com!capple, master!jerry, steve.fisher@worldnet.att.net Subject: WP Schema Inconsistencies (was: inetorgperson) Sender: owner-ietf-schema-reg@imc.org Precedence: bulk OK...I'll take another step down this slippery slope....rats or no rats... The following list shows that there are several, different, "standard" white pages-related "schemas" or aspects of "schemas" for representing people in directories (or projecting such information from directories) being specified by different groups (more than one within the IETF): draft-ietf-asid-ldapv3-schema-x500-00.txt draft-ietf-asid-inetorgperson-00.txt draft-ietf-ids-iwps-schema-spec-05.txt NAC LIPS (http://www2.netapps.org/netapps/lipschemafinal.htm) X.520/X.521 V-Card 2.0/2.1 (I realize this doesn't quite fit so neatly in with the others.) (there are probably others as well) The attribute naming differences between these "schemas" range from large to small if you compare them on a pair-wise, round-robin basis. For example, consider several attributes from IWPS and NAC LIPS: IWPS Attribute Name NAC LIPS Attribute Name ----------------------------------------------- Cert userCertificate Home Page labeledURI Personal Phone homePhone Personal Fax homeFax Personal Pager (not applicable) Personal Postal Address homePostalAddress Office Phone telephoneNumber Office Fax facsimileTelephoneNumber Office Mobile Phone mobileTelephoneNumber Office Pager pager Based on attribute naming inconsistencies like this and also on LDAP client/server interoperability testing results from research going on in my lab, several questions come to mind: 1) How is interoperability going to materialize if everyone races off in different directions when it comes to attribute naming? 2) Has a situation already been created in which it is not possible to define a standard, core schema that anyone will pay attention to in meaningful ways? 3) While I realize that there was a schema registration BOF held at the Memphis IETF, I do not believe a WG charted as I remember hearing about during this BOF will address the white pages core schema consistency issue. What are the chances that a BOF in Munich on the subject would be well-attended? 4) Do I have a volunteer for a co-conspiritor to get such a BOF going and on the agenda in Munich? Chris Apple Electronic Directory Group AT&T Labs capple@att.com +1 908 582 2409 From owner-ietf-schema-reg Mon May 19 17:59:10 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA06224 for ietf-schema-reg-bks; Mon, 19 May 1997 17:59:10 -0700 (PDT) Received: from INET-02-IMC.microsoft.com (mail2.microsoft.com [131.107.3.42]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id RAA06218 for ; Mon, 19 May 1997 17:59:07 -0700 (PDT) Received: by INET-02-IMC with Internet Mail Service (5.0.1458.30) id ; Mon, 19 May 1997 17:59:34 -0700 Message-ID: From: Chris Weider To: "'ietf-schema-reg@imc.org'" Subject: First draft of Schema Registry charter Date: Mon, 19 May 1997 17:59:34 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.30) Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Hi gang: Here's a proposal for the Schema Registry charter. Please comment; I'd like to get this in final shape by 5/30. Thanks! Chris Schema Registration (schema) Charter Current Status: Proposed Working Group Chair(s): Chris Weider cweider@microsoft.com Applications Area Director(s): Keith Moore moore+iesg@cs.utk.edu Harald Alvestrand ; Mon, 19 May 1997 20:11:14 -0700 (PDT) Received: from tintin.netscape.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id UAA21342 for ; Mon, 19 May 1997 20:11:43 -0700 (PDT) Received: from vertigo ([205.217.228.51]) by tintin.netscape.com (Netscape Messaging Server 3.0) with SMTP id AAA9959; Mon, 19 May 1997 20:11:43 -0700 Message-ID: <338115E9.4287@netscape.com> Date: Mon, 19 May 1997 20:09:29 -0700 From: Tim Howes Organization: Netscape Communications Corp. X-Mailer: Mozilla 3.01Gold (X11; I; IRIX 6.2 IP22) MIME-Version: 1.0 To: Chris Weider CC: "'ietf-schema-reg@imc.org'" Subject: Re: First draft of Schema Registry charter References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Chris Weider wrote: > > Hi gang: > Here's a proposal for the Schema Registry charter. Please comment; I'd > like to get this in final shape by 5/30. Looks great, Chris. A few comments below. > Schema Registration (schema) Given that one of the goals is explicitly to provide a listing service, not a registration service, maybe we should change the name of the group accordingly. > Charter > > Current Status: Proposed Working Group > > Chair(s): > Chris Weider cweider@microsoft.com > > > Applications Area Director(s): > Keith Moore moore+iesg@cs.utk.edu > Harald Alvestrand > Area Advisor > > Mailing Lists: > General Discussion: ietf-schema-reg@imc.org > To subscribe: ietf-schema-reg-request@imc.org > In Body: subscribe > Archive: http://www.imc.org/ietf-schema-reg > > Description of Working Group: > > In order to achieve the goal of interoperable directory services, > implementors must agree on standard object classes and attribute types. > There are a growing number of places where schema for Internet Directory > Services and Internet Operations are being defined. While this plethora > of schema authors is desirable, a schema registry service is needed to > avoid duplication of effort, allow a single point of schema discovery, > and promote interoperability of directory services and operations. > > This working group will create the standards necessary to deploy a > schema registry service. This service will be deployed by December 1997. > The standards will use the following design criteria: > > - Schema are 'listed' rather then 'registered'. then => than. > - The process of listing schema will be centralized for the initial > deployment. > - The database which provides the registry store will be centrally > administered. > > These criteria will reduce administrative overhead, reduce the number of > protocol and process elements which need to be defined, and do not > preclude the provision of additional functionality if the community > decides it is necessary. > > To this end, the work items include: > > Determining the minimum namespace for the registry. > Determining which syntaxes are allowed for registration. > Finding a document editor. > Deciding whether to allow modifications and amendments to the registered > schema. I would say "whether and how". > Determining the functionality and operational requirements for the > registry service. > > Goals and Milestones: > > June 97 Finalize charter > > June 97 Locate document editor > > Aug 97 Submit Registration Procedure document as Internet Draft > > Aug 97 Submit Registry Requirements document as Internet Draft > > Oct 97 Submit Registration Procedure document as Informational > RFC > > Oct 97 Submit Registry Requirements document as Informational > RFC > > Dec 97 Deploy registry, close working group I'm all for moving fast, but does putting out the requirements document at the same time the solution comes out seem odd to you? Not a biggie I guess, since the requirements is mostly for us. But you might at least list the requirements doc first in the milestones. :) -- Tim From owner-ietf-schema-reg Tue May 20 07:38:33 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id HAA13930 for ietf-schema-reg-bks; Tue, 20 May 1997 07:38:33 -0700 (PDT) Received: from novell.com (orm-mail20.orem.novell.com [151.155.174.10]) by mail.proper.com (8.8.5/8.7.3) with SMTP id HAA13925 for ; Tue, 20 May 1997 07:38:30 -0700 (PDT) Received: from INET-ORM-Message_Server by novell.com with Novell_GroupWise; Tue, 20 May 1997 08:38:57 -0600 Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 20 May 1997 08:38:07 -0600 From: Russel Weiser To: ietf-schema-reg@imc.org Subject: RE: First draft of Schema Registry charter Sender: owner-ietf-schema-reg@imc.org Precedence: bulk I personally would like to see something in the charter that discusses how coalescing of schema overlaps is encouraged and facilitated. The problems that Bruce Greenblatt and Christopher Walon Apple are real. So I believe that coalescing,obsoletion and a referral isues should take presidence over any attempt of modification and or amendment process. Note when I say referal , I'm think some way that way of Obsoleting a definition with some pointer left in place pointing to the OID of the new accepted attribute description. Then maybe the most popular attribute names and uses would shine through. cheers Russel F Weiser Novell Inc. IID Mail stop PRV-F21 122 E 1700 S Provo, Utah 84606 tele (801)-861-7808 FAX:(801-861-2699 E-mail: Rweiser@novell.com From owner-ietf-schema-reg Tue May 20 08:02:25 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id IAA14305 for ietf-schema-reg-bks; Tue, 20 May 1997 08:02:25 -0700 (PDT) Received: from acl.lanl.gov (root@acl.lanl.gov [128.165.147.1]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id IAA14300 for ; Tue, 20 May 1997 08:02:21 -0700 (PDT) Received: from montana.acl.lanl.gov (montana.acl.lanl.gov [128.165.147.143]) by acl.lanl.gov (8.7.3/8.8.5) with SMTP id JAA13116; Tue, 20 May 1997 09:00:20 -0600 (MDT) Message-Id: <3.0.32.19970520085647.00729364@cic-mail.lanl.gov> X-Sender: u114212@cic-mail.lanl.gov X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 20 May 1997 09:01:53 -0600 To: Chris Weider , "'ietf-schema-reg@imc.org'" From: "Ron Daniel, Jr." Subject: Re: First draft of Schema Registry charter Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-schema-reg@imc.org Precedence: bulk At 05:59 PM 5/19/97 -0700, Chris Weider wrote: > Here's a proposal for the Schema Registry charter. Please comment; I'd >like to get this in final shape by 5/30. Looks good. >While this plethora >of schema authors is desirable, a schema registry service is needed to >avoid duplication of effort, allow a single point of schema discovery, >and promote interoperability of directory services and operations. How about: This plethora of schemas makes interoperation difficult, but is unavoidable. A registration service that provides a single point of discovery for white-pages schemas will promote interoperability by reducing further duplication of effort and by identifying correspondances between schemata. >To this end, the work items include: > >Determining the minimum namespace for the registry. Um, could you explain? Are we registering complete schemas (e.g. vcard, IWPS,...), individual elements (e.g. home-phone, postal-address, ...), both (e.g. IWPS/Personal-phone) or is this work item saying that we need to make that decision as part of the work of the group? >Determining which syntaxes are allowed for registration. Also the additional information to be collected, such as the contact info for the schema developer, relevant RFCs, etc. >Aug 97 Submit Registration Procedure document as Internet Draft > >Aug 97 Submit Registry Requirements document as Internet Draft I agree with Tim that these should probably not be in the same month. Later, Ron Daniel Jr. voice:+1 505 665 0597 Advanced Computing Lab fax:+1 505 665 4939 MS B287 email:rdaniel@lanl.gov Los Alamos National Lab http://www.acl.lanl.gov/~rdaniel Los Alamos, NM, USA, 87545 From owner-ietf-schema-reg Tue May 20 09:29:14 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA15639 for ietf-schema-reg-bks; Tue, 20 May 1997 09:29:14 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id JAA15635 for ; Tue, 20 May 1997 09:29:11 -0700 (PDT) Received: from tintin.netscape.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id JAA03967 for ; Tue, 20 May 1997 09:29:42 -0700 (PDT) Received: from vertigo ([205.217.228.51]) by tintin.netscape.com (Netscape Messaging Server 3.0) with SMTP id AAA1748; Tue, 20 May 1997 09:29:42 -0700 Message-ID: <3381D0EF.15FB@netscape.com> Date: Tue, 20 May 1997 09:27:27 -0700 From: Tim Howes Organization: Netscape Communications Corp. X-Mailer: Mozilla 3.01Gold (X11; I; IRIX 6.2 IP22) MIME-Version: 1.0 To: Bruce Greenblatt CC: ietf-schema-reg@imc.org Subject: Re: inetorgperson References: <1.5.4.32.19970519221513.006bfda4@beauty.sjf.novell.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-schema-reg@imc.org Precedence: bulk I find the approach of adding a new auxiliary object class for each new attribute you want to add to an entry burdensome, inefficient, unworkable, and generally without advantage. There's no reason not to include attributes (like userCertificate or labeledURI) directly in a derived object class. Though, there are situations in which adding an auxiliary object class is a good way to get the new attribute you want. As for why the class itself is not auxiliary, well, we felt it was more appropriate to make it a subclass of person. I would expect clients to be searching for person entries, not residentialPerson or organizationalPerson entries. The reason we chose organizationalPerson instead of residentialPerson is just that it already contained more of the attributes we wanted. Having said that, though, I should point out that the purpose of this list, as I understand it, is not to discuss various schema proposals. The purpose of this list and working group is to define the means by which schema elements are listed, making them available to the community. -- Tim Bruce Greenblatt wrote: > > OK. I'll start off ... The inetOrgPerson object class is defined in > http://info.internet.isi.edu:80/0/in-drafts/files/draft-ietf-asid-inetorgper > son-00.txt. It is a structural object class that is defined as a subclass of > organizationalPerson, and several things about it aren't clear to me. > > - why isn't this an auxiliary object class so that residentialPerson objects > can have this information as well? > > - why does this object class have a userCertificate attribute? This can be > added to any object by making use of the strongAuthenticationUser object class. > > - why does this object class have a labelledURI attribute? Can't this be > done with the labelledURI auxiliary object class defined in > http://info.internet.isi.edu:80/0/in-drafts/files/draft-ietf-asid-schema-pil > ot-00.txt? > > The last two items raise the more general question of what are we really > doing with auxiliary classes? Are they seen as useful, and a way to add > attributes to objects that exist in the tree? Or are they seen as confusing > and complicated, and it will be expected to have numerous overlapping object > class definitions? > > Bruce > ============================================== > Bruce Greenblatt bgg@novell.com > Internet Directory Services (408) 577-7688 > Novell, Inc. Personal: bruceg@megamed.com > 2180 Fortune Dr. http://www.megamed.com/~bruceg > San Jose, CA 95131 > ---> Check out http://www.nldap.com (Novell's LDAP Server for testing) > ============================================== From owner-ietf-schema-reg Tue May 20 10:46:37 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA16574 for ietf-schema-reg-bks; Tue, 20 May 1997 10:46:37 -0700 (PDT) Received: from isak.telepost.no (isak.telepost.no [193.212.240.68]) by mail.proper.com (8.8.5/8.7.3) with SMTP id KAA16568 for ; Tue, 20 May 1997 10:46:33 -0700 (PDT) Received: by isak.telepost.no; Tue, 20 May 97 19:46:36 +0200 X400-Received: by /c=no/admd=telemax/prmd=internet/; converted ( (1)(0)(10021)(7)(1)(0)(6)(1), (1)(0)(10021)(7)(1)(0)(6)(6), (1)(0)(10021)(7)(1)(0)(6)(100), (2)(6)(1)(4)(11)); Relayed; 20 May 1997 19:46:36 +0200 X400-Received: by /c=NO/admd=TELEMAX/; Relayed; 20 May 1997 17:45:22 Z X400-Received: by mta MHNORWAY in /c=no/admd=telemax/prmd=internet/; converted ( (1)(0)(10021)(7)(1)(0)(6)(1), (1)(0)(10021)(7)(1)(0)(6)(6), (1)(0)(10021)(7)(1)(0)(6)(100), (2)(6)(1)(4)(11)); Relayed; 20 May 1997 19:46:36 +0200 X400-MTS-Identifier: [/c=NO/admd=TELEMAX/; NORWAYII R0000000864150321120] Content-Identifier: 55672 97/05/20 Content-Return: Prohibited X400-Content-Type: P2-1984 ( 2 ) Conversion: Allowed Original-Encoded-Information-Types: Teletex Disclose-Recipients: Prohibited Alternate-Recipient: Allowed X400-Originator: frode.hernes@maxware.telemax.no X400-Recipients: non-disclosure; Message-Id: <"55672 97/05/20*/c=no/admd=telemax/prmd=/o=maxware/s=hernes/g=frode/"@MHS> In-Reply-To: Date: 20 May 1997 17:45:22 Z From: "Frode Hernes" To: ietf-schema-reg@imc.org (Receipt notification requested) Subject: Re:WP Schema Inconsistencies (was: inetorgperson) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Hi, I agree with Tim, this should be a list for registration / announcement, = can we all use ietf-ids = for schema / attribute discussions ? Also, I have for two years been on a schema announce list (without seeing= much traffic), is = this terminated now ? -- The welcome message I got in '95 from "schema-announce": - - - - - - -= - - - - - - = Welcome to the schema-announce mailing list! If you ever want to remove yourself from this mailing list, send the following command in email to "schema-announce-request@dsmail.internic.net": unsubscribe Or you can send mail to "Majordomo@dsmail.internic.net" with the followin= g command in the body of your email message: unsubscribe schema-announce Frode Hernes Here's the general information for the list you've subscribed to, in case you don't already have it: schema-announce This moderated mailing list will be used to announce updates to the X.500 Internet Schema maintained by the IETF Schema Working Group. The Schema update announcements will be announced on the following lists: = wpp-camayocs@psi.com managers@nameflow.dante.net If you are not on the above two lists and wish to receive update announcements please subscribe to this list by sending the following command to majordomo@dsmail.internic.net in the body of the message: subscribe schema-announce The Internet X.500 Schema itself is available via = the following URLs: ftp://ds.internic.net/pub/src/x500/schema/ gopher://ds.internic.net/pub/src/x500/schema/ http://ds.internic.net/pub/src/x500/schema/ If you ever wish to be removed from the list, send the following command to majordomo@dsmail.internic.net in the body of the message: unsubscribe schema-announce List Owner: = Sri Sataluri AT&T Bell Laboratories schema-announce-owner@dsmail.internic.net - - - - end- - - - = Frode. - - - - - - - - - - - - - Frode Hernes MaXware 12614 Builders Road Herndon, VA 20170 Tel:(703) 435 2587 Mobile:(703) 919 5166 Fax:1 (800) 355 2071 X.400:g=3DFrode;s=3DHernes;o=3DMaXware;a=3DTelemax;c=3DNo Mailto:frode.hernes@maxware.telemax.no MaXware A.S: mailto:maxware@maxware.no http://www.maxware.no From owner-ietf-schema-reg Tue May 20 11:02:27 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA16755 for ietf-schema-reg-bks; Tue, 20 May 1997 11:02:27 -0700 (PDT) Received: from cagw2.att.com (cagw2.att.com [192.128.52.90]) by mail.proper.com (8.8.5/8.7.3) with SMTP id LAA16751 for ; Tue, 20 May 1997 11:02:24 -0700 (PDT) Received: from qsun.ho.att.com by caig2.att.att.com (SMI-8.6/EMS-1.2 sol2) id OAA01032; Tue, 20 May 1997 14:10:57 -0400 Received: from qsun2.ho.att.com.qsun2 by qsun.ho.att.com (4.1/EMS-1.1.1 SunOS) id AA00659; Tue, 20 May 97 14:03:12 EDT Received: from sumedha.ho.att.com by qsun2.ho.att.com.qsun2 (5.x/EMS-1.2 sol2) id AA28099; Tue, 20 May 1997 14:03:29 -0400 Message-Id: <3381E76A.CF3590FD@att.com> Date: Tue, 20 May 1997 14:03:22 -0400 From: Sri Sataluri Reply-To: sri@att.com Organization: AT&T X-Mailer: Mozilla 4.0b4 [en] (Win95; I) Mime-Version: 1.0 To: Chris Weider Cc: "'ietf-schema-reg@imc.org'" Subject: Re: First draft of Schema Registry charter X-Priority: 3 (Normal) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Chris Weider wrote: > > Services and Internet Operations are being defined. While this > plethora > of schema authors is desirable, a schema registry service is needed to use "specifications" instead of "authors" > The standards will use the following design criteria: > > - Schema are 'listed' rather then 'registered'. I am confused with this statement. The requirements document is supposed to state what is needed. What is the difference between listing and registration. Will the schema registry try to be self contained and consistent? If yes, it has to arbitrate, reject duplicates, and provide feedback. If on the other hand it is like a news server where any one can post anything - I do not see much use for such a service. > Finding a document editor. editor(s) - we have atleast 2 documents - it is important to have different editors for the requirements and solution. > Deciding whether to allow modifications and amendments to the > registered > schema. > Determining the functionality and operational requirements for the > registry service. > > Goals and Milestones: Thanks. -- -sri (Srinivas R. Sataluri, sri@att.com or sataluri@mail.att.net) From owner-ietf-schema-reg Tue May 20 12:15:08 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA17486 for ietf-schema-reg-bks; Tue, 20 May 1997 12:15:08 -0700 (PDT) Received: from lotus.lotus.com (lotus.com [192.233.136.1]) by mail.proper.com (8.8.5/8.7.3) with SMTP id MAA17482 for ; Tue, 20 May 1997 12:15:05 -0700 (PDT) From: Frank_Dawson/CAM/Lotus@lotus.com Received: from internet2.lotus.com by lotus.lotus.com (SMI-8.6/SMI-SVR4) id PAA14141; Tue, 20 May 1997 15:12:14 -0400 Received: from MTA2.lotus.com by internet2.lotus.com (5.x/SMI-SVR4) id AD25456; Tue, 20 May 1997 15:08:41 -0400 Received: by mta2.lotus.com(Lotus SMTP MTA v1.1 (385.6 5-6-1997)) id 8525649D.0069F1C6 ; Tue, 20 May 1997 15:17:11 -0400 X-Lotus-Fromdomain: LOTUS@MTA To: cweider@microsoft.com Cc: ietf-schema-reg@imc.org Message-Id: <8525649D.0068E21A.00@mta2.lotus.com> Date: Tue, 20 May 1997 15:10:54 -0400 Subject: Re: First draft of Schema Registry charter Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Folks: I am not particularly happy about the number of schemas we have for directories either. It would be very much simplier if everyone would just use mine ;-) It would be a far worse thing if the IETF got into the job of filtering schemas and determining which ones were eligible for "listing" and which ones were to be rejected. I seem to have gotten the wiff of this in a couple of the postings. This would not be good thing. Just be happy being a collector and list any that come in. - - Frank Dawson From owner-ietf-schema-reg Tue May 20 12:37:26 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA17759 for ietf-schema-reg-bks; Tue, 20 May 1997 12:37:26 -0700 (PDT) Received: from INET-04-IMC.microsoft.com (mail4.microsoft.com [131.107.3.29]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA17754 for ; Tue, 20 May 1997 12:37:24 -0700 (PDT) Received: by mail4.microsoft.com with Internet Mail Service (5.0.1458.30) id ; Tue, 20 May 1997 12:37:53 -0700 Message-ID: From: Chris Weider To: "'Frank_Dawson/CAM/Lotus@lotus.com'" Cc: ietf-schema-reg@imc.org Subject: RE: First draft of Schema Registry charter Date: Tue, 20 May 1997 12:37:52 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.30) Sender: owner-ietf-schema-reg@imc.org Precedence: bulk As I pointed out at the meeting, if we want something deployed this year (or even this decade) we have to go with listing semantics. And contrary to Sri's comment, this would be a useful repository and a place to discover new schema rather than roll your own. It is also an important first step to a registry if we decide we want and can maintain one. Chris > -----Original Message----- > From: Frank_Dawson/CAM/Lotus@lotus.com > [SMTP:Frank_Dawson/CAM/Lotus@lotus.com] > Sent: Tuesday, May 20, 1997 12:11 PM > To: Chris Weider > Cc: ietf-schema-reg@imc.org > Subject: Re: First draft of Schema Registry charter > > > > > > Folks: > > I am not particularly happy about the number of schemas we have for > directories either. It would be very much simplier if everyone would > just > use mine ;-) > > It would be a far worse thing if the IETF got into the job of > filtering > schemas and determining which ones were eligible for "listing" and > which > ones were to be rejected. I seem to have gotten the wiff of this in a > couple of the postings. This would not be good thing. > > Just be happy being a collector and list any that come in. > > - - Frank Dawson > From owner-ietf-schema-reg Tue May 20 12:42:36 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA17910 for ietf-schema-reg-bks; Tue, 20 May 1997 12:42:36 -0700 (PDT) Received: from INET-01-IMC.microsoft.com (mail1.microsoft.com [131.107.3.41]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA17906 for ; Tue, 20 May 1997 12:42:33 -0700 (PDT) Received: by INET-01-IMC with Internet Mail Service (5.0.1458.30) id ; Tue, 20 May 1997 12:43:06 -0700 Message-ID: From: Chris Weider To: "'sri@att.com'" Cc: "'ietf-schema-reg@imc.org'" Subject: RE: First draft of Schema Registry charter Date: Tue, 20 May 1997 12:41:26 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.30) Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Hi Sri: Having different editors is a fine idea. I think you're wrong about the usefulness of a listing service; it's a central repository of defined schema, which may well help the schema proliferation problem. And it's an important first step to a registry. Building a registry that arbitrates, rejects duplicates, and provides feedback is a monumental undertaking. Let's get the first step deployed. Chris > -----Original Message----- > From: Sri Sataluri [SMTP:sri@att.com] > Sent: Tuesday, May 20, 1997 11:03 AM > To: Chris Weider > Cc: 'ietf-schema-reg@imc.org' > Subject: Re: First draft of Schema Registry charter > > Chris Weider wrote: > > > > > Services and Internet Operations are being defined. While this > > plethora > > of schema authors is desirable, a schema registry service is needed > to > use "specifications" instead of "authors" > > > The standards will use the following design criteria: > > > > - Schema are 'listed' rather then 'registered'. > > I am confused with this statement. The requirements document > is supposed to state what is needed. What is the difference > between listing and registration. Will the schema registry > try to be self contained and consistent? If yes, it has to > arbitrate, reject duplicates, and provide feedback. If on > the other hand it is like a news server where any one can > post anything - I do not see much use for such a service. > > > Finding a document editor. > > editor(s) - we have atleast 2 documents - it is important > to have different editors for the requirements and solution. > > > Deciding whether to allow modifications and amendments to the > > registered > > schema. > > Determining the functionality and operational requirements for the > > registry service. > > > > Goals and Milestones: > > Thanks. > > -- > -sri (Srinivas R. Sataluri, sri@att.com or sataluri@mail.att.net) From owner-ietf-schema-reg Tue May 20 12:43:18 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA17942 for ietf-schema-reg-bks; Tue, 20 May 1997 12:43:18 -0700 (PDT) Received: from INET-04-IMC.microsoft.com (mail4.microsoft.com [131.107.3.29]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA17930 for ; Tue, 20 May 1997 12:43:15 -0700 (PDT) Received: by mail4.microsoft.com with Internet Mail Service (5.0.1458.30) id ; Tue, 20 May 1997 12:43:27 -0700 Message-ID: From: Chris Weider To: "'Ron Daniel, Jr.'" , "'ietf-schema-reg@imc.org'" Subject: RE: First draft of Schema Registry charter Date: Tue, 20 May 1997 12:43:20 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.30) Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Your wording is better than mine. Thanks! We as a group need to decide what granularity we are listing. I have some opinions but we should get the charter set first. Also, I agree with the comments you and Tim have made with naming. I'll change that in the next rev of the proposed charter. Thanks! Chris > -----Original Message----- > From: Ron Daniel, Jr. [SMTP:rdaniel@lanl.gov] > Sent: Tuesday, May 20, 1997 8:02 AM > To: Chris Weider; 'ietf-schema-reg@imc.org' > Subject: Re: First draft of Schema Registry charter > > At 05:59 PM 5/19/97 -0700, Chris Weider wrote: > > Here's a proposal for the Schema Registry charter. Please comment; > I'd > >like to get this in final shape by 5/30. > > Looks good. > > >While this plethora > >of schema authors is desirable, a schema registry service is needed > to > >avoid duplication of effort, allow a single point of schema > discovery, > >and promote interoperability of directory services and operations. > > How about: > > This plethora of schemas makes interoperation difficult, but is > unavoidable. A registration service that provides a single point > of discovery for white-pages schemas will promote interoperability > by reducing further duplication of effort and by identifying > correspondances between schemata. > > > > > >To this end, the work items include: > > > >Determining the minimum namespace for the registry. > > Um, could you explain? Are we registering complete schemas (e.g. > vcard, > IWPS,...), individual elements (e.g. home-phone, postal-address, ...), > both > (e.g. IWPS/Personal-phone) or is this work item saying that we need to > make that decision as part of the work of the group? > > >Determining which syntaxes are allowed for registration. > > Also the additional information to be collected, such as the > contact info for the schema developer, relevant RFCs, etc. > > >Aug 97 Submit Registration Procedure document as > Internet Draft > > > >Aug 97 Submit Registry Requirements document as > Internet Draft > > I agree with Tim that these should probably not be in the same month. > > > Later, > > Ron Daniel Jr. voice:+1 505 665 0597 > Advanced Computing Lab fax:+1 505 665 4939 > MS B287 email:rdaniel@lanl.gov > Los Alamos National Lab http://www.acl.lanl.gov/~rdaniel > Los Alamos, NM, USA, 87545 From owner-ietf-schema-reg Tue May 20 12:46:50 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA18028 for ietf-schema-reg-bks; Tue, 20 May 1997 12:46:50 -0700 (PDT) Received: from INET-01-IMC.microsoft.com (mail1.microsoft.com [131.107.3.41]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA18024 for ; Tue, 20 May 1997 12:46:48 -0700 (PDT) Received: by INET-01-IMC with Internet Mail Service (5.0.1458.30) id ; Tue, 20 May 1997 12:47:21 -0700 Message-ID: From: Chris Weider To: "'Russel Weiser'" , ietf-schema-reg@imc.org Subject: RE: First draft of Schema Registry charter Date: Tue, 20 May 1997 12:47:19 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.30) Sender: owner-ietf-schema-reg@imc.org Precedence: bulk I personally think that schema rationalization and coalescing is outside the scope of this group. Once we have created the registry, though, we have provided an important tool to do this sort of work; perhaps this is an item for a followon? Referrals, though, may well be something to do before modification or amendment. What does everyone else think? Chris > -----Original Message----- > From: Russel Weiser [SMTP:RWEISER@novell.com] > Sent: Tuesday, May 20, 1997 7:38 AM > To: ietf-schema-reg@imc.org > Subject: RE: First draft of Schema Registry charter > > I personally would like to see something in the charter that discusses > how > coalescing of schema overlaps is encouraged and facilitated. The > problems > that Bruce Greenblatt and Christopher Walon Apple are real. So I > believe > that coalescing,obsoletion and a referral isues should take presidence > over > any attempt of modification and or amendment process. Note when I > say > referal , I'm think some way that way of Obsoleting a definition with > some > pointer left in place pointing to the OID of the new accepted > attribute > description. Then maybe the most popular attribute names and uses > would > shine through. > > cheers > > > > > Russel F Weiser > Novell Inc. > IID Mail stop PRV-F21 > 122 E 1700 S > Provo, Utah > 84606 > tele (801)-861-7808 > FAX:(801-861-2699 > E-mail: Rweiser@novell.com > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-ietf-schema-reg Tue May 20 12:48:15 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA18052 for ietf-schema-reg-bks; Tue, 20 May 1997 12:48:15 -0700 (PDT) Received: from INET-04-IMC.microsoft.com (mail4.microsoft.com [131.107.3.29]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA18048 for ; Tue, 20 May 1997 12:48:11 -0700 (PDT) Received: by mail4.microsoft.com with Internet Mail Service (5.0.1458.30) id ; Tue, 20 May 1997 12:48:34 -0700 Message-ID: From: Chris Weider To: "'Tim Howes'" Cc: "'ietf-schema-reg@imc.org'" Subject: RE: First draft of Schema Registry charter Date: Tue, 20 May 1997 12:48:33 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.30) Sender: owner-ietf-schema-reg@imc.org Precedence: bulk I think that a name change is an important point. I'm for it, to avoid confusion as to the purpose of the group. Does anyone else have a problem with Schema Listing? Chris > -----Original Message----- > From: Tim Howes [SMTP:howes@netscape.com] > Sent: Monday, May 19, 1997 8:09 PM > To: Chris Weider > Cc: 'ietf-schema-reg@imc.org' > Subject: Re: First draft of Schema Registry charter > > Chris Weider wrote: > > > > Hi gang: > > Here's a proposal for the Schema Registry charter. Please comment; > I'd > > like to get this in final shape by 5/30. > > Looks great, Chris. A few comments below. > > > Schema Registration (schema) > > Given that one of the goals is explicitly to provide > a listing service, not a registration service, maybe > we should change the name of the group accordingly. > > > Charter > > > > Current Status: Proposed Working Group > > > > Chair(s): > > Chris Weider cweider@microsoft.com > > > > > > Applications Area Director(s): > > Keith Moore moore+iesg@cs.utk.edu > > > Harald Alvestrand > > > Area Advisor > > > > Mailing Lists: > > General Discussion: ietf-schema-reg@imc.org > > To subscribe: ietf-schema-reg-request@imc.org > > In Body: subscribe > > Archive: http://www.imc.org/ietf-schema-reg > > > > Description of Working Group: > > > > In order to achieve the goal of interoperable directory services, > > implementors must agree on standard object classes and attribute > types. > > There are a growing number of places where schema for Internet > Directory > > Services and Internet Operations are being defined. While this > plethora > > of schema authors is desirable, a schema registry service is needed > to > > avoid duplication of effort, allow a single point of schema > discovery, > > and promote interoperability of directory services and operations. > > > > This working group will create the standards necessary to deploy a > > schema registry service. This service will be deployed by December > 1997. > > The standards will use the following design criteria: > > > > - Schema are 'listed' rather then 'registered'. > > then => than. > > > - The process of listing schema will be centralized for the initial > > deployment. > > - The database which provides the registry store will be centrally > > administered. > > > > These criteria will reduce administrative overhead, reduce the > number of > > protocol and process elements which need to be defined, and do not > > preclude the provision of additional functionality if the community > > decides it is necessary. > > > > To this end, the work items include: > > > > Determining the minimum namespace for the registry. > > Determining which syntaxes are allowed for registration. > > Finding a document editor. > > Deciding whether to allow modifications and amendments to the > registered > > schema. > > I would say "whether and how". > > > Determining the functionality and operational requirements for the > > registry service. > > > > Goals and Milestones: > > > > June 97 Finalize charter > > > > June 97 Locate document editor > > > > Aug 97 Submit Registration Procedure document as Internet > Draft > > > > Aug 97 Submit Registry Requirements document as Internet > Draft > > > > Oct 97 Submit Registration Procedure document as > Informational > > RFC > > > > Oct 97 Submit Registry Requirements document as > Informational > > RFC > > > > Dec 97 Deploy registry, close working group > > I'm all for moving fast, but does putting out the requirements > document at the same time the solution comes out seem odd to > you? Not a biggie I guess, since the requirements is mostly for > us. But you might at least list the requirements doc first in > the milestones. :) -- Tim From owner-ietf-schema-reg Tue May 20 13:07:55 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA18285 for ietf-schema-reg-bks; Tue, 20 May 1997 13:07:55 -0700 (PDT) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.5/8.7.3) with SMTP id NAA18281 for ; Tue, 20 May 1997 13:07:52 -0700 (PDT) Received: from norman.cp10.es.xerox.com ([13.240.124.12]) by alpha.xerox.com with SMTP id <18403(2)>; Tue, 20 May 1997 13:07:51 PDT Received: from garfield (garfield.cp10.es.xerox.com) by norman.cp10.es.xerox.com (4.1/SMI-4.1) id AA28915; Tue, 20 May 97 13:08:02 PDT Received: from cpq5100-26 by garfield (SMI-8.6/SMI-SVR4) id NAA06003; Tue, 20 May 1997 13:04:55 -0700 Message-Id: <3.0.1.32.19970520130248.0102c908@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 20 May 1997 13:02:48 PDT To: Frank_Dawson/CAM/Lotus@lotus.com, cweider@microsoft.com From: Carl-Uno Manros Subject: Re: First draft of Schema Registry charter Cc: ietf-schema-reg@imc.org, ipp@pwg.org In-Reply-To: <8525649D.0068E21A.00@mta2.lotus.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-schema-reg@imc.org Precedence: bulk At 12:10 PM 5/20/97 PDT, Frank_Dawson/CAM/Lotus@lotus.com wrote: > >Folks: > >I am not particularly happy about the number of schemas we have for >directories either. It would be very much simplier if everyone would just >use mine ;-) > Folks, in the IPP project, we are trying to create one directory schema protocol that contains recommended attributes for finding and selecting printers and print servers. We would be very happy if there was ONE recommendation on how to write a directory protocol independent schema. I made this suggestion back in Memphis and I am repeating it again here. Even if we historically have x different ways of describing schemas right now, wouldn't it make sense to define a form to be used for new specifications? Isn't that a good task for this group? Think about how much easier schema registration would be down the line! Carl-Uno Manros Co-chair IPP WG Any suggestion Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From owner-ietf-schema-reg Tue May 20 13:56:45 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA18763 for ietf-schema-reg-bks; Tue, 20 May 1997 13:56:45 -0700 (PDT) Received: from cagw1.att.com (cagw1.att.com [192.128.52.89]) by mail.proper.com (8.8.5/8.7.3) with SMTP id NAA18759 for ; Tue, 20 May 1997 13:56:42 -0700 (PDT) Received: from qsun.ho.att.com by caig1.att.att.com (SMI-8.6/EMS-1.2 sol2) id QAA02858; Tue, 20 May 1997 16:51:02 -0400 Received: from qsun2.ho.att.com.qsun2 by qsun.ho.att.com (4.1/EMS-1.1.1 SunOS) id AA16879; Tue, 20 May 97 16:57:33 EDT Received: from sumedha.ho.att.com by qsun2.ho.att.com.qsun2 (5.x/EMS-1.2 sol2) id AA20875; Tue, 20 May 1997 16:57:49 -0400 Message-Id: <33821048.347D7867@att.com> Date: Tue, 20 May 1997 16:57:44 -0400 From: Sri Sataluri Reply-To: sri@att.com Organization: AT&T X-Mailer: Mozilla 4.0b4 [en] (Win95; I) Mime-Version: 1.0 To: Frode Hernes Cc: Receipt notification requested , ietf-ids@umich.edu Subject: Re: WP Schema Inconsistencies (was: inetorgperson) X-Priority: 3 (Normal) References: <"55672 97/05/20*/c=no/admd=telemax/prmd=/o=maxware/s=hernes/g=frode/"@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Frode: Let's presume that the old list is dead and forgotten. Please do not bother to unsubscribe. The purpose of that list was for announcements. Since the new ietf-schema-reg is a mailing list for a real working group, it will need a discussion list. It is useful to seperate announcements from discussion and we have no objection to the use of the ietf-ids@umich.edu list especially by a WG that will finish its work by December 1997! Thanks. -- -sri (Srinivas R. Sataluri, sri@att.com or sataluri@mail.att.net) Frode Hernes wrote: > > Hi, > > I agree with Tim, this should be a list for registration / > announcement, can we all use ietf-ids > for schema / attribute discussions ? > > Also, I have for two years been on a schema announce list (without > seeing much traffic), is > this terminated now ? > > -- The welcome message I got in '95 from "schema-announce": - - - - - > - - - - - - - - > > Welcome to the schema-announce mailing list! > > If you ever want to remove yourself from this mailing list, > send the following command in email to > "schema-announce-request@dsmail.internic.net": > > unsubscribe > > Or you can send mail to "Majordomo@dsmail.internic.net" with the > following command > in the body of your email message: > > unsubscribe schema-announce Frode Hernes > > > Here's the general information for the list you've > subscribed to, in case you don't already have it: > > schema-announce > > This moderated mailing list will be used to announce > updates to the X.500 Internet Schema maintained > by the IETF Schema Working Group. The Schema > update announcements will be announced on the > following lists: > > wpp-camayocs@psi.com > managers@nameflow.dante.net > > If you are not on the above two lists and wish to > receive update announcements please subscribe to > this list by sending the following command to > majordomo@dsmail.internic.net in the body of the > message: > > subscribe schema-announce > > The Internet X.500 Schema itself is available via > the following URLs: > > ftp://ds.internic.net/pub/src/x500/schema/ > gopher://ds.internic.net/pub/src/x500/schema/ > http://ds.internic.net/pub/src/x500/schema/ > > If you ever wish to be removed from the list, send > the following command to majordomo@dsmail.internic.net > in the body of the message: > > unsubscribe schema-announce > > List Owner: > Sri Sataluri > AT&T Bell Laboratories > schema-announce-owner@dsmail.internic.net > - - - - end- - - - > > Frode. > > - - - - - - - - - - - - - > Frode Hernes > MaXware > > 12614 Builders Road > Herndon, VA 20170 > Tel:(703) 435 2587 > Mobile:(703) 919 5166 > Fax:1 (800) 355 2071 > X.400:g=Frode;s=Hernes;o=MaXware;a=Telemax;c=No > Mailto:frode.hernes@maxware.telemax.no > > MaXware A.S: > mailto:maxware@maxware.no > http://www.maxware.no From owner-ietf-schema-reg Tue May 20 14:42:53 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA19113 for ietf-schema-reg-bks; Tue, 20 May 1997 14:42:53 -0700 (PDT) Received: from acl.lanl.gov (root@acl.lanl.gov [128.165.147.1]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id OAA19109 for ; Tue, 20 May 1997 14:42:50 -0700 (PDT) Received: from montana.acl.lanl.gov (montana.acl.lanl.gov [128.165.147.143]) by acl.lanl.gov (8.7.3/8.8.5) with SMTP id PAA00730; Tue, 20 May 1997 15:42:32 -0600 (MDT) Message-Id: <3.0.32.19970520154107.007344d0@cic-mail.lanl.gov> X-Sender: u114212@cic-mail.lanl.gov X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 20 May 1997 15:41:10 -0600 To: Chris Weider , "'Russel Weiser'" , ietf-schema-reg@imc.org From: "Ron Daniel, Jr." Subject: RE: First draft of Schema Registry charter Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-schema-reg@imc.org Precedence: bulk At 12:47 PM 5/20/97 -0700, Chris Weider wrote: >I personally think that schema rationalization and coalescing is outside >the scope of this group. Unfortunate, but true. Listing can be accomplished. Coalescing is one of those problems that is likely to grow and grow and grow. (See the example at the end of the message). Let's do what we can. If people have a place to go to where they can discover schemas and elements then reuse is more likely. Not mandatory, but more likely. >Once we have created the registry, though, we >have provided an important tool to do this sort of work; perhaps this is >an item for a followon? Referrals, though, may well be something to do >before modification or amendment. What does everyone else think? I think the idea of a follow-on is fine, but they are going to have to confront some hard problems. For example, the directory schemas will all have a field that corresponds to "Name". Let's assume we want to map the fields to OIDs for the concepts. We will assign the OID "prefix.1" to the concept of "Name". But some schemas will have the name in direct order and others in sorted order (Ron Daniel vs. Daniel, Ron). Are these the same concept? Some schemas may break out given name, family name, middle name(s), vons, generational qualifer, etc. while others just have a string for all of it. Are these the same concept? And then we get to make distinctions between personal names, organization names, product names, pseudonyms, etc. etc. etc. So now our one OID is likely to turn into something more like: prefix.1 Name prefix.1.0 Unknown name type prefix.1.1 Personal Name prefix.1.1.0 personal name in direct order prefix.1.1.1 personal name in sorted order prefix.1.1.2 structured personal name prefix.1.1.2.1 family name prefix.1.1.2.2 given name prefix.1.1.2.3 middle name(s) prefix.1.1.2.4 generational qualifier prefix.1.1.3.X will no doubt be used for a different form of structured name prefix.1.2 Organization Name (Organization names are not necessarily simple, take a look at some of the ISO working group names for example.) prefix.1.3 Product Name (Product names are not necessarily simple. The military is infamous for structuring names in obscure ways. Also, product names might be given by a code such as the UPC.) prefix.1.4 Alias etc. Lets stick to listing things for now and worry about coalescing later. Ron Daniel Jr. voice:+1 505 665 0597 Advanced Computing Lab fax:+1 505 665 4939 MS B287 email:rdaniel@lanl.gov Los Alamos National Lab http://www.acl.lanl.gov/~rdaniel Los Alamos, NM, USA, 87545 From owner-ietf-schema-reg Tue May 20 21:43:21 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id VAA22643 for ietf-schema-reg-bks; Tue, 20 May 1997 21:43:21 -0700 (PDT) Received: from i.control.att.com ([135.205.52.126]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id VAA22639 for ; Tue, 20 May 1997 21:43:18 -0700 (PDT) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Wed, 21 May 1997 00:43:24 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for ietf-ids@umich.edu; Wed, 21 May 1997 00:43:21 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Wed, 21 May 1997 00:43:21 -0400 (EDT) From: capple@master.control.att.com (Christopher Walon Apple) To: nspiegel@atlasinc.on.ca, ietf-ids@umich.edu, ietf-schema-reg@imc.org, Christopher Walon Apple Subject: Re: WP Schema Inconsistencies (was: inetorgperson) Sender: owner-ietf-schema-reg@imc.org Precedence: bulk >> OK...I'll take another step down this slippery slope....rats or no >> rats... >> >> The following list shows that there are several, different, "standard" >> white >> pages-related "schemas" or aspects of "schemas" for representing >> people in >> directories (or projecting such information from directories) being >> specified >> by different groups (more than one within the IETF): > >Is it not possible to allow schema proliferation and just have a >attribute mapping solution? Yes, provided that semantics do not collide. > >Can schema translation be doen easily? Ditto. > >Is that expensive from a performance perspective? Not terribly, its just a hassle to bother implementing it; so my conclusion is that it will be dropped from lists of more important features for LDAP implementations. > >Obviously if the same attribute name is used for two different meanings >we run into a problem. Its already happened: telephoneNumber can: + be interpretted by end-users to mean "home telephone" or "business telephone", depending on whose client you use (by virtue of assumptions that the client implementor made about the "likely" semantics of this attribute) + be stored in a directory database with administrator-assigned semantics of either "home telephone" or "business telephone", depending on whose attribute-naming-conventions/object-class/schema-concept you use + be thought of as simply a confusing term in the first place (at least in the English language) because there are actually lots of numbers that could be referred to (and are, semantically, in _some_ schemas and object-classes) as types of telephone numbers (pager, mobile/cellular, PDA, FAX, work phone, etc.) > However, there is a lot of room for flexibility >before that happens. > >I agree that a standard set of attributes would be great, but if we >allow implementors to use whatever attribute naming they like >(particularily for ill defined attributes) then set-up a mapping process >once LDAP has officially supported naming schemes wouldn't that solve >the problem of >a) let's get on with it and Agreed...subject to stating that I think multiple names for the same attribute and attribute semantic collisions are evil _and_ that I don't think LDAP is the problem. The problem is that lots of different groups think that _their_ way of naming attributes is best. The truth is that it is unlikely that any _one_ way is best, in absolute terms; but that _one_ way is better than multiple ways; even if its not the best way. Also, I did not mean to imply that the schema registration work should be supplanted by an effort to strive for consistency in naming attributes with the same semantics. I actually think that we'll have to use the results of a schema registry effort as a bandage until "things" cool off a bit w.r.t. the proliferation of schemas. I am suggesting that there is more work that needs to be done to make interoperability between various clients and servers happen more quickly (in time) and more efficiently/less complicated (in operational situations). >b) let's make sure it is interoperable. Its not interoperable across multiple clients unless the semantic properties of information in a directory database are reflected as intended in client UIs. > >Neil > > Chris. From owner-ietf-schema-reg Wed May 21 20:01:18 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id UAA14016 for ietf-schema-reg-bks; Wed, 21 May 1997 20:01:18 -0700 (PDT) Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id UAA14012 for ; Wed, 21 May 1997 20:01:14 -0700 (PDT) Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 21 May 1997 20:02:47 -0700 To: ietf-schema-reg@imc.org From: "Paul E. Hoffman" Subject: RE: First draft of Schema Registry charter Sender: owner-ietf-schema-reg@imc.org Precedence: bulk At 12:47 PM -0700 5/20/97, Chris Weider wrote: >I personally think that schema rationalization and coalescing is outside >the scope of this group. Once we have created the registry, though, we >have provided an important tool to do this sort of work; perhaps this is >an item for a followon? Referrals, though, may well be something to do >before modification or amendment. What does everyone else think? I propose that we list (not register) two types of documents: schemas and something that I'll call "translation documents" for lack of a better term. A translation document is a document that is co-authored by two schema producers that lists what both authors believe are: - equivalent attributes - near-equivalent attributes (format differences for identical content, same format but a slight difference in content) - attributes unique to each document (that is, all others) The spirit of this is the same as the spirit of this group: help prevent someone from starting their own schema if they can reuse an existing one. If I'm using schema X and have a customer demand for a few new attributes, I can possible find another schema that is easy to emit and has the additional attributes by looking at the translation documents that involve X, before I have to read all the other schemas. The not-so-hidden agenda here is that, if a translation document for X and Y is 95% equivalent attributes, the two authors will come out with a single version 2 document that collapses the two schemas, and we can relegate the version 1 documents to "historical". These kinds of documents, completely voluntary, may help cause coalescing without any group pressure to do so. And, if it doesn't, it still helps someone shop among the schemas. Again, the translation documents would just be listed, not registered. --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-schema-reg Sun May 25 12:02:24 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA07495 for ietf-schema-reg-bks; Sun, 25 May 1997 12:02:24 -0700 (PDT) Received: from nix.swip.net (nix.swip.net [192.71.220.2]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA07491 for ; Sun, 25 May 1997 12:02:16 -0700 (PDT) Received: from localhost (paf@localhost) by nix.swip.net (8.8.2/8.8.2) with SMTP id VAA21155; Sun, 25 May 1997 21:03:29 +0200 (MET DST) Date: Sun, 25 May 1997 21:03:28 +0200 (MET DST) From: Patrik Faltstrom To: Christopher Walon Apple cc: Bruce Greenblatt , ietf-schema-reg@imc.org, ietf-asid@umich.edu, ietf-ids@umich.edu, master!jerry@redheat.rs.itd.umich.edu, steve.fisher@worldnet.att.net Subject: Re: WP Schema Inconsistencies (was: inetorgperson) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-schema-reg@imc.org Precedence: bulk On Mon, 19 May 1997, Christopher Walon Apple wrote: > Based on attribute naming inconsistencies like this and also on LDAP > client/server interoperability testing results from research going on in > my lab, several questions come to mind: > > 1) How is interoperability going to materialize if everyone races off in > different directions when it comes to attribute naming? The problem is not the naming, it is the syntax and usage of the attributes. As long as one can do the translation between two schemas, things are all right. You have a problem when one schema for example stores first name and last name in the same attribute value and a different schema stores them in two different attributes. That is the approach we took when defining Whois++ templates for documents. We did check the Dublin Core set of attributes, and then invented names that conformed to the Whois++ attribute name syntax to be identifiers that can be used in the protocol. If the IDS Whitepages schema were finished ealier, we could have checked with that schema before setting down the template used in Whois++ for persons (now afterwords I have seen that there is no problem in doing the mapping -- but we were lucky... :-). What I think _is_ needed are BCPs which have lists like the one that Bruce gave that lists how to translate from one schema to another one. For example from Whois++ templates to vCard profiles, or LDAP whatever. > 2) Has a situation already been created in which it is not possible to define > a standard, core schema that anyone will pay attention to in meaningful > ways? I think it is perfectly alright to do for persons the same thing as the Dublin Core set of attributes do for objects. I.e. define a small, core set of attributes that _always_ is a core. One should have _really_ strong arguments for not defining data like this core set of things, in the given syntax (as Chris Apple is writing). Other attributes can be added later on, but these core attributes should be the core. Period. One good question, which I don't think is answered yet, is if the White pages schema produced in the IDS group is that set of core attributes or not? If we are lucky -- yes, othervise I think we should try to come up with such a set. The important thing here is that it is a _CORE_ set of attributes. No bells and whistles! The vCard spec is for example too extensive from my point of view. > 3) While I realize that there was a schema registration BOF held at the > Memphis IETF, I do not believe a WG charted as I remember hearing about > during this BOF will address the white pages core schema consistency issue. > What are the chances that a BOF in Munich on the subject would be well-attended? > > 4) Do I have a volunteer for a co-conspiritor to get such a BOF going and on the > agenda in Munich? We should try to at least talk about this problem. The mapping of attribute values between different protocols, schemas etc etc becomes more and more needed in the future as I don't belive for one second that we will ever get _one_ white pages directory service in the world. As long as we have two, we have to do mappings... And, even if we end up having one only, the mapping have to be done in the client anyway to be able to present the data in a tasty way to the end user. Patrik From owner-ietf-schema-reg Tue May 27 10:22:10 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA01329 for ietf-schema-reg-bks; Tue, 27 May 1997 10:22:10 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.42]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id KAA01325 for ; Tue, 27 May 1997 10:22:08 -0700 (PDT) Received: by INET-02-IMC with Internet Mail Service (5.0.1458.30) id ; Tue, 27 May 1997 10:23:24 -0700 Message-ID: <88CE23A0B727D0118BB000805FD4752401AA6056@RED-81-MSG.dns.microsoft.com> From: Tony Genovese To: "'Patrik Faltstrom'" Cc: ietf-schema-reg@imc.org, ietf-asid@umich.edu, ietf-ids@umich.edu Subject: RE: WP Schema Inconsistencies (was: inetorgperson) Date: Tue, 27 May 1997 10:24:34 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.30) Sender: owner-ietf-schema-reg@imc.org Precedence: bulk > One good question, which I don't think is answered yet, is if the > White > pages schema produced in the IDS group is that set of core attributes > or > not? If we are lucky -- yes, othervise I think we should try to come > up > with such a set. > Patrik, I know this thread sounds like there is an open issue here but, we have spent, what, almost two years looking at the core set of attributes. That was the purpose of the IWPS doc. If the group honestly think we need to continue looking at the core (listed in the IWPS) set, then I conclude that it is an area that we can never solve. > We should try to at least talk about this problem. The mapping of > attribute values between different protocols, schemas etc etc becomes > more > and more needed in the future as I don't belive for one second that we > will ever get _one_ white pages directory service in the world. As > long as > we have two, we have to do mappings... > > And, even if we end up having one only, the mapping have to be done in > the > client anyway to be able to present the data in a tasty way to the end > user. > The Mapping issue is turely an open. In the doc: This set of attributes describes information types, and are not defined attributes in a particular schema. Any technology deploying a White Page service ( WHOIS ++, LDAP, vCard, etc.) will need to publish as a companion document, their specific schema detailing how the general attributes of the White Pages schema are expressed. Tony... From owner-ietf-schema-reg Thu Jun 5 12:20:00 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA07128 for ietf-schema-reg-bks; Thu, 5 Jun 1997 12:20:00 -0700 (PDT) Received: from Networking.Stanford.EDU (networking.Stanford.EDU [36.53.0.155]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA07124 for ; Thu, 5 Jun 1997 12:19:56 -0700 (PDT) From: Jeff.Hodges@Stanford.edu Received: from Wind.Stanford.EDU (wind.Stanford.EDU [36.53.0.147]) by Networking.Stanford.EDU (8.8.5/8.6.6) with SMTP id MAA25918 for ; Thu, 5 Jun 1997 12:21:53 -0700 Date: Thu, 5 Jun 1997 12:21:53 -0700 (PDT) Reply-To: Jeff.Hodges@Stanford.edu Subject: Re: First draft of Schema Registry charter To: ietf-schema-reg@imc.org In-Reply-To: <3.0.32.19970520085647.00729364@cic-mail.lanl.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-schema-reg@imc.org Precedence: bulk > This plethora of schemas makes interoperation difficult, but is > unavoidable. A registration service that provides a single point > of discovery for white-pages schemas will promote interoperability > by reducing further duplication of effort and by identifying > correspondances between schemata. I suggest that the WG description utilize the word "reuse" -- especially given it has been prominent in the subsequent conversation. How about this build on the WG description.. This plethora of schemas makes interoperation difficult, but is unavoidable. A listing service providing a single point of discovery for white-pages schemas will promote schema reuse, reduce duplication of effort, and thus promote directory service interoperability. Jeff From owner-ietf-schema-reg Mon Jun 23 14:11:17 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA27478 for ietf-schema-reg-bks; Mon, 23 Jun 1997 14:11:17 -0700 (PDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.23]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id OAA27474 for ; Mon, 23 Jun 1997 14:11:14 -0700 (PDT) Received: by mail3.microsoft.com with Internet Mail Service (5.0.1458.49) id ; Mon, 23 Jun 1997 14:10:35 -0700 Message-ID: From: Chris Weider To: "'ietf-schema-reg@imc.org'" Subject: New version of charter for proposed Schema Listing group Date: Mon, 23 Jun 1997 14:07:40 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Hi Gang: Here is the latest version of the schema listing charter. I've incorporated all the comments (and taken some text from Jeff Hodges) with the exception of any comments identifying additional work items for the group. I think that this will be enough to get us started. There are three additional questions, one trivial, two not. The trivial one is 'should we change the mailing list to 'ietf-schema-list'? The important one is: Should we add milestones for listing translation documents, as Paul Hoffman suggested? If these documents can be provided in a machine-usable format, I think they could be very helpful. But I would like to get the basic listing service up first. What do you folks think? I'd like to get this wrapped up by next Monday, so we don't have to revise our milestones again :^) Thanks! Chris Schema Listing (schema) Charter Current Status: Proposed Working Group Chair(s): Chris Weider cweider@microsoft.com Applications Area Director(s): Keith Moore moore+iesg@cs.utk.edu Harald Alvestrand ; Mon, 23 Jun 1997 14:28:23 -0700 (PDT) Received: from montana.acl.lanl.gov. (montana.acl.lanl.gov [128.165.147.143]) by acl.lanl.gov (8.8.5/8.8.5) with SMTP id PAA13716; Mon, 23 Jun 1997 15:30:00 -0600 (MDT) Message-Id: <3.0.32.19970623152813.007404f0@cic-mail.lanl.gov> X-Sender: u114212@cic-mail.lanl.gov X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 23 Jun 1997 15:28:23 -0600 To: Chris Weider , "'ietf-schema-reg@imc.org'" From: "Ron Daniel, Jr." Subject: Re: New version of charter for proposed Schema Listing group Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-schema-reg@imc.org Precedence: bulk At 02:07 PM 6/23/97 -0700, Chris Weider wrote: >There are >three additional questions, one trivial, two not. The trivial one is >'should we change the mailing list to 'ietf-schema-list'? No, let's just stick with ietf-schema-reg. It works just fine, and we already have a bit of an archive. >The important >one is: Should we add milestones for listing translation documents, as >Paul Hoffman suggested? If these documents can be provided in a >machine-usable format, I think they could be very helpful. But I would >like to get the basic listing service up first. What do you folks think? Let's get the basic listing service drafts written. If translation documents are not required for deploying the service, then they are somebody else's problem. If they are, then we will just have some documents generated that were not explicitly listed on the charter. If the requirements document is going to be submitted by July someone has to volunteer to be the editor RSN. >I'd like to get this wrapped up by next Monday, so we don't have to >revise our milestones again :^) Indeed. Let's get after it. Ron Daniel Jr. voice:+1 505 665 0597 Advanced Computing Lab fax:+1 505 665 4939 MS B287 email:rdaniel@lanl.gov Los Alamos National Lab http://www.acl.lanl.gov/~rdaniel Los Alamos, NM, USA, 87545 From owner-ietf-schema-reg Mon Jun 30 15:45:16 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA02981 for ietf-schema-reg-bks; Mon, 30 Jun 1997 15:45:16 -0700 (PDT) Received: from Networking.Stanford.EDU (networking.Stanford.EDU [36.53.0.155]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id PAA02977 for ; Mon, 30 Jun 1997 15:45:12 -0700 (PDT) From: Jeff.Hodges@Stanford.edu Received: from Wind.Stanford.EDU (wind.Stanford.EDU [36.53.0.147]) by Networking.Stanford.EDU (8.8.5/8.6.6) with SMTP id PAA22780; Mon, 30 Jun 1997 15:47:13 -0700 Date: Mon, 30 Jun 1997 15:47:13 -0700 (PDT) Reply-To: Jeff.Hodges@Stanford.edu Subject: Re: New version of charter for proposed Schema Listing group To: Chris Weider cc: "'ietf-schema-reg@imc.org'" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Apologies for the late reply, I was out last week. Charter looks good. One comment would be to add something like.. - Schema are 'listed' rather than 'registered', where.. - 'listed' connotes ... . - 'registered' connotes ... . I second Ron's comments. Jeff From owner-ietf-schema-reg Fri Jul 25 23:24:06 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id XAA20501 for ietf-schema-reg-bks; Fri, 25 Jul 1997 23:24:06 -0700 (PDT) Received: from i.control.att.com ([135.205.52.126]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id XAA20497 for ; Fri, 25 Jul 1997 23:24:02 -0700 (PDT) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Sat, 26 Jul 1997 02:27:12 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for ietf-schema-reg@imc.org; Sat, 26 Jul 1997 02:27:07 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Sat, 26 Jul 1997 02:27:07 -0400 (EDT) From: capple@master.control.att.com (Christopher W Apple) To: internet-drafts@ietf.org Cc: ietf-schema-reg@imc.org Subject: draft-apple-schema-listing-rqmts-00.txt Sender: owner-ietf-schema-reg@imc.org Precedence: bulk INTERNET-DRAFT C. Apple AT&T Laboratories Expires: January 26, 1998 26 July 1997 Directory Schema Listing Requirements Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This memo documents requirements for listing directory services schemas in a centrally operated, administered, and maintained repository. This repository will be available as a resource to directory protocol and service implementors to facilitate schema discovery. 1.0 Introduction The fastest route to interoperable directory services is through standard object classes and attribute types. There is a growing number of places where schema for Internet Directory Services and Internet Operations are being defined, with varying degrees of documentation. This plethora of schemas is unavoidable in the light of the needs of different service communities, but it makes it difficult for directory service builders to find and make use of an existing schema that will serve their needs and increase interoperability with other systems. A listing service providing a single point of discovery for white-pages schema will promote schema Apple [Page 1] INTERNET-DRAFT Directory Schema Listing Requirements 26 July 1997 reuse, reduce duplication of effort, and thus promote directory service interoperability. This document contains requirements for various aspects of listing schemas. 2.0 Listing Service Requirements 2.1 Functional Requirements Schema are 'listed' rather than 'registered'. A list of available schemas MUST be maintained. Schema will be named according to the namespace defined in section 3. The listing service shall also maintain information about the schema, beyond its definition. This information is referred to as meta data and will include information about the following differentiating characteristics: + a globally unique identifier for the schema name + protocol and protocol version for which the schema is valid + name/title of schema + version information for the schema + date of creation or update + indication of listing status + indication of relationship to other schemas + originating organization or individual + name of contact person for schema + e-mail of contact person for schema + telephone of contact person for schema + postal address of contact person for schema 2.2 Operational Requirements The process of listing schema will be centralized for the initial deployment. The database which provides the listing store will be centrally administered. Listing files will be accessible via FTP and HTTP. Listing content and listing meta data will be stored in a file named in accordance with the file name syntax defined in section 5.0. Listing content and listing meta data will be stored in a file Apple [Page 2] INTERNET-DRAFT Directory Schema Listing Requirements 26 July 1997 formatted in accordance with section 5.0. 3.0 Listing Service Namespace The listing service namespace shall be protocol-independent. Names constructed using the listing service namespace shall be permanent, globally unique, and publicly available. 3.2 Listed Schema Name Syntax ::= '-' ::= ['v' ] ::= IANA-assigned directory service protocol identifier ::= a protocol version number string ::= protocol-specific information Consider the following example of a schema name for the vCard schema [VCARD] for use in LDAPv3 [LDAPV3]: ldapv3-vCardObject where: vCardObject is the name of the object class identified by the OID: 1.3.6.1.4.1.2309.1.1.1.1 [VCARD] An alternate, but still globally unique, name for this schema is: ldapv3-1.3.6.1.4.1.2309.1.1.1.1 4.0 Listing Requirements Schema listing content will be composed only of the information actually required to specify the schema. Schema listing meta data will be composed of other information as defined in paragraph 4.2. 4.1 Listing Content 4.1.1 Allowable Listing Content Syntaxes LDAP Data Interchange Format [LDIF] Abstract Syntax Notation One [ASN1] Apple [Page 3] INTERNET-DRAFT Directory Schema Listing Requirements 26 July 1997 BNF [RFC822] Augmented BNF [ABNF] TBR. Working group needs to achieve consensus on the list of allowable syntaxes. 4.1.2 Allowable Listing Content Character Sets As specified in references for allowable listing content syntaxes. Exceptions: TDB. Working group needs to achieve consensus on whether or not profiling of these syntaxes is necessary/appropriate. 4.2 Listing Meta Data 4.2.1 Listing Meta Data Syntax TBD. Working group needs to achieve consensus on which meta data elements are important enough to include (see paragraph 2.1). 4.2.2 Allowable Listing Meta Data Character Sets TBD. Working group needs to achieve consensus on allowable character sets. 5.0 Listing Storage Requirements Listing file names shall be permanent and publicly available. 5.1 Listing File Name Syntax The content and meta data for each listing shall be contained in a file named according to the following syntax: ::= "ietf-schema-directory-" ".txt" ::= ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' 5.2 Listing File Format Specification TBD. Dependent on resolution of TBDs for section 4.0. 6.0 Security Considerations Security requirements are not discussed in this memo. Apple [Page 4] INTERNET-DRAFT Directory Schema Listing Requirements 26 July 1997 7.0 Acknowledgements Leslie Daigle of Bunyip Information Systems and Chris Weider of Microsoft provided valuable comments on the pre-Internet-Draft- version of this document. 8.0 References [ABNF] D. Crocker, P. Overell, "Augmented BNF for Syntax Specifications", INTERNET-DRAFT , July 1997. [ASN1] ITU-T Recommendation X.680, "Abstract Syntax Notation One (ASN.1) - Specification of Basic Notation", 1994. [LDAPV3] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol (Version 3)", INTERNET-DRAFT , July 1997. [LDIF] G. Good, "The LDAP Data Interchange Format (LDIF) _ Technical Specification", INTERNET-DRAFT , July 1997. [RFC822] D. Crocker, "Standard of the Format of ARPA-Internet Text Messages", STD 11, RFC 822, August 1982. [VCARD] F. Dawson, M. O'Brien, "The vCard Schema For Use In LDAPv3", INTERNET-DRAFT , July 1997. 9.0 Author's Address Chris Apple AT&T Laboratories 600 - 700 Mountain Ave., Room 2F-165 Murray Hill, NJ 07974-0636 USA E-Mail: capple@att.com Phone: +1 908 582 2409 FAX: +1 908 582 6113 This INTERNET-DRAFT expires on January 26, 1998. Apple [Page 5] From owner-ietf-schema-reg Sun Jul 27 12:14:21 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA08241 for ietf-schema-reg-bks; Sun, 27 Jul 1997 12:14:21 -0700 (PDT) Received: from i.control.att.com ([135.205.52.126]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA08235 for ; Sun, 27 Jul 1997 12:14:18 -0700 (PDT) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Sun, 27 Jul 1997 15:17:34 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for ietf-schema-reg@imc.org; Sun, 27 Jul 1997 15:17:33 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Sun, 27 Jul 1997 15:17:33 -0400 (EDT) From: capple@master.control.att.com (Christopher W Apple) To: capple@master.control.att.com (Christopher W Apple) Cc: ietf-schema-reg@imc.org Subject: Re: draft-apple-schema-listing-rqmts-00.txt Sender: owner-ietf-schema-reg@imc.org Precedence: bulk FYI...the reason this draft doesn't show up as draft-ietf-schema- is that the Schema WG charter has not been officially approved by the IESG. Once this happens, we'll rename the draft. Chris. From owner-ietf-schema-reg Mon Jul 28 11:38:02 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA25882 for ietf-schema-reg-bks; Mon, 28 Jul 1997 11:38:02 -0700 (PDT) Received: from ietf.org (ietf.org [132.151.1.19]) by mail.proper.com (8.8.5/8.7.3) with SMTP id LAA25875 for ; Mon, 28 Jul 1997 11:37:57 -0700 (PDT) Received: from ietf.ietf.org by ietf.org id aa14868; 28 Jul 97 14:20 EDT To: Christopher W Apple cc: Cynthia Clark , ietf-schema-reg@imc.org Subject: Re: draft-apple-schema-listing-rqmts-00.txt In-reply-to: Your message of "Sat, 26 Jul 1997 02:27:07 EDT." Date: Mon, 28 Jul 1997 14:20:28 -0400 From: Cynthia Clark Message-ID: <9707281420.aa14868@ietf.org> Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Chris, Just for your information, I am currently working on your Internet-Draft . I'll probably send an announcement to the entire IETF regarding your I-D sometime tomorrow or the next day. Please note the minor filename change. Kind Regards, Cynthia ------------------------------------------------------ Cynthia Clark, IETF Internet-Drafts Administrator E-mail Address preference: ------------------------------------------------------- From owner-ietf-schema-reg Thu Aug 7 09:31:20 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA11250 for ietf-schema-reg-bks; Thu, 7 Aug 1997 09:31:20 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.31]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id JAA11246 for ; Thu, 7 Aug 1997 09:31:17 -0700 (PDT) Received: by mail5.microsoft.com with Internet Mail Service (5.0.1458.49) id ; Thu, 7 Aug 1997 09:30:17 -0700 Message-ID: From: Chris Weider To: "'ietf-schema-reg@imc.org'" Subject: Schedule for Schema Listing Group in Munich Date: Thu, 7 Aug 1997 09:28:07 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Hi gang: Here's the tentative schedule for the Schema Listing Group BOF in Munich. If you have any additions/suggestions, please let me know. I can't stress enough the fact that you need to come prepared for this meeting. See you there! Chris Time: Wednesday 13/8/97 15:30-17:30 Place: Lindau Room 15:30-15:45 Charter Discussion There are still two open requests for charter additions: Listing of schema mappings, and Guides for schema creators. Keep in mind that we are under orders to deploy a simple schema listing service by 1 Jan 98. With that in mind, I suggest that schema mapping listing may be in scope but if added to the schedule should be set for after 1 Jan 98 (unless we can finess it by creating a schema mapping schema). Also, I suggest that guides for schema creators be ruled out of scope. Please comment on this list or at the meeting 15:45 - 16:30 Discussion of the Directory Schema Listing Requirements document by Chris Apple (draft-apple-schema-rqmts-list-00.txt) There has been no discussion of this on the list. As our timeline is agressive, if you wish to comment on this document at the meeting, you MUST read the document (preferably before you get into the room :^) ). This period will be used for discussion of the document itself, not of the open issues identified in the document. 16:30 - 17:30 Open Issue discussion We need to come to closure on the following issues: The list of allowable listing content syntaxes The list of allowable listing content character set(s) The list of required metadata elements for a schema listing The list of protocols used to access the repository The submission procedure Should listed schema all be published as RFCs as well? From owner-ietf-schema-reg Wed Aug 20 12:13:09 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA06016 for ietf-schema-reg-bks; Wed, 20 Aug 1997 12:13:09 -0700 (PDT) Received: from i.control.att.com ([135.205.52.126]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA06010 for ; Wed, 20 Aug 1997 12:13:04 -0700 (PDT) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Wed, 20 Aug 1997 15:17:48 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for ietf-schema-reg@imc.org; Wed, 20 Aug 1997 15:17:47 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Wed, 20 Aug 1997 15:17:47 -0400 (EDT) From: capple@master.control.att.com (Christopher W Apple) To: ietf-schema-reg@imc.org Cc: master.control.att.com!capple Subject: meta data for schema listings Sender: owner-ietf-schema-reg@imc.org Precedence: bulk As promised in Munich, here's the schema listing meta data element descriptions as currently specified in the requirements document: + a globally unique identifier for the schema name BOF concensus was to use OIDs + protocol and protocol version for which the schema is valid BOF concensus was unclear on this item: - might be multi-valued (different protocols and versions) - might be removed because its redundant with other elements + name/title of schema words for the schema title; exs: inetOrgPerson or vCard + version information for the schema listing a version number for the schema listing itself; BOF concensus was to mandate incrementing the version number when any change occurs to a listed schema + date of creation or update a date/time stamp + indication of listing status obsoletes vs. obsoleted by vs. current (similar to RFCs) + indication of relationship to other schemas words describing how schema relates to other listed schemas ex: this schema inherits all attributes from schema_X and adds attribute_Y + originating organization or individual + name of contact person for schema + e-mail of contact person for schema + telephone of contact person for schema + postal address of contact person for schema There were requests to add: + a URL for more information about the schema + intended use of the schema + indication of standard vs. experimental vs. informational vs. not recommended (the difference between this element and the "indication of listing status" is that the later is an indication of whether or not this listing is considered active or deprecated; similar to RFC obsoletes vs. obsoleted-by status) + URLs as pointers to listing content expressed in available syntaxes Anyone see a reason to add other elements or remove any? It would be best to limit discussions to with which meta data elements to include/exclude _now_ and handle debates over appropriate syntax for the elements after the next rev of the listing requirements draft is published. Chris Apple Internet Directory Group AT&T Laboratories capple@master.control.att.com +1 908 582 2409 From owner-ietf-schema-reg Wed Aug 20 12:24:21 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA06207 for ietf-schema-reg-bks; Wed, 20 Aug 1997 12:24:21 -0700 (PDT) Received: from i.control.att.com ([135.205.52.126]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA06203 for ; Wed, 20 Aug 1997 12:24:17 -0700 (PDT) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Wed, 20 Aug 1997 15:29:01 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for ietf-schema-reg@imc.org; Wed, 20 Aug 1997 15:29:00 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Wed, 20 Aug 1997 15:29:00 -0400 (EDT) From: capple@master.control.att.com (Christopher W Apple) To: ietf-schema-reg@imc.org Subject: usage scenarios Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Some folks at the Munich BOF gave examples of usage scenarios, if you want them included in the requirements document, please send me a brief (no more than a few sentences) description of the scenario. I may not be able to include all of them, but will try to merge a few into the document. Thanks. Chris Apple Internet Directory Group AT&T Laboratories capple@master.control.att.com +1 908 582 2409 From owner-ietf-schema-reg Mon Aug 25 15:44:57 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA13719 for ietf-schema-reg-bks; Mon, 25 Aug 1997 15:44:57 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.42]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA13715 for ; Mon, 25 Aug 1997 15:44:53 -0700 (PDT) Received: by INET-02-IMC with Internet Mail Service (5.0.1459.27) id ; Mon, 25 Aug 1997 15:50:22 -0700 Message-ID: From: Chris Weider To: "'ietf-schema-reg@imc.org'" Subject: First Draft: Schema Listing BOF minutes from Munich Date: Mon, 25 Aug 1997 15:50:20 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1459.27) Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Please review these and let me know if there are any changes or omissions. I'd like to submit these Friday 8/29. Thanks! Chris Minutes of the 8/13/97 meeting of the Schema Listing BOF Special thanks to John Strassner for taking the minutes! The agenda was as follows 1: Bash the charter 2: Current holes in the Schema Listing Requirements document (Chris Apple) 3: Discussion of open issues Discussion: 1: There were no problems with the charter 2: Holes in the document that need to be patched - doesn't match Scott Bradner's requirement terminology - Security considerations - The philosophy of unlimited read and tightly controlled write needs to be spelled out in the document 3: Other issues resolved - Syntax specs should be BNF - Localized versions of the schema should be made available and should be pointed to by the main schema. This includes language tags. - OIDs will be used to uniquely identify schema - A question about two competing requests (i.e. same names, but different content) came up. This should be handled in a separate process document. However, since the service will be assigning OIDs to the schema, each schema will have a unique name. - Does a change in the machine-readable portion of a schema require a rev of the entire schema? YES. - The schema listing file name for a given schema will be the last component of the OID assigned to that schema. We should not include any other human semantics in the file name - Again, this is a listing service, not a vetting service. Schema standardization will happen after schema are listed - We will be adding a usage scenario section to the document. - We will be selecting one syntax as a required syntax for the service and will add two more if we can get the parsers. The three agreed on by the group are LDIF, ASN.1, and XML. We'll do a small list poll for the required one. - We will be requiring FTP and HTTP access to the repository. 4: Open issues for the list - Should any document that specifies schema be allowed to be registered? This is an issue for the list - Who owns the database? Who runs it? This will be discussed as we get closer to the process document. - Do we need to track and forbid display name collision of schema and attributes? I.e. two people trying to register the 'Person' schema even though they have different OIDs? - Should the listing service be searchable? We need to decide whether it is, and if so, what engine would be used. There are also the matters of UI and complexity of the interface. - Can this service be tied into the URN infrastructure? - For Jan 1, 1998, should we allow machine submission of schema. We are leaning towards NO but will take to the list. - Which (if any) of the submitted schema will be made into RFCs? - Should schema be signed so that people can verify that their schema are indeed the ones that they sent? Which signature algorithm should be used? - Do we store metaschema (i.e. schema not tied to any protocol, such as the Dublin Core). If so, how? How do we tie them to their expressions in various protocols? - What character sets should we support? How do we support them? - What are the required metadata elements for a schema listing? - Should we push for LDAP and SMTP access to the repository for Jan 1? - How do we control versioning? - Can we provide an automated submission process for Jan 1? - Is the store moderated to avoid BadGuy(tm) or StupidGuy(tm) attacks? One general rule is that we could agree that unsigned schema are automatically rejected 5: Action items a: change the acronym of the working group so that it doesn't contain the name schema... b: Put together the engineering team. Volunteers were: Michael Mealling - NSI Sam Sun - CNRI Mark Wahl - Critical Angle Sanjay Jain - Oracle John Strassner - Cisco Chris Weider - Microsoft c: rev the document and start the list discussions. We will cut off list discussion no later than 15 September to insure that the engineering team has everything it needs. From owner-ietf-schema-reg Wed Aug 27 22:26:00 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id WAA04627 for ietf-schema-reg-bks; Wed, 27 Aug 1997 22:26:00 -0700 (PDT) Received: from i.control.att.com ([135.205.52.126]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id WAA04623 for ; Wed, 27 Aug 1997 22:25:55 -0700 (PDT) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Thu, 28 Aug 1997 01:31:05 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for ietf-schema-reg@imc.org; Thu, 28 Aug 1997 01:31:04 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Thu, 28 Aug 1997 01:31:04 -0400 (EDT) From: capple@master.control.att.com (Christopher W Apple) To: internet-drafts@ietf.org Cc: ietf-schema-reg@imc.org Subject: draft-apple-schema-rqmts-list-01.txt Sender: owner-ietf-schema-reg@imc.org Precedence: bulk INTERNET-DRAFT C. Apple AT&T Laboratories Expires: February 27, 1998 27 August 1997 Directory Schema Listing Requirements Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This memo documents requirements for listing directory services schemas in a centrally operated, administered, and maintained repository. This repository will be available as a resource to directory protocol and service implementors to facilitate schema discovery. 1.0 Introduction The fastest route to interoperable directory services is through standard object classes and attribute types. There is a growing number of places where schema for Internet Directory Services and Internet Operations are being defined, with varying degrees of documentation. This plethora of schemas is unavoidable in the light of the needs of different service communities, but it makes it difficult for directory service builders to find and make use of an existing schema that will serve their needs and increase interoperability with other systems. A listing service providing a single point of discovery for directory service schema will promote schema reuse, reduce duplication of effort, Apple [Page 1] INTERNET-DRAFT Directory Schema Listing Requirements 27 August 1997 and thus promote directory service interoperability. The intent is to offer a schema listing service with public read access and restricted, moderated write access. Initially, such a listing service will be centrally operated, administered, and maintained. The schema listing repository database may also be mirrored to ensure some level of redundancy for read access in the event of service interruption. Eventually, the operations, administration, and maintenance of such a listing service may evolve to use a more distributed deployment scenario. The schema listing service is also intended to be largely automated, with minimal human involvement. Human involvement is likely to be limited to the following types of activities: + handling repository access problems + trouble resolution for computing and communications facilities + dealing with reasonable requests that fall outside of the scope of normal schema listing repository operations 1.1 Scope This document contains requirements for various aspects of listing schemas. The definition of schema listing procedures is out of scope. 1.2 Terms and Definitions Information Object - an descriptive abstraction of some real-world object Schema - a collection of definitions for related information objects Listing Meta Data - characteristics that differentiate one schema from another that are used to catalog schema Listing Content - a formal specification, using a single type of syntax, of a schema Schema Listing - the combination of listing meta data and all available syntax types of listing content for a particular schema Repository - a database in which schema listings are stored Operator - an organization that administers and maintains a repository Primary Repository - the repository that masters the schema listings Apple [Page 2] INTERNET-DRAFT Directory Schema Listing Requirements 27 August 1997 database Shadow Repository - a repository that mirrors the primary repository 1.3 Usage Scenarios 1.3.1 Location and Retrieval of the vCard Schema for LDAPv3 A user of the schema listing service wants to locate a copy of the vCard schema for LDAPv3 so that they can use it in a prototyping project. First, they point their web browser at a schema listing repository web site and download the list of available schema. Next, they use the search command on their browser to locate occurences of the string "vCard". The browser automatically scrolls down to the appropriate place in the list of available schema and the user clicks on a link to view the listing meta data to verify that this is indeed the vCard schema for use with version 3 of the LDAP protocol. Included in the web-based representation of the listing meta data are ftp URLs pointing to available syntaxes for this schema. The user clicks on the link for the syntax that they can use. 1.3.2 Submission of a New Schema Listing via SMTP A schema writer wishes to list a schema they have created and prepares the listing meta data and listing content according to appropriate syntax specifications. However, the schema writer does not currently have an OID at which to root this schema. The schema writer must first apply for and obtain an OID through channels other than the schema listing service. Once this OID is available for use, the schema writer incorporates it into the listing meta data and submits a signed SMTP message to the listing repository containing the listing meta data and all available syntaxes of the listing content in multipart-mixed MIME format. The listing repository operator validates the request, and if properly formed, assigns a unique serial number to the listing and publishes it according to the listing procedures. An announcement of the newly published schema listing is sent to a mailing list reserved for this purpose. 2.0 Listing Service Requirements 2.1 Functional Requirements Schema are 'listed' rather than 'registered'. Listed schema MAY be published as an RFC. A list of available schemas MUST be maintained. Apple [Page 3] INTERNET-DRAFT Directory Schema Listing Requirements 27 August 1997 Schema MUST be named according to the namespace defined in section 3. The listing service SHALL also maintain information about the schema, beyond its definition. This information is referred to as meta data and MUST include the following differentiating characteristics: + a globally unique identifier for the schema name + name/title of schema + version information for the schema + date of creation or update + indication of listing status + indication of relationship to other schemas + originating organization or individual + name of contact person for schema + e-mail of contact person for schema + telephone of contact person for schema + postal address of contact person for schema + character set tag for the listing meta data + language tag for the listing meta data + URL for more information + URL for each available syntax + intended use of the schema Listing meta data and listing content MUST be parsable. 2.2 Operational Requirements The process of listing schema MUST be centralized for the initial deployment. The database which provides the listing store MUST be centrally administered. The database which provides the listing store MAY be mirrored. Listing content and listing meta data MUST be stored in separate files. These files MUST be named in accordance with the file name syntax defined in section 5.0. All schema submitted for listing MUST be signed using PGP with the TBD signature algorithm. The schema listing repository MUST be moderated by verifying conformance with the request signature requirement specified in section 6. All schema listing requests that are not signed or signed improperly MUST be discarded. Apple [Page 4] INTERNET-DRAFT Directory Schema Listing Requirements 27 August 1997 All listing meta data elements included in the BNF [RFC822] grammar rule (see paragraph 4.2) MUST be included by the requester as a part of a listing request submission. All remaining listing meta data elements MUST be created by the primary listing repository operator. A mailing list MUST be created for announcing new and updated schema listings. A mailbox MUST be created for the purpose of receiving service trouble requests from users. Listing repository operators (of primary or shadow sites) MUST NOT claim ownership of listing meta data or listing content submitted for inclusion in the service. Exceptions to this requirement MAY be claimed, IF a listing repository operator (primary or shadow) submits one or more requests for listing schema that originated within their own organizations. These exceptions MUST be limited to claims of ownership on particular schema listings originating from the listing repository operator in question and MUST NOT be extended to include other schema listings. 2.3 Repository Access Functionality The following schema listing repository access protocols MUST be supported: FTP, HTTP, and SMTP. The following access functions are REQUIRED initially: a) obtain schema listing content b) obtain schema listing meta data c) browse schema listing meta data d) browse schema listing content e) obtain a list of available schema f) browse a list of available schema g) search a list of available schema h) add a schema listing i) update a schema listing The following access functions MAY be supported: a) search schema listing content b) search schema listing meta data 3.0 Listing Service Namespace The listing service namespace MUST be protocol-independent. Names constructed using the listing service namespace MUST be permanent, Apple [Page 5] INTERNET-DRAFT Directory Schema Listing Requirements 27 August 1997 globally unique, and publicly available. The listing name MUST be the OID at which the schema is rooted. Consider the following example of a schema name for the vCard schema [VCARD]: 1.3.6.1.4.1.2309.1.1.1.1 4.0 Listing Requirements Listing content MUST be limited to the information actually required to specify the schema. Listing meta data SHALL be composed of other information as defined in paragraph 4.2. 4.1 Listing Content 4.1.1 Allowable Listing Content Syntaxes The following listing content syntaxes MUST be supported initially: + LDAP Data Interchange Format [LDIF] + Abstract Syntax Notation One [ASN1] as profiled for use in X.500- 1993 [X.501] + XML [XML] The following listing content syntaxes MAY be supported eventually: + BNF [RFC822] + Augmented BNF [ABNF] 4.1.2 Allowable Listing Content Character Sets As specified in references for allowable listing content syntaxes. Exceptions: TDB. Working group needs to achieve consensus on whether or not profiling of these syntaxes is necessary/appropriate. 4.2 Listing Meta Data 4.2.1 Listing Meta Data Syntax Listing meta data MUST be formatted according to the following BNF Apple [Page 6] INTERNET-DRAFT Directory Schema Listing Requirements 27 August 1997 [RFC822] grammar: meta-data = provided syntax-URL created provided = name title version intended-use content-syntax related-to status origin contact-name contact-email contact-telephone contact-address md-charset md-lang-tag more-info name = "schemaName:" SPACE oid CRLF oid = oid-component *("." oid-component) oid-component = 1*DIGIT title = "schemaTitle:" SPACE multi-lingual-string CRLF multi-lingual-string = version = "schemaVersion:" SPACE multi-lingual-string CRLF intended-use = "schemaIntendedUse:" SPACE multi-lingual-string CRLF content-syntax = "availableSyntax:" SPACE allowed-syntax CRLF [content-syntax] allowed-syntax = "ldif" / "asn1" / "xml" related-to = "listingRelatedTo:" SPACE file-name CRLF [related-to] file-name = status = "listingStatus:" SPACE allowed-status CRLF allowed-status = deprecation-info / "current" deprecation-info = ("obsoletes" / "obsoleted-by") SPACE file-name origin = "schemaOrigin:" SPACE mult-lingual-string CRLF contact-name = "contactName:" SPACE multi-lingual-string CRLF contact-email = "contactEmail:" SPACE addr-spec CRLF addr-spec = local-part "@" domain-part domain-part = sub-domain *("." sub-domain) sub-domain = 1* Apple [Page 7] INTERNET-DRAFT Directory Schema Listing Requirements 27 August 1997 contact-phone = 1* ; MUST use full CRLF ; international form ; e.g., +1 908 582 2409 contact-address = "contactPostalAddress:" SPACE postal-address postal-address = multi-lingual-string *(multi-lingual-string "$") syntax-URL = CRLF [syntax-URL] created = "Created:" SPACE date "-" time "-" CRLF date = 4DIGIT "-" 2DIGIT "-" 2DIGIT ; year-month-day ; e.g., 1997-08-27 time = 2DIGIT "-" 2DIGIT "-" 2DIGIT ; hh-mm-ss ; e.g., 00-00-00 thru 23-59-59 ; MUST be based on GMT md-charset = md-lang-tag = more-info = CRLF specials = "(" / ")" / "<" / ">" / "@" ; MUST be in quoted- / "," / ";" / ":" / "\" / <"> ; string, to use / "." / "[" / "]" ; within a word CHAR = CTL = CRLF = CR LF CR = LF = SPACE = DIGIT = <"> = 4.2.2 Allowable Listing Meta Data Character Sets Apple [Page 8] INTERNET-DRAFT Directory Schema Listing Requirements 27 August 1997 TBD. Working group needs to achieve consensus on allowable character sets. 5.0 Listing Storage Requirements Listing file names MUST be permanent and publicly available. All file names for listing meta data and listing content MUST comply with the following BNF [RFC822] grammar: file-name = "schema-" sequence "-" type ".txt" type = "metadata" / "ldif" / "asn1" / "xml" sequence = nonzero-digit 0* ; initialized to one (1) for first ; listed schema ; increments by one (1) for each ; successive schema listed nonzero-digit = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" DIGIT = 6.0 Security Considerations Editorial Comment: I am leaning towards _only_ keeping the content in paragraph 6.3 in this requirements document. I'd like for the working group to pay close attention to the scope of this document (requirements for the service) and the other document which is due out soon as well (schema listing procedures). It seems more appropriate to me to document more detailed attack/threat scenarios in the procedures document rather than in the requirements document. The rationale for this is that we do not know exactly what the procedures will be like and thus how can we really begin to analyze how they might be compromised? 6.1 Compromisable Assets One or more of the following assets could be compromised if the service is attacked: + Listing meta data + Listing content + Repository Hardware & Software + Networking Facilities Connecting Repository to the Internet + Repository Mirror Sites Apple [Page 9] INTERNET-DRAFT Directory Schema Listing Requirements 27 August 1997 6.2 Attack Scenarios Allowable methods for submitting requests to list schema in the repository are: a) sending an e-mail message to a mail box b) submitting requests using web-based forms Based on these request submission methods, there are a number of known repository attack scenarios that must be considered during the implementation of schema listing procedures and the software and operational processes required to support them. 6.2.1 Denial-of-Service Attack Scenarios Scenario A: someone could send in a large number of improperly formed requests Scenario B: someone could send in a large number of properly formed, but frivolous, useless, or trivial requests 6.2.2 Confuse-the-User Attack Scenarios Scenario A: someone could send in a large number of valid, but frivolous, useless, or trivial requests and some or all of these requests actually become listings in the repository Scenario B: someone could maliciously submit one or more slightly modified versions of existing schema listings which are popular or widely used 6.3 Security Requirements on Schema Listing Procedures The schema listing procedures MUST: a) include mechanisms to verify that all properly formed submissions are submitted by the person claiming to own the e-mail address listed in the request b) include mechanisms to verify a submitter's authority to update an existing schema listing c) include mechanisms to validate the integrity of all properly formed submissions d) include mechanisms to ensure the non-repudiation of all validly formed submissions Apple [Page 10] INTERNET-DRAFT Directory Schema Listing Requirements 27 August 1997 e) only accept changes to the identity of the contact person for a schema or to the information used to verify the identity of same from the current contact person f) cover the situation in which the contact person for a schema is no longer available or is unable to submit updates to the schema listing which they master 7.0 Acknowledgements Leslie Daigle of Bunyip Information Systems and Chris Weider of Microsoft provided valuable comments on the pre-Internet-Draft-version of this document. The engineering team for listing service requirements: Sanjay Jain - Oracle Michael Mealling - NSI John Strassner - Cisco Sam Sun - CNRI Mark Wahl - Critical Angle Chris Weider - Microsoft 8.0 References [ABNF] D. Crocker, P. Overell, "Augmented BNF for Syntax Specifications", INTERNET-DRAFT , July 1997. [ASN1] ITU-T Recommendation X.680, "Abstract Syntax Notation One (ASN.1) - Specification of Basic Notation", 1994. [CHARSET] Internet Assigned Numbers Authority, "CHARACTER SETS", . [LDAPV3] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol (Version 3)", INTERNET-DRAFT , July 1997. [LDIF] G. Good, "The LDAP Data Interchange Format (LDIF) _ Technical Specification", INTERNET-DRAFT , July 1997. [MLSF] C. Newman, "Multi-Lingual String Format (MLSF)", INTERNET-DRAFT , June 1997. [RFC822] D. Crocker, "Standard of the Format of ARPA-Internet Text Messages", STD 11, RFC 822, August 1982. Apple [Page 11] INTERNET-DRAFT Directory Schema Listing Requirements 27 August 1997 [RFC1738] T. Berners-Lee, L. Masinter, M. McCahill, "Uniform Resource Locators", RFC 1738, December 1994. [RFC1766] H. Alvestrand, "Tags for the Identification of Languages", RFC 1766, March 1995. [VCARD] F. Dawson, M. O'Brien, "The vCard Schema For Use In LDAPv3", INTERNET-DRAFT , July 1997. [X.501] The Directory: Models. ITU-T Recommendation X.501, 1993. 9.0 Author's Address Chris Apple AT&T Laboratories 600 - 700 Mountain Ave., Room 2F-165 Murray Hill, NJ 07974-0636 USA E-Mail: capple@att.com Phone: +1 908 582 2409 FAX: +1 908 582 3296 This INTERNET-DRAFT expires on February 27, 1998. Apple [Page 12] From owner-ietf-schema-reg Mon Sep 8 15:41:00 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA05111 for ietf-schema-reg-bks; Mon, 8 Sep 1997 15:41:00 -0700 (PDT) Received: from inet16.us.oracle.com (inet16.us.oracle.com [192.86.155.100]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA05101 for ; Mon, 8 Sep 1997 15:40:54 -0700 (PDT) Received: from mailsun2.us.oracle.com (mailsun2.us.oracle.com [144.25.88.74]) by inet16.us.oracle.com (8.8.5/8.8.5) with SMTP id PAA01837 for ; Mon, 8 Sep 1997 15:42:05 -0700 (PDT) Received: by mailsun2.us.oracle.com (SMI-8.6/37.8) id PAA00679; Mon, 8 Sep 1997 15:49:56 -0700 Message-Id: <199709082249.PAA00679@mailsun2.us.oracle.com> Date: 08 Sep 97 15:34:56 -0700 From: "Sanjay Jain" To: ietf-schema-reg@imc.org Subject: comments on schema listing requirement doc MIME-Version: 1.0 X-Mailer: Oracle InterOffice (version 4.0.4.0.0) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Chris Overall the schema listing requirement doc looks great. Here are my short comments: 1. Introduction section: Will the schema listing service be repository of only LDAP directory related schemas or any directory/non-directory related schemas ? 2. I guess one can submit a listing content in any or all of the valid syntaxes. Should the listing service generate the listing contents in the missing syntaxes so that a listing content is maintained in all the supported syntaxes ? 3. In section 2.2: I am not sure if we need to put the requirement of signing schema submissions using PGP for the first step of setting up the schema listing service. I don't know if it requires lot of administrative overhead. 4. In section 2.3: I think the search schema listing content functionality is very important and should be included in the REQUIRED functionality list. E.g. before defining a new LDAP attribute, I would normally like to check if somebody has already defined an attribute with the same name. sanjay From owner-ietf-schema-reg Mon Sep 8 16:08:03 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA05392 for ietf-schema-reg-bks; Mon, 8 Sep 1997 16:08:03 -0700 (PDT) Received: from i.control.att.com ([135.205.52.126]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA05387 for ; Mon, 8 Sep 1997 16:07:59 -0700 (PDT) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Mon, 8 Sep 1997 19:08:40 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for SKJAIN@us.oracle.com; Mon, 8 Sep 1997 19:08:40 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Mon, 8 Sep 1997 19:08:40 -0400 (EDT) From: capple@master.control.att.com (Christopher W Apple) To: "Sanjay Jain" , ietf-schema-reg@imc.org Subject: Re: comments on schema listing requirement doc Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Thanks for the comments. I'd like to hear from others on the list as well to see if everyone thinks the concensus of requested mods to the document was captured. While the document has not been officially published yet, I'd like to go ahead with discussion since we are on an aggressive timeline. If you've already deleted the posting in which the document was sent out, take a look at the mailing list archive: Chris Apple Internet Directory Group AT&T Laboratories capple@master.control.att.com +1 908 582 2409 From owner-ietf-schema-reg Mon Sep 8 17:40:12 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA06422 for ietf-schema-reg-bks; Mon, 8 Sep 1997 17:40:12 -0700 (PDT) Received: from folder.critical-angle.com (cai-gw.eden.net [206.81.238.241] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with SMTP id RAA06418 for ; Mon, 8 Sep 1997 17:40:06 -0700 (PDT) Received: (qmail 19733 invoked from network); 9 Sep 1997 00:35:02 -0000 Received: from folder.critical-angle.com (206.81.238.241) by folder.critical-angle.com with SMTP; 9 Sep 1997 00:35:02 -0000 From: Mark Wahl To: capple@master.control.att.com (Christopher W Apple) cc: ietf-schema-reg@imc.org Subject: Re: comments on schema listing requirement doc In-reply-to: Your message of "Mon, 08 Sep 1997 19:08:40 EDT." Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=foo; charset=us-ascii Date: Mon, 08 Sep 1997 19:35:01 -0500 Message-ID: <19731.873765301@folder.critical-angle.com> Sender: owner-ietf-schema-reg@imc.org Precedence: bulk --foo Content-Type: text/plain > I'd like to hear from others on the list as well to see if everyone thinks > the concensus of requested mods to the document was captured. While the > document has not been officially published yet, I'd like to go ahead with > discussion since we are on an aggressive timeline. Hello, While reviewing the schema requirements draft I started to get the feeling that LDIF was not quite the right data representation format for the schema listing service. I was concerned that there may be expectations associated with LDIF that may not be appropriate in this context. LDIF is based on the LDAP information model for the transfer of entries. The objects exchanged by components in schema listing services may not however necessarily correspond 1:1 to entries. (A subschema entry may contain multiple schema definitions.) I would like to suggest as an alternative, defining a profile of the MIME directory content-type for the transfer of schema information. This profile would contain the same elements in the same format as an LDAP subschema entry. The main parsing difference from LDIF would be the Content Transfer Encoding, however C-T-Es are widely implemented. I think it would be clearer to describe how an object represented as a MIME type is exchanged between the components. One can simply send it through mail, combine it with other contents, retrieve it via HTTP etc. Attached below is a skeleton for a document which would define the profile of MIME directory for use by the schema service. Thanks in advance for your consideration, Mark Wahl, Enterprise Directory Integration Critical Angle Inc. --foo Content-Type: text/plain Network Working Group M. Wahl Request for Comments: DRAFT Critical Angle Inc. A MIME Directory Profile for LDAP Schema 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working docu- ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 2. Abstract This document defines a MIME directory profile [1] for holding an LDAP [2] schema. *** to be continued 3. Overview A schema for use with LDAPv3 consists of any number of object class, attribute type, matching rule and syntax definitions. The schema may have a numeric OID assigned to it by a schema listing service. A schema may import definitions from another schema. Schema imports are not, however, transient. For example, a schema may contain a definition for a "modem" object class, which is to be defined as a subclass of the X.521 "device" object class. In this case, the schema would import the definitions of X.521. *** to be continued 4. The "schema-ldap-0" MIME Directory Profile Registration This profile is identified by the following registration template information. To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME profile "schema-ldap-0" Profile name: schema-ldap-0 Profile purpose: To represent a schema defined for use with LDAPv3 servers. Profile types: SOURCE, ldapSchemas, schemaDesc, attributeTypes, matchingRules, objectClasses, matchingRuleUse, ldapSyntaxes Profile special notes: The charset parameter MUST be present on the MIME content, and the value of this parameter MUST be "utf-8". Neither the "BEGIN" and "END" types nor type grouping are used in contents of this profile. All of the types in this profile are multi-valued (except for ldapSchemas), and each value is present on its own contentline. Values may be present in any order, and need not be arranged by type. The "SOURCE" type is optional, and if values are present they SHOULD be URIs of the "ldap" or "http" forms. If the URI is of the "ldap" form, the object indicated by the URI is a subschema entry. If the URL is of the "http" form, the object is a human-readable description of the schema, such as an HTML document. In this version of the profile, exactly one value of the ldapSchemas type MUST be present. (Later versions of the profile may permit multiple ldapSchemas values to be present in a content.) Implementors should note that there will likely be values of the types in most contents which will be longer than 76 characters. In addition, there may be non-ASCII characters and embedded CRLFs inside of values, which could require either quoting of the value or use of a content transfer encoding. If a contentline in a particular content contains a "context" parameter and the value of that parameter is not "ldap", then that contentline SHOULD be ignored. Intended usage: COMMON 5. MIME Directory Type Registrations This document defines all the types, with the exception of "SOURCE" used in the schema-ldap-0 profile. The "SOURCE" type is defined in [1]. 5.1. ldapSchemas To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type ldapSchemas Type name: ldapSchemas Type purpose: To represent the LDAPv3 attribute "ldapSchemas", defined in section A.1. Type encoding: 8bit Type valuetype: text, encoded according to the BNF of section A.4. Type special notes: Each value of this type specifies one LDAP schema definition. A definition of each object class, attribute, matching rule, matching rule use and syntax referenced in a value of ldapSchemas MUST either be defined in one of the schemas referenced in the "IMPORTS" field or present in this content. Intended usage: COMMON 5.2. attributeTypes To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type attributeTypes Type name: attributeTypes Type purpose: To represent the LDAPv3 attribute "attributeTypes", defined in section 5.1.6 of [3]. Type encoding: 8bit Type valuetype: text, encoded according to the BNF of "AttributeTypeDescription" given in section 4.2 of [3]. Type special notes: Each value of the type specifies one LDAPv3 attribute type definition. The syntaxes and matching rules referenced in a value of attributeTypes MUST either be present in this content, or defined in one of the schemas referenced in the "IMPORTS" field of the ldapSchemas line which includes this attribute type. Intended usage: COMMON 5.3. matchingRules To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type matchingRules Type name: matchingRules Type purpose: To represent the LDAPv3 attribute "matchingRules", defined in section 5.1.8 of [3]. Type encoding: 8bit Type valuetype: text, encoded according to the BNF of "MatchingRuleDescription" given in section 4.5 of [3]. Type special notes: Each value of the type specifies one matching rule definition. The syntax reference in a value of matchingRules MUST either be present in this content, or defined in one of the schemas referenced in the "IMPORTS" field of the ldapSchemas line which includes this attribute type. Intended usage: COMMON 5.4. objectClasses To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type objectClasses Type name: objectClasses Type purpose: To represent the LDAPv3 attribute "objectClasses", defined in section 5.1.7 of [3]. Type encoding: 8bit Type valuetype: text, encoded according to the BNF of "ObjectClassDescription" given in section 4.4 of [3]. Type special notes: Each value of the type specifies one LDAPv3 object class definition. The attributes and object classes referenced in a value of objectClasses MUST either be present in this content, or defined in one of the schema referenced in the "IMPORTS" statement of the ldapSchemas line which includes this object class. Intended usage: COMMON 5.5. matchingRuleUse To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type matchingRuleUse Type name: matchingRuleUse Type purpose: To represent the LDAPv3 attribute "matchingRuleUse", defined in section 5.1.9 of [3]. Type encoding: 8bit Type valuetype: text, encoded according to the BNF of "MatchingRuleUseDescription" given in section 4.5 of [3]. Type special notes: Each value of the type specifies a relationship between a matching rule and attribute types. The matching rule and attribute types referenced in a value of matchingRuleUse MUST either be present in this content, or defined in one of the schemas referenced in the "IMPORTS" statement of the ldapSchemas line which includes this matching rule. Intended usage: COMMON 5.6. ldapSyntaxes To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type ldapSyntaxes Type name: ldapSyntaxes Type purpose: To represent the LDAPv3 attribute "ldapSyntaxes", defined in section 5.3.1 of [3]. Type encoding: 8bit Type valuetype: text, encoded according to the BNF of "SyntaxDescription" given in section 4.3.3 of [3]. Type special notes: Each value of this type specifies a single LDAPv3 attribute value syntax. Intended usage: COMMON 5.7. schemaDesc To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type schemaDesc Type name: schemaDesc Type purpose: To represent the LDAPv3 attribute "schemaDesc", defined in section A.3 below. Type encoding: 8bit Type valuetype: text, encoded according to the BNF of section A.4. Type special notes: Each value of this type specifies the descriptive information associated with an LDAPv3 schema. Intended usage: COMMON 6. Example From: Whomever@wherever.com To: Someone@somewhere.com Subject: schema information MIME-Version: 1.0 Message-Id: Content-Type: text/directory; profile="schema-ldap-0", charset="utf-8" Content-Transfer-Encoding: Quoted-Printable ldapSchemas: ( NAME 'bogus schema' CLASSES ( top $ thing ) = ATTRIBUTES ( objectClass $ name ) SYNTAXES ( = 1.3.6.1.4.1.1466.115.121.1.38 $ 1.3.6.1.4.1.1466.115.121.1.15 ) ) attributeTypes: ( 2.5.4.0 NAME 'objectClass' SYNTAX = 1.3.6.1.4.1.1466.115.121.1.38 ) attributeTypes: ( 2.5.4.41 NAME 'name' SYNTAX = 1.3.6.1.4.1.1466.115.121.1.15{32768} ) objectClasses: ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass ) objectClasses: ( 2.5.6.999 NAME 'thing' MUST name ) ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'String' ) ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' ) 7. Bibliography [1] [draft-ietf-asid-mime-directory] [2] [draft-ietf-asid-ldapv3-protocol] [3] [draft-ietf-asid-ldapv3-attributes] [4] [draft-ietf-asid-ldif] Appendix A This appendix defines two new attributes which could be present in an subschema entry. These attributes may be added to a future revision of the LDAP attribute definition [3]. A.1. ldapSchemas attribute type definition ( TBA NAME 'ldapSchemas' SYNTAX TBA USAGE directoryOperation ) Each value of the ldapSchemas attribute defines one schema. Its syntax, given in section A.2, contains the elements needed for an LDAPv3 server to correctly process operations which use the definitions from this syntax. A.2. LDAP Schema syntax definition ( TBA DESC 'LDAP Schema' ) Values in this syntax are represented according to the following BNF: LdapSchema = "(" whsp [numericoid whsp] [ "NAME" qdescrs ] [ "OBSOLETE" whsp ] [ "IMPORTS" oids ] [ "CLASSES" oids ] [ "ATTRIBUTES" oids ] [ "MATCHING-RULES" oids ] [ "SYNTAXES" oids ] whsp ")" A.3. schemaDesc attribute type description ( TBA NAME 'schemaDesc' SYNTAX TBA USAGE directoryOperation ) The schemaDesc attribute associates descriptive information with a syntax definition. A.4. Schema Info syntax definition ( TBA DESC 'Schema Info' ) Values in this syntax are represented according to the following BNF: SchemaInfo = "(" whsp [numericoid whsp] [ "NAME" qdescrs ] [ "DESC" qdstring ] whsp ")" *** more to be added, as specified in the schema listing requirements --foo-- From owner-ietf-schema-reg Mon Sep 8 20:16:26 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id UAA08182 for ietf-schema-reg-bks; Mon, 8 Sep 1997 20:16:26 -0700 (PDT) Received: from i.control.att.com ([135.205.52.126]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id UAA08178 for ; Mon, 8 Sep 1997 20:16:21 -0700 (PDT) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Mon, 8 Sep 1997 23:16:30 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for ietf-schema-reg@imc.org; Mon, 8 Sep 1997 23:16:25 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Mon, 8 Sep 1997 23:16:25 -0400 (EDT) From: capple@master.control.att.com (Christopher W Apple) To: Mark Wahl , ietf-schema-reg@imc.org Subject: Re: comments on schema listing requirement doc Sender: owner-ietf-schema-reg@imc.org Precedence: bulk >While reviewing the schema requirements draft I started to get the feeling >that LDIF was not quite the right data representation format for the schema >listing service. I was concerned that there may be expectations associated >with LDIF that may not be appropriate in this context. > >LDIF is based on the LDAP information model for the transfer of entries. >The objects exchanged by components in schema listing services may not however >necessarily correspond 1:1 to entries. (A subschema entry may contain multiple >schema definitions.) > >I would like to suggest as an alternative, defining a profile of the MIME >directory content-type for the transfer of schema information. It sounds like your intent is to replace the currently specified syntax of "LDIF" with "a MIME part conformant with ." I have no objections to replacing "LDIF," but think that the other syntaxes should remain, provided that the overall directory-service-protocol-independence requirement is still something over which list members are in concensus. This brings us to an issue that was intended for list discussion: should we only allow for one syntax for the initial service offering? A new question is: should this syntax be based on Mark's proposal or the existing syntax specifications? I think there are some process points that need to be explored about how to incorporate Mark's proposal should there be concensus to do so: There are currently two documents listed as deliverables for the proposed Schema Listing WG charter: + a requirements document (draft-apple-schema-rqmts-list-01.txt) + a process document (being worked on by the engineering team) The requirements document is intended to become an informational RFC. I think the process document is intended to become a BCP. If we use the MIME directory profile that you've defined should it be + included as an appendix to the requirements document? the process document? OR + an independent informational RFC? standards-track RFC? If it needs to be standards-track RFC does it need to be named as a deliverable of the Schema Listing WG? >This profile would contain the same elements in the same format as an LDAP >subschema entry. The main parsing difference from LDIF would be the >Content Transfer Encoding, however C-T-Es are widely implemented. > >I think it would be clearer to describe how an object represented as a MIME >type is exchanged between the components. One can simply send it through mail, >combine it with other contents, retrieve it via HTTP etc. This is sort of what we had in mind, but were planning on using text/plain MIME to transfer LDIF, ASN.1, and/or XML schema specifications. I see no technical problems with replacing the notion of "transfer of LDIF using text/plain MIME" with that of "transfer of LDAPv3 schema using ." Chris A. From owner-ietf-schema-reg Tue Sep 9 10:28:38 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA18237 for ietf-schema-reg-bks; Tue, 9 Sep 1997 10:28:38 -0700 (PDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.23]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA18233 for ; Tue, 9 Sep 1997 10:28:35 -0700 (PDT) Received: by mail3.microsoft.com with Internet Mail Service (5.0.1459.27) id ; Tue, 9 Sep 1997 10:22:51 -0700 Message-ID: From: Chris Weider To: "'minutes@ietf.org'" , "'ietf-schema-reg@imc.org'" Subject: Final minutes of the Schema Listing BOF Date: Tue, 9 Sep 1997 10:21:39 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1459.27) Sender: owner-ietf-schema-reg@imc.org Precedence: bulk As no one pointed out any problems, these are unchanged from the draft minutes sent out in August. Chris Minutes of the 8/13/97 meeting of the Schema Listing BOF Special thanks to John Strassner for taking the minutes! The agenda was as follows 1: Bash the charter 2: Current holes in the Schema Listing Requirements document (Chris Apple) 3: Discussion of open issues Discussion: 1: There were no problems with the charter 2: Holes in the document that need to be patched - doesn't match Scott Bradner's requirement terminology - Security considerations - The philosophy of unlimited read and tightly controlled write needs to be spelled out in the document 3: Other issues resolved - Syntax specs should be BNF - Localized versions of the schema should be made available and should be pointed to by the main schema. This includes language tags. - OIDs will be used to uniquely identify schema - A question about two competing requests (i.e. same names, but different content) came up. This should be handled in a separate process document. However, since the service will be assigning OIDs to the schema, each schema will have a unique name. - Does a change in the machine-readable portion of a schema require a rev of the entire schema? YES. - The schema listing file name for a given schema will be the last component of the OID assigned to that schema. We should not include any other human semantics in the file name - Again, this is a listing service, not a vetting service. Schema standardization will happen after schema are listed - We will be adding a usage scenario section to the document. - We will be selecting one syntax as a required syntax for the service and will add two more if we can get the parsers. The three agreed on by the group are LDIF, ASN.1, and XML. We'll do a small list poll for the required one. - We will be requiring FTP and HTTP access to the repository. 4: Open issues for the list - Should any document that specifies schema be allowed to be registered? This is an issue for the list - Who owns the database? Who runs it? This will be discussed as we get closer to the process document. - Do we need to track and forbid display name collision of schema and attributes? I.e. two people trying to register the 'Person' schema even though they have different OIDs? - Should the listing service be searchable? We need to decide whether it is, and if so, what engine would be used. There are also the matters of UI and complexity of the interface. - Can this service be tied into the URN infrastructure? - For Jan 1, 1998, should we allow machine submission of schema. We are leaning towards NO but will take to the list. - Which (if any) of the submitted schema will be made into RFCs? - Should schema be signed so that people can verify that their schema are indeed the ones that they sent? Which signature algorithm should be used? - Do we store metaschema (i.e. schema not tied to any protocol, such as the Dublin Core). If so, how? How do we tie them to their expressions in various protocols? - What character sets should we support? How do we support them? - What are the required metadata elements for a schema listing? - Should we push for LDAP and SMTP access to the repository for Jan 1? - How do we control versioning? - Can we provide an automated submission process for Jan 1? - Is the store moderated to avoid BadGuy(tm) or StupidGuy(tm) attacks? One general rule is that we could agree that unsigned schema are automatically rejected 5: Action items a: change the acronym of the working group so that it doesn't contain the name schema... b: Put together the engineering team. Volunteers were: Michael Mealling - NSI Sam Sun - CNRI Mark Wahl - Critical Angle Sanjay Jain - Oracle John Strassner - Cisco Chris Weider - Microsoft c: rev the document and start the list discussions. We will cut off list discussion no later than 15 September to insure that the engineering team has everything it needs. From owner-ietf-schema-reg Fri Sep 19 07:57:42 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA19158 for ietf-schema-reg-bks; Fri, 19 Sep 1997 07:57:42 -0700 (PDT) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id HAA19154 for ; Fri, 19 Sep 1997 07:57:35 -0700 (PDT) Received: from beethoven.bunyip.com (beethoven.Bunyip.Com [192.197.208.5]) by mocha.bunyip.com (8.8.5/8.8.5) with ESMTP id KAA00346 for ; Fri, 19 Sep 1997 10:59:23 -0400 (EDT) Received: from localhost (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) with SMTP id KAA07057 for ; Fri, 19 Sep 1997 10:59:21 -0400 X-Authentication-Warning: beethoven.bunyip.com: leslie owned process doing -bs Date: Fri, 19 Sep 1997 10:59:21 -0400 (EDT) From: Leslie Daigle To: ietf-schema-reg@imc.org Subject: Schema Listing Requirements Document In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-schema-reg@imc.org Precedence: bulk I have a few comments/questions re. Chris Apple's document, By and large, I think it's quite good. I've already sent Chris a couple of comments of an editorial nature, but had some other issues I thought should be brought up on the list. These fall into 2 categories: 1. questions of temporal scope for these requirements 2. the schema object vs. the schema listing object On point 1, I understand that the point of this work is to get something up and running ASAP (Jan 1998, as I recall), and to that end these requirements include a lot of more-or-less hard-coded choices (e.g., the filenaming convention). I think that's fine, but I do think that the document scope section should make it clearer that these are requirements for a FIRST schema listingn service, and that all issues of extension and scaling will be addressed after operational experience has been garnered (i.e., these issues are recognized, but are beyond scope). Point number 2 relates to the fact that, in reading the document, it wasn't entirely clear to me _what_ is being listed -- by calling this a listing service, not a registry, I had thought that the point was to store representations of schemas. The document, though, seems to focus on the storage of the schema, as represented using one of several possible mechanisms. If that doesn't seem like a clear distinction, think about teh implications of intellectual property. _Anyone_ can have a representation of a Whois++ USER template, and I would have expected that, for instance, we might expect to see multiple listings of one such schema. Anyone can have a representation of something vcard-ish, but we'd probably only "believe" the one that was verifiably submitted by Frank Dawson. The document currently focuses on issues of ensuring validity of submissions, at a _content_ level. I.e., it wasn't clear to me that the concerns re. validation were not at the level of making sure it was, in fact, Frank Dawson (or his organization) that had submitted the listing. This belies concerns with authoritativeness that seem more appropriate at the schema level, than at the representation level, and I think it pushes us into the realm of registry-rather-than-listing-service. I think we should back off on those issues, let everyone list whatever representations they want, and let buyer-beware. I think it's the only reasonable approach for a 1998 launch. To that end, a lot of uses of the single word "schema" should be replaced by "schema listing" and some of the issues may just fall out. Detailed comments on the document (on this and a few other, more minor issues) follow. > Abstract > > This memo documents requirements for listing directory services > schemas in a centrally operated, administered, and maintained > repository. This repository will be available as a resource to > directory protocol and service implementors to facilitate schema > discovery. Let's start here and say this is a "first effort at..." > 1.1 Scope > > This document contains requirements for various aspects of listing > schemas. > > The definition of schema listing procedures is out of scope. Requirements for a system that will be up and running RSN are in scope; issues of eventual, inevitable extensibility are not. > use with version 3 of the LDAP protocol. Included in the web-based > representation of the listing meta data are ftp URLs pointing to > available syntaxes for this schema. The user clicks on the link for the > syntax that they can use. "available syntaxes for this schema" should be "this schema listing", I believe. > Schema MUST be named according to the namespace defined in section 3. Just as one example -- it's the schema listing that should be named, if the schema listing is what is being, errr, listed. > + a globally unique identifier for the schema name > + name/title of schema > + version information for the schema > + date of creation or update > + indication of listing status > + indication of relationship to other schemas > + originating organization or individual > + name of contact person for schema > + e-mail of contact person for schema > + telephone of contact person for schema > + postal address of contact person for schema > + character set tag for the listing meta data > + language tag for the listing meta data > + URL for more information > + URL for each available syntax > + intended use of the schema This is a hodge-podge of things that are relevant to the schema, and things that are relevant to teh schema listing. This is why it is critical to decide if this service is storing schema representations (of which there may be many, some more definitive than others) or if it's attempting to capture the essence of the schema (and all its attendant IP). Thus, should this be the contact person for the schema or the schema listing? Or should there be both? > Listing repository operators (of primary or shadow sites) MUST NOT claim > ownership of listing meta data or listing content submitted for > inclusion in the service. Exceptions to this requirement MAY be claimed, > IF a listing repository operator (primary or shadow) submits one or more > requests for listing schema that originated within their own > organizations. These exceptions MUST be limited to claims of ownership > on particular schema listings originating from the listing repository > operator in question and MUST NOT be extended to include other schema > listings. I don't think the listing services should claim ownership of metadata at all. I don't think listers should claim ownership of metadata. Buyer beware. > a) obtain schema listing content > b) obtain schema listing meta data > c) browse schema listing meta data > d) browse schema listing content > e) obtain a list of available schema > f) browse a list of available schema > g) search a list of available schema > h) add a schema listing > i) update a schema listing e-g: schema listings. > The listing name MUST be the OID at which the schema is rooted. Rooted? If this is about schema listings, this should be more clearly defined. If it is about schemas, then this is about LDAP/X.500 object classes, and that's that. > Editorial Comment: I am leaning towards _only_ keeping the content in > paragraph 6.3 in this requirements document. I'd like for the working > group to pay close attention to the scope of this document (requirements > for the service) and the other document which is due out soon as well I don't think the other sectiosn should go; rather, I think they should be re-cast more in the way 6.3 is written. I.e., they should talk about "the service MUST address the following", or "a proposal for a service MUST describe how it does/does not address the following". > 6.3 Security Requirements on Schema Listing Procedures > > The schema listing procedures MUST: > > a) include mechanisms to verify that all properly formed submissions > are submitted by the person claiming to own the e-mail address listed > in the request Have fun! > c) include mechanisms to validate the integrity of all properly > formed submissions Define integrity. If this is just j-random-listing, there's not much to worry about (except for the issues of listing-just-for-fun, outlined in the earlier subsections of section 6. > d) include mechanisms to ensure the non-repudiation of all validly > formed submissions Define conditions/scope for non-repudiation. Cheers! Leslie. ---------------------------------------------------------------------------- "_Be_ Leslie Daigle where you _are_." Bunyip Information Systems (514) 875-8611 -- ThinkingCat leslie@bunyip.com ---------------------------------------------------------------------------- From owner-ietf-schema-reg Fri Sep 19 14:46:56 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA23936 for ietf-schema-reg-bks; Fri, 19 Sep 1997 14:46:56 -0700 (PDT) Received: from folder.critical-angle.com (critical-angle.com [206.81.238.241]) by mail.proper.com (8.8.7/8.7.3) with SMTP id OAA23932 for ; Fri, 19 Sep 1997 14:46:52 -0700 (PDT) Received: (qmail 1346 invoked from network); 19 Sep 1997 21:41:51 -0000 Received: from folder.critical-angle.com (206.81.238.241) by folder.critical-angle.com with SMTP; 19 Sep 1997 21:41:51 -0000 From: Mark Wahl To: capple@master.control.att.com (Christopher W Apple) cc: ietf-schema-reg@imc.org Subject: Re: comments on schema listing requirement doc In-reply-to: Your message of "Mon, 08 Sep 1997 23:16:25 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Sep 1997 16:41:51 -0500 Message-ID: <1344.874705311@folder.critical-angle.com> Sender: owner-ietf-schema-reg@imc.org Precedence: bulk > I have no objections to replacing "LDIF," but think that the other syntaxes > should remain, provided that the overall directory-service-protocol-independence > requirement is still something over which list members are in concensus. One approach would be to have each directory service define a profile of the MIME text/directory which contains the attributes of its schema. There could also be a protocol-independent profile which adds the meta-data attributes. > The requirements document is intended to become an informational RFC. I think > the process document is intended to become a BCP. If we use the MIME > directory profile that you've defined should it be I would suggest keeping it an independent document, as this would help to maintain a separation between the directory-service-dependent and directory-service-independent aspects of the listing service. Mark Wahl, Enterprise Directory Integration Critical Angle Inc. From owner-ietf-schema-reg Thu Sep 25 15:55:24 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA15080 for ietf-schema-reg-bks; Thu, 25 Sep 1997 15:55:24 -0700 (PDT) Received: from folder.critical-angle.com (critical-angle.com [206.81.238.241]) by mail.proper.com (8.8.7/8.7.3) with SMTP id PAA15076 for ; Thu, 25 Sep 1997 15:55:18 -0700 (PDT) Received: (qmail 21862 invoked from network); 25 Sep 1997 22:59:20 -0000 Received: from folder.critical-angle.com (206.81.238.241) by folder.critical-angle.com with SMTP; 25 Sep 1997 22:59:20 -0000 From: Mark Wahl To: capple@att.com cc: ietf-schema-reg@imc.org Subject: security requirements of the schema listing service Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 25 Sep 1997 17:59:20 -0500 Message-ID: <21860.875228360@folder.critical-angle.com> Sender: owner-ietf-schema-reg@imc.org Precedence: bulk I would like discuss in a bit more detail the security requirements of the schema listing service. The security mechanisms in the requirements document are: > All schema submitted for listing MUST be signed using PGP with the TBD > signature algorithm. > All schema listing requests that are not signed or signed improperly > MUST be discarded. Section 6.3 refers to the "identity of a submitter" a few times. I think this needs to be clarified further, and the syntax of the contact field in the meta-data, an email address, is not sufficient to meet the requirements of this section. > a) include mechanisms to verify that all properly formed submissions > are submitted by the person claiming to own the e-mail address listed > in the request If the submission protocol is ordinary SMTP, then an attacker can generate any message headers he desires, and an active attacker can remove messages in transit. This rules out a verification mechanism based on replying to the e-mail address with a message "you just submitted the following schema", since the attacker can delete this message as it goes past. Thus, more information is required than just an address. > b) include mechanisms to verify a submitter's authority to update an > existing schema listing Over the lifetime of a schema, the characteristics of a submitter can change. The service definition needs to clarify what changes are permitted, and what changes would fail verification of authority. Over the period of two years, a significant percentage of people change their PGP keys, name and email address. One approach is to return to the submitter a service-assigned secret token which the submitter can include in future updates. However, this requires both confidentiality in the communications with the service and in the service's databases. Instead, there needs to be a means of identifying a submitter such that, for example, any one of the properties can change, while the submitter can still be verified. > c) include mechanisms to validate the integrity of all properly > formed submissions > > d) include mechanisms to ensure the non-repudiation of all validly > formed submissions With PGP, all that can be verified is that submission was not modified in transit. It does not validate any relationships between the submitted meta-data and external information. There are two cases of non-repudiation: - the submitter repudiates the schema The submitter can destroy their private key, and claim that an impersonator signed a schema with their name. To prevent this, a third party needs to have verified the binding of the identity of the submitter to their key before the request was sent. - the service repudiates having received the schema To prevent this, the service must sign the schema. These aspects have significant impact on the listing procedures, and should be called out explicitly in the requirements. > e) only accept changes to the identity of the contact person for a > schema or to the information used to verify the identity of same from > the current contact person > > f) cover the situation in which the contact person for a schema is no > longer available or is unable to submit updates to the schema listing > which they master If the contact person for a schema is an employee in the company that developed a schema, and that person is hired away by a competitor, then that person is able to keep modifying the schema until someone else in the company is able to convince the schema listing service to go from state e) to state f). Since that other person is not the contact for the schema, and the contact for the schema still is able to submit updates, this would be difficult to resolve in an automated system. I suggest that this problem might be minimized if the phrase "contact person" is replaced by "contact role". It is the responsibility of the submitting organization to define and maintain the role occupant(s), who may change over time, without the schema listing service being aware. Another security issue which I would like to have noted in the security requirements section is impersonation of the schema listing service. If an attacker controls part of the Internet between a schema submitter and a listing server, the attacker can discard requests. If an attacker controls part of the Internet between a schema requestor and a listing server, the attacker can generate fake schemas. Thus, there are two changes to the existing text: 1. Replace "contact person" with "contact role". This allows an organization to change their contact person without bothering the schema service. 2. Replace the meta-data field of the submitter's identity with "a binding between the submitter's name and email address, and the key they used for signing, certified by a trusted third party (TTP)." and five additional requirements which are implied by the security considerations, which should be made explicit. 1. There is a trusted third party which establishes the identity of submitting contact roles to a level which satisfies the schema listing service, by signing keys. In the X.509 world, this is known as a "Certification Authority". The TTP should be able to handle changes in submitter parameters (e.g. they change their key every year). The TTP should be on-line and replicated so that the schema listing service should be capable of verifying identity of received messages (e.g. if a key has been compromised, messages should no longer be accepted using that key). [[ To allow the widest use of the schema listing service, the TTP should use a signing algorithm which is widely available, as patent-free as possible, and preferably the same as the algorithm with which submitters sign the schemas. ]] 2. Contact roles must be certified by a TTP prior to submitting a request. The certification contains the identity of the role (e.g. their name and email address), and their signing key. [[ To allow the widest use of the schema listing service, the certification process should be free. ]] 3. The schema listing service must be certified by a TTP. This prevents a schema user from being misled by a imposter listing service. The schema listing service's signed key should be widely distributed. 4. The schema listing service must sign all schemas which it has accepted. service signs | service-added meta-data | submitting contact role signs | | submitter's meta-data | | schema 5. The schema listing service replies with its certified key and the signed schema to submission requests. This ensures the non-repudiation of schema listings by the listing service. HOWEVER, Historically there have difficulties in establishing an Internet certification system, which have seriously limited the deployment of services based on it (e.g. Privacy Enhanced Mail). In order to ensure that the schema listing service meets its required timescales, I would recommend that the organizations which will perform the TTP service be located ASAP. If they cannot be found, then the requirements in the security considerations should be moved to "not considered". The service will operate, although it will be open to a number of attacks. Mark Wahl, Enterprise Directory Integration Critical Angle Inc. From owner-ietf-schema-reg Fri Sep 26 04:15:42 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id EAA23159 for ietf-schema-reg-bks; Fri, 26 Sep 1997 04:15:42 -0700 (PDT) Received: from amalthea.salford.ac.uk (amalthea.salford.ac.uk [146.87.255.61]) by mail.proper.com (8.8.7/8.7.3) with SMTP id EAA23128 for ; Fri, 26 Sep 1997 04:12:02 -0700 (PDT) Received: (qmail 7985 invoked by alias); 26 Sep 1997 11:13:51 -0000 Message-ID: <19970926111351.7983.qmail@amalthea.salford.ac.uk> Received: (qmail 7971 invoked from network); 26 Sep 1997 11:13:48 -0000 Received: from man-014.dialup.zetnet.co.uk (HELO zetnet.co.uk) (194.247.41.17) by amalthea.salford.ac.uk with SMTP; 26 Sep 1997 11:13:48 -0000 Comments: Authenticated sender is From: "David Chadwick" Organization: University of Salford To: Mark Wahl Date: Fri, 26 Sep 1997 12:14:40 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: security requirements of the schema listing service Reply-to: D.W.Chadwick@iti.salford.ac.uk CC: ietf-schema-reg@imc.org, Andy@fw4.iti.salford.ac.uk In-reply-to: <21860.875228360@folder.critical-angle.com> X-mailer: Pegasus Mail for Win32 (v2.53/R1) Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Mark wrote: > In order to ensure that the schema listing service meets its required > timescales, I would recommend that the organizations which will perform > the TTP service be located ASAP. If they cannot be found, then the > requirements in the security considerations should be moved to "not considered". > The service will operate, although it will be open to a number of attacks. > There are a number of TTP services operating today. We all know about Verisign, for example, but in Europe we also have a number of them, several operating under the EC funded ICE-TEL project. At Salford, we have just established an LDAP based directory for storing the certificates and CRLs of the ICE-TEL CAs. We would be willing to host a similar service for the schema registry project. We also operate a TTP service, but we would need to discuss the requirements further before we offer this service to the schema registry project. David *************************************************** David Chadwick IT Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 370 957 287 Email D.W.Chadwick@iti.salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm *************************************************** From owner-ietf-schema-reg Fri Sep 26 12:03:24 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA02393 for ietf-schema-reg-bks; Fri, 26 Sep 1997 12:03:24 -0700 (PDT) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA02389 for ; Fri, 26 Sep 1997 12:03:19 -0700 (PDT) Received: from beethoven.bunyip.com (beethoven.Bunyip.Com [192.197.208.5]) by mocha.bunyip.com (8.8.5/8.8.5) with ESMTP id PAA01343; Fri, 26 Sep 1997 15:01:48 -0400 (EDT) Received: from localhost (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) with SMTP id PAA10290; Fri, 26 Sep 1997 15:02:18 -0400 X-Authentication-Warning: beethoven.bunyip.com: leslie owned process doing -bs Date: Fri, 26 Sep 1997 15:02:17 -0400 (EDT) From: Leslie Daigle To: Mark Wahl cc: capple@att.com, ietf-schema-reg@imc.org Subject: Re: security requirements of the schema listing service In-Reply-To: <21860.875228360@folder.critical-angle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Well, SMTP-based delivery of PGP-signed messages works fine for the model of this as a schema _listing_ service, since there is very little content that needs to be secured if everyone can have their own description. Your call for more elaborate security strikes me as being appropriate for a schema _registry_ service, where the validity of the schema itself is called into question if the service is not secured. This follows on to my earlier message about the requirements document, wherein I posed questions about the scope of this group's work -- whether the schema is being stored or the listing is being stored. And, since there was no discussion re. that posting, I naturally assume everyone agreed with it. :-) Leslie. ---------------------------------------------------------------------------- "_Be_ Leslie Daigle where you _are_." Bunyip Information Systems (514) 875-8611 -- ThinkingCat leslie@bunyip.com ---------------------------------------------------------------------------- From owner-ietf-schema-reg Mon Sep 29 00:51:55 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id AAA05247 for ietf-schema-reg-bks; Mon, 29 Sep 1997 00:51:55 -0700 (PDT) Received: from folder.critical-angle.com (critical-angle.com [206.81.238.241]) by mail.proper.com (8.8.7/8.7.3) with SMTP id AAA05243 for ; Mon, 29 Sep 1997 00:51:49 -0700 (PDT) Received: (qmail 32194 invoked from network); 29 Sep 1997 07:56:04 -0000 Received: from folder.critical-angle.com (206.81.238.241) by folder.critical-angle.com with SMTP; 29 Sep 1997 07:56:04 -0000 From: Mark Wahl To: ietf-schema-reg@imc.org To: D.W.Chadwick@iti.salford.ac.uk cc: Mark Wahl Cc: Andy@fw4.iti.salford.ac.uk Subject: Re: security requirements of the schema listing service In-reply-to: Your message of "Fri, 26 Sep 1997 12:14:40 -0000." <19970926111351.7981.qmail@amalthea.salford.ac.uk> Date: Mon, 29 Sep 1997 02:56:04 -0500 Message-ID: <32192.875519764@folder.critical-angle.com> Sender: owner-ietf-schema-reg@imc.org Precedence: bulk > There are a number of TTP services operating today. We all know about > Verisign, for example, but in Europe we also have a number of them, > several operating under the EC funded ICE-TEL project. At Salford, we > have just established an LDAP based directory for storing the > certificates and CRLs of the ICE-TEL CAs. We would be willing to host > a similar service for the schema registry project. > We also operate a TTP service, but we would need to discuss the > requirements further before we offer this service to the schema > registry project. There are two independent classes of objects for which a certification service could be used. The first would be the schema listing servers themselves. These servers would sign listed schemas, and if their keys are trusted, then a user retrieving documents from the service can ensure that schemas were not modified after listing. Certifying these servers would not be too difficult, since there would be a very small number of them, and their operational procedures would be governed by a set of specifications. The second would be users submitting schemas to the listing service. If they sign their schemas prior to submission (so that the resulting schemas are signed by both the submitter and listing service), then there is a foothold for the ability to relate between a submitter and a listed document, allowing for the automatic validation of subsequent update requests. This is a much more difficult problem as the submitting community would potentially be very large (hundreds of organizations worldwide providing directory services may wish to list their schema additions.) The schema listing requirements draft specifies PGP as the document security mechanism, presumably as this is the only widely-deployed standards-track specification. == Whether none, one or both of the certification functions should be part of the requirements depends, as Leslie Daigle has pointed out, on the expectations users should place on the service, which are often based on the security mechanisms associated with it. With a free-for-all listing service, then it a client retrieving from the listing service will have difficultly in processing the meta-data. It would not be possible to automatically determine the difference between the following two examples: Example A: While Alice is on vacation, Org. A updates its schema listing == schemaName: 1.1 schemaOrigin: Alice == schemaName: 1.2 schemaOrigin: Bob listingStatus: obsoletes 1.1 == Example B: Organization B claims they have a better schema than Org. A == schemaName: 1.1 schemaOrigin: Alice == schemaName: 1.2 schemaOrigin: Carol listingStatus: obsoletes 1.1 == This would prevent the schema listing service from being effectively used by an organization to distribute maintenance updates to its schema definitions. These kind of organizations would need a registry, which could validate interrelationships between schema at submission time, or a key management service, which could allow the client to validate that, by default, Bob was authorized to modify schema 1.1 but Carol was not. If there is a desire for a registry service which performs additional checks or requires particular security services that would not be available in the initial timeframe, then there would be a transition in future to a service specification offering these different characteristics. Then would exist a potential backwards-compatibility problem with schemas that are listed in the initial service offering, as their meta-data would need to be verified. Either the older meta-data information would be validated by hand, removed, or labeled as not-validated. Manual updates would likely be too costly if there have been many listed schemas, and an automated client written to the updated specifications would likely not be able to handle non-validated information. Planning to remove information which has been entered earlier seems bad. For simplification, a radical approach to consider would be to eliminate from this draft both the security requirements AND the majority of the meta-data, under a model that the listing service should only provide schema interrelationship meta-data which it could verify to be correct, which initially would be none. For example, the listing could be cut down to schema name (service-assigned OID), optional brief description (human-readable string and language indication), optional pointer to where the schema is _registered_ elsewhere (a set of URLs), and the schema listing itself (MIME content). The listing service procedures would state that issues of schema updates, interrelationships, ownership and IPR are outside the scope of the listing service, and are instead the responsibility of the indicated schema registry service(s). This eliminates the client confusion problem with the update example at the source by ensuring that it could not occur. Then, when these larger issues of schema registration have been resolved, the security services can be enabled, and additional forms of meta-data permitted for new listings. Mark Wahl, Enterprise Directory Integration Critical Angle Inc. From owner-ietf-schema-reg Mon Sep 29 13:16:15 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA15546 for ietf-schema-reg-bks; Mon, 29 Sep 1997 13:16:15 -0700 (PDT) Received: from lotus.lotus.com (lotus.com [192.233.136.1]) by mail.proper.com (8.8.7/8.7.3) with SMTP id NAA15542 for ; Mon, 29 Sep 1997 13:16:11 -0700 (PDT) From: Frank_Dawson/CAM/Lotus@lotus.com Received: from internet2.lotus.com by lotus.lotus.com (SMI-8.6/SMI-SVR4) id QAA01462; Mon, 29 Sep 1997 16:13:35 -0400 Received: from MTA2.lotus.com by internet2.lotus.com (5.x/SMI-SVR4) id AB01541; Mon, 29 Sep 1997 16:08:57 -0400 Received: by mta2.lotus.com(Lotus SMTP MTA SMTP v4.6 (462.2 9-3-1997)) id 85256521.006F664A ; Mon, 29 Sep 1997 16:16:46 -0400 X-Lotus-Fromdomain: LOTUS@MTA To: ietf-schema-reg@imc.org Message-Id: <85256521.006E71FE.00@mta2.lotus.com> Date: Mon, 29 Sep 1997 16:09:53 -0400 Subject: security requirements of the schema listing service Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Folks: I may be missing something on the "security requirements". Why is it so important to have this level of authentication for a schema submission? What happens when someone uses snail-mail to submit a request? Or if they fax the request in? It seems like overkill to be requiring PGP signing of a request. Won't the listing authority be communicating with the submitter to confirm receipt and clarify any questions with the application? Why is this being made so difficult? Don't other feel this way too? - - Frank Dawson From owner-ietf-schema-reg Mon Sep 29 13:37:32 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA15891 for ietf-schema-reg-bks; Mon, 29 Sep 1997 13:37:32 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA15886 for ; Mon, 29 Sep 1997 13:37:28 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id NAA25469 for ; Mon, 29 Sep 1997 13:39:23 -0700 (PDT) Received: from netscape.com ([205.217.228.51]) by dredd.mcom.com (Netscape Messaging Server 3.0) with ESMTP id AAA5489; Mon, 29 Sep 1997 13:39:22 -0700 Message-ID: <343011C2.88DE30F5@netscape.com> Date: Mon, 29 Sep 1997 13:38:26 -0700 From: Tim Howes Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.02 [en] (X11; I; IRIX 6.2 IP22) MIME-Version: 1.0 To: Frank_Dawson/CAM/Lotus@lotus.com CC: ietf-schema-reg@imc.org Subject: Re: security requirements of the schema listing service References: <85256521.006E71FE.00@mta2.lotus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Frank_Dawson/CAM/Lotus@lotus.com wrote: > Folks: > > I may be missing something on the "security requirements". Why is it so > important to have this level of authentication for a schema submission? > > What happens when someone uses snail-mail to submit a request? Or if they > fax the request in? > > It seems like overkill to be requiring PGP signing of a request. Won't the > listing authority be communicating with the submitter to confirm receipt > and clarify any questions with the application? Why is this being made so > difficult? > > Don't other feel this way too? I certainly do. What problem is all this security trying to solve? Does any other registration mechanism have anything even remotely like this? I don't think so. Seems like a definite case of overkill to me. -- Tim From owner-ietf-schema-reg Mon Sep 29 14:11:03 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA16318 for ietf-schema-reg-bks; Mon, 29 Sep 1997 14:11:03 -0700 (PDT) Received: from folder.critical-angle.com (critical-angle.com [206.81.238.241]) by mail.proper.com (8.8.7/8.7.3) with SMTP id OAA16314 for ; Mon, 29 Sep 1997 14:10:56 -0700 (PDT) Received: (qmail 1483 invoked from network); 29 Sep 1997 21:15:22 -0000 Received: from folder.critical-angle.com (206.81.238.241) by folder.critical-angle.com with SMTP; 29 Sep 1997 21:15:22 -0000 From: Mark Wahl To: howes@netscape.com cc: ietf-schema-reg@imc.org Subject: Re: security requirements of the schema listing service Date: Mon, 29 Sep 1997 16:15:22 -0500 Message-ID: <1481.875567722@folder.critical-angle.com> Sender: owner-ietf-schema-reg@imc.org Precedence: bulk > What problem is all this security trying to solve? Allow submitters of schemas to be able to maintain their listings. Allow schema information retrieved from the service to be processed automatically. Eliminate certain classes of security threats to submitters, service users, and the listing servers themselves. Reduce the number of operations in the schema listing service which require human interaction. > Does any other registration mechanism have anything even remotely like this? DNS, for one. InterNIC domain registration template If a Contact of the Domain has previously used the Contact Template to specify the use of Pretty Good Privacy (PGP) or encrypted password, the authentication scheme and information associated with it should be listed in items 0b and 0c. These items contain the authorization information for the sender of an update request and help determine if the request is coming from a valid sender. These items are REQUIRED when a domain is being modified. RFC 2065 The Domain Name System (DNS) has become a critical operational part of the Internet infrastructure yet it has no strong security mechanisms to assure data integrity or authentication. Extensions to the DNS are described that provide these services to security aware resolvers or applications through the use of cryptographic digital signatures. These digital signatures are included in secured zones as resource records. Security can still be provided even through non-security aware DNS servers in many cases. Mark Wahl, Enterprise Directory Integration Critical Angle Inc. From owner-ietf-schema-reg Mon Sep 29 14:53:17 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA16870 for ietf-schema-reg-bks; Mon, 29 Sep 1997 14:53:17 -0700 (PDT) Received: from i.control.att.com ([135.205.52.126]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA16865 for ; Mon, 29 Sep 1997 14:53:13 -0700 (PDT) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Mon, 29 Sep 1997 17:55:08 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for howes@netscape.com; Mon, 29 Sep 1997 17:55:09 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Mon, 29 Sep 1997 17:55:09 -0400 (EDT) From: capple@master.control.att.com (Christopher W Apple) To: Tim Howes , Frank_Dawson/CAM/Lotus@lotus.com Cc: ietf-schema-reg@imc.org Subject: Re: security requirements of the schema listing service Sender: owner-ietf-schema-reg@imc.org Precedence: bulk >Frank_Dawson/CAM/Lotus@lotus.com wrote: > >> What happens when someone uses snail-mail to submit a request? Or if they >> fax the request in? As of the "-01.txt" version of the requirements document, these two methods for submitting schema listings are not mentioned. It will not expedite deployment activities to add them. In my opinion, expediting the deployment of the service should be our primary goal at this point. If relaxing original expectations in terms of security helps achieve this end and this is acceptable to the members of the list: so be it (subject to the concept clearing the IESG when the requirements and process documents go in for approval). >> It seems like overkill to be requiring PGP signing of a request. Won't the >> listing authority be communicating with the submitter to confirm receipt >> and clarify any questions with the application? I suppose this is likely to be the case. Until we get closer to service turn-up we'll not know the answer to how this works operationally. > Why is this being made so >> difficult? That was not the intent. The mini-concensus of the Munich schema listing engineering team was that the method of moderating schema listing requests would be via signing; if it was not signed the request would be rejected. I am not opposed (personally) to removing (or reducing) these requirements, but want to wait for a bit more air time on the implication that it be done. Replacement text for the guilty paragraphs is always welcome. >> >> Don't other feel this way too? > >I certainly do. What problem is all this security trying to >solve? Does any other registration mechanism have anything >even remotely like this? I think Mark Wahl answered these questions pretty succinctly in an earlier posting. > Seems like a definite >case of overkill to me. -- Tim If this opinion is expressed by a few more folks and is not contested significantly, I'll make changes to the requirements document to reflect it. Once again, replacement text for the guilty paragraphs is always welcome. Chris Apple Internet Directory Group AT&T Laboratories capple@master.control.att.com +1 908 582 2409 From owner-ietf-schema-reg Mon Sep 29 16:28:42 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA17965 for ietf-schema-reg-bks; Mon, 29 Sep 1997 16:28:42 -0700 (PDT) Received: from lotus.lotus.com (lotus.com [192.233.136.1]) by mail.proper.com (8.8.7/8.7.3) with SMTP id QAA17957 for ; Mon, 29 Sep 1997 16:28:37 -0700 (PDT) From: Frank_Dawson/CAM/Lotus@lotus.com Received: from internet2.lotus.com by lotus.lotus.com (SMI-8.6/SMI-SVR4) id TAA17994; Mon, 29 Sep 1997 19:27:26 -0400 Received: from mta2.lotus.com by internet2.lotus.com (5.x/SMI-SVR4) id AA08554; Mon, 29 Sep 1997 19:23:17 -0400 Received: by mta2.lotus.com(Lotus SMTP MTA SMTP v4.6 (462.2 9-3-1997)) id 85256521.00813EB9 ; Mon, 29 Sep 1997 19:31:42 -0400 X-Lotus-Fromdomain: LOTUS@MTA To: Mark Wahl Cc: ietf-schema-reg@imc.org Message-Id: <85256521.0080B545.00@mta2.lotus.com> Date: Mon, 29 Sep 1997 19:26:48 -0400 Subject: Re: security requirements of the schema listing service Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Mark Wahl wrote, in part: "Eliminate certain classes of security threats to submitters, service users, and the listing servers themselves" I think we may be worrying about what is (or is not) under the bed, here! -- Frank From owner-ietf-schema-reg Mon Sep 29 16:59:30 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA18220 for ietf-schema-reg-bks; Mon, 29 Sep 1997 16:59:30 -0700 (PDT) Received: from folder.critical-angle.com (critical-angle.com [206.81.238.241]) by mail.proper.com (8.8.7/8.7.3) with SMTP id QAA18216 for ; Mon, 29 Sep 1997 16:59:25 -0700 (PDT) Received: (qmail 2047 invoked from network); 30 Sep 1997 00:03:51 -0000 Received: from folder.critical-angle.com (206.81.238.241) by folder.critical-angle.com with SMTP; 30 Sep 1997 00:03:51 -0000 From: Mark Wahl To: ietf-schema-reg@imc.org cc: Frank_Dawson/CAM/Lotus@lotus.com cc: Mark Wahl Subject: Re: security requirements of the schema listing service In-reply-to: Your message of "Mon, 29 Sep 1997 19:26:48 EDT." <85256521.0080B545.00@mta2.lotus.com> Date: Mon, 29 Sep 1997 19:03:51 -0500 Message-ID: <2045.875577831@folder.critical-angle.com> Sender: owner-ietf-schema-reg@imc.org Precedence: bulk > "Eliminate certain classes of security threats to submitters, service > users, and the listing servers themselves" > I think we may be worrying about what is (or is not) under the bed, here! Two examples in related systems have been: - modifying the author fields of an Internet draft and recirculating it - attempts to insert new or modified records into the root DNS servers An organization which has invested time and resources in developing a schema definition and wishes to share the results publically will have concerns that their work is not misrepresented. Users who intend to extract updates from the schema listing service for maintaining the schemas of their own operational directories will have concerns that invalid updates could disrupt their operations. In order for these submittesr and service users to determine whether the schema listing service is suitable for their needs, there should be clear statements in the requirements document of the services which are and are not provided by the service. Mark Wahl, Enterprise Directory Integration Critical Angle Inc. From owner-ietf-schema-reg Mon Sep 29 17:14:45 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA18424 for ietf-schema-reg-bks; Mon, 29 Sep 1997 17:14:45 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id RAA18420 for ; Mon, 29 Sep 1997 17:14:41 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id RAA09174 for ; Mon, 29 Sep 1997 17:16:39 -0700 (PDT) Received: from netscape.com ([205.217.228.51]) by dredd.mcom.com (Netscape Messaging Server 3.0) with ESMTP id AAA16783; Mon, 29 Sep 1997 17:16:39 -0700 Message-ID: <343044AB.90E781A9@netscape.com> Date: Mon, 29 Sep 1997 17:15:40 -0700 From: Tim Howes Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.02 [en] (X11; I; IRIX 6.2 IP22) MIME-Version: 1.0 To: Mark Wahl CC: ietf-schema-reg@imc.org Subject: Re: security requirements of the schema listing service References: <1481.875567722@folder.critical-angle.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Well, apparently it's been a while since I got a domain name! :) I can buy that we should be moving toward offering more security. But we need to be realistic about 1) the types of threats we're likely to see; 2) the consequences of those threats; and 3) how hard it is to recover from a security breech (has there been irreparable damage). I'm not convinced we've passed the "something really bad happens if we don't do this" test. I believe this will be a significant barrier to schema publication. -- Tim Mark Wahl wrote: > > What problem is all this security trying to solve? > > Allow submitters of schemas to be able to maintain their listings. > > Allow schema information retrieved from the service to be processed > automatically. > > Eliminate certain classes of security threats to submitters, service users, > and the listing servers themselves. > > Reduce the number of operations in the schema listing service which require > human interaction. > > > Does any other registration mechanism have anything even remotely like this? > > DNS, for one. > > InterNIC domain registration template > If a Contact of the Domain has previously used the Contact Template to > specify the use of Pretty Good Privacy (PGP) or encrypted password, the > authentication scheme and information associated with it should be > listed in items 0b and 0c. These items contain the authorization > information for the sender of an update request and help determine if > the request is coming from a valid sender. These items are REQUIRED > when a domain is being modified. > > RFC 2065 > The Domain Name System (DNS) has become a critical operational part > of the Internet infrastructure yet it has no strong security > mechanisms to assure data integrity or authentication. Extensions to > the DNS are described that provide these services to security aware > resolvers or applications through the use of cryptographic digital > signatures. These digital signatures are included in secured zones > as resource records. Security can still be provided even through > non-security aware DNS servers in many cases. > > Mark Wahl, Enterprise Directory Integration > Critical Angle Inc. From owner-ietf-schema-reg Mon Sep 29 17:27:37 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA18537 for ietf-schema-reg-bks; Mon, 29 Sep 1997 17:27:37 -0700 (PDT) Received: from [165.227.249.112] (buddhi.proper.com [165.227.249.112]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id RAA18533 for ; Mon, 29 Sep 1997 17:27:33 -0700 (PDT) Message-Id: In-Reply-To: <2045.875577831@folder.critical-angle.com> References: Your message of "Mon, 29 Sep 1997 19:26:48 EDT." <85256521.0080B545.00@mta2.lotus.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 29 Sep 1997 17:30:17 -0700 To: ietf-schema-reg@imc.org From: Paul Hoffman / IMC Subject: Re: security requirements of the schema listing service Sender: owner-ietf-schema-reg@imc.org Precedence: bulk I think making this a MUST is overkill. Also, without specifying how the recipient will trust th sender, signing will be useless. Given that we're using PGP here, there has to be something that describes how the trust model in RFC 1991 will operate for this protocol. I suggest we change: >All schema submitted for listing MUST be signed using PGP with the TBD >signature algorithm. To: Schema submitted for listing may be signed using PGP/MIME as described in RFC 2015. Operators MUST be able to accept schema in PGP/MIME messages, although they do not have to validate the signatures. The method for validating and determining trust of the signature is outside the scope of this document and is determined by the parties in the exchange. --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-schema-reg Mon Sep 29 17:40:07 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA18648 for ietf-schema-reg-bks; Mon, 29 Sep 1997 17:40:07 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id RAA18638; Mon, 29 Sep 1997 17:40:02 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id RAA22246; Mon, 29 Sep 1997 17:41:47 -0700 (PDT) Received: from netscape.com ([205.217.228.51]) by dredd.mcom.com (Netscape Messaging Server 3.0) with ESMTP id AAA1326; Mon, 29 Sep 1997 17:41:46 -0700 Message-ID: <34304A90.1BEBA56@netscape.com> Date: Mon, 29 Sep 1997 17:40:48 -0700 From: Tim Howes Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.02 [en] (X11; I; IRIX 6.2 IP22) MIME-Version: 1.0 To: Paul Hoffman / IMC CC: ietf-schema-reg@imc.org Subject: Re: security requirements of the schema listing service References: Your message of "Mon, 29 Sep 1997 19:26:48 EDT." <85256521.0080B545.00@mta2.lotus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Paul Hoffman / IMC wrote: > I think making this a MUST is overkill. Also, without specifying how the > recipient will trust th sender, signing will be useless. Given that we're > using PGP here, there has to be something that describes how the trust > model in RFC 1991 will operate for this protocol. > > I suggest we change: > > >All schema submitted for listing MUST be signed using PGP with the TBD > >signature algorithm. > > To: > > Schema submitted for listing may be signed using PGP/MIME as described in > RFC 2015. Operators MUST be able to accept schema in PGP/MIME messages, > although they do not have to validate the signatures. The method for > validating and determining trust of the signature is outside the scope of > this document and is determined by the parties in the exchange. This wording would make me happier. -- Tim From owner-ietf-schema-reg Tue Sep 30 02:33:11 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id CAA27006 for ietf-schema-reg-bks; Tue, 30 Sep 1997 02:33:11 -0700 (PDT) Received: from europa.salford.ac.uk (europa.salford.ac.uk [146.87.3.2]) by mail.proper.com (8.8.7/8.7.3) with SMTP id CAA26994 for ; Tue, 30 Sep 1997 02:33:04 -0700 (PDT) Received: (qmail 12587 invoked by alias); 30 Sep 1997 09:35:33 -0000 Message-ID: <19970930093533.12586.qmail@europa.salford.ac.uk> Received: (qmail 12578 invoked from network); 30 Sep 1997 09:35:32 -0000 Received: from iti-ash-116.salford.ac.uk (HELO 116.82.SALFORD.AC.UK) (146.87.82.116) by europa.salford.ac.uk with SMTP; 30 Sep 1997 09:35:32 -0000 Comments: Authenticated sender is From: "David Chadwick" Organization: University of Salford To: ietf-schema-reg@imc.org, Paul Hoffman / IMC Date: Tue, 30 Sep 1997 10:32:38 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: security requirements of the schema listing service Reply-to: D.W.Chadwick@iti.salford.ac.uk In-reply-to: References: <2045.875577831@folder.critical-angle.com> X-mailer: Pegasus Mail for Windows (v2.50) Sender: owner-ietf-schema-reg@imc.org Precedence: bulk > From: Paul Hoffman / IMC > I suggest we change: > > >All schema submitted for listing MUST be signed using PGP with the TBD > >signature algorithm. > > To: > > Schema submitted for listing may be signed using PGP/MIME as described in > RFC 2015. Operators MUST be able to accept schema in PGP/MIME messages, > although they do not have to validate the signatures. The method for > validating and determining trust of the signature is outside the scope of > this document and is determined by the parties in the exchange. > I agree with the sentiments of this, and would add: the method for determining trust in an unsigned listing request is outside the scope of this document, as is the method for determining trust in the list itself. David *************************************************** David Chadwick IT Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 370 957 287 Email D.W.Chadwick@iti.salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm *************************************************** From owner-ietf-schema-reg Tue Sep 30 09:07:27 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA04271 for ietf-schema-reg-bks; Tue, 30 Sep 1997 09:07:27 -0700 (PDT) Received: from i.control.att.com ([135.205.52.126]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA04264; Tue, 30 Sep 1997 09:07:23 -0700 (PDT) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Tue, 30 Sep 1997 12:09:21 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for D.W.Chadwick@iti.salford.ac.uk; Tue, 30 Sep 1997 12:09:16 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Tue, 30 Sep 1997 12:09:16 -0400 (EDT) From: capple@master.control.att.com (Christopher W Apple) To: D.W.Chadwick@iti.salford.ac.uk, ietf-schema-reg@imc.org, Paul Hoffman / IMC Subject: Re: security requirements of the schema listing service Sender: owner-ietf-schema-reg@imc.org Precedence: bulk >> I suggest we change: >> >> >All schema submitted for listing MUST be signed using PGP with the TBD >> >signature algorithm. >> >> To: >> >> Schema submitted for listing may be signed using PGP/MIME as described in >> RFC 2015. Operators MUST be able to accept schema in PGP/MIME messages, >> although they do not have to validate the signatures. The method for >> validating and determining trust of the signature is outside the scope of >> this document and is determined by the parties in the exchange. >> > >I agree with the sentiments of this, and would add: > >the method for determining trust in an unsigned listing request is >outside the scope of this document, as is the method for determining >trust in the list itself. Thanks for the replacement text. I'll make the change it. There are a number of other changes I'll propose to the list later today (based on private comments and discussions on the engineering team). Chris Apple Internet Directory Group AT&T Laboratories capple@master.control.att.com +1 908 582 2409 From owner-ietf-schema-reg Wed Oct 1 00:05:04 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id AAA14832 for ietf-schema-reg-bks; Wed, 1 Oct 1997 00:05:04 -0700 (PDT) Received: from lotus.lotus.com (lotus.com [192.233.136.1]) by mail.proper.com (8.8.7/8.7.3) with SMTP id AAA14824 for ; Wed, 1 Oct 1997 00:04:57 -0700 (PDT) From: Frank_Dawson/CAM/Lotus@lotus.com Received: from internet2.lotus.com by lotus.lotus.com (SMI-8.6/SMI-SVR4) id DAA06849; Wed, 1 Oct 1997 03:04:12 -0400 Received: from mta2.lotus.com by internet2.lotus.com (5.x/SMI-SVR4) id AA14138; Wed, 1 Oct 1997 02:59:11 -0400 Received: by mta2.lotus.com(Lotus SMTP MTA SMTP v4.6 (462.2 9-3-1997)) id 85256523.002B37D2 ; Wed, 1 Oct 1997 03:07:47 -0400 X-Lotus-Fromdomain: LOTUS@MTA To: D.W.Chadwick@iti.salford.ac.uk Cc: ietf-schema-reg@imc.org Message-Id: <85256522.003EA806.00@mta2.lotus.com> Date: Tue, 30 Sep 1997 07:25:49 -0400 Subject: Re: security requirements of the schema listing service Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-schema-reg@imc.org Precedence: bulk David Chadwick wrote, in part: "the method for determining trust in an unsigned listing request is outside the scope of this document, as is the method for determining trust in the list itself." Okay, so it sounds like this whole security thing for submittal is really outside the scope of this document... -- Frank From owner-ietf-schema-reg Wed Oct 1 22:51:58 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id WAA00537 for ietf-schema-reg-bks; Wed, 1 Oct 1997 22:51:58 -0700 (PDT) Received: from i.control.att.com ([135.205.52.126]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id WAA00533 for ; Wed, 1 Oct 1997 22:51:53 -0700 (PDT) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Thu, 2 Oct 1997 01:53:55 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for ietf-schema-reg@imc.org; Thu, 2 Oct 1997 01:53:54 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Thu, 2 Oct 1997 01:53:54 -0400 (EDT) From: capple@master.control.att.com (Christopher W Apple) To: ietf-schema-reg@imc.org Subject: rqmts doc status Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Below is a list of changes I plan on making to the requirements document unless there are a lot of strong objections. These items were collected from (my perception of) concensus on recent mailing list security and trust discussions as well as engineering team discussions aimed at expediting service deployment. I plan on starting in with the mods to the document early next week. So, if you want more clarification on any of these items or think something should be handled differently than described, please post it to the list. Chris A. 1) Meta data syntax should be moved out to a separate document and replaced with a requirement that the meta data should be parsable. Rationale: The requirements for the service are likely to be more stable over time than will the meta data elements and their syntax. Moving them out to a separate document lets us change the meta data evolve, as we gain experience using and running the service without having to drag the the entire requirements document into a revision cycle. 2) Do not use MLSF to represent meta data in different languages. Rationale: The author of the MLSF draft does not plan on progressing the draft further. UTF-8 in base64 or UTF-7 with RFC 1766 language tags is sufficient and can be transported using an appropriate MIME construct. 3) Do not place a strong requirement on signing schema listing requests. Rationale: See the mailing list archive. Look for the thread on security considerations. 4) Don't specify listing content syntax in the requirements document. Replace with a Rationale: Similar to that for 1, above. Also, instead of using requiring LDIF, XML, or ASN.1 use: + the MIME-DIR profile for transporting schema listing content intended for use in LDAP implementations + other yet-to-be-defined MIME-DIR profiles for transporting schema listing content intended for use in whois, whois++, rwhois, etc. implementations 5) Change appropriate text in the requirements document to reflect a willingness to supply OIDs used as a schema names for schema writers who are unable to obtain one on their own: + change example in usage scenarios section + modify requirements to reflect that schema writers MAY supply the OID and that the primary repository operator MUST if the writer does not do so Rationale: Correct discrepancy between the -01.txt rev of the requirements document and the Munich BOF minutes. 6) Change appropriate text in the document so that the "owner" of a schema listing can be either the person who submitted it or the organization to which they belong. This also means that we should allow the e-mail address meta data element to be multi-valued to allow for different or identical e-mails for the contact person for a listed schema. Rationale: Allows different people at the same organization to be the schema 'czar' for a particular listing or set of listings. Allows one person organizations to publish schema listings (by allowing an organizational e-mail address and a listing contact person e-mail address to be the same or different). 7) Change the language that specifies that ownership of the listing data cannot be claimed to simply state that a free means of accessing the service (for both requests and retrievals MUST be provided by all listing repository providers, primary and mirrored. Rationale: A WG/BOF cannot sign a contract and what's there sounds suspiciously like legalese that the document editor is not qualified to write. 8) Add language to document constraints on use of a moderated mailing list (similar to MIME registration) used for public review of the listing requests. Allow 2 week review period on list; if no comments are made, schema is listed. Otherwise, request is either denied or schema is listed subject to comments. Rationale: Multi-language meta data, quality of schema listing content, and proper listing request format need a quick public review. 9) Corrections to the BNF grammars in the document (to be moved into a separate document). Rationale: Editorial comments were received privately from Leslie Daigle. 10) Clarify scope section to make it clearer that the document is limited to requirements associated with the _initial_ deployment of a listing service. Rationale: Lots of hard-coded choices have been reflected in the requirements document for the purposes of expediting deployment. Future releases of the service may require an update of the requirements document. 11) Document needs to be scrubbed to ensure consistent use of Scott Bradner's requirements specification terminology as well as of the terms and definitions described in the requirements document itself. Rationale: Several private and public comments were received which point to potentially inconsistent use of such terminology. 12) Rework the security considerations section to reflect text changes and discussion on the mailing list: + buyer beware w.r.t. the authenticity of the listing meta data and listing content + methods of establishing, validating, and determining trust w.r.t. various methods of service access (listing request, listing retrieval, etc.) are outside of the scope of the document + schema writers may PGP-sign listing requests + listing repository operators must accept PGP-signed listing requests, but are not required to validate them (there are better words posted by Paul Hoffman, David Chadwick, and Mark Wahl in the mailing list archive that I'll actually use as replacement text) Rationale: Current section is overkill. We can cope with bugs that bite in bed and there are only moderately large dust bunnies under it. Add contextual definitions for commonly-used security keywords. From owner-ietf-schema-reg Thu Oct 2 13:14:29 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA11963 for ietf-schema-reg-bks; Thu, 2 Oct 1997 13:14:29 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.29]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA11957 for ; Thu, 2 Oct 1997 13:14:11 -0700 (PDT) Received: by mail4.microsoft.com with Internet Mail Service (5.5.1664.3) id ; Thu, 2 Oct 1997 13:18:41 -0700 Message-ID: From: Chris Weider To: "'Tim Howes'" , Mark Wahl Cc: ietf-schema-reg@imc.org Subject: RE: security requirements of the schema listing service Date: Thu, 2 Oct 1997 13:16:44 -0700 X-Mailer: Internet Mail Service (5.5.1664.3) Sender: owner-ietf-schema-reg@imc.org Precedence: bulk I've come around to agreeing with this position. The review process should be enough to avoid bogosity. Chris > -----Original Message----- > From: Tim Howes [SMTP:howes@netscape.com] > Sent: Monday, September 29, 1997 5:16 PM > To: Mark Wahl > Cc: ietf-schema-reg@imc.org > Subject: Re: security requirements of the schema listing service > > Well, apparently it's been a while since I got a domain name! :) > > I can buy that we should be moving toward offering more security. > But we need to be realistic about 1) the types of threats we're likely > to see; 2) the consequences of those threats; and 3) how hard it is to > recover from a security breech (has there been irreparable damage). > > I'm not convinced we've passed the "something really bad happens > if we don't do this" test. I believe this will be a significant > barrier > to schema publication. -- > Tim > > Mark Wahl wrote: > > > > What problem is all this security trying to solve? > > > > Allow submitters of schemas to be able to maintain their listings. > > > > Allow schema information retrieved from the service to be processed > > automatically. > > > > Eliminate certain classes of security threats to submitters, service > users, > > and the listing servers themselves. > > > > Reduce the number of operations in the schema listing service which > require > > human interaction. > > > > > Does any other registration mechanism have anything even remotely > like this? > > > > DNS, for one. > > > > InterNIC domain registration template > > If a Contact of the Domain has previously used the Contact > Template to > > specify the use of Pretty Good Privacy (PGP) or encrypted > password, the > > authentication scheme and information associated with it should > be > > listed in items 0b and 0c. These items contain the authorization > > information for the sender of an update request and help > determine if > > the request is coming from a valid sender. These items are > REQUIRED > > when a domain is being modified. > > > > RFC 2065 > > The Domain Name System (DNS) has become a critical operational > part > > of the Internet infrastructure yet it has no strong security > > mechanisms to assure data integrity or authentication. > Extensions to > > the DNS are described that provide these services to security > aware > > resolvers or applications through the use of cryptographic > digital > > signatures. These digital signatures are included in secured > zones > > as resource records. Security can still be provided even through > > non-security aware DNS servers in many cases. > > > > Mark Wahl, Enterprise Directory Integration > > Critical Angle Inc. > > From owner-ietf-schema-reg Thu Oct 2 13:29:33 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA12098 for ietf-schema-reg-bks; Thu, 2 Oct 1997 13:29:33 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.29]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA12093 for ; Thu, 2 Oct 1997 13:29:23 -0700 (PDT) Received: by mail4.microsoft.com with Internet Mail Service (5.5.1664.3) id ; Thu, 2 Oct 1997 13:33:46 -0700 Message-ID: From: Chris Weider To: "'capple@master.control.att.com'" , ietf-schema-reg@imc.org Subject: RE: rqmts doc status Date: Thu, 2 Oct 1997 13:31:48 -0700 X-Mailer: Internet Mail Service (5.5.1664.3) Sender: owner-ietf-schema-reg@imc.org Precedence: bulk I think all these changes make sense. Chris > -----Original Message----- > From: capple@master.control.att.com > [SMTP:capple@master.control.att.com] > Sent: Wednesday, October 01, 1997 10:54 PM > To: ietf-schema-reg@imc.org > Subject: rqmts doc status > > Below is a list of changes I plan on making to the requirements > document > unless there are a lot of strong objections. These items were > collected from > (my perception of) concensus on recent mailing list security and trust > discussions as well as engineering team discussions aimed at > expediting service > deployment. > > I plan on starting in with the mods to the document early next week. > So, if > you want more clarification on any of these items or think something > should > be handled differently than described, please post it to the list. > > Chris A. > > 1) Meta data syntax should be moved out to a separate document and > replaced > with a requirement that the meta data should be parsable. > > Rationale: The requirements for the service are likely to be more > stable over time than will the meta data elements and > their syntax. Moving them out to a separate document lets > us change the meta data evolve, as we gain experience > using and running the service without having to drag the > the entire requirements document into a revision cycle. > > > 2) Do not use MLSF to represent meta data in different languages. > > Rationale: The author of the MLSF draft does not plan on > progressing the draft further. UTF-8 in base64 or UTF-7 > with RFC 1766 language tags is sufficient and can be > transported > using an appropriate MIME construct. > > > 3) Do not place a strong requirement on signing schema listing > requests. > > Rationale: See the mailing list archive. Look for the thread on > security > considerations. > > > 4) Don't specify listing content syntax in the requirements document. > Replace > with a > > Rationale: Similar to that for 1, above. Also, instead of using > requiring > LDIF, XML, or ASN.1 use: > > + the MIME-DIR profile for transporting schema listing > content intended for use in LDAP implementations > > + other yet-to-be-defined MIME-DIR profiles for > transporting > schema listing content intended for use in whois, > whois++, > rwhois, etc. implementations > > > 5) Change appropriate text in the requirements document to reflect > a willingness to supply OIDs used as a schema names for schema > writers > who are unable to obtain one on their own: > > + change example in usage scenarios section > > + modify requirements to reflect that schema writers MAY supply > the OID and that the primary repository operator MUST if the > writer does not do so > > Rationale: Correct discrepancy between the -01.txt rev of the > requirements > document and the Munich BOF minutes. > > > 6) Change appropriate text in the document so that the "owner" of a > schema > listing can be either the person who submitted it or the > organization to > which they belong. This also means that we should allow the e-mail > address > meta data element to be multi-valued to allow for different or > identical > e-mails for the contact person for a listed schema. > > Rationale: Allows different people at the same organization to be the > schema > 'czar' for a particular listing or set of listings. Allows > one person > organizations to publish schema listings (by allowing an > organizational e-mail address and a listing contact person > e-mail > address to be the same or different). > > > 7) Change the language that specifies that ownership of the listing > data cannot be claimed to simply state that a free means of > accessing the > service (for both requests and retrievals MUST be provided by all > listing > repository providers, primary and mirrored. > > Rationale: A WG/BOF cannot sign a contract and what's there sounds > suspiciously > like legalese that the document editor is not qualified to > write. > > > 8) Add language to document constraints on use of a moderated mailing > list > (similar to MIME registration) used for public review of the > listing > requests. Allow 2 week review period on list; if no comments are > made, > schema is listed. Otherwise, request is either denied or schema is > listed > subject to comments. > > Rationale: Multi-language meta data, quality of schema listing > content, > and proper listing request format need a quick public review. > > > 9) Corrections to the BNF grammars in the document (to be moved into a > separate document). > > Rationale: Editorial comments were received privately from Leslie > Daigle. > > > 10) Clarify scope section to make it clearer that the document is > limited to > requirements associated with the _initial_ deployment of a listing > service. > > Rationale: Lots of hard-coded choices have been reflected in the > requirements > document for the purposes of expediting deployment. Future > releases of the service may require an update of the > requirements > document. > > > 11) Document needs to be scrubbed to ensure consistent use of Scott > Bradner's > requirements specification terminology as well as of the terms and > definitions described in the requirements document itself. > > Rationale: Several private and public comments were received which > point to > potentially inconsistent use of such terminology. > > > 12) Rework the security considerations section to reflect text changes > and discussion on the mailing list: > > + buyer beware w.r.t. the authenticity of the listing meta data > and listing > content > > + methods of establishing, validating, and determining trust > w.r.t. various > methods of service access (listing request, listing retrieval, > etc.) are > outside of the scope of the document > > + schema writers may PGP-sign listing requests > > + listing repository operators must accept PGP-signed listing > requests, but > are not required to validate them > > (there are better words posted by Paul Hoffman, David Chadwick, > and Mark Wahl > in the mailing list archive that I'll actually use as > replacement text) > > Rationale: Current section is overkill. We can cope with bugs that > bite in bed > and there are only moderately large dust bunnies under it. > > Add contextual definitions for commonly-used security > keywords. From owner-ietf-schema-reg Mon Oct 6 10:17:15 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA13459 for ietf-schema-reg-bks; Mon, 6 Oct 1997 10:17:15 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.29]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA13453; Mon, 6 Oct 1997 10:17:11 -0700 (PDT) Received: by mail4.microsoft.com with Internet Mail Service (5.5.1664.3) id ; Mon, 6 Oct 1997 10:21:26 -0700 Message-ID: <21FD6499922DD111A4F600805FCCD6F23FAD9D@RED-86-MSG.dns.microsoft.com> From: Don Schmidt To: capple@master.control.att.com, D.W.Chadwick@iti.salford.ac.uk, ietf-schema-reg@imc.org, Paul Hoffman / IMC Subject: RE: security requirements of the schema listing service Date: Mon, 6 Oct 1997 10:19:58 -0700 X-Mailer: Internet Mail Service (5.5.1664.3) Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Leaving the validation of signatures (thus issues of trust) to the producer and consumer of a listing is clearly a significant simplification that will enable deployment on the stated timetable. However, it does not address change control. There is no way for the service to verify an update should be allowed to replace the current listing; nor is there any way for a consumer to be sure the service has posted the latest listing - or is in fact the valid listing service. This was the major area of concern at Munich that provoked the security considerations in the draft. If the scope/charter has been redefined such that robust change control is no longer relevant, then the proposed changes make sense. So could we have a clear statement of the requirements in this area? Otherwise, eliminating trust features because they are too complicated or will take too long does not seem appropriate. des Don Schmidt Program Mgr Microsoft Corp > -----Original Message----- > From: capple@master.control.att.com > [SMTP:capple@master.control.att.com] > Sent: Tuesday, September 30, 1997 9:09 AM > To: D.W.Chadwick@iti.salford.ac.uk; ietf-schema-reg@imc.org; Paul > Hoffman / IMC > Subject: Re: security requirements of the schema listing service > > >> I suggest we change: > >> > >> >All schema submitted for listing MUST be signed using PGP with the > TBD > >> >signature algorithm. > >> > >> To: > >> > >> Schema submitted for listing may be signed using PGP/MIME as > described in > >> RFC 2015. Operators MUST be able to accept schema in PGP/MIME > messages, > >> although they do not have to validate the signatures. The method > for > >> validating and determining trust of the signature is outside the > scope of > >> this document and is determined by the parties in the exchange. > >> > > > >I agree with the sentiments of this, and would add: > > > >the method for determining trust in an unsigned listing request is > >outside the scope of this document, as is the method for determining > >trust in the list itself. > > Thanks for the replacement text. I'll make the change it. There are a > number of > other changes I'll propose to the list later today (based on private > comments and > discussions on the engineering team). > > > Chris Apple > Internet Directory Group > AT&T Laboratories > capple@master.control.att.com > +1 908 582 2409 From owner-ietf-schema-reg Tue Oct 7 06:10:04 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id GAA00115 for ietf-schema-reg-bks; Tue, 7 Oct 1997 06:10:04 -0700 (PDT) Received: from lotus.lotus.com (lotus.com [192.233.136.1]) by mail.proper.com (8.8.7/8.7.3) with SMTP id GAA29998; Tue, 7 Oct 1997 06:09:43 -0700 (PDT) From: Frank_Dawson/CAM/Lotus@lotus.com Received: from internet2.lotus.com by lotus.lotus.com (SMI-8.6/SMI-SVR4) id JAA28674; Tue, 7 Oct 1997 09:09:25 -0400 Received: from mta2.lotus.com by internet2.lotus.com (5.x/SMI-SVR4) id AA20538; Tue, 7 Oct 1997 09:05:46 -0400 Received: by mta2.lotus.com(Lotus SMTP MTA SMTP v4.6 (462.2 9-3-1997)) id 85256529.0048B5EC ; Tue, 7 Oct 1997 09:14:11 -0400 X-Lotus-Fromdomain: LOTUS@MTA To: Don Schmidt Cc: capple@master.control.att.com, D.W.Chadwick@iti.salford.ac.uk, ietf-schema-reg@imc.org, "Paul Hoffman / IMC" Message-Id: <85256529.00488A1C.00@mta2.lotus.com> Date: Tue, 7 Oct 1997 09:15:04 -0400 Subject: RE: security requirements of the schema listing service Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Don Schmidt, wrote in part: "Leaving the validation of signatures (thus issues of trust) to the producer and consumer of a listing is clearly a significant simplification that will enable deployment on the stated timetable. However, it does not address change control. There is no way for the service to verify an update should be allowed to replace the current listing; nor is there any way for a consumer to be sure the service has posted the latest listing - or is in fact the valid listing service. This was the major area of concern at Munich that provoked the security considerations in the draft." There are numerous ways that the listing authority can verify the authenticity of the submitting party. They can also verify that the submitter is the same as the submitter of the original schema application. All of this can be done via nominal office communication techniques; without *requiring* the use of signed/encrypted email messages. - - Frank From owner-ietf-schema-reg Tue Oct 7 12:22:24 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA06471 for ietf-schema-reg-bks; Tue, 7 Oct 1997 12:22:24 -0700 (PDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.23]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA06463; Tue, 7 Oct 1997 12:22:19 -0700 (PDT) Received: by mail3.microsoft.com with Internet Mail Service (5.0.1459.27) id <4L01KMSY>; Tue, 7 Oct 1997 12:26:04 -0700 Message-ID: From: Chris Weider To: "'Frank_Dawson/CAM/Lotus@lotus.com'" , Don Schmidt Cc: capple@master.control.att.com, D.W.Chadwick@iti.salford.ac.uk, ietf-schema-reg@imc.org, Paul Hoffman / IMC Subject: RE: security requirements of the schema listing service Date: Tue, 7 Oct 1997 12:25:03 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1459.27) Sender: owner-ietf-schema-reg@imc.org Precedence: bulk What do you mean by 'standard office techniques'? Wouldn't they likely have a much greater overhead than signed mail? Chris > -----Original Message----- > From: Frank_Dawson/CAM/Lotus@lotus.com > [SMTP:Frank_Dawson/CAM/Lotus@lotus.com] > Sent: Tuesday, October 07, 1997 6:15 AM > To: Don Schmidt > Cc: capple@master.control.att.com; D.W.Chadwick@iti.salford.ac.uk; > ietf-schema-reg@imc.org; Paul Hoffman / IMC > Subject: RE: security requirements of the schema listing service > > Don Schmidt, wrote in part: > > "Leaving the validation of signatures (thus issues of trust) to the > producer and consumer of a listing is clearly > a significant simplification that will enable deployment on the stated > timetable. However, it does not > address change control. There is no way for the service to verify an > update should be allowed to replace > the current listing; nor is there any way for a consumer to be sure > the > service has posted the latest > listing - or is in fact the valid listing service. This was the major > area of concern at Munich that provoked > the security considerations in the draft." > > There are numerous ways that the listing authority can verify the > authenticity of the submitting party. They can also verify that the > submitter is the same as the submitter of the original schema > application. > > All of this can be done via nominal office communication techniques; > without *requiring* the use of signed/encrypted email messages. > > - - Frank > From owner-ietf-schema-reg Sat Oct 11 00:23:06 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id AAA11109 for ietf-schema-reg-bks; Sat, 11 Oct 1997 00:23:06 -0700 (PDT) Received: from folder.critical-angle.com (eden-gw.critical-angle.com [206.81.238.241] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with SMTP id AAA11105 for ; Sat, 11 Oct 1997 00:22:55 -0700 (PDT) Received: (qmail 14301 invoked from network); 11 Oct 1997 07:25:03 -0000 Received: from folder.critical-angle.com (206.81.238.241) by folder.critical-angle.com with SMTP; 11 Oct 1997 07:25:03 -0000 From: Mark Wahl To: Chris Weider Cc: capple@master.control.att.com Cc: ietf-asid@umich.edu cc: ietf-schema-reg@imc.org Reply-To: M.Wahl@critical-angle.com Subject: draft proposal for transfer of LDAP schemas in MIME Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_14960659990" Date: Sat, 11 Oct 1997 02:25:02 -0500 Message-ID: <14299.876554702@folder.critical-angle.com> Sender: owner-ietf-schema-reg@imc.org Precedence: bulk This is a multipart MIME message. --==_Exmh_14960659990 Content-Type: text/plain; charset=us-ascii Hello, Attached please find a first draft for a listing content syntax for LDAP schemas, based on the "text/directory" MIME content type. This draft has been sent to the Internet-Drafts repository and should appear in the archives in a few days. This document is primarily intended for use by the components of the Internet schema listing service. As it is based on a MIME type, procedures for transfer, aggregation and signing should be straightforward. This document only provides a specification for the content of a schema definition that would be needed by a directory server to make use of the schema. t does not intend to discuss how a schema should be created, as this is outside of the scope of the listing service. A separate document with guidelines for LDAP schema writers is planned for an LDAP Service Deployment working group. Mark Wahl, Enterprise Directory Integration Critical Angle Inc. --==_Exmh_14960659990 Content-Type: text/plain ; name="draft-wahl-mime-schema-00.txt"; charset=us-ascii Content-Description: draft-wahl-mime-schema-00.txt Content-Disposition: attachment; filename="draft-wahl-mime-schema-00.txt" Network Working Group M. Wahl Request for Comments: DRAFT Critical Angle Inc. October 10, 1997 A MIME Directory Profile for LDAP Schema 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working docu- ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 2. Abstract This document defines a MIME directory profile [1] for holding an LDAP [2] schema. It is intended for communication with the Internet schema listing service [3]. 3. Overview This document defines how a MIME type may be used to transfer a single LDAPv3 schema definition. A schema for use with LDAPv3 consists of any number of object class, attribute type, matching rule and syntax definitions. These concepts are defined in the LDAPv3 protocol definition [2]. The schema may have a numeric OID assigned to it by a schema listing or registration service. A schema may import definitions from another schema. Schema imports are not, however, transitive. For example, a schema may contain a definition for a "modem" object class, which is to be defined as a subclass of the X.521 "device" object class. In this case, the schema must import the definitions of X.521. Wahl Mime Directory Profile for LDAP Schema Page 1 INTERNET-DRAFT draft-wahl-mime-schema-00.txt Oct. 1997 4. The "schema-ldap-0" MIME Directory Profile Registration This profile is identified by the following registration template information. To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME profile "schema-ldap-0" Profile name: schema-ldap-0 Profile purpose: To represent a schema defined for use with LDAPv3 servers. Profile types: SOURCE, ldapSchemas, schemaDesc, attributeTypes, matchingRules, objectClasses, matchingRuleUse, ldapSyntaxes Profile special notes: The charset parameter MUST be present on the MIME content, and the value of this parameter MUST be "utf-8". This ensures that schema values can be used in LDAPv3 attribute values without a character set translation. Neither the "BEGIN" and "END" types nor type grouping are used in contents of this profile. All of the types in this profile with the exception of ldapSchemas may be multi-valued. Each value is present on its own contentline. Values may be present in any order, and need not be arranged by type. The "SOURCE" type is optional, and if values are present they SHOULD be URIs of the "ldap" or "http" forms. If the URI is of the "ldap" form, the object indicated by the URI is a subschema entry. The use of the "http" form is reserved for future applications. In this version of the profile, exactly one value of the ldapSchemas type MUST be present. (Later versions of the profile may permit multiple ldapSchemas values to be present in a content.) Implementors should note that there will likely be values of the profile types in most contents much longer than 76 bytes. In addition, there may be non-ASCII characters and embedded CRLFs inside of values, which could require either quoting of the value or use of a content transfer encoding. If a contentline in a particular content contains a "context" parameter and the value of that parameter is not "ldap", then that contentline SHOULD be ignored. Intended usage: COMMON Wahl Mime Directory Profile for LDAP Schema Page 2 INTERNET-DRAFT draft-wahl-mime-schema-00.txt Oct. 1997 5. MIME Directory Type Registrations This document defines all the types, with the exception of "SOURCE" used in the schema-ldap-0 profile. The "SOURCE" type is defined in [1]. These types are primarily intended for use in the "schema-ldap-0" directory profile, although they may be applicable to other profiles to be defined in the future. 5.1. ldapSchemas To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type ldapSchemas Type name: ldapSchemas Type purpose: To represent the LDAPv3 attribute "ldapSchemas", defined in section A.1. Type encoding: 8bit Type valuetype: text, encoded according to the BNF of section A.4. Type special notes: Each value of this type specifies the contents of an LDAP schema definition. A definition of each object class, attribute, matching rule, matching rule use and syntax referenced in a value of ldapSchemas MUST either be defined in one of the schemas referenced in the "IMPORTS" field, or present in the content containing this value. Intended usage: COMMON 5.2. attributeTypes To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type attributeTypes Type name: attributeTypes Type purpose: To represent the LDAPv3 attribute "attributeTypes", defined in section 5.1.6 of [4]. Type encoding: 8bit Type valuetype: text, encoded according to the BNF of "AttributeTypeDescription" given in section 4.2 of [4]. Type special notes: Each value of the type specifies one LDAPv3 attribute type definition. The syntax and matching rules referenced in a value of attributeTypes MUST either be present in this content, or defined in one of the schemas referenced in the "IMPORTS" field of the ldapSchemas line. Intended usage: COMMON Wahl Mime Directory Profile for LDAP Schema Page 3 INTERNET-DRAFT draft-wahl-mime-schema-00.txt Oct. 1997 5.3. matchingRules To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type matchingRules Type name: matchingRules Type purpose: To represent the LDAPv3 attribute "matchingRules", defined in section 5.1.8 of [4]. Type encoding: 8bit Type valuetype: text, encoded according to the BNF of "MatchingRuleDescription" given in section 4.5 of [4]. Type special notes: Each value of the type specifies one matching rule definition. The syntax reference in a value of matchingRules MUST either be present in this content, or defined in one of the schemas referenced in the "IMPORTS" field of the ldapSchemas line. Intended usage: COMMON 5.4. objectClasses To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type objectClasses Type name: objectClasses Type purpose: To represent the LDAPv3 attribute "objectClasses", defined in section 5.1.7 of [4]. Type encoding: 8bit Type valuetype: text, encoded according to the BNF of "ObjectClassDescription" given in section 4.4 of [4]. Type special notes: Each value of the type specifies one LDAPv3 object class definition. The attributes and object classes referenced in a value of objectClasses MUST either be present in this content, or defined in one of the schema referenced in the "IMPORTS" field of the ldapSchemas line. Intended usage: COMMON 5.5. matchingRuleUse To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type matchingRuleUse Type name: matchingRuleUse Type purpose: To represent the LDAPv3 attribute "matchingRuleUse", defined in section 5.1.9 of [4]. Wahl Mime Directory Profile for LDAP Schema Page 4 INTERNET-DRAFT draft-wahl-mime-schema-00.txt Oct. 1997 Type encoding: 8bit Type valuetype: text, encoded according to the BNF of "MatchingRuleUseDescription" given in section 4.5 of [4]. Type special notes: Each value of the type specifies a relationship between a matching rule and attribute types. The matching rule and attribute types referenced in a value of matchingRuleUse MUST either be present in this content, or defined in one of the schemas referenced in the "IMPORTS" statement of the ldapSchemas line. Intended usage: COMMON 5.6. ldapSyntaxes To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type ldapSyntaxes Type name: ldapSyntaxes Type purpose: To represent the LDAPv3 attribute "ldapSyntaxes", defined in section 5.3.1 of [4]. Type encoding: 8bit Type valuetype: text, encoded according to the BNF of "SyntaxDescription" given in section 4.3.3 of [4]. Type special notes: Each value of this type specifies a single LDAPv3 attribute value syntax. Intended usage: COMMON 5.7. schemaDesc To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type schemaDesc Type name: schemaDesc Type purpose: To represent the LDAPv3 attribute "schemaDesc", defined in section A.3 below. Type encoding: 8bit Type valuetype: text, encoded according to the BNF of section A.4. Type special notes: Each value of this type specifies the descriptive information associated with a schema. Intended usage: COMMON Wahl Mime Directory Profile for LDAP Schema Page 5 INTERNET-DRAFT draft-wahl-mime-schema-00.txt Oct. 1997 6. Example From: Whomever@wherever.com To: Someone@somewhere.com Subject: schema information MIME-Version: 1.0 Message-Id: Content-Type: text/directory; profile="schema-ldap-0", charset="utf-8" Content-Transfer-Encoding: Quoted-Printable ldapSchemas: ( NAME 'bogus schema' CLASSES ( top $ thing ) = ATTRIBUTES ( objectClass $ name ) SYNTAXES ( = 1.3.6.1.4.1.1466.115.121.1.38 $ 1.3.6.1.4.1.1466.115.121.1.15 ) ) attributeTypes: ( 2.5.4.0 NAME 'objectClass' SYNTAX = 1.3.6.1.4.1.1466.115.121.1.38 ) objectClasses: ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass ) attributeTypes: ( 2.5.4.41 NAME 'name' SYNTAX = 1.3.6.1.4.1.1466.115.121.1.15{32768} ) objectClasses: ( 2.5.6.999 NAME 'thing' MUST name ) ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'String' ) ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' ) 7. Security Considerations A MIME body part containing an text/directory of the schema-ldap-0 profile may be incorporated in a digitally signed MIME content, which can be used to verify that the body part has not been modified in transit. When the signer has been certified by a trusted third party service, it may also be possible to verify the origin of the content. 8. Bibliography [1] "A MIME Content-Type for Directory Information", 07/24/1997, INTERNET DRAFT . [2] "Lightweight Directory Access Protocol (v3)", 08/21/1997, INTERNET DRAFT . [3] "Directory Schema Listing Requirements", 08/28/1997, INTERNET DRAFT . [4] "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", 08/21/1997, INTERNET DRAFT . [5] "The LDAP Data Interchange Format (LDIF) - Technical Specification", 07/25/1997, INTERNET DRAFT . Wahl Mime Directory Profile for LDAP Schema Page 6 INTERNET-DRAFT draft-wahl-mime-schema-00.txt Oct. 1997 9. Authors Address Mark Wahl Critical Angle Inc. 4815 West Braker Lane #502-385 Austin, TX 78759 USA Phone: +1 512 372-3160 EMail: M.Wahl@critical-angle.com Appendix A This appendix defines two new attributes which could be present in an subschema entry. These attributes could be added to a future revision of the LDAP attribute definition [4]. A.1. ldapSchemas attribute type definition ( 1.3.6.1.4.1.1466.101.120.17 NAME 'ldapSchemas' SYNTAX 1.3.6.1.4.1.1466.115.121.1.56 USAGE directoryOperation ) Each value of the ldapSchemas attribute defines one schema. Its syntax, given in section A.2, contains the elements needed for an LDAPv3 server to correctly process operations which use the definitions from this syntax. A.2. LDAP Schema Definition syntax definition ( 1.3.6.1.4.1.1466.115.121.1.56 DESC 'LDAP Schema Definition' ) Values in this syntax are represented according to the following BNF: LdapSchema = "(" whsp [numericoid whsp] [ "NAME" qdescrs ] [ "OBSOLETE" whsp ] [ "IMPORTS" oids ] [ "CLASSES" oids ] [ "ATTRIBUTES" oids ] [ "MATCHING-RULES" oids ] [ "SYNTAXES" oids ] whsp ")" The numericoid field, if present, uniquely identifies the schema. A new OID should be assigned if any of the fields of the schema change. It is not possible to import definitions from a schema until an OID has been assigned to it. The "NAME" field contains optional human-readable labels for the schema. The "OBSOLETE" field is present if the schema is obsolete. Wahl Mime Directory Profile for LDAP Schema Page 7 INTERNET-DRAFT draft-wahl-mime-schema-00.txt Oct. 1997 The "IMPORTS" field lists the OIDs of other schemas which are to be incorporated by reference into this schema. It is an error to have an attribute type or object class defined in a schema with the same name but a different OID as an attribute type or object class in an imported schema. It is also an error to import from two schema definitions in which there are attribute types or object classes with the same names but different OIDs. The "CLASSES" field lists the OIDs of object classes defined in this schema. A schema need not contain any object class definitions. A schema must not contain two object class definitions of the same name but with different OIDs. The "ATTRIBUTES" field lists the OIDs of attribute types defined in this schema. A schema need not contain any object class definitions. A schema must not contain two attribute type definitions of the same name but with different OIDs. The "MATCHING-RULES" field lists the OIDs of matching rules defined in this schema. A schema need not contain any matching rules. The "SYNTAXES" field lists the OIDs of syntaxes defined in this schema. A schema need not contain any matching rules. A.3. schemaDesc attribute type description ( 1.3.6.1.4.1.1466.101.120.18 NAME 'schemaDesc' SYNTAX 1.3.6.1.4.1.1466.115.121.1.57 USAGE directoryOperation ) The schemaDesc attribute associates descriptive and meta-data information with a schema definition. This information conveyed by this attribute is intended for use by readers of the schema and by schema manipulation tools, and need not be interpreted by directory servers. A.4. Schema Description syntax definition ( 1.3.6.1.4.1.1466.115.121.1.57 DESC 'LDAP Schema Description' ) Values in this syntax are represented according to the following BNF: SchemaInfo = "(" whsp [numericoid whsp] [ "DESC" qdstring ] whsp ")" Additional fields will be added in future versions of this document, as required by the schema listing service. Wahl Mime Directory Profile for LDAP Schema Page 8 --==_Exmh_14960659990-- From owner-ietf-schema-reg Sat Oct 11 01:07:12 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id BAA11307 for ietf-schema-reg-bks; Sat, 11 Oct 1997 01:07:12 -0700 (PDT) Received: from i.control.att.com ([135.205.52.126]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id BAA11303 for ; Sat, 11 Oct 1997 01:07:08 -0700 (PDT) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Sat, 11 Oct 1997 04:09:18 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for ietf-schema-reg@imc.org; Sat, 11 Oct 1997 04:09:18 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Sat, 11 Oct 1997 04:09:18 -0400 (EDT) From: capple@master.control.att.com (Christopher W Apple) To: internet-drafts@ietf.org Cc: ietf-schema-reg@imc.org Subject: draft-apple-schema-rqmts-list-02.txt Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Please publish this as a replacement for draft-apple-schema-list-01.txt. Thanks. Chris Apple Business Site: AnyWho Directory Services Internet Directory Group http://www.anywho.com AT&T Laboratories capple@master.control.att.com +1 908 582 2409 INTERNET-DRAFT C. Apple AT&T Laboratories Expires: April 11, 1998 11 October 1997 Directory Schema Listing Requirements Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This memo documents requirements for listing directory services schema in a centrally operated, administered, and maintained repository. This repository will be available as a resource to directory protocol and service implementors to facilitate schema discovery. 1.0 Introduction The fastest route to interoperable directory services is through standard object classes and attribute types. There is a growing number of places where schema for Internet Directory Services and Internet Operations are being defined, with varying degrees of documentation. This plethora of schema is unavoidable in the light of the needs of different service communities, but it makes it difficult for directory service builders to find and make use of an existing schema that will serve their needs and increase interoperability with other systems. A listing service providing a single point of discovery for directory service schema will promote schema reuse, reduce duplication of effort, Apple [Page 1] INTERNET-DRAFT Directory Schema Listing Requirements 11 October 1997 and thus promote directory service interoperability. The intent is to offer a schema listing service with public read access and restricted, moderated write access. Many hard-coded choices and constraints have been reflected in this requirements document for the purpose of expediting deployment. Future releases of the service may require an update of this document. Initially, such a listing service will be centrally operated, administered, and maintained. The schema listing repository database may also be mirrored to ensure some level of redundancy for read access in the event of service interruption. Eventually, the operations, administration, and maintenance of such a listing service may evolve to use a more distributed deployment scenario. The schema listing service is also intended to be largely automated, with minimal human involvement. Human involvement is likely to be limited to the following types of activities: + handling repository access problems + trouble resolution for computing and communications facilities + dealing with reasonable requests that fall outside of the scope of normal schema listing repository operations + reviewing schema listing requests on a mailing list prior to publishing in the listing repository Future releases of the service may automate some of these tasks. 1.1 Scope Requirements for the initial release of a directory schema listing service are inside the scope of this document. Specifications for syntaxes and grammars to be used in the initial release of the directory schema listing service are outside the scope of this document. Documentation of schema listing procedures is outside the scope of this document. 1.2 Terms and Definitions Information Object - a descriptive abstraction of some real-world object Schema - a collection of definitions for related information objects Listing Meta Data - characteristics that differentiate one schema from another; used to catalog schema Apple [Page 2] INTERNET-DRAFT Directory Schema Listing Requirements 11 October 1997 Listing Content - a formal specification, using a single type of syntax, of a schema Schema Listing - the combination of listing meta data and all available syntax types of listing content for a particular schema Repository - a database in which schema listings are stored Schema Listing Request - a schema listing formatted using MIME constructs that is submitted for consideration as a schema listing to be published in a repository Operator - an organization that administers and maintains a repository Primary Repository - the repository that masters the schema listings database Shadow Repository - a repository that mirrors the primary repository Contact Person - the name of the individual who holds the authority to update a schema listing and who should be contacted if questions or concerns arise related to a schema listing or schema listing request Listing Authority Contact - the name of the individual who holds authority to replace a contact person; can be either the contact person for a schema listing or an alternate contact within the organization to which the contact person belongs (this allows one person organizations to list schema) The terms for specifying requirement level described in [RFC2119] are used in this document. 1.3 Usage Scenarios 1.3.1 Location and Retrieval of the vCard Schema for LDAPv3 A user of the schema listing service wants to locate a copy of the vCard schema for LDAPv3 so that they can use it in a prototyping project. First, they point their web browser at a schema listing repository web site and download the list of available schema. Next, they use the search command on their browser to locate occurences of the string "vCard". The browser automatically scrolls down to the appropriate place in the list of available schema and the user clicks on a link to view the listing meta data to verify that this is indeed the vCard schema for use with version 3 of the LDAP protocol. Included in the web-based representation of the listing meta data are ftp URLs pointing to available syntaxes for this schema. The user clicks on the link for the syntax that they can use. Apple [Page 3] INTERNET-DRAFT Directory Schema Listing Requirements 11 October 1997 1.3.2 Submission of a New Schema Listing via SMTP A schema writer wishes to list a schema they have created and prepares the listing meta data and listing content according to appropriate syntax specifications. However, the schema writer does not currently have an OID at which to root this schema. The schema writer may apply for and obtain an OID through channels other than the schema listing service. However, if the schema writer is unable or does not wish to independently obtain an OID, the primary listing repository operator will supply one. Once this OID is available for use, the schema writer or the listing repository operator incorporates it into the listing meta data and submits an SMTP message includeing the listing meta data and all available syntaxes of the listing content in multipart-mixed MIME format to a listing request review mailing list. After a short review period, the listing repository operator validates the request, and if properly formed, assigns a unique serial number to the listing and publishes it according to the listing procedures. An announcement of the newly published schema listing is sent to a mailing list reserved for this purpose. 2.0 Listing Service Requirements 2.1 Functional Requirements Listed schema MAY be published as an RFC. A list of available schema listings MUST be maintained. Schema MUST be named according to the namespace defined in section 3. Schema listings MUST be identifiable by a unique serial number. The listing service SHALL also maintain information about the schema, beyond its definition. This information is referred to as meta data and will consist of information used for cataloging schema in the listing repositories. The particular set of meta data elements used during the initial deployment of the listing service are outside of the scope of this document. Listing meta data and listing content MUST be parsable. 2.2 Operational Requirements The process of listing schema MUST be centralized for the initial deployment. Apple [Page 4] INTERNET-DRAFT Directory Schema Listing Requirements 11 October 1997 Updated schema listings SHALL be deprecated. A new serial number SHALL be generated for each schema listing that results in the deprecation of an existing schema listing. Schema listing serial numbers MUST NOT be recycled or re-used. The listing repository MUST be centrally administered. The listing repository MAY be mirrored. Schema listing requests MAY be signed using PGP/MIME as described in [RFC2015]. The primary listing repository operator MUST be able to accept schema listing requests in PGP/MIME messages, although they are NOT REQUIRED to validate the signatures. The method for validating and determining trust of signatures is outside the scope of this document and is determined by the parties in the exchange. The method for determining and validating trust in an unsigned request is outside the scope of this document, as is the method for determining trust in schema listing repository or its content. A mailing list MUST be created for the purpose of submitting schema listing requests for publishing in the schema listing repository. The schema listing repository MUST be moderated via this mailing list. Schema listing requests MUST be subjected to community review on this mailing list for a period of at least 2 weeks. If no comments are received, properly formed schema SHALL be listed as requested; otherwise, the request MAY either denied or the schema MAY listed subject to incorporation of comments. A mailing list MUST be created for announcing new and updated schema listings. A mailbox MUST be created for the purpose of receiving service trouble requests from users. Listing repository operators (of primary and shadow sites) MUST provide a free means of accessing the listing service consistent with the functions documented in paragraph 2.3. 2.3 Repository Access Functionality The following schema listing repository access protocols MUST be supported: FTP [RFC959], HTTP 1.1[RFC2044], and SMTP [RFC821]. The following access functions are REQUIRED: a) obtain schema listing content Apple [Page 5] INTERNET-DRAFT Directory Schema Listing Requirements 11 October 1997 b) obtain schema listing meta data c) browse schema listing meta data d) browse schema listing content e) obtain a list of available schema listings f) browse a list of available schema listings g) search a list of available schema listings h) add a schema listing i) update a schema listing The following access functions MAY be supported: a) search schema listing content b) search schema listing meta data 3.0 Listing Service Namespace The listing service namespace MUST be protocol-independent. Names constructed using the listing service namespace MUST be permanent, globally unique, and publicly available. The listing name MUST be the OID at which the schema is rooted. Consider the following example of a schema name for the vCard schema [VCARD]: 1.3.6.1.4.1.2309.1.1.1.1 4.0 Listing Requirements Listing content SHALL be limited to the information actually required to specify the schema. Listing meta data SHALL be composed of information used to catalog schema listings. Meta data element syntax SHALL be defined based on the concept of tagged attribute type-value pairs. Language tags as specified in [RFC1766] MUST be used in listing content and meta data. Meta data element values MUST be encoded using the UCS Transformation Format - 8 bit form [RFC2044]. For the purposes of submitting a listing request, listing content and meta data SHOULD be structured according to appropriate MIME type definitions [MIME]. Apple [Page 6] INTERNET-DRAFT Directory Schema Listing Requirements 11 October 1997 5.0 Listing Storage Requirements Listing file names MUST be permanent, globally unique, and publicly available. Listing content and listing meta data MUST be stored in separate files. 6.0 Security Considerations 6.1 Compromisable Assets One or more of the following assets could be compromised if the service is attacked: + Listing meta data + Listing content + Repository Hardware & Software + Networking Facilities Connecting Repository to the Internet + Repository Mirror Sites 6.2 Attack Scenarios Allowable methods for submitting schema listing requests are: a) sending an e-mail message to a mail box b) submitting requests using web-based forms Based on these request submission methods, there are a number of known repository attack scenarios that must be considered during the implementation of schema listing procedures and the software and operational processes required to support them. 6.2.1 Denial-of-Service Attack Scenarios Scenario A: someone could send in a large number of improperly formed requests Scenario B: someone could send in a large number of properly formed, but frivolous, useless, or trivial requests 6.2.2 Confuse-the-User Attack Scenarios Scenario A: someone could send in a large number of valid, but frivolous, useless, or trivial requests and some or all of these requests actually become listings in the repository Scenario B: someone could maliciously submit one or more slightly Apple [Page 7] INTERNET-DRAFT Directory Schema Listing Requirements 11 October 1997 modified versions of existing schema listings which are popular or widely used 6.3 Security Requirements on Schema Listing Procedures The following contextual definitions apply to the requirements listed in the remainder of this paragraph: Verification - a process of determining authenticity of facts implied or explicitly specified by a contact person during the process of submitting a schema listing request; the methods used to implement such a process MAY or MAY NOT be based on an IETF-sanctioned security protocol; specification of the methods used to implement such a process as well as the trust relationships relevant to the process are outside the scope of this document. High-Quality Directory Schema - a directory schema that serves some useful purpose (e.g., a related set of attribute and object class definitions for holding information about people in a LDAP directory); a schema that is _not_ merely trivial or frivolous (e.g., a trivial schema might consist of a related set of attribute and object class definitions for holding information about the two possible binary bit values in a directory). The schema listing procedures SHOULD be designed to enable: a) verification that all properly formed schema listing requests are submitted by the contact person claiming to originate them c) methods of ensuring that only properly-formed, high-quality directory schema are published in the schema listing repository d) verifcation that requests to change the identity of the contact person for a schema listing originate from the listing authority contact e) coping with the situation in which the contact person and/or listing authority contact for a schema is no longer available or is unable to submit updates to the schema listing for which they hold update authority 7.0 Acknowledgements Leslie Daigle of Bunyip Information Systems and Chris Weider of Microsoft provided valuable comments on multiple versions of this document. The engineering team for listing service requirements: Apple [Page 8] INTERNET-DRAFT Directory Schema Listing Requirements 11 October 1997 Sanjay Jain - Oracle Michael Mealling - NSI John Strassner - Cisco Sam Sun - CNRI Mark Wahl - Critical Angle Chris Weider - Microsoft The members of the ietf-schema-reg@imc.org mailing list. 8.0 References [CHARSET] Internet Assigned Numbers Authority, "CHARACTER SETS", . [LDAPV3] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol (Version 3)", INTERNET-DRAFT , July 1997. [MIME] [RFC2045], [RFC2046], and [RFC2047]. [RFC821] J. Postel, "Simple Mail Transfer Protocol", RFC 821, Aug-01- 1982. [RFC959] J. Postel, J.K. Reynolds, "File Transfer Protocol", RFC 959, Oct-01-1985. [RFC1766] H. Alvestrand, "Tags for the Identification of Languages", RFC 1766, March 1995. [RFC2015] M. Elkins, "MIME Security with Pretty Good Privacy (PGP)", RFC 2015, October 1996. [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Level", March 1997. [RFC2068] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997. [RFC2044] F. Yergeau, "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, October 1996. [RFC2045] N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC2046] N. Freed & N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. Apple [Page 9] INTERNET-DRAFT Directory Schema Listing Requirements 11 October 1997 [RFC2047] K. Moore, "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996. [VCARD] F. Dawson, M. O'Brien, "The vCard Schema For Use In LDAPv3", INTERNET-DRAFT , July 1997. 9.0 Author's Address Chris Apple AT&T Laboratories 600 - 700 Mountain Ave., Room 2F-165 Murray Hill, NJ 07974-0636 USA E-Mail: capple@att.com Phone: +1 908 582 2409 FAX: +1 908 582 3296 This INTERNET-DRAFT expires on April 11, 1998. Apple [Page 10] From owner-ietf-schema-reg Sat Oct 11 01:17:39 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id BAA11379 for ietf-schema-reg-bks; Sat, 11 Oct 1997 01:17:39 -0700 (PDT) Received: from i.control.att.com ([135.205.52.126]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id BAA11375 for ; Sat, 11 Oct 1997 01:17:35 -0700 (PDT) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Sat, 11 Oct 1997 04:19:46 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for ietf-schema-reg@imc.org; Sat, 11 Oct 1997 04:19:46 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Sat, 11 Oct 1997 04:19:46 -0400 (EDT) From: capple@master.control.att.com (Christopher W Apple) To: internet-drafts@ietf.org Cc: ietf-schema-reg@imc.org Subject: Re: draft-apple-schema-rqmts-list-02.txt Sender: owner-ietf-schema-reg@imc.org Precedence: bulk >Please publish this as a replacement for draft-apple-schema-list-01.txt. Sorry, that should have been: draft-apple-schema-rqmts-list-01.txt. Chris Apple Business Site: AnyWho Directory Services Internet Directory Group http://www.anywho.com AT&T Laboratories capple@master.control.att.com +1 908 582 2409 From owner-ietf-schema-reg Sat Oct 11 01:26:20 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id BAA11422 for ietf-schema-reg-bks; Sat, 11 Oct 1997 01:26:20 -0700 (PDT) Received: from i.control.att.com ([135.205.52.126]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id BAA11418 for ; Sat, 11 Oct 1997 01:26:15 -0700 (PDT) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Sat, 11 Oct 1997 04:28:57 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for ietf-schema-reg@imc.org; Sat, 11 Oct 1997 04:28:56 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Sat, 11 Oct 1997 04:28:56 -0400 (EDT) From: capple@master.control.att.com (Christopher W Apple) To: ietf-schema-reg@imc.org Subject: Re: draft-apple-schema-rqmts-list-02.txt Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Three additional documents will follow: + meta data syntax + file name syntax + schema listing procedures The first two are almost complete (they were moved out of the requirements document) and the third has been reviewed by the engineering team. I plan on sending them to the I-D Editor by wednesday, 10/15/97. Chris Apple Business Site: AnyWho Directory Services Internet Directory Group http://www.anywho.com AT&T Laboratories capple@master.control.att.com +1 908 582 2409 From owner-ietf-schema-reg Wed Oct 15 14:23:06 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA08398 for ietf-schema-reg-bks; Wed, 15 Oct 1997 14:23:06 -0700 (PDT) Received: from i.control.att.com ([135.205.52.126]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA08390 for ; Wed, 15 Oct 1997 14:23:01 -0700 (PDT) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Wed, 15 Oct 1997 17:25:30 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for michaelm@rwhois.net; Wed, 15 Oct 1997 17:25:29 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Wed, 15 Oct 1997 17:25:29 -0400 (EDT) From: capple@master.control.att.com (Christopher W Apple) To: internet-drafts@ietf.org Cc: michaelm@rwhois.net, ietf-schema-reg@imc.org Subject: draft-apple-schema-file-list-00.txt Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Please publish the following Internet-Draft. Thanks! ------------------------------------------------------------------------ Chris Apple Business Site: AnyWho Directory Services Internet Directory Group http://www.anywho.com AT&T Laboratories capple@master.control.att.com +1 908 582 2409 Tired of slow directories? Try AnyWho. ------------------------------------------------------------------------ INTERNET-DRAFT C. Apple AT&T Laboratories Expires: April 15, 1998 15 October 1997 Directory Schema Listing Requirements Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This memo specifies a file name syntax for use by the primary listing repository operator of the directory schema listing service. 1.0 Introduction The fastest route to interoperable directory services is through standard object classes and attribute types. There is a growing number of places where schema for Internet Directory Services and Internet Operations are being defined, with varying degrees of documentation. This plethora of schema is unavoidable in the light of the needs of different service communities, but it makes it difficult for directory service builders to find and make use of an existing schema that will serve their needs and increase interoperability with other systems. A listing service providing a single point of discovery for directory service schema will promote schema reuse, reduce duplication of effort, and thus promote directory service interoperability. Schema listings will be stored in multiple files based on the different types of information associated with a listing: meta data and one or more syntax Apple [Page 1] INTERNET-DRAFT Directory Schema Listing File Name Syntax 15 October 1997 specifications. 1.1 Scope A file name syntax specification intended for use during the initial release of a directory schema listing service is inside the scope of this document. 1.2 Terms and Definitions Information Object - a descriptive abstraction of some real-world object Schema - a collection of definitions for related information objects Listing Meta Data - characteristics that differentiate one schema from another; used to catalog schema Listing Content - a formal specification, using a single type of syntax, of a schema Schema Listing - the combination of listing meta data and all available syntax types of listing content for a particular schema The terms for specifying requirement level described in [RFC2119] are used in this document. 2.0 File Name Syntax All file names for listing meta data and listing content MUST comply with the following BNF [RFC822] grammar: file-name = "schema-" sequence "-" type ".txt" type = "metadata" / "ldap" / "whoispp" sequence = NZDIGIT 0* ; initialized to one (1) for first ; schema listing ; increments by one (1) for each ; successive schema listing published NZDIGIT = DIGIT = Other possible values of the type component of a file name MAY be defined in the future to accomodate schema listings with syntaxes other Apple [Page 2] INTERNET-DRAFT Directory Schema Listing File Name Syntax 15 October 1997 than those relevant to LDAP [LDAPV3] and WHOIS++ [RFC1835]. 3.0 Security Considerations There are no known security concerns associated with the file name syntax specified in this document. 4.0 Acknowledgements Leslie Daigle of Bunyip Information Systems reviewed and provided valuable comments on the syntax specification content in this document. 5.0 References [LDAPV3] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol (Version 3)", INTERNET-DRAFT , August 1997. [RFC822] D. Crocker, "Standard of the Format of ARPA-Internet Text Messages", STD 11, RFC 822, August 1982. [RFC1835] P. Deutsch, R. Schoultz, P. Faltstrom, C. Weider, "Architecture of the WHOIS++ Service", August, 1995. [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Level",March 1997. 6.0 Author's Address Chris Apple AT&T Laboratories 600 - 700 Mountain Ave., Room 2F-165 Murray Hill, NJ 07974-0636 USA E-Mail: capple@att.com Phone: +1 908 582 2409 FAX: +1 908 582 3296 This INTERNET-DRAFT expires on April 15, 1998. Apple [Page 3] From owner-ietf-schema-reg Wed Oct 15 14:48:53 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA08785 for ietf-schema-reg-bks; Wed, 15 Oct 1997 14:48:53 -0700 (PDT) Received: from i.control.att.com ([135.205.52.126]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA08781 for ; Wed, 15 Oct 1997 14:48:49 -0700 (PDT) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Wed, 15 Oct 1997 17:51:48 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for michaelm@rwhois.net; Wed, 15 Oct 1997 17:51:47 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Wed, 15 Oct 1997 17:51:47 -0400 (EDT) From: capple@master.control.att.com (Christopher W Apple) To: ietf-schema-reg@imc.org Cc: michaelm@rwhois.net Subject: wrong title Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Sorry for this, but the title in the I-D just sent to the list was incorrect. I've sent a note to the I-D editor asking for a correction prior to being published officially. The correct title is: Directory Schema Listing File Name Syntax. ------------------------------------------------------------------------ Chris Apple Business Site: AnyWho Directory Services Internet Directory Group http://www.anywho.com AT&T Laboratories capple@master.control.att.com +1 908 582 2409 Tired of slow directories? Try AnyWho. ------------------------------------------------------------------------ From owner-ietf-schema-reg Thu Oct 16 03:23:45 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id DAA18697 for ietf-schema-reg-bks; Thu, 16 Oct 1997 03:23:45 -0700 (PDT) Received: from i.control.att.com ([135.205.52.126]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id DAA18693 for ; Thu, 16 Oct 1997 03:23:41 -0700 (PDT) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Thu, 16 Oct 1997 06:26:42 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for michaelm@rwhois.net; Thu, 16 Oct 1997 06:26:41 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Thu, 16 Oct 1997 06:26:41 -0400 (EDT) From: capple@master.control.att.com (Christopher W Apple) To: ietf-schema-reg@imc.org Cc: michaelm@rwhois.net, cweider@microsoft.com Subject: pre-I-D meta data syntax spec Sender: owner-ietf-schema-reg@imc.org Precedence: bulk This has not been sent to the Internet-Drafts Editor yet. I'd like comments on it quickly before doing so. The reason that this looks so different than the meta data sytnax spec that was cut out of the requirements document is that there is an actual file format specification for the meta data included. This is also why it took longer than planned. While writing this spec, I discovered a few problems with the requirements spec and the file name syntax spec, so both will have to be revised. Specifically, the requirements document specifies that all meta data should include language tags, for certain meta data elements this does not make sense (as you'll see in the spec below). Also, instead of specifing specific protocol identifiers in the file name syntax and meta data syntax, it would be better to reference "IANA-assigned protocol identifiers" in both syntax specs and then to profile the supported directory service protocol identifiers in the listing procedures document. Lastly, I had to add a new meta data element to cover security considerations for the listed schema themselves (a URL pointing to security considerations text) to the meta data syntax spec. This means that there is an additional file type that needs to be supported by the file name syntax spec. Based on the above, I need to work on the listing procedures document a bit more with my co-author before its ready to send to the list. Please review the documents that have been posted to the list so far: + requirements document (draft-apple-schema-rqmts-list-02.txt) + file name sytnax spec (draft-apple-schema-file-list-00.txt) + meta data spec (not official, but draft-apple-schema-meta-list-00.txt) + Mark Wahl's MIME-DIR profile for transporting LDAPv3 schema (I can't remember the draft name.) I will be unable to access my mail for most of the day on thursday, but will check in first thing friday morning to see if anyone has sent in comments. ------------------------------------------------------------------------ Chris Apple Business Site: AnyWho Directory Services Internet Directory Group http://www.anywho.com AT&T Laboratories capple@master.control.att.com +1 908 582 2409 Tired of slow directories? Try AnyWho. ------------------------------------------------------------------------ INTERNET-DRAFT C. Apple AT&T Laboratories Expires: April 15, 1998 15 October 1997 Directory Schema Listing Meta Data Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This memo defines and specifies meta data element semantics and syntax for cataloging directory services schema in a schema listing service. 1.0 Introduction The fastest route to interoperable directory services is through standard object classes and attribute types. There is a growing number of places where schema for Internet Directory Services and Internet Operations are being defined, with varying degrees of documentation. This plethora of schema is unavoidable in the light of the needs of different service communities, but it makes it difficult for directory service builders to find and make use of an existing schema that will serve their needs and increase interoperability with other systems. A listing service providing a single point of discovery for directory service schema will promote schema reuse, reduce duplication of effort, and thus promote directory service interoperability. Meta data elements will be used to catalog and distinguish schema listings in this service. Apple [Page 1] INTERNET-DRAFT Directory Schema Listing Meta Data 15 October 1997 1.1 Scope Meta data file format and element syntax, language tagging, and semantic specifications intended for use during the initial release of a directory schema listing service are inside the scope of this document. 1.2 Terms and Definitions Information Object - a descriptive abstraction of some real-world object Schema - a collection of definitions for related information objects Listing Meta Data - characteristics that differentiate one schema from another; used to catalog schema Listing Content - a formal specification, using a single type of syntax, of a schema Schema Listing - the combination of listing meta data and all available syntax types of listing content for a particular schema Repository - a database in which schema listings are stored Schema Listing Request - a schema listing formatted using MIME constructs that is submitted for consideration as a schema listing to be published in a repository Operator - an organization that administers and maintains a repository Primary Repository - the repository that masters the schema listings database Shadow Repository - a repository that mirrors the primary repository Contact Person - the name of the individual who holds the authority to update a schema listing and who should be contacted if questions or concerns arise related to a schema listing or schema listing request Listing Authority Contact - the name of the individual who holds authority to replace a contact person; can be either the contact person for a schema listing or an alternate contact within the organization to which the contact person belongs (this allows one person organizations to list schema) The terms for specifying requirement level described in [RFC2119] are used in this document. 2.0 Common Syntaxes Apple [Page 2] INTERNET-DRAFT Directory Schema Listing Meta Data 15 October 1997 The following BNF rules are used throughout the remainder of this document: url = safe = SEP = (CRLF / LF) DIGIT = NZDIGIT = except "0" (60 octal)> CHAR = CTL = CRLF = CR LF CR = LF = SPACE = <"> = 3.0 Meta Data File Format Syntax The following definition uses the BNF specified in [RFC 822]. meta-data-file = md-element-record *(1*SEP md-element-record) md-element-record = 1*(md-element-spec) md-element-spec = md-element-desc ((":") / (":" *SPACE (value / url)) / ("::" *SPACE base64-value) md-element-desc = Apple [Page 3] INTERNET-DRAFT Directory Schema Listing Meta Data 15 October 1997 language-option = "lang=" language-tag language-tag = value = 1*safe-initval *safe safe-initval = base64-value = Notes on Meta Data File Format Syntax 1) Any line in a meta data file MAY be wrapped by inserting a line separator (SEP) and a SPACE. Any line which begins with a single space MUST be treated as a continuation of the previous line. 2) Any meta data element value which contains characters other than those defined as "safe," or begins with a character other than those defined as "safe-initval", above, MUST be base-64 encoded. 4.0 Meta Data Element Type Specifications Each meta data element type specification is composed of the following components: + description - a label consisting of alphanumeric ASCII characters describing the meta data element type + value syntax - a BNF-based [RFC822] syntax specification for the value of a meta data element type + semantic definition - a brief description of the type of information that will be encoded using the meta data value syntax + language tag requirement - a statement of whether a language tag is required or not permitted + multi-valued requirement - a statement of whether the meta data element type is permitted to be multi- or single-valued (MV or SV) Apple [Page 4] INTERNET-DRAFT Directory Schema Listing Meta Data 15 October 1997 Table 4-1 shows the relationship between a value syntax rule name, its corresponding semantic definition and description label that MUST be used for it in meta data stored in and transfered to/from a schema listing repository. Table 4-2 shows the relationship between a value syntax rule name and its corresponding language tag and multi-valued requirements. Table 4-1 Value | Semantic | Description Syntax | Definition | Label ------------------------------------------------------------- sequence | a globally unique sequence | "listingSequence" | number for the schema listing | ------------------------------------------------------------- charset | character set tag for meta | "charset" | data | ------------------------------------------------------------- name | a globally unique | "schemaName" | identifier for the schema | | name; specified by OID | ------------------------------------------------------------- title | the real world title of | "schemaTitle" | a listed schema | ------------------------------------------------------------- version | version information for | "schemaVersion" | a listed schema | ------------------------------------------------------------- use | description of the intended | "schemaUse" | use for a listed schema | ------------------------------------------------------------- syntax | an available syntax | "availableSyntax" | specification for a schema | | listing | ------------------------------------------------------------- related | an indication of a | "relatedTo" | relationship to another | | schema listing | ------------------------------------------------------------- status | an indication of listing | "status" | status | ------------------------------------------------------------- c-name | name of contact person for | "contactName" | schema listing | ------------------------------------------------------------- Apple [Page 5] INTERNET-DRAFT Directory Schema Listing Meta Data 15 October 1997 Table 4-1 (continued) Value | Semantic | Description Syntax | Definition | Label ------------------------------------------------------------- c-email | e-mail address of contact | "contactEmail | person for schema listing | ------------------------------------------------------------- c-phone | telephone number of contact | "contactPhone" | person for schema listing | ------------------------------------------------------------- c-addr | postal address of contact | "contactAddress" | person for schema listing | ------------------------------------------------------------- lac-name | name of listing authority | "authName" | contact (LAC) for schema | | listing; its value MAY be | | same as c-name | ------------------------------------------------------------- lac-email| e-mail address of LAC for | "authEmail" | schema listing; its value | | MAY be same as c-email | ------------------------------------------------------------- lac-phone| telephone number of LAC | "authPhone" | for schema listing; value | | MAY be same as c-phone | ------------------------------------------------------------- lac-addr | postal address of LAC for | "authAddress" | schema listing; value MAY | | be same as c-addr | ------------------------------------------------------------- content | a FTP URL for an available | "contentURL" | syntax of listing content | ------------------------------------------------------------- security | a FTP URL for a text | "securityURL" | description of security | | considerations for a single | | available syntax of listing | ------------------------------------------------------------- created | the creation date for | "created" | a schema listing | ------------------------------------------------------------- more | a pointer to additional | "moreInfo" | information about | | a listed schema | ------------------------------------------------------------- Apple [Page 6] INTERNET-DRAFT Directory Schema Listing Meta Data 15 October 1997 Table 4-2 Value | Language Tag | MV or SV Syntax | Requirement | Requirement -------------------------------------------------- sequence | MUST NOT be used | MUST be SV -------------------------------------------------- charset | MUST NOT be used | MUST be SV -------------------------------------------------- name | MUST NOT be used | MUST be SV -------------------------------------------------- title | REQUIRED | MUST be SV or MV -------------------------------------------------- version | MUST NOT be used | MUST be SV -------------------------------------------------- use | REQUIRED | MUST be SV -------------------------------------------------- syntax | MUST NOT be used | MUST be SV or MV -------------------------------------------------- related | MUST NOT be used | MUST be SV or MV -------------------------------------------------- status | MUST NOT be used | MUST be SV or MV -------------------------------------------------- c-name | REQUIRED | MUST be SV -------------------------------------------------- c-email | MAY be used | MUST be SV -------------------------------------------------- c-phone | MAY be used | MUST be SV -------------------------------------------------- c-addr | REQUIRED | MUST be SV -------------------------------------------------- lac-name | REQUIRED | MUST be SV -------------------------------------------------- lac-email | MAY be used | MUST be SV -------------------------------------------------- lac-phone | MAY be used | MUST be SV -------------------------------------------------- lac-addr | REQUIRED | MUST be SV -------------------------------------------------- content | MUST NOT be used | MUST be SV or MV -------------------------------------------------- security | REQUIRED | MUST be SV or MV -------------------------------------------------- created | MUST NOT be used | MUST be SV -------------------------------------------------- more | REQUIRED | MUST be SV or MV -------------------------------------------------- Apple [Page 7] INTERNET-DRAFT Directory Schema Listing Meta Data 15 October 1997 4.1 Meta Data Element Value Syntax Rules The BNF [RFC822] grammar rules below MUST be used when composing meta data element type values for use in the directory schema listing service (the rules are shown in the same order as in Table 4-1 above): sequence = NZDIGIT 0*(DIGIT) charset = "utf-8" name = oid oid-component = 1*DIGIT title = safe version = printable-string intended-use = safe content-syntax = "ldap" / "whoispp" related = url ; MUST be constrained to a FTP URL for ; a meta data file name as specified in [FILESYN] status = deprecation / "current" deprecation = ("obsoletes" / "obsoleted-by") SPACE url ; the URL in this case MUST be ; constrained to a FTP URL for ; a meta data file named as specified ; in [FILESYN] c-name = safe c-email = local-part "@" domain-part domain-part = sub-domain *("." sub-domain) sub-domain = 1* c-phone = 1* ; MUST use full ; international form ; e.g., +1 908 582 2409 Apple [Page 8] INTERNET-DRAFT Directory Schema Listing Meta Data 15 October 1997 c-addr = postal-string 5*("$" postal-string) postal-string = except "$"> lac-name = c-name lac-email =c-email lac-phone = c-phone lac-addr = c-address content = url ; the URL in this case MUST be a FTP URL ; pointing to the file name of a single ; available syntax for a schema listing security = url ; the URL in this case MUST be a FTP URL ; pointing to the name of the file containing ; security considerations for a single ; available syntax created = date "-" time date = 4DIGIT "-" 2DIGIT "-" 2DIGIT ; year-month-day ; e.g., 1997-08-27 time = 2DIGIT "-" 2DIGIT "-" 2DIGIT ; hh-mm-ss ; e.g., 00-00-00 thru 23-59-59 ; MUST be based on GMT more = url specials = "(" / ")" / "<" / ">" / "@" ; MUST be in quoted- / "," / ";" / ":" / "\" / <"> ; string to use / "." / "[" / "]" ; within a word 4.2 Meta Data Element Sourcing Requirements The following meta data elements (identified by description label) MUST be provided by schema writers during the process of reviewing a schema prior to publishing in a listing repository: + charset + schemaTitle + schemaVersion Apple [Page 9] INTERNET-DRAFT Directory Schema Listing Meta Data 15 October 1997 + schemaUse + availableSyntax + relatedTo + status + contactName + contactEmail + contactPhone + contactAddress + authName + authEmail + authPhone + authAddress + moreInfo The meta data element with the description label "schemaName" MAY be provided by the schema writer. If the schema writer is unwilling or unable to provide this element, the primary listing repository operator MUST provide it. The following meta data elements (identified by description label) MUST be provided by the primary schema listing repository operator and MUST NOT be accepted from the schema writer: + sequence + contentURL + securityURL + created 5.0 Security Considerations The meta data element and file format specifications in this document do not provide any method for carrying authentication information. Users of meta data files must take care to verify the integrity of any such file retrieved from a schema listing repository or received from a source external to the schema listing service. 6.0 Acknowledgements The file format specification in this document borrows heavily from the file format BNF grammar found in [LDIF]. Leslie Daigle of Bunyip Information Systems provided valuable comments on the content of the pre-Internet-Draft-version of this document. The engineering team for listing service requirements: Sanjay Jain - Oracle Michael Mealling - NSI Apple [Page 10] INTERNET-DRAFT Directory Schema Listing Meta Data 15 October 1997 John Strassner - Cisco Sam Sun - CNRI Mark Wahl - Critical Angle Chris Weider - Microsoft 7.0 References [FILESYN] C. Apple, "Directory Schema Listing File Name Syntax", INTERNET-DRAFT , October 1997. [LDIF] G. Good, "The LDAP Data Interchange Format (LDIF) - Technical Specification", INTERNET-DRAFT , July 1997. [RFC822] D. Crocker, "Standard of the Format of ARPA-Internet Text Messages", STD 11, RFC 822, August 1982. [RFC1738] T. Berners-Lee, L. Masinter, M. McCahill, "Uniform Resource Locators", RFC 1738, December 1994. [RFC1766] H. Alvestrand, "Tags for the Identification of Languages", RFC 1766, March 1995. [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Level", March 1997. 8.0 Author's Address Chris Apple AT&T Laboratories 600 - 700 Mountain Ave., Room 2F-165 Murray Hill, NJ 07974-0636 USA E-Mail: capple@att.com Phone: +1 908 582 2409 FAX: +1 908 582 3296 This INTERNET-DRAFT expires on April 15, 1998. Apple [Page 11] From owner-ietf-schema-reg Thu Oct 16 10:47:17 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA24815 for ietf-schema-reg-bks; Thu, 16 Oct 1997 10:47:17 -0700 (PDT) Received: from folder.critical-angle.com (eden-gw.critical-angle.com [206.81.238.241] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with SMTP id KAA24810 for ; Thu, 16 Oct 1997 10:47:12 -0700 (PDT) Received: (qmail 567 invoked from network); 16 Oct 1997 17:49:14 -0000 Received: from folder.critical-angle.com (206.81.238.241) by folder.critical-angle.com with SMTP; 16 Oct 1997 17:49:14 -0000 From: Mark Wahl To: capple@master.control.att.com (Christopher W Apple) cc: Mark Wahl cc: ietf-schema-reg@imc.org Subject: Re: pre-I-D meta data syntax spec In-reply-to: Your message of "Thu, 16 Oct 1997 06:26:41 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 16 Oct 1997 12:49:13 -0500 Message-ID: <565.877024153@folder.critical-angle.com> Sender: owner-ietf-schema-reg@imc.org Precedence: bulk 1. security considerations require an additional file type. It seems there are several places where a large body of text such as this could be stored. 1. inline in the meta-data 2. elsewhere on the Internet with URLs (URIs? URNs?) pointing to it 3. in a separate file in the schema repository If security considerations were to be stored in a separate file in the schema repository, then what about a very large copyright notice, or a grant of patent rights statement? I don't think we want to have a proliferation of file types, and substantial copyright statements or patent licenses are probably as likely to be needed as substantial security considerations, so I suggest they should either be inlined in the meta-data or be a URL to somewhere outside of the control of the schema listing service. 2. BNF and character set The production describes ASCII values up to 255. This could be confusing as some people think ASCII goes up to 127, and the requirements document requires UTF-8, which generates non-ASCII bytes in the 128-255 range. Same applies to the safe-initval production. 3. md-element-spec for URLs There is an ambiguity in this production. A value can begin with a 'h' character, as can a url. This is also slightly different from LDIF, in which URLs are type: The listing name MUST be the OID at which the schema is rooted. I am not sure what is meant by "rooted" for LDAP and WHOIS++ schemas. An OID assigned by the schema listing service does not affect the schema itself, and may be assigned many years after the schema was created. Thanks, Mark Wahl, Enterprise Directory Integration Critical Angle Inc. From owner-ietf-schema-reg Thu Oct 16 17:24:23 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA29433 for ietf-schema-reg-bks; Thu, 16 Oct 1997 17:24:23 -0700 (PDT) Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id RAA29429 for ; Thu, 16 Oct 1997 17:24:18 -0700 (PDT) Received: (from michael@localhost) by bailey.dscga.com (8.8.2/8.8.2) id UAA14894 for ietf-schema-reg@imc.org; Thu, 16 Oct 1997 20:26:02 -0400 (EDT) From: Michael Mealling Message-Id: <199710170026.UAA14894@bailey.dscga.com> Subject: some suggested changes to the specs... To: ietf-schema-reg@imc.org Date: Thu, 16 Oct 1997 20:26:01 -0400 (EDT) Reply-To: michaelm@rwhois.net X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Hi all! After being out of touch for a few weeks and seeing what came out of the discussions I missed I had a few nits to pick. I always hate it when a discussion gets re-opened so if I'm out of line please let me know. The first nit was that we had gotten away from allowing arbitrary representations of a schema. I'm not suggesting that the listing service need to understand arbitrary representations, just be able to store and return them on request. My concern was that if we required everyone to translate their schema's into and back out of the MIME-DIR version that it would be too high a barrier for adoption. My suggestion was that we still require our 'common' representation but that the registering entity be able to include in the submittal other files along with their file type. As someone who hopes to help out with the implementation this seems fairly easy to implement. The other concerns the relationship between the OID and the version number. It seemed to me that the version number could just as easily been part of the OID. The problem was that the OID specified was the one given to the registry by the submitter. This meant that if the registry tried to muck with the OID that it would walk on the toes of the schema owner's subtrees. My solution was to have two OIDs if necessary. E.g. LDAP calls Vcard '1.3.6.1.4.1.2309.1.1.1.1'. MIME-DIR calls it 'vcard'. Both are what each application-area/protocol uses for a name. The registry doesn't have any control over those which is dangerous because it can't manage them or gaurantee uniqueness. Thus we cause the registry to create a unique-id for it. As far as the registry is concerned this unique-id is the real _name_. Here's the example: Vcard is registered. In the metadata we say that its known as '1.3.6.1.4.1.2309.1.1.1.1' via LDAP and 'vcard' via MIME-DIR. The registry creates a new unique-id which is itself an OID. Its just that its kind of flat because its just the part of the tree that the registry uses. E.g. we get a subtree from the IANA and create numbers underneath it like this: .1 becomes the listing service _name_ for Vcard. LDAP and X.500 shouldn't care because they can't create new subtrees under our subtree. No collisions and we get to dictate revision terms. I'd do something like this: .x.y where: x = listing sequence number y = listing version number This way if the entity that registered says that its a child and not a peer we iterate the version number. If they consider a wholly new thing then we gen the sequence number. It's really up to them anyway... This gives us a directory structure that looks like this: schema-repository/1/schema.ldif schema-repository/1/schema.xml schema-repository/1/schema.mdl schema-repository/1/schema.metadata schema-repository/1.1/schema.ldif schema-repository/1.1/schema.metadata schema-repository/2/schema.ldif schema-repository/2/schema.html schema-repository/2/schema.metadata You could even turn the dots into directories and further seperate them... What the actual filename is doesn't matter. The 'schema' part looks kind of redundant doesn't it. Comments? -MM -- ------------------------------------------------------------------------------ Michael Mealling | 505 Huntmar Park Drive | Phone: (703)742-0400 Software Engineer | Herndon, VA 22070 | Fax: (703)742-9552 Network Solutions | | michaelm@rwhois.net From owner-ietf-schema-reg Thu Oct 16 18:04:26 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id SAA29801 for ietf-schema-reg-bks; Thu, 16 Oct 1997 18:04:26 -0700 (PDT) Received: from i.control.att.com ([135.205.52.126]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id SAA29797 for ; Thu, 16 Oct 1997 18:04:22 -0700 (PDT) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Thu, 16 Oct 1997 21:07:25 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for michaelm@rwhois.net; Thu, 16 Oct 1997 21:07:24 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Thu, 16 Oct 1997 21:07:24 -0400 (EDT) From: capple@master.control.att.com (Christopher W Apple) To: michaelm@rwhois.net, ietf-schema-reg@imc.org Subject: Re: some suggested changes to the specs... Sender: owner-ietf-schema-reg@imc.org Precedence: bulk I think this idea about how to name the schema listings is MUCH BETTER than what's currently documented. If anyone disagrees, speak up. >The other concerns the relationship between the OID and the version >number. It seemed to me that the version number could just as easily >been part of the OID. The problem was that the OID specified was >the one given to the registry by the submitter. This meant that if >the registry tried to muck with the OID that it would walk on the >toes of the schema owner's subtrees. > >My solution was to have two OIDs if necessary. E.g. LDAP calls >Vcard '1.3.6.1.4.1.2309.1.1.1.1'. MIME-DIR calls it 'vcard'. Both >are what each application-area/protocol uses for a name. The registry >doesn't have any control over those which is dangerous because it can't >manage them or gaurantee uniqueness. Thus we cause the registry >to create a unique-id for it. As far as the registry is concerned this >unique-id is the real _name_. > >Here's the example: > >Vcard is registered. In the metadata we say that its known as >'1.3.6.1.4.1.2309.1.1.1.1' via LDAP and 'vcard' via MIME-DIR. The >registry creates a new unique-id which is itself an OID. Its just >that its kind of flat because its just the part of the tree that >the registry uses. E.g. we get a subtree from the IANA and create >numbers underneath it like this: > >.1 becomes the listing service _name_ for Vcard. > >LDAP and X.500 shouldn't care because they can't create new subtrees >under our subtree. No collisions and we get to dictate revision terms. >I'd do something like this: >.x.y > >where: >x = listing sequence number >y = listing version number > >This way if the entity that registered says that its a child and not >a peer we iterate the version number. If they consider a wholly new >thing then we gen the sequence number. It's really up to them anyway... > >This gives us a directory structure that looks like this: > >schema-repository/1/schema.ldif >schema-repository/1/schema.xml >schema-repository/1/schema.mdl >schema-repository/1/schema.metadata >schema-repository/1.1/schema.ldif >schema-repository/1.1/schema.metadata >schema-repository/2/schema.ldif >schema-repository/2/schema.html >schema-repository/2/schema.metadata > >You could even turn the dots into directories and further seperate them... >What the actual filename is doesn't matter. The 'schema' part looks >kind of redundant doesn't it. > >Comments? I think the file name does matter a bit. I would change the above to use a file name that lets you identify the schema listing by its sequence and a version number, rather than limiting the encoding of the sequence.version information to the file's path in the file system of the repository. I suggest something like this: schema-repository/1/schema-ldif-1 schema-repository/1/schema-xml-1 schema-repository/1/schema-mdl-1 schema-repository/1/schema-metadata-1 schema-repository/1.1/schema-ldif-1.1 schema-repository/1.1/schema-metadata-1.1 schema-repository/2/schema-ldif-2 schema-repository/2/schema-html-2 schema-repository/2/schema-metadata-2 This way when someone saves the file to their local disk, it has some traceability back to its source location in the repository file system without them having to look inside of the file. This will require a few changes to the file name syntax, but there are a few more to make to that document as well. I'll post a list of proposed changes to all of the documents for the service When a few more accumulate. ------------------------------------------------------------------------ Chris Apple Business Site: AnyWho Directory Services Internet Directory Group http://www.anywho.com AT&T Laboratories capple@master.control.att.com +1 908 582 2409 Tired of slow directories? Try AnyWho. ------------------------------------------------------------------------ From owner-ietf-schema-reg Thu Oct 16 18:38:08 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id SAA00197 for ietf-schema-reg-bks; Thu, 16 Oct 1997 18:38:08 -0700 (PDT) Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id SAA00193 for ; Thu, 16 Oct 1997 18:38:03 -0700 (PDT) Received: (from michael@localhost) by bailey.dscga.com (8.8.2/8.8.2) id VAA14933; Thu, 16 Oct 1997 21:39:32 -0400 (EDT) From: Michael Mealling Message-Id: <199710170139.VAA14933@bailey.dscga.com> Subject: Re: some suggested changes to the specs... In-Reply-To: from Christopher W Apple at "Oct 16, 97 09:07:24 pm" To: capple@master.control.att.com (Christopher W Apple) Date: Thu, 16 Oct 1997 21:39:32 -0400 (EDT) Cc: michaelm@rwhois.net, ietf-schema-reg@imc.org Reply-To: michaelm@rwhois.net X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Christopher W Apple said this: > I think this idea about how to name the schema listings is MUCH BETTER > than what's currently documented. If anyone disagrees, speak up. Thanks! > >schema-repository/2/schema.metadata > > > >You could even turn the dots into directories and further seperate them... > >What the actual filename is doesn't matter. The 'schema' part looks > >kind of redundant doesn't it. > > > >Comments? > > I think the file name does matter a bit. > > I would change the above to use a file name that lets you identify > the schema listing by its sequence and a version number, rather than > limiting the encoding of the sequence.version information to the file's > path in the file system of the repository. > > I suggest something like this: > > schema-repository/1/schema-ldif-1 > schema-repository/1/schema-xml-1 > schema-repository/1/schema-mdl-1 > schema-repository/1/schema-metadata-1 > schema-repository/1.1/schema-ldif-1.1 > schema-repository/1.1/schema-metadata-1.1 > schema-repository/2/schema-ldif-2 > schema-repository/2/schema-html-2 > schema-repository/2/schema-metadata-2 > > This way when someone saves the file to their local disk, it > has some traceability back to its source location in the repository > file system without them having to look inside of the file. Good point. Save those files outside the directory structure and they don't make a bit of sense... -MM -- ------------------------------------------------------------------------------ Michael Mealling | 505 Huntmar Park Drive | Phone: (703)742-0400 Software Engineer | Herndon, VA 22070 | Fax: (703)742-9552 Network Solutions | | michaelm@rwhois.net From owner-ietf-schema-reg Fri Oct 17 09:51:17 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA12011 for ietf-schema-reg-bks; Fri, 17 Oct 1997 09:51:17 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.31]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA12007 for ; Fri, 17 Oct 1997 09:51:14 -0700 (PDT) Received: by mail5.microsoft.com with Internet Mail Service (5.5.1664.16) id ; Fri, 17 Oct 1997 09:55:29 -0700 Message-ID: From: Chris Weider To: "'michaelm@rwhois.net'" , capple@master.control.att.com Cc: ietf-schema-reg@imc.org Subject: RE: some suggested changes to the specs... Date: Fri, 17 Oct 1997 09:54:37 -0700 X-Mailer: Internet Mail Service (5.5.1664.16) Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Looks good to me. Chris > -----Original Message----- > From: Michael Mealling [SMTP:michael@bailey.dscga.com] > Sent: Thursday, October 16, 1997 6:40 PM > To: capple@master.control.att.com > Cc: michaelm@rwhois.net; ietf-schema-reg@imc.org > Subject: Re: some suggested changes to the specs... > > Christopher W Apple said this: > > I think this idea about how to name the schema listings is MUCH > BETTER > > than what's currently documented. If anyone disagrees, speak up. > > Thanks! > > > >schema-repository/2/schema.metadata > > > > > >You could even turn the dots into directories and further seperate > them... > > >What the actual filename is doesn't matter. The 'schema' part looks > > >kind of redundant doesn't it. > > > > > >Comments? > > > > I think the file name does matter a bit. > > > > I would change the above to use a file name that lets you identify > > the schema listing by its sequence and a version number, rather than > > limiting the encoding of the sequence.version information to the > file's > > path in the file system of the repository. > > > > I suggest something like this: > > > > schema-repository/1/schema-ldif-1 > > schema-repository/1/schema-xml-1 > > schema-repository/1/schema-mdl-1 > > schema-repository/1/schema-metadata-1 > > schema-repository/1.1/schema-ldif-1.1 > > schema-repository/1.1/schema-metadata-1.1 > > schema-repository/2/schema-ldif-2 > > schema-repository/2/schema-html-2 > > schema-repository/2/schema-metadata-2 > > > > This way when someone saves the file to their local disk, it > > has some traceability back to its source location in the repository > > file system without them having to look inside of the file. > > Good point. Save those files outside the directory structure and > they don't make a bit of sense... > > -MM > > -- > ---------------------------------------------------------------------- > -------- > Michael Mealling | 505 Huntmar Park Drive | Phone: > (703)742-0400 > Software Engineer | Herndon, VA 22070 | Fax: > (703)742-9552 > Network Solutions | | > michaelm@rwhois.net From owner-ietf-schema-reg Fri Oct 17 10:02:10 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA12195 for ietf-schema-reg-bks; Fri, 17 Oct 1997 10:02:10 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.31]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA12191 for ; Fri, 17 Oct 1997 10:02:07 -0700 (PDT) Received: by mail5.microsoft.com with Internet Mail Service (5.5.1664.16) id ; Fri, 17 Oct 1997 10:06:22 -0700 Message-ID: From: Chris Weider To: "'michaelm@rwhois.net'" , ietf-schema-reg@imc.org Subject: RE: some suggested changes to the specs... Date: Fri, 17 Oct 1997 10:05:42 -0700 X-Mailer: Internet Mail Service (5.5.1664.16) Sender: owner-ietf-schema-reg@imc.org Precedence: bulk One comment below... Chris > -----Original Message----- > From: Michael Mealling [SMTP:michael@bailey.dscga.com] > Sent: Thursday, October 16, 1997 5:26 PM > To: ietf-schema-reg@imc.org > Subject: some suggested changes to the specs... > > Hi all! > > After being out of touch for a few weeks and seeing what came out of > the discussions I missed I had a few nits to pick. I always hate it > when a discussion gets re-opened so if I'm out of line please let me > know. > > The first nit was that we had gotten away from allowing arbitrary > representations of a schema. I'm not suggesting that the listing > service > need to understand arbitrary representations, just be able to store > and > return them on request. My concern was that if we required everyone > to translate their schema's into and back out of the MIME-DIR version > that > it would be too high a barrier for adoption. [Chris Weider] Ah, but without some recommended schema we're allowing folks to register any old crap whether it's useful or not. > My suggestion was that we still require our 'common' representation > but > that the registering entity be able to include in the submittal other > files along with their file type. As someone who hopes to help out > with the implementation this seems fairly easy to implement. > > The other concerns the relationship between the OID and the version > number. It seemed to me that the version number could just as easily > been part of the OID. The problem was that the OID specified was > the one given to the registry by the submitter. This meant that if > the registry tried to muck with the OID that it would walk on the > toes of the schema owner's subtrees. > > My solution was to have two OIDs if necessary. E.g. LDAP calls > Vcard '1.3.6.1.4.1.2309.1.1.1.1'. MIME-DIR calls it 'vcard'. Both > are what each application-area/protocol uses for a name. The registry > doesn't have any control over those which is dangerous because it > can't > manage them or gaurantee uniqueness. Thus we cause the registry > to create a unique-id for it. As far as the registry is concerned this > > unique-id is the real _name_. > > Here's the example: > > Vcard is registered. In the metadata we say that its known as > '1.3.6.1.4.1.2309.1.1.1.1' via LDAP and 'vcard' via MIME-DIR. The > registry creates a new unique-id which is itself an OID. Its just > that its kind of flat because its just the part of the tree that > the registry uses. E.g. we get a subtree from the IANA and create > numbers underneath it like this: > > .1 becomes the listing service _name_ for Vcard. > > LDAP and X.500 shouldn't care because they can't create new subtrees > under our subtree. No collisions and we get to dictate revision terms. > I'd do something like this: > .x.y > > where: > x = listing sequence number > y = listing version number > > This way if the entity that registered says that its a child and not > a peer we iterate the version number. If they consider a wholly new > thing then we gen the sequence number. It's really up to them > anyway... > > This gives us a directory structure that looks like this: > > schema-repository/1/schema.ldif > schema-repository/1/schema.xml > schema-repository/1/schema.mdl > schema-repository/1/schema.metadata > schema-repository/1.1/schema.ldif > schema-repository/1.1/schema.metadata > schema-repository/2/schema.ldif > schema-repository/2/schema.html > schema-repository/2/schema.metadata > > You could even turn the dots into directories and further seperate > them... > What the actual filename is doesn't matter. The 'schema' part looks > kind of redundant doesn't it. > > Comments? > > -MM > -- > ---------------------------------------------------------------------- > -------- > Michael Mealling | 505 Huntmar Park Drive | Phone: > (703)742-0400 > Software Engineer | Herndon, VA 22070 | Fax: > (703)742-9552 > Network Solutions | | > michaelm@rwhois.net From owner-ietf-schema-reg Fri Oct 17 10:09:09 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA12314 for ietf-schema-reg-bks; Fri, 17 Oct 1997 10:09:09 -0700 (PDT) Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA12310 for ; Fri, 17 Oct 1997 10:09:04 -0700 (PDT) Received: (from michael@localhost) by bailey.dscga.com (8.8.2/8.8.2) id NAA15687; Fri, 17 Oct 1997 13:07:24 -0400 (EDT) From: Michael Mealling Message-Id: <199710171707.NAA15687@bailey.dscga.com> Subject: Re: some suggested changes to the specs... In-Reply-To: from Chris Weider at "Oct 17, 97 10:05:42 am" To: cweider@microsoft.com (Chris Weider) Date: Fri, 17 Oct 1997 13:07:22 -0400 (EDT) Cc: michaelm@rwhois.net, ietf-schema-reg@imc.org Reply-To: michaelm@rwhois.net X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Chris Weider said this: > > -----Original Message----- > > From: Michael Mealling [SMTP:michael@bailey.dscga.com] > > Sent: Thursday, October 16, 1997 5:26 PM > > To: ietf-schema-reg@imc.org > > Subject: some suggested changes to the specs... > > > > Hi all! > > > > After being out of touch for a few weeks and seeing what came out of > > the discussions I missed I had a few nits to pick. I always hate it > > when a discussion gets re-opened so if I'm out of line please let me > > know. > > > > The first nit was that we had gotten away from allowing arbitrary > > representations of a schema. I'm not suggesting that the listing > > service > > need to understand arbitrary representations, just be able to store > > and > > return them on request. My concern was that if we required everyone > > to translate their schema's into and back out of the MIME-DIR version > > that > > it would be too high a barrier for adoption. > > [Chris Weider] Ah, but without some recommended schema we're > allowing folks to register any old crap whether it's useful or not. > I never suggested getting rid of the required/recommended one. Just that in addition to it we allow other stuff. I'd rather have useful and non-useful stuff in the registry as opposed to nothing at all.... -MM -- ------------------------------------------------------------------------------ Michael Mealling | 505 Huntmar Park Drive | Phone: (703)742-0400 Software Engineer | Herndon, VA 22070 | Fax: (703)742-9552 Network Solutions | | michaelm@rwhois.net From owner-ietf-schema-reg Fri Oct 17 10:12:53 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA12372 for ietf-schema-reg-bks; Fri, 17 Oct 1997 10:12:53 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.29]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA12368 for ; Fri, 17 Oct 1997 10:12:49 -0700 (PDT) Received: by mail4.microsoft.com with Internet Mail Service (5.5.1664.3) id <40ZVG6PQ>; Fri, 17 Oct 1997 10:16:39 -0700 Message-ID: From: Chris Weider To: "'michaelm@rwhois.net'" Cc: ietf-schema-reg@imc.org Subject: RE: some suggested changes to the specs... Date: Fri, 17 Oct 1997 10:15:07 -0700 X-Mailer: Internet Mail Service (5.5.1664.3) Sender: owner-ietf-schema-reg@imc.org Precedence: bulk O.K.... I can live with that. Chris > -----Original Message----- > From: Michael Mealling [SMTP:michael@bailey.dscga.com] > Sent: Friday, October 17, 1997 10:07 AM > To: Chris Weider > Cc: michaelm@rwhois.net; ietf-schema-reg@imc.org > Subject: Re: some suggested changes to the specs... > > Chris Weider said this: > > > -----Original Message----- > > > From: Michael Mealling [SMTP:michael@bailey.dscga.com] > > > Sent: Thursday, October 16, 1997 5:26 PM > > > To: ietf-schema-reg@imc.org > > > Subject: some suggested changes to the specs... > > > > > > Hi all! > > > > > > After being out of touch for a few weeks and seeing what came out > of > > > the discussions I missed I had a few nits to pick. I always hate > it > > > when a discussion gets re-opened so if I'm out of line please let > me > > > know. > > > > > > The first nit was that we had gotten away from allowing arbitrary > > > representations of a schema. I'm not suggesting that the listing > > > service > > > need to understand arbitrary representations, just be able to > store > > > and > > > return them on request. My concern was that if we required > everyone > > > to translate their schema's into and back out of the MIME-DIR > version > > > that > > > it would be too high a barrier for adoption. > > > > [Chris Weider] Ah, but without some recommended schema we're > > allowing folks to register any old crap whether it's useful or not. > > > > I never suggested getting rid of the required/recommended one. Just > that > in addition to it we allow other stuff. I'd rather have useful and > non-useful stuff in the registry as opposed to nothing at all.... > > -MM > > -- > ---------------------------------------------------------------------- > -------- > Michael Mealling | 505 Huntmar Park Drive | Phone: > (703)742-0400 > Software Engineer | Herndon, VA 22070 | Fax: > (703)742-9552 > Network Solutions | | > michaelm@rwhois.net From owner-ietf-schema-reg Fri Oct 17 11:04:22 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA13003 for ietf-schema-reg-bks; Fri, 17 Oct 1997 11:04:22 -0700 (PDT) Received: from i.control.att.com ([135.205.52.126]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA12999 for ; Fri, 17 Oct 1997 11:04:18 -0700 (PDT) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Fri, 17 Oct 1997 14:07:23 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for michaelm@rwhois.net; Fri, 17 Oct 1997 14:07:23 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Fri, 17 Oct 1997 14:07:23 -0400 (EDT) From: capple@master.control.att.com (Christopher W Apple) To: michaelm@rwhois.net, cweider@microsoft.com (Chris Weider) Cc: ietf-schema-reg@imc.org Subject: Re: some suggested changes to the specs... Sender: owner-ietf-schema-reg@imc.org Precedence: bulk >> > The first nit was that we had gotten away from allowing arbitrary >> > representations of a schema. I'm not suggesting that the listing >> > service >> > need to understand arbitrary representations, just be able to store >> > and >> > return them on request. My concern was that if we required everyone >> > to translate their schema's into and back out of the MIME-DIR version >> > that >> > it would be too high a barrier for adoption. >> >> [Chris Weider] Ah, but without some recommended schema we're >> allowing folks to register any old crap whether it's useful or not. >> > >I never suggested getting rid of the required/recommended one. Just that >in addition to it we allow other stuff. I'd rather have useful and >non-useful stuff in the registry as opposed to nothing at all.... I think this is already constrained sufficiently in the requirements document and the (unpublished but will be next week) procedures document. Hopefully, by using a public mailing list which we require schema writers to use as a means of submitting schema listing requests, we will eliminate most of the crap that would otherwise get through, regardless of whether or not the listing content is MIME-DIR. ------------------------------------------------------------------------ Chris Apple Business Site: AnyWho Directory Services Internet Directory Group http://www.anywho.com AT&T Laboratories capple@master.control.att.com +1 908 582 2409 Tired of slow directories? Try AnyWho. ------------------------------------------------------------------------ From owner-ietf-schema-reg Fri Oct 17 23:35:21 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id XAA19343 for ietf-schema-reg-bks; Fri, 17 Oct 1997 23:35:21 -0700 (PDT) Received: from i.control.att.com ([135.205.52.126]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id XAA19339 for ; Fri, 17 Oct 1997 23:35:17 -0700 (PDT) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Sat, 18 Oct 1997 02:37:50 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for ietf-schema-reg@imc.org; Sat, 18 Oct 1997 02:37:49 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Sat, 18 Oct 1997 02:37:49 -0400 (EDT) From: capple@master.control.att.com (Christopher W Apple) To: Mark Wahl , capple@master.control.att.com (Christopher W Apple) Cc: ietf-schema-reg@imc.org Subject: Re: draft-apple-schema-rqmts-list-02.txt Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Thanks a lot for the comments! >1. schemas and syntaxes (1.3.1) > >> Included in the web-based representation of the listing meta data are ftp >> URLs pointing to available syntaxes for this schema. The user clicks on the >> link for the syntax that they can use. > >When I see the phrase "available syntax for [the vCard] schema" I think >Directory String, Case Ignore String etc, since a schema definition often >includes syntaxes. Perhaps another word like "profile" could be used instead >of "syntax". I have no objections to replacing the work "syntax" with "profile" where appropriate. Does anyone have concerns about doing this? >2. signed schema requests > >> Schema listing requests MAY be signed using PGP/MIME as described in >> [RFC2015]. The primary listing repository operator MUST be able to >> accept schema listing requests in PGP/MIME messages, although they are >> NOT REQUIRED to validate the signatures. > >As the meta-data is modified by the schema listing service to add additional >fields, that would violate a signature which covered the meta data submitted >by the user. Perhaps there should be a brief statement in this document of >what the user signing their request can expect. For example, if I mail in > > From: Mark Wahl > Content-Type: multipart/signed (outer wrapper binding metadata+schema) > > Content-Type: multipart/mixed > > Content-Type: text/directory; profile="schema-metadata-0" > > Content-Type: multipart/signed (inner wrapper on schema only) > > Content-Type: text/directory; profile="schema-ldap-0" > > Content-Type: application/pgp-signature > > Content-Type: application/pgp-signature > >the original message and meta data is not kept, so the outer wrapper is not >usable, however the inner wrapper could be preserved. Would the file >schema-1-ldap.txt contain a multipart/signed of the inner wrapper? Currently, the requirements spec does not mention a requirement to retain signature information. As a matter of fact, it basically sets up a user-and-repository-provider-beware deployment scenario; at least for the first release. I think it would be better to add a statement to the document explicitly declaring that retaining signature information is NOT REQUIRED for the intial deployment, and to handle signature retention requirements as an add-on to the service and requirements spec at a release of the service after the initial one.....unless of course concensus on the list indicates otherwise. What do other people think about this? > >3. Access Functions (2.3) > >There is an inconsistency: FTP, HTTP and SMTP protocols are to be supported, but >the required functions include: g) searching, h) adding and i) updating? Good point. In the notes I took during the engineering team meeting in Munich, there are descriptions of how each protocol is used (or not used) to implement a particular part of access functionality. Perhaps an appendix profiling the use of each access protocol is appropriate. I'll add this and refer to them in paragraph 2.3 unless anyone objects to it. >I don't believe that it is required to be able to search with FTP or add via >HTTP. Also what is the difference between obtaining and browsing a content or >list? Obtaining means that you can use FTP or an SMTP-to-FTP gateway to actually retrieve a file (without using a browser; some of us still do it that way :) whereas browsing a file could mean using either FTP or HTTP to view a file within a web browser. This should become clearer once the appendices mentioned above are added, but alternate text to clear up confusion independent of these appendices will be appreciated. > >4. Assigning OIDs to schemas (3.0) > >> The listing name MUST be the OID at which the schema is rooted. > >I am not sure what is meant by "rooted" for LDAP and WHOIS++ schemas. An OID >assigned by the schema listing service does not affect the schema itself, and >may be assigned many years after the schema was created. What I meant by "rooted" may be more related to the way I've personally used OIDs (or my own private construct similar to OIDs) in the past than the general "BCP-ish" way of using them. In the past, I've allocated unique identifiers for schema (not necessarily directory schema) that were used as a name for the schema itself, and that the name of every attribute type, syntax rule, matching rule, semantic rule, etc. was allocated as an extension of that unique identifier. This means that even if the same attribute type description is re-used across schema, but with a differing syntax or semantic rules, there is a way to interpret such an attribute's value so long as all references to it are made by the full, explicit attribute name (of course, a registry of all schema must exist :). However, the proposal Micheal Mealling posted to the list for how to name schema will result in this language changing to remove my concept of "rooting a schema at an OID." ------------------------------------------------------------------------ Chris Apple Business Site: AnyWho Directory Services Internet Directory Group http://www.anywho.com AT&T Laboratories capple@master.control.att.com +1 908 582 2409 Tired of slow directories? Try AnyWho. ------------------------------------------------------------------------ From owner-ietf-schema-reg Sat Oct 18 01:23:14 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id BAA19982 for ietf-schema-reg-bks; Sat, 18 Oct 1997 01:23:14 -0700 (PDT) Received: from i.control.att.com ([135.205.52.126]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id BAA19978 for ; Sat, 18 Oct 1997 01:23:09 -0700 (PDT) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Sat, 18 Oct 1997 04:25:44 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for michaelm@rwhois.net; Sat, 18 Oct 1997 04:25:39 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Sat, 18 Oct 1997 04:25:39 -0400 (EDT) From: capple@master.control.att.com (Christopher W Apple) To: Mark Wahl , capple@master.control.att.com (Christopher W Apple) Cc: ietf-schema-reg@imc.org, michaelm@rwhois.net Subject: Re: pre-I-D meta data syntax spec Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Thanks for the comments! Mark Wahl wrote: >1. security considerations require an additional file type. Yeah, I had made that comment to the list (unless there was a mail problem I don't know about) myself. That's what I get for publishing the file name syntax spec first. :) >It seems there are several places where a large body of text such as this could >be stored. > 1. inline in the meta-data > 2. elsewhere on the Internet with URLs (URIs? URNs?) pointing to it > 3. in a separate file in the schema repository > >If security considerations were to be stored in a separate file in the schema >repository, then what about a very large copyright notice, or a grant of >patent rights statement? I don't think we want to have a proliferation of file >types, and substantial copyright statements or patent licenses are probably as >likely to be needed as substantial security considerations, so I suggest they >should either be inlined in the meta-data or be a URL to somewhere outside of >the control of the schema listing service. Well, this does present a bit of a dilema. I'm not comfortable with the idea of a shema writer or the organization with which they are associated being able to change the security considerations associated with a listed schema or even a statement about patent licensing or copyright notices without there being some mechanism for users of such schema to be aware of any changes. So, I think it would be a mistake to use URLs (actually UR*s) in this context that point to content which is out of the change control processes implemented by the repository. I have no strong opinion about selecting either "inline in the meta data" or "in a separate file in the repository" and will adjust the language to reflect list concensus. Other folks should speak up about whether its best to go one way or the other. >2. BNF and character set > >The production describes ASCII values up to 255. This could be confusing >as some people think ASCII goes up to 127, and the requirements document >requires UTF-8, which generates non-ASCII bytes in the 128-255 range. Same >applies to the safe-initval production. I don't see the problem here. These two productions were lifted directly out of draft-ietf-asid-ldif-02.txt, which is for use by LDAP implementations that use UTF-8 as way of encoding strings. I don't see how draft-apple-schema-meta-list-00.txt proposes anything different w.r.t. the way the terms UTF-8, ASCII, and base-64 are used in the LDIF spec. Its possible that I mistakenly deleted something when editing the grammar components take from the LDIF spec. If so, just point out what's missing and I'll fix it. Otherwise, I don't know how to change the document based on this comment and will need a more specific editorial suggestion to act on it. > >3. md-element-spec for URLs > >There is an ambiguity in this production. A value can begin with a 'h' >character, as can a url. This is also slightly different from LDIF, in which >URLs are type:4. md-element-desc and language-option > >The document did not appear to define the term "augment". I assume you probably >mean using semicolon as in LDAP. The use of the = in language-option is >different from LDAP, where we use -. I suggest the use of '-' instead of '=': >human parsers looking at (type,value) data often get confused when there are >both = and : characters at which one is the "real" delimiter >(e.g. "foo;lang=fr:bar") Your assumption is correct about the term "augment." Point noted, I'll add a definition for it. I'll also swap out the '=' for a '-' while I'm at it. >5. Transfer form for meta-data > >A fair portion of section 2 and 3 define formatting rules. However, this >document does not appear to define a content type for transfer of this >meta-data. I would like to encourage the creation of MIME-DIR profile for >meta-data, since we would be using MIME-DIR for LDAP schema information. >This cuts down the amount of parsing code which would need to be written, and >issues of "safe" characters or wrapping lines are taken care of by MIME-DIR, >and thus need not be in this document. Much of section 3.0 could be removed. I'll respond to this one in a different message. > >6. charset description label > >I assume in a content description labels can appear in any order. Thus, >there could be several textual fields in a meta-data before the charset field. >This means that a parser cannot display information until it has finished >parsing the content. My intent was to include a requirement that the charset "type:value" pair would be the first meta data element in any schema listing. Haste and resulting oversight are why it was not included. It will be added. >If the MIME-DIR profile suggestion of point 5 were adopted, then this field >is not necessary, as MIME-DIR already includes a mechanism for indicating >character set in the Content Header, rather than in the content itself. See response for point 5. >7. availableSyntax description label > >I did not see a BNF production for syntax, only content-syntax. The word >"syntax" seems to have many different definitions inside the schema listing >service. Since we have a MIME-DIR profile for LDAP, perhaps it might be >better to use the term "availableProfile", in which the profile field is the >value. If in the future there have been several iterations of the schema >listing service, and based on deployment experience there are changes to the >LDAP schema profile which are not backwards compatible with previous versions, >it would be possible to use this attribute to indicate that a schema is listed >with a particular version of the profile, on in multiple profiles, e.g. > >availableProfile: schema-ldap-0 >availableProfile: schema-ldap-67 >availableProfile: schema-whoispp-3 I have no objections to changing the BNF production name or the type label to use the word "profile." The way you suggest including multiple versions of a profile is consistent with the proposal from Michael Mealling on how to name schema as well as my recommendation (in response to Michael's proposal, not the one specified in the file name syntax spec) for how to name files. > >8. related description label > >There are several forms of relation which could be covered by this attribute: > - this schema is derived from schema X > - this schema is used by schema X > - this schema relies of definitions from schema X > - this schema should be used instead of schema X > >In LDAP, the labeledURI field allows for both a URI and a short human-readable >message describing the subject of the URI, so that a human browsing the >directory can determine whether to follow a particular URI or not. In might >be worthwhile to consider including not only the target of a schema >relationship, but also an indication of the type of relationship with the >target. > >Also, as this field is constrainted to be a URL to the schema listing service, >this would mean that if at some point in the future the listing service moves, >any signed meta-data will need to be resigned as the URLs inside of related >lines would be invalid. Also, if there are multiple shadow repositories, >would there need to be multiple relatedTo lines for a particular schema? Finally >this requires that all referenced schemas be listed before a schema which >references them, which would prevent indicating a symmetric relationship. >I suggest that it might be worthwhile to consider changing this field to be >a combination of an OID and an optional set of relationship indiciations. > >For example, > >relatedTo: 1.1 >relatedTo: 1.2 $ obsoletes >relatedTo: 1.3 $ inherits >relatedTo: 1.4 $ updates >relatedTo: 1.5 $ x-vendorname-vendorspecificrelationship > >This would simplify the status field to be either "current" or "obsolete". Sounds good to me. I'll change it as you suggest unless concensus indicates otherwise. > >9. contactName field > >In some cases there may not be a single person responsible for a schema. It >may be a group or a role. > >contactName: XAC Schema Study Group >contactName: SchemaMaster OK. I'll make a change to the definition for this element to reflect this. Were you suggesting that it also be multi-valued? >Also the c-name field is defined to be a single ASCII character, which is >probably not right. Its not. I'll fix it. >10. contactAddress > >The production for c-addr requires that the postal address consist of at least >6 lines. I think the 5 is on the wrong side. I'll check RFC 822 and make a change if appropriate. I meant to allow for up to six lines. >11. contentURL > >If there are replicas of the schema listing service does the contentURL >contain multiple values? That's certainly an option once we have at least one shadow repository site operational, but I don't think the spec needs to change to allow for that. >12. securityURL > >I think the security considerations should be inline. > >securityConsiderations: Security Considerations are not discussed. Doesn't matter to me which way we go on this. What do others have to say about it? >13. name production > >There is no relationship between oid and oid-component. An error on my part. Consider it fixed. >14. single-valued attributes with language tags > >Language tags help a client to choose an appropriate value out of several. As >there are environments where there is requirement to provide information in >multiple languages simultaneously, I suggest that the fields which require a >language tag must be permitted to be multi-valued. This affects schemaUse, >contactName, contactAddress, authName and authAddress. > >Also, what are the semantic implications on a client of the schema listing >service when a language tag is encountered on an email or telephone value? >Do you mean that the person, group or role is capable of receiving email or >voice in a particular language? Yes. I'll add text explaining this. >As these are single-valued attributes, it >would prevent someone from indicating that they speak multiple languages. > >I suggest that this could be resolved by: > - allowing schemaUse to be multi-valued > - remove language tags from contact and auth fields > - create new multi-valued properties contactLanguage and authLanguage whose > values are language tags. I'll resolve it this way unless I hear otherwise from the list. The only other option is to allow for multiple language tags per element, but I'll assume that you thought using multi-valued elements is the better way to go unless I hear otherwise. >15. requirement to provide relatedTo > >relatedTo is listed as a MUST be provided field. This prevents a schema which >is not related to any other schemas (e.g. the first one) from being listed. Duh. Consider the requirement language changed to accomodate schema unrelated to other schema. >16. schemaVersion > >Are there any ordering properties on a schemaVersion field? > >Suppose someone decides to list the "X.520(1993)" schema in the directory as >one of the first schemas. Later on, someone else decides to list the >"X.520(88)" schema, which had some minor variations. > >A client using the service will see that the "X.520(88)" schema is the more >recent listing, and even that "X.520(88)" is strcmp() greater than "X.520(1993)". >However, it is an earlier schema version. > >It might be worthwhile to consider restricting the schemaVersion field to >consist of a numbers separated by periods, e.g. 1, 1.1, 2, 2.1, 2.0.5 etc, so >that it is always possible to compare version numbers, and also possible to >insert new versions between two existing versions. I see no problem with constraining version numbers the way you suggest. I'll make the change unless concensus indicates otherwise. ------------------------------------------------------------------------ Chris Apple Business Site: AnyWho Directory Services Internet Directory Group http://www.anywho.com AT&T Laboratories capple@master.control.att.com +1 908 582 2409 Tired of slow directories? Try AnyWho. ------------------------------------------------------------------------ From owner-ietf-schema-reg Sat Oct 18 09:01:45 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA23826 for ietf-schema-reg-bks; Sat, 18 Oct 1997 09:01:45 -0700 (PDT) Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA23822 for ; Sat, 18 Oct 1997 09:01:39 -0700 (PDT) Received: (from michael@localhost) by bailey.dscga.com (8.8.2/8.8.2) id MAA16819; Sat, 18 Oct 1997 12:03:13 -0400 (EDT) From: Michael Mealling Message-Id: <199710181603.MAA16819@bailey.dscga.com> Subject: Re: draft-apple-schema-rqmts-list-02.txt In-Reply-To: from Christopher W Apple at "Oct 18, 97 02:37:49 am" To: capple@master.control.att.com (Christopher W Apple) Date: Sat, 18 Oct 1997 12:03:12 -0400 (EDT) Cc: ietf-schema-reg@imc.org Reply-To: michaelm@rwhois.net X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Christopher W Apple said this: > >2. signed schema requests > > > >> Schema listing requests MAY be signed using PGP/MIME as described in > >> [RFC2015]. The primary listing repository operator MUST be able to > >> accept schema listing requests in PGP/MIME messages, although they are > >> NOT REQUIRED to validate the signatures. > > > >As the meta-data is modified by the schema listing service to add additional > >fields, that would violate a signature which covered the meta data submitted > >by the user. Perhaps there should be a brief statement in this document of > >what the user signing their request can expect. For example, if I mail in > > > > From: Mark Wahl > > Content-Type: multipart/signed (outer wrapper binding metadata+schema) > > > > Content-Type: multipart/mixed > > > > Content-Type: text/directory; profile="schema-metadata-0" > > > > Content-Type: multipart/signed (inner wrapper on schema only) > > > > Content-Type: text/directory; profile="schema-ldap-0" > > > > Content-Type: application/pgp-signature > > > > Content-Type: application/pgp-signature > > > >the original message and meta data is not kept, so the outer wrapper is not > >usable, however the inner wrapper could be preserved. Would the file > >schema-1-ldap.txt contain a multipart/signed of the inner wrapper? > > Currently, the requirements spec does not mention a requirement to > retain signature information. As a matter of fact, it basically sets up a > user-and-repository-provider-beware deployment scenario; at least for > the first release. I think it would be better to add a statement to the > document explicitly declaring that retaining signature information is > NOT REQUIRED for the intial deployment, and to handle signature retention > requirements as an add-on to the service and requirements spec at a release > of the service after the initial one.....unless of course concensus on > the list indicates otherwise. What do other people think about this? I'd prefer it to not be in the first phase. It brings up liability as well as technical issues that we don't have time to deal with right now. > >3. Access Functions (2.3) > > > >There is an inconsistency: FTP, HTTP and SMTP protocols are to be supported, > > but the required functions include: g) searching, h) adding and i) updating? > > Good point. In the notes I took during the engineering team meeting in > Munich, there are descriptions of how each protocol is used (or not used) > to implement a particular part of access functionality. Perhaps an appendix > profiling the use of each access protocol is appropriate. I'll add this > and refer to them in paragraph 2.3 unless anyone objects to it. > > >I don't believe that it is required to be able to search with FTP or add via > >HTTP. Also what is the difference between obtaining and browsing a content > >or list? > > Obtaining means that you can use FTP or an SMTP-to-FTP gateway to actually > retrieve a file (without using a browser; some of us still do it that way :) > whereas browsing a file could mean using either FTP or HTTP to view a file > within a web browser. This should become clearer once the appendices mentioned > above are added, but alternate text to clear up confusion independent of > these appendices will be appreciated. When I used the term 'browsing' in the engineering meeting I meant it in the context of just looking around the repository. Obtaining means you know what you want specifically, browsing means your just looking around with some vague idea of what you want. -MM -- ------------------------------------------------------------------------------ Michael Mealling | 505 Huntmar Park Drive | Phone: (703)742-0400 Software Engineer | Herndon, VA 22070 | Fax: (703)742-9552 Network Solutions | | michaelm@rwhois.net From owner-ietf-schema-reg Thu Oct 23 07:14:23 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA21587 for ietf-schema-reg-bks; Thu, 23 Oct 1997 07:14:23 -0700 (PDT) Received: from ietf.org (ietf.org [132.151.1.19]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id HAA21576 for ; Thu, 23 Oct 1997 07:14:19 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id KAA15049; Thu, 23 Oct 1997 10:18:11 -0400 (EDT) Message-Id: <199710231418.KAA15049@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org From: Internet-Drafts@ietf.org cc: ietf-schema-reg@imc.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-apple-schema-file-list-00.txt Date: Thu, 23 Oct 1997 10:18:10 -0400 Sender: owner-ietf-schema-reg@imc.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Directory Schema Listing File Name Syntax Author(s) : C. Apple Filename : draft-apple-schema-file-list-00.txt Pages : 3 Date : 16-Oct-97 This memo specifies a file name syntax for use by the primary listing repository operator of the directory schema listing service. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-apple-schema-file-list-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-apple-schema-file-list-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-apple-schema-file-list-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971016155231.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-apple-schema-file-list-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-apple-schema-file-list-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971016155231.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-schema-reg Tue Oct 28 21:40:46 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id VAA21148 for ietf-schema-reg-bks; Tue, 28 Oct 1997 21:40:46 -0800 (PST) Received: from i.control.att.com (H-135-205-52-126.control.att.com [135.205.52.126] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id VAA21144 for ; Tue, 28 Oct 1997 21:40:41 -0800 (PST) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Wed, 29 Oct 1997 00:39:05 -0500 (EST) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for ietf-schema-reg@imc.org; Wed, 29 Oct 1997 00:39:05 -0500 (EST) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Wed, 29 Oct 1997 00:39:05 -0500 (EST) From: capple@master.control.att.com (Christopher W Apple) To: Mark Wahl , capple@master.control.att.com (Christopher W Apple) Cc: ietf-schema-reg@imc.org Subject: Re: pre-I-D meta data syntax spec Sender: owner-ietf-schema-reg@imc.org Precedence: bulk We've discussed the idea of using a profile of MIME-DIR on the engineering team list and think that meta data draft should indeed be converted to a be a profile of MIME-DIR, re-using the existing BNF and some of the text (subject to implementing Mark's recommended changes and corrections). Doing so will expedite deployment. I'll work on incorporating Mark's changes to the existing document this week and then convert it to a MIME-DIR profile document format early next week. Please raise any concerns you may have about this now by posting to the list. I don't plan on re-formatting the document a second time, so please try to raise concerns quickly. >5. Transfer form for meta-data > >A fair portion of section 2 and 3 define formatting rules. However, this >document does not appear to define a content type for transfer of this >meta-data. I would like to encourage the creation of MIME-DIR profile for >meta-data, since we would be using MIME-DIR for LDAP schema information. >This cuts down the amount of parsing code which would need to be written, and >issues of "safe" characters or wrapping lines are taken care of by MIME-DIR, >and thus need not be in this document. Much of section 3.0 could be removed. > >6. charset description label > >I assume in a content description labels can appear in any order. Thus, >there could be several textual fields in a meta-data before the charset field. >This means that a parser cannot display information until it has finished >parsing the content. > >If the MIME-DIR profile suggestion of point 5 were adopted, then this field >is not necessary, as MIME-DIR already includes a mechanism for indicating >character set in the Content Header, rather than in the content itself. Thanks! ------------------------------------------------------------------------ Chris Apple Business Site: AnyWho Directory Services Internet Directory Group http://www.anywho.com AT&T Laboratories capple@master.control.att.com +1 908 582 2409 Tired of slow directories? Try AnyWho. ------------------------------------------------------------------------ From owner-ietf-schema-reg Wed Oct 29 22:14:41 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id WAA12429 for ietf-schema-reg-bks; Wed, 29 Oct 1997 22:14:41 -0800 (PST) Received: from i.control.att.com (H-135-205-52-126.control.att.com [135.205.52.126] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id WAA12425 for ; Wed, 29 Oct 1997 22:14:36 -0800 (PST) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Thu, 30 Oct 1997 01:12:02 -0500 (EST) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for michaelm@rwhois.net; Thu, 30 Oct 1997 01:12:02 -0500 (EST) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Thu, 30 Oct 1997 01:12:02 -0500 (EST) From: capple@master.control.att.com (Christopher W Apple) To: Chris Weider , michaelm@rwhois.net, ietf-schema-reg@imc.org Cc: M.Wahl@critical-angle.com Subject: RE: proc doc Sender: owner-ietf-schema-reg@imc.org Precedence: bulk >I'm cool with inclusion by reference if our standard format tells the user >that those references are outside our control. >Chris I forgot one thing in the prior response to this message (actually two, I forgot to indicate in plain text who the other response was from!): + a meta data element needs to be added explaining that the use of the moreInfo meta data element, if present, points to external information outside of the control of the schema listing service; lets call it: "caveat" and give it a simple text value, tagged as English, and make it very similar to the text above. (I'm assuming that Michael's lawyers will give him general disclaimer text applicable to the whole service, so that's probably all we need to say here. If Michael's lawyers want to provide even this caveat text, they should be aware that it can't be changed willy-nilly since its in a spec and that they should get it right the first time.) ------------------------------------------------------------------------ Chris Apple Business Site: AnyWho Directory Services Internet Directory Group http://www.anywho.com AT&T Laboratories capple@master.control.att.com +1 908 582 2409 Tired of slow directories? Try AnyWho. ------------------------------------------------------------------------ From owner-ietf-schema-reg Thu Oct 30 14:31:29 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA25339 for ietf-schema-reg-bks; Thu, 30 Oct 1997 14:31:29 -0800 (PST) Received: from i.control.att.com (H-135-205-52-126.control.att.com [135.205.52.126] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA25334 for ; Thu, 30 Oct 1997 14:31:25 -0800 (PST) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Thu, 30 Oct 1997 17:30:30 -0500 (EST) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for ietf-schema-reg@imc.org; Thu, 30 Oct 1997 17:30:15 -0500 (EST) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Thu, 30 Oct 1997 17:30:15 -0500 (EST) From: capple@master.control.att.com (Christopher W Apple) To: ietf-schema-reg@imc.org Subject: MD5 Sender: owner-ietf-schema-reg@imc.org Precedence: bulk I found a reference for MD5: RFC1321. ------------------------------------------------------------------------ Chris Apple Business Site: AnyWho Directory Services Internet Directory Group http://www.anywho.com AT&T Laboratories capple@master.control.att.com +1 908 582 2409 Tired of slow directories? Try AnyWho. ------------------------------------------------------------------------ From owner-ietf-schema-reg Thu Oct 30 15:06:20 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA25772 for ietf-schema-reg-bks; Thu, 30 Oct 1997 15:06:20 -0800 (PST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.42]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA25768 for ; Thu, 30 Oct 1997 15:06:16 -0800 (PST) Received: by INET-02-IMC with Internet Mail Service (5.0.1459.27) id ; Thu, 30 Oct 1997 15:05:53 -0800 Message-ID: From: Chris Weider To: "'capple@master.control.att.com'" , ietf-schema-reg@imc.org Subject: RE: MD5 Date: Thu, 30 Oct 1997 15:02:49 -0800 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1459.27) Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Cool. Chris > -----Original Message----- > From: capple@master.control.att.com > [SMTP:capple@master.control.att.com] > Sent: Thursday, October 30, 1997 2:30 PM > To: ietf-schema-reg@imc.org > Subject: MD5 > > I found a reference for MD5: RFC1321. > > > ---------------------------------------------------------------------- > -- > Chris Apple Business Site: AnyWho Directory > Services > Internet Directory Group http://www.anywho.com > AT&T Laboratories > capple@master.control.att.com > +1 908 582 2409 Tired of slow directories? Try > AnyWho. > ---------------------------------------------------------------------- > -- From owner-ietf-schema-reg Thu Oct 30 22:48:16 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id WAA00240 for ietf-schema-reg-bks; Thu, 30 Oct 1997 22:48:16 -0800 (PST) Received: from att.com (kcgw1.att.com [192.128.133.151]) by mail.proper.com (8.8.7/8.7.3) with SMTP id WAA00236 for ; Thu, 30 Oct 1997 22:48:13 -0800 (PST) Received: by kcgw1.att.com; Fri Oct 31 00:44 CST 1997 Received: from i.control.att.com (i.control.att.com [135.205.52.126]) by kcig1.att.att.com (AT&T/GW-1.0) with ESMTP id AAA11472 for ; Fri, 31 Oct 1997 00:37:23 -0600 (CST) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Fri, 31 Oct 1997 01:46:45 -0500 (EST) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for michaelm@rwhois.net; Fri, 31 Oct 1997 01:46:09 -0500 (EST) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Fri, 31 Oct 1997 01:46:09 -0500 (EST) From: capple@master.control.att.com (Christopher W Apple) To: ietf-schema-reg@imc.org Cc: M.Wahl@critical-angle.com, cweider@microsoft.com, michaelm@rwhois.net Subject: just when you thought it was over... Sender: owner-ietf-schema-reg@imc.org Precedence: bulk I think there's one more area that we haven't explored adequately: what do we do about listing requests that are under review? After looking through all of the old mail from this list (and the big list), I've found that we talk about things that indicate we have an implicit understanding that pending requests/those-under-review, will be stored in the repository as well. This is especially apparent when you look back at the discussions about the "relatedTo" meta data element we had a while back. We decided to use temporary OIDs as schema listing request names. So, a few things come to mind: + none of the documents mention this explicitly -- they should + mentioning this explicitly means that there is a new file type required; I propose extending the file name syntax to include an additional possible value of "request" and to make the sequence "." version part of the file name syntax be more like this: filename = listing / request listing = "schema-" type "-" sequence "." version type = "metadata" / "ldap" / "whoispp" / "rwhois" sequence = request = "request-" temp "-" ddver ddver = DIGIT DIGIT ; initialized to "00" temp = ("x-" / "X-") (oid / guid) oid = guid = this means that meta data and listing content file stay the same whereas request file names look like this: request-x-1.1-00 + a request file would simply contain the listing request as it came across on the review mailing list, mail headers, content length, and multi-part MIME containers intact Is this overkill or necessary? BTW: I've incorporated all comments so far except the ones involving the process document and some of the stuff we discussed earlier this week. I'm waiting on any comments from the big list until monday before I convert the meta data document to a MIME-DIR profile. ------------------------------------------------------------------------ Chris Apple Business Site: AnyWho Directory Services Internet Directory Group http://www.anywho.com AT&T Laboratories capple@master.control.att.com +1 908 582 2409 Tired of slow directories? Try AnyWho. ------------------------------------------------------------------------ From owner-ietf-schema-reg Fri Oct 31 05:06:15 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id FAA05553 for ietf-schema-reg-bks; Fri, 31 Oct 1997 05:06:15 -0800 (PST) Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id FAA05549 for ; Fri, 31 Oct 1997 05:06:10 -0800 (PST) Received: (from michael@localhost) by bailey.dscga.com (8.8.2/8.8.2) id IAA21355; Fri, 31 Oct 1997 08:03:40 -0500 (EST) From: Michael Mealling Message-Id: <199710311303.IAA21355@bailey.dscga.com> Subject: Re: just when you thought it was over... In-Reply-To: from Christopher W Apple at "Oct 31, 97 01:46:09 am" To: capple@master.control.att.com (Christopher W Apple) Date: Fri, 31 Oct 1997 08:03:40 -0500 (EST) Cc: ietf-schema-reg@imc.org, M.Wahl@critical-angle.com, cweider@microsoft.com, michaelm@rwhois.net Reply-To: michaelm@rwhois.net X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Christopher W Apple said this: > I think there's one more area that we haven't explored adequately: > what do we do about listing requests that are under review? After > looking through all of the old mail from this list (and the big list), > I've found that we talk about things that indicate we have an implicit > understanding that pending requests/those-under-review, will be stored > in the repository as well. Be extremely careful with this. I know its policy and all but by actually having it in the repository, approved or not, you have, from the legal standpoing, already committed yourself to certain liabilities and obligations in certain jurisdictions (my fiancee is in law school and its starting to affect my word usage ;-). I personally would like to stay as far away as possible from this area by simply not putting schema that are in review in the repository. You can reference them in the metadata of the request but they are not "in the repository" yet. They are somewhere else, the review queue, the repository operators inbox, something else that isn't available to the public yet. > This is especially apparent when you look back at the discussions about > the "relatedTo" meta data element we had a while back. We decided to > use temporary OIDs as schema listing request names. So, a few things > come to mind: > > + none of the documents mention this explicitly -- they should > > + mentioning this explicitly means that there is a new file type > required; I propose extending the file name syntax to include > an additional possible value of "request" and to make > the sequence "." version part of the file name syntax be more > like this: > > filename = listing / request > > listing = "schema-" type "-" sequence "." version > > type = "metadata" / "ldap" / "whoispp" / "rwhois" > > sequence = > > request = "request-" temp "-" ddver > > ddver = DIGIT DIGIT ; initialized to "00" > > temp = ("x-" / "X-") (oid / guid) > > oid = > > guid = > > this means that meta data and listing content file stay the > same whereas request file names look like this: > > request-x-1.1-00 > > + a request file would simply contain the listing request as > it came across on the review mailing list, mail headers, content > length, and multi-part MIME containers intact This is fine as long as the repository doesn't make 'em available to the public. The only place they should be "available" is in the archives of the reviewing mailing list. > Is this overkill or necessary? Slight overkill. It really only means something to the members of the reviewing list and the initial repository insertion process which for a long time is going to be simply several humans with good mail filters. I can't think of a programatic reason for it, but then again it doesn't break anything and removes yet another possible area of ambiguity. Leave it in unless someone complains about it. And I'm not complaining about it. -MM -- ------------------------------------------------------------------------------ Michael Mealling | 505 Huntmar Park Drive | Phone: (703)742-0400 Software Engineer | Herndon, VA 22070 | Fax: (703)742-9552 Network Solutions | | michaelm@rwhois.net From owner-ietf-schema-reg Fri Oct 31 12:48:52 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA12177 for ietf-schema-reg-bks; Fri, 31 Oct 1997 12:48:52 -0800 (PST) Received: from att.com (cagw1.att.com [192.128.52.89]) by mail.proper.com (8.8.7/8.7.3) with SMTP id MAA12172 for ; Fri, 31 Oct 1997 12:48:48 -0800 (PST) Received: by cagw1.att.com; Fri Oct 31 15:43 EST 1997 Received: from i.control.att.com (root@i.control.att.com [135.205.52.126]) by caig1.att.att.com (AT&T/GW-1.0) with ESMTP id PAA18591 for ; Fri, 31 Oct 1997 15:39:21 -0500 (EST) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Fri, 31 Oct 1997 15:47:42 -0500 (EST) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for michaelm@rwhois.net; Fri, 31 Oct 1997 15:47:42 -0500 (EST) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Fri, 31 Oct 1997 15:47:42 -0500 (EST) From: capple@master.control.att.com (Christopher W Apple) To: michaelm@rwhois.net, capple@master.control.att.com (Christopher W Apple) Cc: ietf-schema-reg@imc.org, M.Wahl@critical-angle.com, cweider@microsoft.com Subject: Re: just when you thought it was over... Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Michael Mealling said this: >Christopher W Apple said this: >> I think there's one more area that we haven't explored adequately: >> what do we do about listing requests that are under review? After >> looking through all of the old mail from this list (and the big list), >> I've found that we talk about things that indicate we have an implicit >> understanding that pending requests/those-under-review, will be stored >> in the repository as well. > >Be extremely careful with this. I know its policy and all but by actually >having it in the repository, approved or not, you have, from the legal >standpoing, already committed yourself to certain liabilities and obligations >in certain jurisdictions (my fiancee is in law school and its starting >to affect my word usage ;-). I personally would like to stay as far >away as possible from this area by simply not putting schema that >are in review in the repository. You can reference them in the metadata of >the request but they are not "in the repository" yet. They are somewhere >else, the review queue, the repository operators inbox, something else that >isn't available to the public yet. OK. I understand. Make it clear that these are not considered to be a part of the repository. They will have to be in something like an archive for a mailing list. >> This is especially apparent when you look back at the discussions about >> the "relatedTo" meta data element we had a while back. We decided to >> use temporary OIDs as schema listing request names. So, a few things >> come to mind: >> >> + none of the documents mention this explicitly -- they should [stuff deleted that we probably don't need if we go with something like that proposed below] >> Is this overkill or necessary? > >Slight overkill. It really only means something to the members of >the reviewing list and the initial repository insertion process which >for a long time is going to be simply several humans with good mail >filters. I can't think of a programatic reason for it, but then again >it doesn't break anything and removes yet another possible area of >ambiguity. Leave it in unless someone complains about it. And I'm not >complaining about it. OK. How about we don't add the new file name syntax parts that deal with the "requast" files I was talking about, and use some free software to HTML-ize the review mailing list archive. This makes it easy for people to find related schema listing requests currently under review; which was really my goal in creating a different kind of file name. And we have to make a clear distinction between the website for the repository and the web site for the review mailing list archive both in documents and in the real world. Sound more reasonable? ------------------------------------------------------------------------ Chris Apple Business Site: AnyWho Directory Services Internet Directory Group http://www.anywho.com AT&T Laboratories capple@master.control.att.com +1 908 582 2409 Tired of slow directories? Try AnyWho. ------------------------------------------------------------------------ From owner-ietf-schema-reg Fri Oct 31 12:54:28 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA12261 for ietf-schema-reg-bks; Fri, 31 Oct 1997 12:54:28 -0800 (PST) Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA12257 for ; Fri, 31 Oct 1997 12:54:20 -0800 (PST) Received: (from michael@localhost) by bailey.dscga.com (8.8.2/8.8.2) id PAA22166; Fri, 31 Oct 1997 15:52:09 -0500 (EST) From: Michael Mealling Message-Id: <199710312052.PAA22166@bailey.dscga.com> Subject: Re: just when you thought it was over... In-Reply-To: from Christopher W Apple at "Oct 31, 97 03:47:42 pm" To: capple@master.control.att.com (Christopher W Apple) Date: Fri, 31 Oct 1997 15:52:09 -0500 (EST) Cc: michaelm@rwhois.net, capple@master.control.att.com, ietf-schema-reg@imc.org, M.Wahl@critical-angle.com, cweider@microsoft.com Reply-To: michaelm@rwhois.net X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Christopher W Apple said this: > Michael Mealling said this: > >Christopher W Apple said this: > >> I think there's one more area that we haven't explored adequately: > >> what do we do about listing requests that are under review? After > >> looking through all of the old mail from this list (and the big list), > >> I've found that we talk about things that indicate we have an implicit > >> understanding that pending requests/those-under-review, will be stored > >> in the repository as well. > > > >Be extremely careful with this. I know its policy and all but by actually > >having it in the repository, approved or not, you have, from the legal > >standpoing, already committed yourself to certain liabilities and obligations > >in certain jurisdictions (my fiancee is in law school and its starting > >to affect my word usage ;-). I personally would like to stay as far > >away as possible from this area by simply not putting schema that > >are in review in the repository. You can reference them in the metadata of > >the request but they are not "in the repository" yet. They are somewhere > >else, the review queue, the repository operators inbox, something else that > >isn't available to the public yet. > > OK. I understand. Make it clear that these are not considered to be > a part of the repository. They will have to be in something like an > archive for a mailing list. > > >> This is especially apparent when you look back at the discussions about > >> the "relatedTo" meta data element we had a while back. We decided to > >> use temporary OIDs as schema listing request names. So, a few things > >> come to mind: > >> > >> + none of the documents mention this explicitly -- they should > > > [stuff deleted that we probably don't need > if we go with something like that proposed below] > > >> Is this overkill or necessary? > > > >Slight overkill. It really only means something to the members of > >the reviewing list and the initial repository insertion process which > >for a long time is going to be simply several humans with good mail > >filters. I can't think of a programatic reason for it, but then again > >it doesn't break anything and removes yet another possible area of > >ambiguity. Leave it in unless someone complains about it. And I'm not > >complaining about it. > > OK. How about we don't add the new file name syntax parts that > deal with the "requast" files I was talking about, and use some free > software to HTML-ize the review mailing list archive. This makes it > easy for people to find related schema listing requests currently > under review; which was really my goal in creating a different kind of > file name. And we have to make a clear distinction between the > website for the repository and the web site for the review mailing list > archive both in documents and in the real world. > > Sound more reasonable? > Yep! I'm cool w'dat.... -MM -- ------------------------------------------------------------------------------ Michael Mealling | 505 Huntmar Park Drive | Phone: (703)742-0400 Software Engineer | Herndon, VA 22070 | Fax: (703)742-9552 Network Solutions | | michaelm@rwhois.net From owner-ietf-schema-reg Fri Oct 31 13:30:51 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA12716 for ietf-schema-reg-bks; Fri, 31 Oct 1997 13:30:51 -0800 (PST) Received: from att.com (kcgw1.att.com [192.128.133.151]) by mail.proper.com (8.8.7/8.7.3) with SMTP id NAA12711 for ; Fri, 31 Oct 1997 13:30:47 -0800 (PST) Received: by kcgw1.att.com; Fri Oct 31 15:27 CST 1997 Received: from i.control.att.com (root@i.control.att.com [135.205.52.126]) by kcig1.att.att.com (AT&T/GW-1.0) with ESMTP id PAA18086 for ; Fri, 31 Oct 1997 15:19:11 -0600 (CST) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Fri, 31 Oct 1997 16:29:09 -0500 (EST) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for michaelm@rwhois.net; Fri, 31 Oct 1997 16:29:08 -0500 (EST) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Fri, 31 Oct 1997 16:29:08 -0500 (EST) From: capple@master.control.att.com (Christopher W Apple) To: michaelm@rwhois.net, capple@master.control.att.com (Christopher W Apple) Cc: ietf-schema-reg@imc.org, M.Wahl@critical-angle.com, cweider@microsoft.com Subject: Re: just when you thought it was over... Sender: owner-ietf-schema-reg@imc.org Precedence: bulk >> OK. How about we don't add the new file name syntax parts that >> deal with the "requast" files I was talking about, and use some free >> software to HTML-ize the review mailing list archive. This makes it >> easy for people to find related schema listing requests currently >> under review; which was really my goal in creating a different kind of >> file name. And we have to make a clear distinction between the >> website for the repository and the web site for the review mailing list >> archive both in documents and in the real world. >> >> Sound more reasonable? >> > >Yep! I'm cool w'dat.... > >-MM Great! I think Paul Hoffman uses Hypermail 1.02 on the IMC web site to do this and it seems to work reasonably well. ------------------------------------------------------------------------ Chris Apple Business Site: AnyWho Directory Services Internet Directory Group http://www.anywho.com AT&T Laboratories capple@master.control.att.com +1 908 582 2409 Tired of slow directories? Try AnyWho. ------------------------------------------------------------------------ From owner-ietf-schema-reg Mon Nov 3 22:16:26 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id WAA29271 for ietf-schema-reg-bks; Mon, 3 Nov 1997 22:16:26 -0800 (PST) Received: from att.com (cagw1.att.com [192.128.52.89]) by mail.proper.com (8.8.7/8.7.3) with SMTP id WAA29267 for ; Mon, 3 Nov 1997 22:16:19 -0800 (PST) Received: by cagw1.att.com; Tue Nov 4 01:10 EST 1997 Received: from i.control.att.com (root@i.control.att.com [135.205.52.126]) by caig1.att.att.com (AT&T/GW-1.0) with ESMTP id BAA00862 for ; Tue, 4 Nov 1997 01:07:21 -0500 (EST) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Tue, 4 Nov 1997 01:16:04 -0500 (EST) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for ietf-asid@umich.edu; Tue, 4 Nov 1997 01:16:03 -0500 (EST) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Tue, 4 Nov 1997 01:16:03 -0500 (EST) From: capple@master.control.att.com (Christopher W Apple) To: ietf-asid@umich.edu, ietf-schema-reg@imc.org Cc: howes@netscape.com, paf@swip.net, cweider@microsoft.com, michaelm@rwhois.net Subject: Re: pre-I-D meta data syntax spec Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Frank Dawson wrote: > I believe it was decided that the character set parameter was to be removed > from MIME-Directory. Can anyone confirm this? Or say that this is not the case? ------------------------------------------------------------------------ Chris Apple Business Site: AnyWho Directory Services Internet Directory Group http://www.anywho.com AT&T Laboratories capple@master.control.att.com +1 908 582 2409 Tired of slow directories? Try AnyWho. ------------------------------------------------------------------------ From owner-ietf-schema-reg Tue Nov 4 09:07:17 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA08960 for ietf-schema-reg-bks; Tue, 4 Nov 1997 09:07:17 -0800 (PST) Received: from iceland.it.earthlink.net (iceland-c.it.earthlink.net [204.119.177.28]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA08954 for ; Tue, 4 Nov 1997 09:07:13 -0800 (PST) Received: from fdawson.lotus.com (ip185.raleigh2.nc.pub-ip.psi.net [38.30.39.185]) by iceland.it.earthlink.net (8.8.7/8.8.5) with SMTP id JAA14426; Tue, 4 Nov 1997 09:06:51 -0800 (PST) Message-Id: <199711041706.JAA14426@iceland.it.earthlink.net> Reply-To: "Frank Dawson" From: "Frank Dawson" To: "Christopher W Apple" , , Cc: , , , Subject: Re: pre-I-D meta data syntax spec Date: Tue, 4 Nov 1997 12:07:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1008.3 X-MimeOLE: Produced By Microsoft MimeOLE Engine V4.71.1008.3 Sender: owner-ietf-schema-reg@imc.org Precedence: bulk This was decided at the Memphis meeting. -----Original Message----- From: Christopher W Apple To: ietf-asid@umich.edu ; ietf-schema-reg@imc.org Cc: howes@netscape.com ; paf@swip.net ; cweider@MICROSOFT.com ; michaelm@rwhois.net Date: Tuesday, November 04, 1997 3:14 AM Subject: Re: pre-I-D meta data syntax spec Frank Dawson wrote: > I believe it was decided that the character set parameter was to be removed > from MIME-Directory. Can anyone confirm this? Or say that this is not the case? ------------------------------------------------------------------------ Chris Apple Business Site: AnyWho Directory Services Internet Directory Group http://www.anywho.com AT&ww.aT Laboratories capple@master.control.att.com +1 908 582 2409 Tired of slow directories? Try AnyWho. ------------------------------------------------------------------------ From owner-ietf-schema-reg Tue Nov 4 10:14:05 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA10168 for ietf-schema-reg-bks; Tue, 4 Nov 1997 10:14:05 -0800 (PST) Received: from att.com (kcgw1.att.com [192.128.133.151]) by mail.proper.com (8.8.7/8.7.3) with SMTP id KAA10147 for ; Tue, 4 Nov 1997 10:13:54 -0800 (PST) Received: by kcgw1.att.com; Tue Nov 4 12:10 CST 1997 Received: from i.control.att.com (root@i.control.att.com [135.205.52.126]) by kcig1.att.att.com (AT&T/GW-1.0) with ESMTP id MAA07294 for ; Tue, 4 Nov 1997 12:03:16 -0600 (CST) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Tue, 4 Nov 1997 13:13:12 -0500 (EST) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for ietf-asid@umich.edu; Tue, 4 Nov 1997 13:13:11 -0500 (EST) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Tue, 4 Nov 1997 13:13:11 -0500 (EST) From: capple@master.control.att.com (Christopher W Apple) To: "Frank Dawson" , "Christopher W Apple" , , Cc: , , , Subject: Re: pre-I-D meta data syntax spec Sender: owner-ietf-schema-reg@imc.org Precedence: bulk The current version of the MIME-DIR document (draft-ietf-asid-mime-direct-04.txt) was updated in July 1997 and states in paragraph 5.3 that charset is a REQUIRED MIME header parameter. After checking the meeting minutes from Memphis, I see this: "The final issue discussed was the use of the "charset" attribute parameter, allowing the character set to be set on individual values within a text/directory content-type. This was felt to be a bad thing and contrary to the MIME way of doing things and contrary to the IAB character set proclamation (thou shalt use UTF-8) by several people. After debate, the group decided to remove the "charset" attributes parameter and require the UTF-8 "charset" MIME header parameter be specified by default on text/directory content-types. The result of this is the loss of ability to switch charsets on a per-value basis within a text/directory component, but this is thought to be a good thing." The way which we are considering using a charset parameter is consistent with both the current MIME-DIR spec and the meeting minutes from Memphis. This will be more apparent after the meta data document is reformatted to comply with the MIME-DIR spec. > This was decided at the Memphis meeting. > >-----Original Message----- >From: Christopher W Apple >To: ietf-asid@umich.edu ; ietf-schema-reg@imc.org > >Cc: howes@netscape.com ; paf@swip.net ; >cweider@MICROSOFT.com ; michaelm@rwhois.net > >Date: Tuesday, November 04, 1997 3:14 AM >Subject: Re: pre-I-D meta data syntax spec > > > >Frank Dawson wrote: >> I believe it was decided that the character set parameter was to be >removed >> from MIME-Directory. > >Can anyone confirm this? Or say that this is not the case? > ------------------------------------------------------------------------ Chris Apple Business Site: AnyWho Directory Services Internet Directory Group http://www.anywho.com AT&ww.aT Laboratories capple@master.control.att.com +1 908 582 2409 Tired of slow directories? Try AnyWho. ------------------------------------------------------------------------ From owner-ietf-schema-reg Wed Nov 5 06:58:22 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id GAA28875 for ietf-schema-reg-bks; Wed, 5 Nov 1997 06:58:22 -0800 (PST) Received: from germany.it.earthlink.net (germany-c.it.earthlink.net [204.250.46.123]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id GAA28871 for ; Wed, 5 Nov 1997 06:58:15 -0800 (PST) Received: from fdawson.lotus.com (ip139.raleigh2.nc.pub-ip.psi.net [38.30.39.139]) by germany.it.earthlink.net (8.8.7/8.8.5) with SMTP id GAA17149; Wed, 5 Nov 1997 06:57:57 -0800 (PST) Message-Id: <199711051457.GAA17149@germany.it.earthlink.net> Reply-To: "Frank Dawson" From: "Frank Dawson" To: "Christopher W Apple" , , Cc: , , , Subject: Re: pre-I-D meta data syntax spec Date: Wed, 5 Nov 1997 09:58:41 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1008.3 X-MimeOLE: Produced By Microsoft MimeOLE Engine V4.71.1008.3 Sender: owner-ietf-schema-reg@imc.org Precedence: bulk I hope that folks on the mailing list aren't confusing the removal of the CHARSET attribute parameter *within* a MIME-Directory content with the CHARSET parameter on the Content-Type MIME header for "text/directory" content types! In Memphis we agreed to remove the CHARSET that, previously, was allowed within a MIME-Directory content on text values. For example, the attribute sequence: N;CHARSET=ISO-8859-1:Dawson;Frank;R.;Mr.;Jr. with the CHARSET attribute parameter is effected by this decision. Now you can only specify: N::Dawson;Frank;R.;Mr.;Jr. and the ISO Latin Alphabet Number One must be specified in the Content-Type MIME header sequence: Content-Type:text/directory;charset=ISO-8859-1 Everyone clear? And agree? - - Frank Dawson From owner-ietf-schema-reg Wed Nov 5 07:03:49 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA28968 for ietf-schema-reg-bks; Wed, 5 Nov 1997 07:03:49 -0800 (PST) Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id HAA28961 for ; Wed, 5 Nov 1997 07:03:45 -0800 (PST) Received: (from michael@localhost) by bailey.dscga.com (8.8.2/8.8.2) id KAA00548; Wed, 5 Nov 1997 10:01:32 -0500 (EST) From: Michael Mealling Message-Id: <199711051501.KAA00548@bailey.dscga.com> Subject: Re: pre-I-D meta data syntax spec In-Reply-To: <199711051457.GAA17149@germany.it.earthlink.net> from Frank Dawson at "Nov 5, 97 09:58:41 am" To: fdawson@earthlink.net Date: Wed, 5 Nov 1997 10:01:30 -0500 (EST) Cc: capple@master.control.att.com, ietf-asid@umich.edu, ietf-schema-reg@imc.org, howes@netscape.com, paf@swip.net, cweider@microsoft.com, michaelm@rwhois.net Reply-To: michaelm@rwhois.net X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Frank Dawson said this: [Charset iso-8859-1 unsupported, filtering to ASCII...] > Everyone clear? And agree? I didn't like it at the time and I still don't but I'm willing to let it slide for concensus' sake. -MM -- ------------------------------------------------------------------------------ Michael Mealling | 505 Huntmar Park Drive | Phone: (703)742-0400 Software Engineer | Herndon, VA 22070 | Fax: (703)742-9552 Network Solutions | | michaelm@rwhois.net From owner-ietf-schema-reg Wed Nov 5 07:18:15 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA29208 for ietf-schema-reg-bks; Wed, 5 Nov 1997 07:18:15 -0800 (PST) Received: from germany.it.earthlink.net (germany-c.it.earthlink.net [204.250.46.123]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id HAA29204 for ; Wed, 5 Nov 1997 07:18:11 -0800 (PST) Received: from fdawson.lotus.com (ip139.raleigh2.nc.pub-ip.psi.net [38.30.39.139]) by germany.it.earthlink.net (8.8.7/8.8.5) with SMTP id HAA01814; Wed, 5 Nov 1997 07:18:05 -0800 (PST) Message-Id: <199711051518.HAA01814@germany.it.earthlink.net> Reply-To: "Frank Dawson" From: "Frank Dawson" To: Cc: , , Subject: Re: pre-I-D meta data syntax spec Date: Wed, 5 Nov 1997 10:18:49 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1008.3 X-MimeOLE: Produced By Microsoft MimeOLE Engine V4.71.1008.3 Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Michael Mealling wrote, in part: "I didn't like it at the time and I still don't but I'm willing to let it slide for concensus' sake." I assume the part that you did not like was the removal of the CHARSET attribute parameter. Well, I agree. I know that this feature was found very useful by the MOPA and other groups in the Pacific Rim. However, some of the reviewers felt that this simplified character shifting approach flew in the face of ISO 2022 standards and also over simplified the issues of character set shifting. Having had to work with ISO 2022, I thought that it was a welcome simplification...but, I too "let it slide for concensus' sake." Did we make a mistake? - - Frank From owner-ietf-schema-reg Wed Nov 5 09:35:12 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA02595 for ietf-schema-reg-bks; Wed, 5 Nov 1997 09:35:12 -0800 (PST) Received: from att.com (kcgw1.att.com [192.128.133.151]) by mail.proper.com (8.8.7/8.7.3) with SMTP id JAA02584 for ; Wed, 5 Nov 1997 09:35:07 -0800 (PST) Received: by kcgw1.att.com; Wed Nov 5 11:32 CST 1997 Received: from i.control.att.com (root@i.control.att.com [135.205.52.126]) by kcig1.att.att.com (AT&T/GW-1.0) with ESMTP id LAA10045 for ; Wed, 5 Nov 1997 11:24:33 -0600 (CST) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Wed, 5 Nov 1997 12:34:27 -0500 (EST) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for ietf-asid@umich.edu; Wed, 5 Nov 1997 12:34:27 -0500 (EST) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Wed, 5 Nov 1997 12:34:27 -0500 (EST) From: capple@master.control.att.com (Christopher W Apple) To: "Frank Dawson" , "Christopher W Apple" , , Cc: , , , Subject: Re: pre-I-D meta data syntax spec Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Frank Dawson wrote: >and the ISO Latin Alphabet Number One must be specified in the Content-Type >MIME header sequence: > > Content-Type:text/directory;charset=ISO-8859-1 > >Everyone clear? And agree? I don't think we need to re-open this discussion. You replied to a posting of a pre-I-D document on the ietf-schema-reg mailing list. This posting was not based on a MIME-DIR profile. We made the decision to convert it to a MIME-DIR profile after your reply hit the mailing list. In your earlier posting, what you said was: "I believe it was decided that the character set parameter was to be removed from MIME-Directory." The current MIME-DIR spec does have something called a charset parameter that is intended for use in the Content-Type header. So, this statement was ambiguous (didn't mention that you were referring to the removal of a parameter intended for use inside of a MIME part) and this is what caused my confusion. Also this comment was not applicable to the document in question because, at the time, it was not a MIME-DIR profile. We could argue about the semantic distinctions between "charset" and the phrase "character set" but I don't think that would be productive. At any rate, I'll comply with draft-ietf-asid-mime-direct-04.txt. Sorry to have opened a can of worms. Lets close it quickly, lest they slither out. ------------------------------------------------------------------------ Chris Apple Business Site: AnyWho Directory Services Internet Directory Group http://www.anywho.com AT&T Laboratories capple@master.control.att.com +1 908 582 2409 Tired of slow directories? Try AnyWho. ------------------------------------------------------------------------ From owner-ietf-schema-reg Wed Nov 5 09:47:50 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA02868 for ietf-schema-reg-bks; Wed, 5 Nov 1997 09:47:50 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA02862 for ; Wed, 5 Nov 1997 09:47:45 -0800 (PST) Received: from eleanor.innosoft.com ("port 59864"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IPNA1KW12M9JF8FG@INNOSOFT.COM> for ietf-schema-reg@imc.org; Wed, 5 Nov 1997 09:46:39 PST Date: Wed, 05 Nov 1997 09:48:50 -0800 (PST) From: Chris Newman Subject: Re: pre-I-D meta data syntax spec In-reply-to: <199711051457.GAA17149@germany.it.earthlink.net> To: ietf-schema-reg@imc.org, IETF ASID Mailing List Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=thor.innosoft.com Sender: owner-ietf-schema-reg@imc.org Precedence: bulk On Wed, 5 Nov 1997, Frank Dawson wrote: > In Memphis we agreed to remove the CHARSET that, previously, was allowed > within a MIME-Directory content on text values. For example, the attribute > sequence: > > N;CHARSET=ISO-8859-1:Dawson;Frank;R.;Mr.;Jr. > > with the CHARSET attribute parameter is effected by this decision. Now you > can only specify: > > N::Dawson;Frank;R.;Mr.;Jr. > > and the ISO Latin Alphabet Number One must be specified in the Content-Type > MIME header sequence: > > Content-Type:text/directory;charset=ISO-8859-1 > > Everyone clear? And agree? Yes. This is a *vast* improvement. Without this change, every VCARD or mime directory processor would have to have a tightly integrated charset-conversion engine. With this change, VCARD processors can leverage existing MIME charset-conversion engines. Hopefully in ten years or so we can use only ISO 10646/UTF-8 -- something available in most modern operating systems. Then we could ditch those huge complex charset-conversion engines. Besides, if it's a text media type, it has to use a single charset. You'd have to make it application/directory if you wanted to switch charsets on the fly. - Chris From owner-ietf-schema-reg Wed Nov 5 21:28:58 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id VAA14760 for ietf-schema-reg-bks; Wed, 5 Nov 1997 21:28:58 -0800 (PST) Received: from att.com (cagw1.att.com [192.128.52.89]) by mail.proper.com (8.8.7/8.7.3) with SMTP id VAA14752 for ; Wed, 5 Nov 1997 21:28:53 -0800 (PST) Received: by cagw1.att.com; Thu Nov 6 00:23 EST 1997 Received: from i.control.att.com (root@i.control.att.com [135.205.52.126]) by caig1.att.att.com (AT&T/GW-1.0) with ESMTP id AAA17882 for ; Thu, 6 Nov 1997 00:20:05 -0500 (EST) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Thu, 6 Nov 1997 00:28:17 -0500 (EST) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for ietf-schema-reg@imc.org; Thu, 6 Nov 1997 00:28:16 -0500 (EST) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Thu, 6 Nov 1997 00:28:16 -0500 (EST) From: capple@master.control.att.com (Christopher W Apple) To: internet-drafts@ietf.org Cc: ietf-schema-reg@imc.org Subject: draft-apple-schema-proc-list-00.txt Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Please publish this I-D. Thanks! ------------------------------------------------------------------------ Chris Apple Business Site: AnyWho Directory Services Internet Directory Group http://www.anywho.com AT&T Laboratories capple@master.control.att.com +1 908 582 2409 Tired of slow directories? Try AnyWho. ------------------------------------------------------------------------ INTERNET-DRAFT C. Apple AT&T Laboratories Expires: May 6, 1998 M. Mealling Network Solutions, Inc. 6 November 1997 Directory Schema Listing Procedures Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This memo documents procedures for listing directory service schemas in a centrally operated, administered, and maintained repository. This repository will be available as a resource to directory protocol and service implementors to facilitate schema discovery. 1.0 Introduction There is a growing number of places where schema for Internet Directory Services are being defined, with varying degrees of documentation. This plethora of schemas is unavoidable in the light of the needs of different service communities, but it makes it difficult for directory service builders to find and make use of an existing schema that will serve their needs and increase interoperability with other systems. A listing service providing a single point of discovery for directory service schema will promote schema reuse, reduce duplication of effort, and thus promote Apple, Mealling [Page 1] INTERNET-DRAFT Directory Schema Listing Procedures 6 November 1997 directory service interoperability. Listed schema will be assiged a permanent serial number (similar to those assigned to RFCs) as a part of the listing process. This listing process was defined to ensure that schema writers can publish their schema in a public forum so that they will be re-used. The IETF schema listing service has public read access and restricted, moderated write access. Currently, this listing service is centrally operated, administered, and maintained by TBD. The schema listing repository is mirrored to ensure some level of redundancy for read access. This document defines schema listing procedures which use TBD as the primary listing repository operator. 1.1 Terms and Definitions Information Object - a descriptive abstraction of some real-world object Schema - a collection of definitions for related information objects Listing Meta Data - characteristics that differentiate one schema from another; used to catalog schema Listing Content - a formal specification of a schema using a profile of [MIMEDIR] created to provide a template for syntax and content transfer encoding of directory service protocol schema Schema Listing - the combination of listing meta data and all available listing content for a particular schema Repository - a database in which schema listings are stored Schema Listing Request - a schema listing formatted using [MIME] constructs that is submitted for consideration as a schema listing to be published in a repository Operator - an organization that administers and maintains a repository Primary Repository - the repository that masters the schema listings database Shadow Repository - a repository that mirrors the primary repository Contact Person - the name of the individual who holds the authority to update a schema listing and who should be contacted if questions Apple, Mealling [Page 2] INTERNET-DRAFT Directory Schema Listing Procedures 6 November 1997 or concerns arise related to a schema listing or schema listing request Listing Authority Contact - the name of the individual who holds authority to replace a contact person; can be either the contact person for a schema listing or an alternate contact within the organization to which the contact person belongs (this allows one person organizations to list schema) The terms for specifying requirement level described in [RFC2119] are used in this document. 2.0 Directory Schema Listing 2.1 Schema Listing Request Architecture Diagram Schema Writer | <-----------------schema listing request V Schema Listing Request Review List | V +-----------------------+ |Significant objections | YES |raised within 2 weeks? |----> Back to the drawing board.... +-----------------------+ | NO (List Moderator recommends that schema listing Schema Listing-->| be published subject to comments on list.) Request V +-----------------+ |Request meets | NO |all requirements?| ----> Back to the drawing board.... +-----------------+ | YES | <-----------------schema listing meta data V and listing content Repository Mirroring Agent | | ... | V V V +----------+ +----------+ +----------+ |Repository| |Repository| |Repository| where: 1 is the primary | 1 | | 2 | | n | 2..n are replicas +----------+ +----------+ +----------+ Listing of a new schema starts with the construction of a listing request. Schema writers send in schema listing requests to a Apple, Mealling [Page 3] INTERNET-DRAFT Directory Schema Listing Procedures 6 November 1997 moderated request review list. Following a comment period of 2 weeks, if no significant objections are raised (determined by the moderator), the moderator sends the listing request to the primary listing repository operator, subject to incorporation of relevant comments by the schema writer. Listing requests are checked to verify compliance with the requirements and conditions discussed below and assigned a permanent serial number. A mirroring agent replicates the new listing across the primary and mirrored copies of the listing repository database. The following sections describe the requirements and procedure. 2.2 Listing Requirements Listing requests are all expected to conform to various requirements laid out in the following sections. 2.2.1 Functionality Requirements Listings MUST include two different types of information: (1) listing meta data (2) listing content Listing meta data will be used to catalog the listed schema by characteristics that differentiate schema. Listing content MUST be limited to the specification of the schema itself. Different profiles containing listing content MAY be included in the same listing request. Listing content MUST actually function as a directory schema. Listing of schema that include listing content that does not function as a directory schema is PROHIBITED. 2.2.2 Naming Requirements All listings MUST have a valid OID as their name. The primary listing repository operator MUST construct an OID for each listing based on the combination of + a root OID obtained from IANA specifically for use in the schema listing service + a sequence number assigned to each schema Apple, Mealling [Page 4] INTERNET-DRAFT Directory Schema Listing Procedures 6 November 1997 listing by the primary repository operator + a version number assigned to each schema listing by the primary repository operator The schema writer MUST allocate a temporary name for all schema listing requests. This listing request name must based on one of the following: + an OID allocated from within an OID subtree which the schema writer or their organization administers + a GUID generated according to [GUIDGEN] or [GUIDOTHER] 2.2.3 Content Formatting and Transfer Encoding Requirements All schema listings MUST employ a common data format. Listing meta data and listing content format and transfer encoding MUST utilize appropriate [MIMEDIR] profiles. Currently, four [MIMEDIR] profiles have been defined for use in the schema listing service: [MIMELDAP] MUST be used to format and encode LDAPv3 listing content. [MIMEWHOIS] MUST be used to format and encode WHOIS++ listing content. [MIMERWHOIS] MUST be used to format and encode RWHOIS listing content. [METASYN] MUST be used to format and encode meta data for all schema listings and listing requests. Other [MIMEDIR] profiles MAY be defined for use in the schema listing service; this procedures document will be updated reflect such changes. 2.2.4 Security Requirements An analysis of security issues for listed schema SHOULD be performed prior to submitting a listing request. However, regardless of what security analysis has or has not been done, all descriptions of security issues MUST be as accurate as possible. In particular, a statement that there are "no security issues associated with this type" MUST not be confused with "the security issues associates with Apple, Mealling [Page 5] INTERNET-DRAFT Directory Schema Listing Procedures 6 November 1997 this type have not been assessed". There is absolutely NO REQUIREMENT that listed schema be secure or completely free from risks. Nevertheless, all known security risks SHOULD be identified in the listing request. The security considerations section of all requests is subject to continuing evaluation and modification, and in particular MAY be extended by use of the "comments on schema listings" mechanism described in subsequent sections. Some of the issues that SHOULD be looked at in a security analysis of a schema listing are: (1) A schema listing might include specifications mandating exposure of certain attributes which would result in compromising the privacy of an organization or individual. (2) A schema listing might be intended for use by applications requiring some sort of security assurances not provided by the schema specified in the listing content. 2.2.5 Usage and Implementation Non-requirements In the directory services environment, where information on the embedded schema knowledge of a directory client is frequently not available to a server, maximum interoperability is attained by restricting the schema used to those agreed upon by the large community of directory service technology developers and users. This was asserted in the past as a reason to limit the number of possible schema to one via standards processes and resulted in a change process with a significant hurdle and delay for those seeking to modify and extend standard schema to better suite their needs. Eventually, various individuals and organizations began using non- standard schema, making interoperability difficult to achieve. The need for "common" or "meta" schema listings does not require limiting the listing of new schema listings. If a limited set of schema is recommended for a particular application, that should be asserted by a separate intended use statement specific for the application and/or environment. As such, universal support and implementation of a schema is NOT a requirement for listing it. If, however, a schema is explicitly intended for limited use, this should be noted in its listing. Apple, Mealling [Page 6] INTERNET-DRAFT Directory Schema Listing Procedures 6 November 1997 2.2.6 Publication Requirements Requests for schema listed in the IETF schema listing service MAY be published as RFCs. The primary listing repository operator will retain copies of all schema listing requests that meet the requirements specified below and "publish" them as part of the schema listing repository. The listing of a schema does not imply endorsement, approval, or recommendation by the IETF or even certification that the specification is adequate for the intended use of the schema. To become Internet Standards, protocol, data objects, or whatever must go through the IETF standards process. This is too difficult and too lengthy a process for the convenient listing of schema. It is expected that applicability statements for particular applications will be published from time to time that recommend implementation of, and support for, schema that have proven particularly useful in those contexts. 2.3 Listing Procedure The following procedure has been implemented by the primary listing repository operator for review and approval of new schema listings. This is not a formal standards process, but rather an administrative procedure intended to foster re-use of directory services schema and to provide a method for collecting schema in a publicly accessible repository. Submitting listing requests can be done via mail, treating posting of a formatted request containing the specification of listing content (in all available types) and supporting material (meta data) to the ietf-schema-review@TBD list, as a first step. 2.3.1 Announcement and Community Review While listed schema are NOT REQUIRED to be published as RFCs, they MUST be posted to the ietf-schema-review@TBD list, allowing a review and comment period of at least 2 weeks. This is necessary to prevent the malicious as well as unintended introduction of obviously bogus or frivolous schema into the listing repository. Schema writers wishing to have their schema listed by the primary listing repository operator, MUST specify any such schema (one per request) according to one or more of the following [MIMEDIR] profiles: [MIMELDAP], [MIMEWHOIS], or [MIMERWHOIS]. Other such profiles may be defined elsewhere and this procedures document will Apple, Mealling [Page 7] INTERNET-DRAFT Directory Schema Listing Procedures 6 November 1997 be update to reflect such process changes. Listing meta data, as specified in [METASYN], MUST also be included in this request. A template for listing requests is specified in paragraph 2.8. Schema writers MUST use this template. Once written, the request should be sent to ietf-schema-review@TBD. 2.3.2 Community Review and Assessment At this stage of the schema listing process, a place holder, such as the ever popular TBD (to be determined) MAY be used in place of an actual OID value for the name of the schema specified in the listing request. Moderated discussions on the ietf-schema-review@TBD mailing list will enable a means of gauging concensus as to whether or not the schema being proposed is bogus. If there is no significant reason to believe that a schema is useful or if it appears to be a bogus or malicious request, the moderator will not submit a listing request to the primary listing repository operator; otherwise, they may do so. If the listing request is to be published, the temporary name (an OID or GUID) for the schema listing MUST be replaced with a constructed OID by the primary listing repository operator. 2.3.3 Primary Repository Operator Listing Provided that the schema listing request meets the requirements defined in paragraph 2.1, the ietf-schema-review@TBD list moderator will send a listing request to the primary repository operator, which will check the schema listing for validity, and make the schema listing available to the community. 2.4 Comments on Schema Listings Comments on listed schema may be submitted by members of the IETF community to for consideration by the rest of the community and the primary listing repository operator. These comments will be passed on to the owner of the schema if possible. Submitters of comments may request that their comment be attached to the schema listing itself. If the ietf-schema-review@TBD list moderator is able to establish concensus affirming the inclusion of such a comment, it will be made accessible in conjunction with the schema listing itself. 2.5 Location of List of Available Schema Schema listings will be posted in the anonymous FTP directory Apple, Mealling [Page 8] INTERNET-DRAFT Directory Schema Listing Procedures 6 November 1997 "ftp://TBD.host.name/schema/" and all listed schema will be listed in a periodically issued RFC. The schema listing content and other supporting material may also be published as an Informational RFC by sending it to "rfc-editor@isi.edu" (please follow the instructions to RFC authors [RFC1543]). 2.6 Primary Repository Operator Procedures for Listing Schemas Schema will be listed by the primary repository operator automatically and without any formal review as long as the following minimal conditions are met: (1) Schema MUST function as an actual directory service schema. In particular, generic database schema MUST NOT be listed. (2) All schema listings MUST have a valid OID as their name. (3) All schema listing requests MUST include both meta data and listing content. (4) Schema listing meta data MUST comply with [METASYN]. (5) Schema listing content MUST be compliant with at least one of the following [MIMEDIR] profiles: + [MIMELDAP] (for LDAPv3 schema specifications) + [MIMEWHOIS] (for WHOIS++ schema specifications) + [MIMERWHOIS] (for RWHOIS schema specifications) Other [MIMEDIR] profiles may be defined in the future and this document will be updated to reflect such additional profiles. (6) Equivalent schema listing content specified using different [MIMEDIR] profiles MAY be included in the same listing request. (7) Any security considerations given must not be obviously bogus. It is neither possible nor necessary for the primary listing repository operator to conduct a comprehensive security review of schema listings. However, the listing request review committee (the members of the listing request review mailing list) has the authority and expertise to identify obviously incompetent material and exclude it. (8) Schema listing requests MAY be signed using PGP/MIME as described in [RFC2015]. The primary listing repository Apple, Mealling [Page 9] INTERNET-DRAFT Directory Schema Listing Procedures 6 November 1997 operator MUST be able to accept schema listing requests in PGP/MIME messages, although they are NOT REQUIRED to validate or retain the signatures. (9) The listing request MUST be formatted according to paragraph 2.8. (10) If the listing request includes one or more external, URI-based references to information associated with the schema specified in the request, a fingerprint of this information MUST be included with each such reference as specified in [METASYN]. The schema writer must also include a special caveat meta data element (as specified in [METASYN]) if at least one such reference is included in the request. 2.7 Change Control Once a schema listing has been published by the primary repository operator, the contact person may request a change to its definition. The contact person for a listed schema is defined to be the person or organizational role or entity who submitted the original listing request. The change request follows the same procedure as the listing request (1) Publish the revised schema listing proposal on the ietf-schema-review@TBD list. (2) Leave at least two weeks for comments. (3) Publish using the primary listing repository operator after formal review if required. Changes SHOULD be requested only when there are serious omission or errors in the published specification. When review is required, a change request MAY be denied if it renders entities that were valid under the previous definition invalid under the new definition. However, the primary listing repository provider SHOULD attempt to verify the authority of a person claiming to be the contact for a schema listing to change it, prior to implementing such changes. The contact person for a schema MAY pass responsibility for the schema to another person or agency by informing the primary listing repository operator and the ietf-schema-announce list; this can be done without discussion or review. The IESG may reassign responsibility for a schema. The most common Apple, Mealling [Page 10] INTERNET-DRAFT Directory Schema Listing Procedures 6 November 1997 case of this will be to enable changes to be made to types where the contact person for the listing has died, moved out of contact, or is otherwise unable to make changes that are important to the community. Schema listings will not be deleted; schema which are no longer believed appropriate for use can be declared OBSOLETE by a change to their "intended use" field; such schema will be clearly marked in the lists published by the primary listing repository operator. 2.8 Listing Proposal Format To: ietf-schema-review@TBD Subject: schema listing request Content-Type: multipart/related; start=2@foo.com; boundary="boundary" Content-ID: top@foo.com --boundary Content-Type: text/directory; profile="schema-meta-0" Content-ID: 3@foo.com (meta data elements and values as specified in [METASYN] and embedded in a text/directory MIME component of profile "schema-meta-0") --boundary Content-Type: text/directory; profile="schema-ldap-0" Content-ID: 3@foo.com (a schema specification compliant with [MIMELDAP]) --boundary Content-Type: text/directory; profile="schema-whoispp-0" Content-ID: 4@foo.com (a schema specification compliant with [MIMEWHOIS]) --boundary Content-Type: text/directory; profile="schema-rwhois-0" Content-ID: 5@foo.com (a schema specification compliant with [MIMERWHOIS]) --boundary-- 2.9 Primary Repository Operator Responsibilities and Constraints The data residing in the repository is not the property of the repository operator. Since the schema actually listed are the intellectual property of the entities creating the listing, the repository operator cannot claim them as intellectual property. All Apple, Mealling [Page 11] INTERNET-DRAFT Directory Schema Listing Procedures 6 November 1997 meta data surrounding the system is considered to be either in the public domain or is owned by the IANA (or some other suitable entity). The repository operator can make no claims whatsoever of ownership over any data in the repository. The repository operator can also make no determinations of appropriateness or suitability of a schema to be listed. This responsibility rests solely with the members of the listing request review committee (the members of the review mailing list). If the list coordinator requests that the repository operator publish a schema listing, the repository operator MUST include the schema listing or be relieved of the reponsibility of running the repository. Currently, the ability to advertise products and services on the repository web site to recoup monies used in operating the service is allowed. At any time, the submittal committee make make a policy decision on the appropriateness of ads on the repository pages. 3.0 Security Considerations As described in [LISTRQMT], the subject of trust with respect to most aspects of the service involving the exchange of information (submitting a listing request, updating an existing schema listing, or retrieving a schema listing) is not addressed in this document. However, the primary schema listing repository operator will take reasonable steps to ensure that information associated with the service is as accurate and authentic as possible. If users of the schema listing service obtain and use schema from the repository, they SHOULD verify that any fingerprints contained as a part of the listing meta data for external references to related content outside of the repository are valid. This can be verified by computing the MD5 checksum of the referenced content and comparing it with the fingerprint value. If this verification fails, the user of this schema information can assume that this external content has changed after the listing was published. In any case, no repository operator has control over external content referenced by URIs in the meta data. Thus the establishment of trust as it relates to the validity of fingerprints and the content which they represent is the solely user's responsibility and is optional. 4.0 Acknowledgements The format and much of the content in this document is based on [RFC2048]. The engineering team for listing service requirements: Apple, Mealling [Page 12] INTERNET-DRAFT Directory Schema Listing Procedures 6 November 1997 Chris Apple - AT&T Labs Michael Mealling - NSI Sanjay Jain - Oracle John Strassner - Cisco Sam Sun - CNRI Mark Wahl - Critical Angle Chris Weider - Microsoft 4.0 References [FILESYN] C. Apple, "Directory Schema Listing File Name Syntax", INTERNET-DRAFT , October 1997. [GUIDGEN] P. Leach, R. Salz, "UUIDs and GUIDs", INTERNET-DRAFT , February 1997. [GUIDOTHER] Open Group CAE Specification C309 "DCE: Remote Procedure Call", August 1994. [LISTRQMT] C. Apple, "Directory Schema Listing Requirements", INTERNET-DRAFT , October 1997. [METASYN] C. Apple, "A MIME Directory Profile for Schema Listing Meta Data", INTERNET-DRAFT , TBP. [MIMELDAP] M. Wahl, "A MIME Directory Profile for LDAP Schema", INTERNET-DRAFT , October 1997. [MIMEWHOIS] TBP. [MIMERWHOIS] TBP. [RFC2015] M. Elkins, "MIME Security with Pretty Good Privacy (PGP)", RFC 2015, October 1996. [RFC2048] N. Freed, J. Klensin, J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, November 1997. 5.0 Authors' Address Chris Apple Room 2F-165 AT&T Laboratories 600 Mountain Ave Murray Hill, NJ 07974 US Apple, Mealling [Page 13] INTERNET-DRAFT Directory Schema Listing Procedures 6 November 1997 Phone: +1 908 582 2409 Fax: +1 908 582 3296 Email: capple@att.com Michael Mealling 505 Huntmar Park Drive Herndon, VA 22070 US Phone: +1 703 742 0400 Fax: +1 703 742 9552 Email: michaelm@rwhois.net This Internet-Draft expires on May 6, 1998. Apple, Mealling [Page 14] From owner-ietf-schema-reg Fri Nov 7 06:39:25 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id GAA16090 for ietf-schema-reg-bks; Fri, 7 Nov 1997 06:39:25 -0800 (PST) Received: from ietf.org (ietf.org [132.151.1.19]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id GAA16086 for ; Fri, 7 Nov 1997 06:39:21 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA05757; Fri, 7 Nov 1997 09:39:19 -0500 (EST) Message-Id: <199711071439.JAA05757@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org From: Internet-Drafts@ietf.org cc: ietf-schema-reg@imc.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-apple-schema-proc-list-00.txt Date: Fri, 07 Nov 1997 09:39:19 -0500 Sender: owner-ietf-schema-reg@imc.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Directorate Working Group of the IETF. Title : Directory Schema Listing Procedures Author(s) : M. Mealling, C. Apple Filename : draft-apple-schema-proc-list-00.txt Pages : 14 Date : 06-Nov-97 This memo documents procedures for listing directory service schemas in a centrally operated, administered, and maintained repository. This repository will be available as a resource to directory protocol and service implementors to facilitate schema discovery. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-apple-schema-proc-list-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-apple-schema-proc-list-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-apple-schema-proc-list-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971106140912.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-apple-schema-proc-list-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-apple-schema-proc-list-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971106140912.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-schema-reg Fri Nov 7 07:49:28 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA17193 for ietf-schema-reg-bks; Fri, 7 Nov 1997 07:49:28 -0800 (PST) Received: from i.control.att.com (H-135-205-52-126.control.att.com [135.205.52.126] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id HAA17183 for ; Fri, 7 Nov 1997 07:49:24 -0800 (PST) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Fri, 7 Nov 1997 10:48:28 -0500 (EST) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for ietf-schema-reg@imc.org; Fri, 7 Nov 1997 10:48:27 -0500 (EST) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Fri, 7 Nov 1997 10:48:27 -0500 (EST) From: capple@master.control.att.com (Christopher W Apple) To: internet-drafts@ietf.org Cc: ietf-schema-reg@imc.org Subject: draft-apple-schema-file-list-01.txt Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Please publish this update to draft-apple-schema-file-list-00.txt. ------------------------------------------------------------------------ Chris Apple Business Site: AnyWho Directory Services Internet Directory Group http://www.anywho.com AT&T Laboratories capple@master.control.att.com +1 908 582 2409 Tired of slow directories? Try AnyWho. ------------------------------------------------------------------------ INTERNET-DRAFT C. Apple AT&T Laboratories Expires: May 6, 1998 6 November 1997 Directory Schema Listing File Names Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This memo specifies a file name syntax for use by the primary listing repository operator of the directory schema listing service. 1.0 Introduction The fastest route to interoperable directory services is through standard object classes and attribute types. There is a growing number of places where schema for Internet Directory Services and Internet Operations are being defined, with varying degrees of documentation. This plethora of schema is unavoidable in the light of the needs of different service communities, but it makes it difficult for directory service builders to find and make use of an existing schema that will serve their needs and increase interoperability with other systems. A listing service providing a single point of discovery for directory service schema will promote schema reuse, reduce duplication of effort, and thus promote directory service interoperability. Schema listings will be stored in multiple files based on the different types of information associated with a listing: meta data and one or more syntax Apple [Page 1] INTERNET-DRAFT Directory Schema Listing File Names 6 November 1997 specifications. 1.1 Scope A file name syntax specification intended for use during the initial release of a directory schema listing service is inside the scope of this document. 1.2 Terms and Definitions Information Object - a descriptive abstraction of some real-world object Schema - a collection of definitions for related information objects Listing Meta Data - characteristics that differentiate one schema from another; used to catalog schema Listing Content - a formal specification of a schema using an appropriate [MIMEDIR] profile Schema Listing - the combination of listing meta data and all available listing content for a particular schema The terms for specifying requirement level described in [RFC2119] are used in this document. 2.0 File Name Syntax All file names for listing meta data and listing content MUST comply with the following BNF [RFC822] grammar: file-name = "schema-" type "-" sequence "." version type = "metadata" / "ldap" / ; these values "whoispp" / "rwhois" ; are defined for the ; initial release of the ; schema listing service sequence = NZDIGIT 0* ; initialized to one (1) for first ; schema listing ; increments by one (1) for each ; successive schema listing published NZDIGIT = Apple [Page 2] INTERNET-DRAFT Directory Schema Listing File Names 6 November 1997 DIGIT = version = 0* ["." version] Other possible values of the type component of a file name MAY be defined in the future to accomodate schema listings specified using [MIMEDIR] profiles other than those defined for containing LDAP [LDAPV3], WHOIS++ [RFC1835], and RWHOIS [RFC1714] schema listing content. 3.0 Security Considerations There are no known security concerns associated with the file name syntax specified in this document. 4.0 Acknowledgements Leslie Daigle of Bunyip Information Systems reviewed and provided valuable comments on the syntax specification content in this document. The schema listing service engineering team: Chris Apple - AT&T Labs Sanjay Sain - Oracle Michael Mealling - NSI John Strassner - Cisco Sam Sun - CNRI Mark Wahl - Critical Angle Chris Weider - Microsoft 5.0 References [LDAPV3] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol (Version 3)", INTERNET-DRAFT , August 1997. [MIMEDIR] T. Howes, M. Smith, "A MIME Content-Type for Directory Information", INTERNET-DRAFT , July 1997. [RFC822] D. Crocker, "Standard of the Format of ARPA-Internet Text Messages", STD 11, RFC 822, August 1982. [RFC1835] P. Deutsch, R. Schoultz, P. Faltstrom, C. Weider, "Architecture of the WHOIS++ Service", RFC 1835, August, 1995. Apple [Page 3] INTERNET-DRAFT Directory Schema Listing File Names 6 November 1997 [RFC1714] S. Williamson, M. Kosters,"Referral Whois Protocol (RWhois)", RFC 1714, November 1994 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Level", RFC 2119, March 1997. 6.0 Author's Address Chris Apple AT&T Laboratories 600 - 700 Mountain Ave., Room 2F-165 Murray Hill, NJ 07974-0636 USA E-Mail: capple@att.com Phone: +1 908 582 2409 FAX: +1 908 582 3296 This INTERNET-DRAFT expires on May 6, 1998. Apple [Page 4] From owner-ietf-schema-reg Fri Nov 7 23:24:36 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id XAA27377 for ietf-schema-reg-bks; Fri, 7 Nov 1997 23:24:36 -0800 (PST) Received: from i.control.att.com (H-135-205-52-126.control.att.com [135.205.52.126] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id XAA27373 for ; Fri, 7 Nov 1997 23:24:32 -0800 (PST) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Sat, 8 Nov 1997 02:23:38 -0500 (EST) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for ietf-schema-reg@imc.org; Sat, 8 Nov 1997 02:23:37 -0500 (EST) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Sat, 8 Nov 1997 02:23:37 -0500 (EST) From: capple@master.control.att.com (Christopher W Apple) To: internet-drafts@ietf.org Cc: ietf-schema-reg@imc.org Subject: draft-apple-schema-rqmts-list-03.txt Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Please publish the I-D included below as an update to draft-apple-schema-rqmts-list-02.txt. ------------------------------------------------------------------------ Chris Apple Business Site: AnyWho Directory Services Internet Directory Group http://www.anywho.com AT&T Laboratories capple@master.control.att.com +1 908 582 2409 Tired of slow directories? Try AnyWho. ------------------------------------------------------------------------ INTERNET-DRAFT C. Apple AT&T Laboratories Expires: May 8, 1998 8 November 1997 Directory Schema Listing Requirements Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This memo documents requirements for listing directory services schema in a centrally operated, administered, and maintained repository. This repository will be available as a resource to directory protocol and service implementors to facilitate schema discovery. 1.0 Introduction The fastest route to interoperable directory services is through standard object classes and attribute types. There is a growing number of places where schema for Internet Directory Services and Internet Operations are being defined, with varying degrees of documentation. This plethora of schema is unavoidable in the light of the needs of different service communities, but it makes it difficult for directory service builders to find and make use of an existing schema that will serve their needs and increase interoperability with other systems. A listing service providing a single point of discovery for directory service schema will promote Apple [Page 1] INTERNET-DRAFT Directory Schema Listing Requirements 8 November 1997 schema reuse, reduce duplication of effort, and thus promote directory service interoperability. The intent is to offer a schema listing service with public read access and restricted, moderated write access. Many hard-coded choices and constraints have been reflected in this requirements document for the purpose of expediting deployment. Future releases of the service may require an update of this document. Initially, such a listing service will be centrally operated, administered, and maintained. The schema listing repository database may also be mirrored to ensure some level of redundancy for read access in the event of service interruption. Eventually, the operations, administration, and maintenance of such a listing service may evolve to use a more distributed deployment scenario. The schema listing service is also intended to be largely automated, with minimal human involvement. Human involvement is likely to be limited to the following types of activities: + handling repository access problems + trouble resolution for computing and communications facilities + dealing with reasonable requests that fall outside of the scope of normal schema listing repository operations + reviewing schema listing requests on a mailing list prior to publishing in the listing repository Future releases of the service may automate some of these tasks. 1.1 Scope Requirements for the initial release of a directory schema listing service are inside the scope of this document. Specifications for syntaxes and grammars to be used in the initial release of the directory schema listing service are outside the scope of this document. Documentation of schema listing procedures is outside the scope of this document. 1.2 Terms and Definitions Information Object - a descriptive abstraction of some real-world object Schema - a collection of definitions for related information objects Apple [Page 2] INTERNET-DRAFT Directory Schema Listing Requirements 8 November 1997 Listing Meta Data - characteristics that differentiate one schema from another; used to catalog schema Listing Content - a formal specification of a schema using a profile of [MIMEDIR] created to provide a template for syntax and content transfer encoding of directory service protocol schema Schema Listing - the combination of listing meta data and all available listing content for a particular schema Repository - a database in which schema listings are stored Schema Listing Request - a schema listing formatted using [MIME] constructs that is submitted for consideration as a schema listing to be published in a repository Operator - an organization that administers and maintains a repository Primary Repository - the repository that masters the schema listings database Shadow Repository - a repository that mirrors the primary repository Contact Person - the name of the individual who holds the authority to update a schema listing and who should be contacted if questions or concerns arise related to a schema listing or schema listing request Listing Authority Contact - the name of the individual who holds authority to replace a contact person; can be either the contact person for a schema listing or an alternate contact within the organization to which the contact person belongs (this allows one person organizations to list schema) The terms for specifying requirement level described in [RFC2119] are used in this document. 1.3 Usage Scenarios 1.3.1 Location and Retrieval of the vCard Schema for LDAPv3 A user of the schema listing service wants to locate a copy of the vCard schema for LDAPv3 so that they can use it in a prototyping project. First, they point their web browser at a schema listing repository web site and download the list of available schema. Next, they use the search command on their browser to locate occurences of the string "vCard". The browser automatically scrolls down to the Apple [Page 3] INTERNET-DRAFT Directory Schema Listing Requirements 8 November 1997 appropriate place in the list of available schema and the user clicks on a link to view the listing meta data to verify that this is indeed the vCard schema for use with version 3 of the LDAP protocol. Included in the web-based representation of the listing meta data are ftp URLs pointing to available profiles containing listing content for this schema. The user clicks on the link for the profile that they can use. 1.3.2 Submission of a New Schema Listing via SMTP A schema writer wishes to list a schema they have created and prepares the listing meta data and listing content according to one or more appropriate [MIMEDIR] profiles. The schema writer will assign a temporary, unique schema name for the request. The schema writer sends an SMTP message including the listing meta data and all available listing content in multipart-related [MIME] format to a listing request review mailing list. After a short review period, the listing repository operator validates the request, and if properly formed, assigns a permanent, unique name to the listing and publishes it according to the listing procedures. An announcement of the newly published schema listing is sent to a mailing list reserved for this purpose. 2.0 Listing Service Requirements 2.1 Functional Requirements Listed schema MAY be published as an RFC. A list of available schema listings MUST be maintained. Schema listings MUST be named according to the namespace requirements defined in section 3. The listing service SHALL also maintain information about the schema, beyond its definition. This information is referred to as meta data and will consist of information used for cataloging schema in the listing repositories. The particular set of meta data elements used during the initial deployment of the listing service will be defined in other documents. Listing meta data and listing content MUST be parsable. 2.2 Operational Requirements The process of listing schema MUST be centralized for the initial deployment. Apple [Page 4] INTERNET-DRAFT Directory Schema Listing Requirements 8 November 1997 Updated schema listings SHALL be deprecated. A new schema listing name SHALL be allocated for each schema listing publication causing the deprectation of an existing schema listing. The listing repository MUST be centrally administered. The listing repository MAY be mirrored. The primary repository operator MUST obtain an OID subtree for which they hold sub-allocation authority for use in the schema listing service. Schema listing requests MAY be signed using PGP/MIME as described in [RFC2015]. The primary listing repository operator MUST be able to accept schema listing requests in PGP/MIME messages, although they are NOT REQUIRED to validate the signatures. The method for validating and determining trust of signatures is outside the scope of this document and is determined by the parties in the exchange. The method for determining and validating trust in an unsigned request is outside the scope of this document, as is the method for determining trust in schema listing repository or its content. A mailing list MUST be created for the purpose of submitting schema listing requests for review prior to publishing in the schema listing repository. The schema listing repository publication process MUST be moderated via this mailing list. Schema listing requests MUST be subjected to community review on this mailing list for a period of at least 2 weeks. If no comments are received, properly formed schema listing requests SHALL be published as schema listings; otherwise, the request MAY either denied or the schema listing MAY published subject to incorporation of comments. A mailing list MUST be created for announcing new and updated schema listings. A mailbox MUST be created for the purpose of receiving service trouble requests from users. Listing repository operators (of primary and shadow sites) MUST provide a free means of accessing the listing service consistent with the functions documented in paragraph 2.3. 2.3 Repository Access Functionality The following schema listing repository access protocols MUST be supported: FTP [RFC959], HTTP 1.1[RFC2044], and SMTP [RFC821]. Apple [Page 5] INTERNET-DRAFT Directory Schema Listing Requirements 8 November 1997 The following access functions are REQUIRED: a) browse and retrieve schema listing content, listing meta data, and a list of available schema listings: + via HTTP using an HTTP client such as a web browser + via FTP using clients such as a GUI- or command-line-based FTP client or a web browser + via SMTP using an SMTP-to-FTP gateway b) search a list of available schema listings: + via HTTP using an HTTP client to download a copy of the list and utilizing search capabilities of that client + via HTTP by accessing repository-based searching facilities capable of accepting keywords from the user and returning schema listing summaries containing those keywords c) add and update schema listings by submitting a formatted request to a mailing list for community review: + via SMTP using appropriate MIME constructs as described in section 4.0 Other access functions, including the following, MAY be supported, but will be defined in other documents in the future: a) search schema listing content b) search schema listing meta data 3.0 Listing Service Namespace Requirements The listing service namespace MUST be protocol-independent. The listing service namespace SHALL be based on OIDs. The listing service namespace SHALL consist of two different types of names: + schema listing names + schema listing request names Apple [Page 6] INTERNET-DRAFT Directory Schema Listing Requirements 8 November 1997 Specific requirements for each type of schema listing name follows. Schema listing names: + MUST be permanent + MUST be globally unique + MUST be publicly available + MUST NOT be recycled or re-used + MUST be created within the OID subtree reserved for use in the schema listing service and administered by the primary listing repository operator Schema listing request names: + MUST be globally unique + MUST be publicly available + MUST be considered temporary + SHALL be assigned by the schema writer + MUST be replaced with a permanent name prior to schema listing publication + MUST be based on one of the following: - an OID tree administered by the individual, organization, or organizational role acting as the schema writer - a GUID constructed according to [GUIDGEN] or [GUIDOTHER] 4.0 Listing Requirements Listing content SHALL be limited to the information actually required to specify and encode the schema for storage and transfer. Listing meta data SHALL be composed of information used to catalog schema listings. Meta data element syntax SHALL be defined based on the concept of tagged attribute type-value pairs. Apple [Page 7] INTERNET-DRAFT Directory Schema Listing Requirements 8 November 1997 Language tags as specified in [RFC1766] MUST be used in listing content and meta data. Meta data element values MUST be encoded using the UCS Transformation Format - 8 bit form [RFC2044]. For the purposes of submitting a listing request, listing content and meta data SHOULD be structured according to appropriate profiles of [MIMEDIR] defined in other documents. Content associated with a schema listing, but not stored in the schema listing repository (such as large copyright notices and vendor logo images) MAY be included by reference in the meta data. If such external references are included in a particular schema listing, a fingerprint of the external content generated prior to schema listing request creation MUST be included along with these references in the request. Details associated with the creation of these external content references, including the algorithm to be used for generation of a content fingerprint and the syntax of the reference, will be defined in the [MIMEDIR] profile used to format and encode listing meta data for storage and transfer. 5.0 Listing Storage Requirements Listing repository file names MUST be permanent, globally unique, and publicly available. Listing repository file names SHOULD be constructed in a manner that allows human and machine users to determine the nature of file content by inspecting the file names. Listing content and listing meta data MUST be stored in separate files. 6.0 Security Considerations 6.1 Compromisable Assets One or more of the following assets could be compromised if the service is attacked: + Listing meta data + Listing content + Repository Hardware & Software + Networking Facilities Connecting Repository to the Internet + Repository Mirror Sites 6.2 Attack Scenarios Apple [Page 8] INTERNET-DRAFT Directory Schema Listing Requirements 8 November 1997 Allowable methods for submitting schema listing requests are: a) sending an e-mail message to a mail box b) submitting requests using web-based forms Based on these request submission methods, there are a number of known repository attack scenarios that must be considered during the implementation of schema listing procedures and the software and operational processes required to support them. 6.2.1 Denial-of-Service Attack Scenarios Scenario A: someone could send in a large number of improperly formed requests Scenario B: someone could send in a large number of properly formed, but frivolous, useless, or trivial requests 6.2.2 Confuse-the-User Attack Scenarios Scenario A: someone could send in a large number of valid, but frivolous, useless, or trivial requests and some or all of these requests actually become listings in the repository Scenario B: someone could maliciously submit one or more slightly modified versions of existing schema listings which are popular or widely used 6.3 Security Requirements on Schema Listing Procedures The following contextual definitions apply to the requirements listed in the remainder of this paragraph: Verification - a process of determining authenticity of facts implied or explicitly specified by a contact person during the process of submitting a schema listing request; the methods used to implement such a process MAY or MAY NOT be based on an IETF-sanctioned security protocol; specification of the methods used to implement such a process as well as the trust relationships relevant to the process are outside the scope of this document. High-Quality Directory Schema - a directory schema that serves some useful purpose (e.g., a related set of attribute and object class definitions for holding information about people in a LDAP directory); a schema that is _not_ merely trivial or frivolous (e.g., a trivial schema might consist of a related set of attribute and object class definitions for holding information about the two possible binary bit values in a Apple [Page 9] INTERNET-DRAFT Directory Schema Listing Requirements 8 November 1997 directory). The schema listing procedures SHOULD be designed to enable: a) verification that all properly formed schema listing requests are submitted by the contact person claiming to originate them b) methods of ensuring that only properly-formed, high-quality directory schema are published in the schema listing repository c) verifcation that requests to change the identity of the contact person for a schema listing originate from the listing authority contact or the contact person d) coping with the situation in which the contact person and/or listing authority contact for a schema is no longer available or is unable to submit updates to the schema listing for which they hold update authority For the initial release of the service, there is NO REQUIREMENT on any participant, user, or application to retain signature information as it applies to an entire schema listing request. Fingerprints included with external content reference meta data elements MUST be retained and included in published listing request. Users of the schema listing service SHOULD verify that fingerprints of referenced content match corresponding fingerprints included with external references as a part of the published schema listing. If purported (included in the listing) and actual (computed by the user) fingerprints are different, users of the service SHOULD consider the possibility that the referenced content has changed since publication of the schema listing and that such a change could affect the way in which associated schema listing content can be used. Referenced content is outside of the control of the schema listing service. A caveat explaining this concept MUST be included in the meta data of all published listings if external references are included in corresponding listing requests. 7.0 Acknowledgements Leslie Daigle of Bunyip Information Systems and Chris Weider of Microsoft provided valuable comments on multiple versions of this document. Apple [Page 10] INTERNET-DRAFT Directory Schema Listing Requirements 8 November 1997 The engineering team for listing service requirements: Chris Apple - AT&T Labs Sanjay Jain - Oracle Michael Mealling - NSI John Strassner - Cisco Sam Sun - CNRI Mark Wahl - Critical Angle Chris Weider - Microsoft The members of the ietf-schema-reg@imc.org mailing list. 8.0 References [CHARSET] Internet Assigned Numbers Authority, "CHARACTER SETS", . [GUIDGEN] P. Leach, R. Salz, "UUIDs and GUIDs", INTERNET-DRAFT , February 1997. [GUIDOTHER] Open Group CAE Specification C309 "DCE: Remote Procedure Call", August 1994. [LDAPV3] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol (Version 3)", INTERNET-DRAFT , October 1997. [MIME] [RFC2045], [RFC2046], and [RFC2047]. [MIMEDIR] T. Howes, M. Smith, "A MIME Content-Type for Directory Information", INTERNET-DRAFT , July 1997. [RFC821] J. Postel, "Simple Mail Transfer Protocol", RFC 821, August 1982. [RFC959] J. Postel, J.K. Reynolds, "File Transfer Protocol", RFC 959, October 1985. [RFC1766] H. Alvestrand, "Tags for the Identification of Languages", RFC 1766, March 1995. [RFC2015] M. Elkins, "MIME Security with Pretty Good Privacy (PGP)", RFC 2015, October 1996. [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Level", March 1997. Apple [Page 11] INTERNET-DRAFT Directory Schema Listing Requirements 8 November 1997 [RFC2068] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners- Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997. [RFC2044] F. Yergeau, "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, October 1996. [RFC2045] N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC2046] N. Freed & N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [RFC2047] K. Moore, "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996. 9.0 Author's Address Chris Apple AT&T Laboratories 600 - 700 Mountain Ave., Room 2F-165 Murray Hill, NJ 07974-0636 USA E-Mail: capple@att.com Phone: +1 908 582 2409 FAX: +1 908 582 3296 This INTERNET-DRAFT expires on May 8, 1998. Apple [Page 12] From owner-ietf-schema-reg Sat Nov 8 08:26:46 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA03837 for ietf-schema-reg-bks; Sat, 8 Nov 1997 08:26:46 -0800 (PST) Received: from folder.critical-angle.com (eden-gw.critical-angle.com [206.81.238.241]) by mail.proper.com (8.8.7/8.7.3) with SMTP id IAA03833 for ; Sat, 8 Nov 1997 08:26:40 -0800 (PST) Received: (qmail 4386 invoked from network); 8 Nov 1997 16:23:57 -0000 Received: from folder.critical-angle.com (206.81.238.241) by folder.critical-angle.com with SMTP; 8 Nov 1997 16:23:57 -0000 From: Mark Wahl To: internet-drafts@ietf.org cc: ietf-schema-reg@imc.org Subject: draft-wahl-mime-schema-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 08 Nov 1997 10:23:56 -0600 Message-ID: <4384.879006236@folder.critical-angle.com> Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Attached is an updated Internet Draft. Please send it to the repositories. Thanks, Mark Wahl, Enterprise Directory Integration Critical Angle Inc. Network Working Group M. Wahl Request for Comments: DRAFT Critical Angle Inc. November 8, 1997 A MIME Directory Profile for LDAP Schema 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working docu- ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 2. Abstract This document defines a MIME directory profile [1] for holding an LDAP [2] schema. It is intended for communication with the Internet schema listing service [3]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [6]. 3. Overview This document defines how a MIME type may be used to transfer a single LDAPv3 schema definition. A schema for use with LDAPv3 consists of any number of object class, attribute type, matching rule and syntax definitions. These concepts are defined in the LDAPv3 protocol definition [2]. The schema may have a numeric OID assigned to it by a schema listing or registration service. A schema may import definitions from another schema. Schema imports are not, however, transitive. For example, a schema may contain a definition for a "modem" object class, which is to be defined as a subclass of the X.521 "device" object class. In this case, the schema must import the definitions of X.521. Wahl MIME Directory Profile for LDAP Schema Page 1 INTERNET-DRAFT draft-wahl-mime-schema-01.txt Nov. 1997 4. The "schema-ldap-0" MIME Directory Profile Registration This profile is identified by the following registration template information. To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME profile "schema-ldap-0" Profile name: schema-ldap-0 Profile purpose: To represent a schema defined for use with LDAPv3 servers. Profile types: SOURCE, ldapSchemas, attributeTypes, matchingRules, objectClasses, matchingRuleUse, ldapSyntaxes Profile special notes: The charset parameter MUST be present on the MIME content, and the value of this parameter MUST be "utf-8". This ensures that schema values can be used in LDAPv3 attribute values without a character set translation. Neither the "BEGIN" and "END" types nor type grouping are used in contents of this profile. All of the types in this profile with the exception of ldapSchemas may be multi-valued. Each value is present on its own contentline. Values may be present in any order, and need not be arranged by type. The "SOURCE" type is optional, and if values are present they SHOULD be URIs of the "ldap" form. If the URI is of the "ldap" form, the object indicated by the URI is a subschema entry. The use of other forms are reserved for future applications. In this version of the profile, exactly one value of the ldapSchemas type MUST be present. (Later versions of the profile may permit multiple ldapSchemas values to be present in a content.) Implementors should note that there will likely be values of the profile types in most contents much longer than 76 bytes. In addition, there may be non-ASCII characters and embedded CRLFs inside of values, which could require either quoting of the value or use of a content transfer encoding. If a contentline in a particular content contains a "context" parameter and the value of that parameter is not "ldap", then that contentline SHOULD be ignored. Intended usage: COMMON Wahl MIME Directory Profile for LDAP Schema Page 2 INTERNET-DRAFT draft-wahl-mime-schema-01.txt Nov. 1997 5. MIME Directory Type Registrations This document defines all the types, with the exception of "SOURCE" used in the schema-ldap-0 profile. The "SOURCE" type is defined in [1]. These types are primarily intended for use in the "schema-ldap-0" directory profile, although they may be applicable to other profiles defined in the future. 5.1. ldapSchemas To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type ldapSchemas Type name: ldapSchemas Type purpose: To represent the LDAPv3 attribute "ldapSchemas", defined in section A.1. Type encoding: 8bit Type valuetype: text, encoded according to the BNF of section A.4. Type special notes: Each value of this type specifies the contents of an LDAP schema definition. A definition of each object class, attribute, matching rule, matching rule use and syntax referenced in a value of ldapSchemas MUST either be defined in one of the schemas referenced in the "IMPORTS" field, or present in the content containing this value. Intended usage: COMMON 5.2. attributeTypes To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type attributeTypes Type name: attributeTypes Type purpose: To represent the LDAPv3 attribute "attributeTypes", defined in section 5.1.6 of [4]. Type encoding: 8bit Type valuetype: text, encoded according to the BNF of "AttributeTypeDescription" given in section 4.2 of [4]. Type special notes: Each value of the type specifies one LDAPv3 attribute type definition. The syntax and matching rules referenced in a value of attributeTypes MUST either be present in this content, or defined in one of the schemas referenced in the "IMPORTS" field of the ldapSchemas line. Intended usage: COMMON Wahl MIME Directory Profile for LDAP Schema Page 3 INTERNET-DRAFT draft-wahl-mime-schema-01.txt Nov. 1997 5.3. matchingRules To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type matchingRules Type name: matchingRules Type purpose: To represent the LDAPv3 attribute "matchingRules", defined in section 5.1.8 of [4]. Type encoding: 8bit Type valuetype: text, encoded according to the BNF of "MatchingRuleDescription" given in section 4.5 of [4]. Type special notes: Each value of the type specifies one matching rule definition. The syntax reference in a value of matchingRules MUST either be present in this content, or defined in one of the schemas referenced in the "IMPORTS" field of the ldapSchemas line. Intended usage: COMMON 5.4. objectClasses To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type objectClasses Type name: objectClasses Type purpose: To represent the LDAPv3 attribute "objectClasses", defined in section 5.1.7 of [4]. Type encoding: 8bit Type valuetype: text, encoded according to the BNF of "ObjectClassDescription" given in section 4.4 of [4]. Type special notes: Each value of the type specifies one LDAPv3 object class definition. The attributes and object classes referenced in a value of objectClasses MUST either be present in this content, or defined in one of the schema referenced in the "IMPORTS" field of the ldapSchemas line. Intended usage: COMMON 5.5. matchingRuleUse To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type matchingRuleUse Type name: matchingRuleUse Wahl MIME Directory Profile for LDAP Schema Page 4 INTERNET-DRAFT draft-wahl-mime-schema-01.txt Nov. 1997 Type purpose: To represent the LDAPv3 attribute "matchingRuleUse", defined in section 5.1.9 of [4]. Type encoding: 8bit Type valuetype: text, encoded according to the BNF of "MatchingRuleUseDescription" given in section 4.5 of [4]. Type special notes: Each value of the type specifies a relationship between a matching rule and attribute types. The matching rule and attribute types referenced in a value of matchingRuleUse MUST either be present in this content, or defined in one of the schemas referenced in the "IMPORTS" statement of the ldapSchemas line. Intended usage: COMMON 5.6. ldapSyntaxes To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type ldapSyntaxes Type name: ldapSyntaxes Type purpose: To represent the LDAPv3 attribute "ldapSyntaxes", defined in section 5.3.1 of [4]. Type encoding: 8bit Type valuetype: text, encoded according to the BNF of "SyntaxDescription" given in section 4.3.3 of [4]. Type special notes: Each value of this type specifies a single LDAPv3 attribute value syntax. Intended usage: COMMON 6. Example From: Whomever@wherever.com To: Someone@somewhere.com Subject: schema information MIME-Version: 1.0 Message-Id: Content-Type: text/directory; profile="schema-ldap-0";charset="utf-8" Content-Transfer-Encoding: Quoted-Printable Wahl MIME Directory Profile for LDAP Schema Page 5 INTERNET-DRAFT draft-wahl-mime-schema-01.txt Nov. 1997 ldapSchemas: ( 1.2.3.4 NAME 'bogus schema' CLASSES ( top $ thing ) = ATTRIBUTES ( objectClass $ name ) SYNTAXES ( = 1.3.6.1.4.1.1466.115.121.1.38 $ 1.3.6.1.4.1.1466.115.121.1.15 ) ) attributeTypes: ( 2.5.4.0 NAME 'objectClass' SYNTAX = 1.3.6.1.4.1.1466.115.121.1.38 ) objectClasses: ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass ) attributeTypes: ( 2.5.4.41 NAME 'name' SYNTAX = 1.3.6.1.4.1.1466.115.121.1.15{32768} ) objectClasses: ( 2.5.6.999 NAME 'thing' MUST name ) ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'String' ) ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' ) 7. Security Considerations A MIME body part containing an text/directory of the schema-ldap-0 profile may be incorporated in a digitally signed MIME content, which can be used to verify that the body part has not been modified in transit. When the signer has been certified by a trusted third party service, it may also be possible to verify the origin of the content. 8. Bibliography [1] "A MIME Content-Type for Directory Information", 07/24/1997, INTERNET DRAFT . [2] "Lightweight Directory Access Protocol (v3)", 08/21/1997, INTERNET DRAFT . [3] "Directory Schema Listing Requirements", 08/28/1997, INTERNET DRAFT . [4] "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", 08/21/1997, INTERNET DRAFT . [5] "The LDAP Data Interchange Format (LDIF) - Technical Specification", 07/25/1997, INTERNET DRAFT . [6] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119. 9. Authors Address Mark Wahl Critical Angle Inc. 4815 West Braker Lane #502-385 Austin, TX 78759 USA Phone: +1 512 372-3160 EMail: M.Wahl@critical-angle.com Wahl MIME Directory Profile for LDAP Schema Page 6 INTERNET-DRAFT draft-wahl-mime-schema-01.txt Nov. 1997 Appendix A This appendix defines two new attributes which could be present in an subschema entry. These attributes could be added to a future revision of the LDAP attribute definition [4]. A.1. ldapSchemas attribute type definition ( 1.3.6.1.4.1.1466.101.120.17 NAME 'ldapSchemas' SYNTAX 1.3.6.1.4.1.1466.115.121.1.56 USAGE directoryOperation ) Each value of the ldapSchemas attribute defines one schema. Its syntax, given in section A.2, contains the elements needed for an LDAPv3 server to correctly process operations which use the definitions from this syntax. A.2. LDAP Schema Definition syntax definition ( 1.3.6.1.4.1.1466.115.121.1.56 DESC 'LDAP Schema Definition' ) Values in this syntax are represented according to the following BNF: LdapSchema = "(" whsp numericoid whsp [ "NAME" qdescrs ] [ "OBSOLETE" whsp ] [ "IMPORTS" oids ] [ "CLASSES" oids ] [ "ATTRIBUTES" oids ] [ "MATCHING-RULES" oids ] [ "SYNTAXES" oids ] whsp ")" The numericoid field uniquely identifies the schema. A new OID should be assigned if any of the fields of the schema change. It is not possible to import definitions from a schema until an OID has been assigned to it. The "NAME" field contains optional human-readable labels for the schema. The "OBSOLETE" field is present if the schema is obsolete. The "IMPORTS" field lists the OIDs of other schemas which are to be incorporated by reference into this schema. It is an error to have an attribute type or object class defined in a schema with the same name but a different OID as an attribute type or object class in an imported schema. It is also an error to import from two schema definitions in which there are attribute types or object classes with the same names but different OIDs. Wahl MIME Directory Profile for LDAP Schema Page 7 INTERNET-DRAFT draft-wahl-mime-schema-01.txt Nov. 1997 The "CLASSES" field lists the OIDs of object classes defined in this schema. A schema need not contain any object class definitions. A schema must not contain two object class definitions of the same name but with different OIDs. The "ATTRIBUTES" field lists the OIDs of attribute types defined in this schema. A schema need not contain any object class definitions. A schema must not contain two attribute type definitions of the same name but with different OIDs. The "MATCHING-RULES" field lists the OIDs of matching rules defined in this schema. A schema need not contain any matching rules. The "SYNTAXES" field lists the OIDs of syntaxes defined in this schema. A schema need not contain any syntaxes. Wahl MIME Directory Profile for LDAP Schema Page 8 From owner-ietf-schema-reg Mon Nov 17 15:42:22 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA06064 for ietf-schema-reg-bks; Mon, 17 Nov 1997 15:42:22 -0800 (PST) Received: from i.control.att.com (H-135-205-52-126.control.att.com [135.205.52.126] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA06060 for ; Mon, 17 Nov 1997 15:42:15 -0800 (PST) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Mon, 17 Nov 1997 18:41:56 -0500 (EST) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for ietf-schema-reg@imc.org; Mon, 17 Nov 1997 18:41:51 -0500 (EST) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Mon, 17 Nov 1997 18:41:51 -0500 (EST) From: capple@master.control.att.com (Christopher W Apple) To: internet-drafts@ietf.org Cc: ietf-schema-reg@imc.org Subject: draft-apple-schema-mime-metadata-00.txt Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Please publish this I-D. ------------------------------------------------------------------------ Chris Apple Business Site: AnyWho Directory Services Internet Directory Group http://www.anywho.com AT&T Laboratories capple@master.control.att.com +1 908 582 2409 Tired of slow directories? Try AnyWho. ------------------------------------------------------------------------ INTERNET-DRAFT C. Apple AT&T Laboratories Expires: May 17, 1998 17 November 1997 Directory Schema Listing Meta Data Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This memo defines a MIME directory profile for content transfer and encoding of meta data elements used for cataloging schema listings in a directory schema listing service. 1.0 Introduction The fastest route to interoperable directory services is through standard object classes and attribute types. There is a growing number of places where schema for Internet Directory Services and Internet Operations are being defined, with varying degrees of documentation. This plethora of schema is unavoidable in the light of the needs of different service communities, but it makes it difficult for directory service builders to find and make use of an existing schema that will serve their needs and increase interoperability with other systems. A listing service providing a single point of discovery for directory service schema will promote schema reuse, reduce duplication of effort, and thus promote directory service interoperability. Meta data will be used to catalog Apple [Page 1] INTERNET-DRAFT Directory Schema Listing Meta Data 17 November 1997 and distinguish schema listings in this service. This document defines a [MIMEDIR] profile for meta data content transfer and encoding. 1.1 Terms and Definitions Information Object - a descriptive abstraction of some real-world object Schema - a collection of definitions for related information objects Listing Meta Data - characteristics that differentiate one schema from another; used to catalog schema Listing Content - a formal specification of a schema using a profile of [MIMEDIR] Schema Listing - the combination of listing meta data and all available listing content for a particular schema Repository - a database in which schema listings are stored Schema Listing Request - a schema listing formatted using [MIME] constructs that is submitted for consideration as a schema listing to be published in a repository Operator - an organization that administers and maintains a repository Primary Repository - the repository that masters the schema listings database Shadow Repository - a repository that mirrors the primary repository Contact Person - the name of the individual who holds the authority to update a schema listing and who should be contacted if questions or concerns arise related to a schema listing or schema listing request Listing Authority Contact - the name of the individual who holds authority to replace a contact person; can be either the contact person for a schema listing or an alternate contact within the organization to which the contact person belongs (this allows one person organizations to list schema) The terms for specifying requirement level described in [RFC2119] are used in this document. Apple [Page 2] INTERNET-DRAFT Directory Schema Listing Meta Data 17 November 1997 2.0 The "schema-metadata-0" MIME Directory Profile Registration This profile is identified by the following registration template information. To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME profile "schema-metadata-0" Profile Name: schema-metadata-0 Profile Purpose: To represent meta data for a schema listing stored in the repository or a schema listing request under community review. Profile Types: listingName, schemaTitle, schemaUse, availableProfile, relatedTo, contactLanguage, contactName, contactEmail, contactPhone, contactAddress, authLanguage, authName, authEmail, authPhone, authAddress, contentURL, security, created, moreInfo, caveat, listingComments Profile Special Notes: The charset parameter MUST be present in the MIME content header and the value of this parameter MUST be "utf-8". Neither the "BEGIN", "END", nor "SOURCE" type is used in the contents of this profile. Type grouping is not used in the contents of this profile. Each MIME Directory Type Registration that follows in section 3 of this document includes a specification of whether or not a particular type is constrained to be single-valued or permitted to be multi-valued. Types that are permitted to be multi-valued MUST have at least one value, unless otherwise noted in the 'Type special notes' component of a type definition. Implementors should note that there will likely be values of profile types in some contents much longer than 76 bytes. In addition, there may be non-ASCII characters and embedded CRLFs inside of values, which could require either quoting of the value or use of a content transfer encoding. The following types MUST be included by schema writers in all schema listing requests: listingName, schemaTitle, schemaUse, availableProfile, contactLanguage, contactName, contactEmail, Apple [Page 3] INTERNET-DRAFT Directory Schema Listing Meta Data 17 November 1997 contactPhone, contactAddress, authLanguage, authName, authEmail, authPhone, authAddress, moreInfo, and security. The 'listingName' type value provided by the schema writer is temporary and only intended for use during the schema listing request review period. The permanent 'listingName' type value MUST be created by the primary listing repository operator. The 'relatedTo' type value MUST be provided by the schema writer as a part of the schema listing request if the schema listing proposed in the request has a relationship to published schema listings and/or other schema listing requests being review. If one or more schema writers are submitting a set of related schema listing requests in parallel, the production of the 'relatedTo' type value MUST be used, rather than the production. The following types MUST be provided by the primary schema listing repository operator and MUST NOT be accepted from the schema writer: contentURL, created, and listingComments. Intended Usage: COMMON 3.0 MIME Directory Type Registrations This document defines all types use in the schema-metadata-0 profile. These types are intended for use in the "schema-metadata-0" profile, although they may be applicable to other profiles defined in the future. 3.1 listingName To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type listingName Type name: listingName Type purpose: To represent a globally unique identifier for the schema listing name. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): Apple [Page 4] INTERNET-DRAFT Directory Schema Listing Meta Data 17 November 1997 name = permanent / temp permanent = oid "." sequence "." version ; a permanent schema listing name assigned ; the primary listing repository operator oid = oid-component *("." oid-component) oid-component = 1*DIGIT DIGIT = sequence = NZDIGIT *DIGIT NZDIGIT = version = version-component *("." version-component) version-component = 1*DIGIT temp = ("x-" / "X-") (oid/guid) ; a temporary schema listing request ; name assigned by a schema writer during ; creation of a listing request guid = Type special notes: This type MUST be single-valued. A language parameter MUST NOT be used with this type. For published schema listings, a value of this type is an OID constructed by the primary listing repository operator based on a root OID administered by the operator, a listing sequence number generated by the operator, and a listing version number assigned by the operator. For schema listing requests a value of this type is an OID assigned by or a GUID generated by the schema writer creating the request with an appropriate prefix to indicate that it is a temporary schema listing name. 3.2 schemaTitle To: ietf-mime-direct@imc.org Apple [Page 5] INTERNET-DRAFT Directory Schema Listing Meta Data 17 November 1997 Subject: Registration of text/directory MIME type schemaTitle Type name: schemaTitle Type purpose: To represent a real world title of a listed schema. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): utf8-text = 1* Type special notes: This type MAY be multi-valued. A language parameter MUST be used with this type. A value of this type MAY contain local or native version numbers or other version indicators for listed schema. Such schema version information MUST be treated as opaque by implementors. 3.3 schemaUse To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type schemaUse Type name: schemaUse Type purpose: To represent a statement of intended use for a listed schema. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): utf8-text = 1* Type special notes: This type MAY be multi-valued. A language parameter MUST be used with this type. A value of this type is an in-line text description of the intended Apple [Page 6] INTERNET-DRAFT Directory Schema Listing Meta Data 17 November 1997 use of a listed schema and MAY include embedded CRLF characters. 3.4 availableProfile To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type availableProfile Type name: availableProfile Type purpose: To represent a file name in the schema listing repository for an available schema specification constructed using an appropriate profile of [MIMEDIR]. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): profile = ; all [FILESYN] values except "metadata" ; MAY be used to construct values Type special notes: This type MAY be multi-valued. A language parameter MUST NOT be used with this type. Currently, there are three [MIMEDIR] profiles defined for containing schema specifications: [MIMELDAP], [MIMEWHOIS], and [MIMERWHOIS]. Additional profiles may be defined in other documents. Each of these profiles is identified by a sort text string representative of the profile name. 3.5 relatedTo To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type relatedTo Type name: relatedTo Type purpose: To represent an indication of a relationship of published schema listing or schema listing request with another published schema listing or schema listing request. Type encoding: 8bit Apple [Page 7] INTERNET-DRAFT Directory Schema Listing Meta Data 17 November 1997 Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): related = (md-filename / req-filename) *SPACE "$" *SPACE related-option md-filename = req-filename = related-option = "obsoletes" / "obsoleted-by" / "updates" / "inherits" / vendor-option vendor-option = ("x-" / "X-") vendor-name "-" vendor-specific-relationship vendor-name = 1*TOKEN vendor-specific-relationship = 1*TOKEN TOKEN = CHAR = specials = "(" / ")" / "<" / ">" / "@" ; MUST be in quoted- / "," / ";" / ":" / "\" / <"> ; string, to use / "." / "[" / "]" ; within a word <"> = SPACE = CRLF = CR LF CR = LF = CTL = Type special notes: This type MAY be multi-valued. If a schema listing is related to different schema listing, this type is REQUIRED, otherwise the use of this type is OPTIONAL. Apple [Page 8] INTERNET-DRAFT Directory Schema Listing Meta Data 17 November 1997 A language parameter MUST NOT be used with this type. This type is used to indicate relationships between published schema listings and schema listing requests as well as between one or more schema listing requests being submitted for review in parallel. Examples of such relationships include deprecation, revision, inheritance, and those specific to a particular vendor. If a schema listing request is related to another request, a value of this type MUST be assigned a temporary value relavent to the related request by the schema writer. Temporary values of this type MUST be subsequently replaced with a permanent value by the primary listing repository operator prior to publication of the listing. 3.6 contactLanguage To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type contactLanguage Type name: contactLanguage Type purpose: To represent a language understood by the contact person, organization, or role for a schema listing. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): c-lang = Type special notes: This type MAY be multi-valued. A language parameter MUST NOT be used with this type. 3.7 contactName To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type contactName Type name: contactName Type purpose: To represent the name of the contact person, organization, or role for a schema listing. Apple [Page 9] INTERNET-DRAFT Directory Schema Listing Meta Data 17 November 1997 Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): utf8-text = 1* Type special notes: This type MUST be single-valued. A language parameter MUST NOT be used with this type. 3.8 contactEmail To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type contactEmail Type name: contactEmail Type purpose: To represent the electronic mail address of the contact person, organization, or role for a schema listing. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): c-email = local-part "@" domain-part domain-part = sub-domain *("." sub-domain) sub-domain = 1* CHAR = specials = "(" / ")" / "<" / ">" / "@" ; MUST be in quoted- / "," / ";" / ":" / "\" / <"> ; string, to use / "." / "[" / "]" ; within a word <"> = SPACE = CRLF = CR LF CR = Apple [Page 10] INTERNET-DRAFT Directory Schema Listing Meta Data 17 November 1997 LF = CTL = Type special notes: This type MUST be single-valued. A language parameter MUST NOT be used with this type. 3.9 contactPhone To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type contactPhone Type name: contactPhone Type purpose: To represent the voice telephone number of the contact person, organization, or role for a schema listing. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): c-phone = 1* ; MUST use full international form (e.g., +1 908 582 2409) CHAR = CRLF = CR LF CR = LF = CTL = Type special notes: This type MUST be single-valued. A language parameter MUST NOT be used with this type. 3.10 contactAddress To: ietf-mime-direct@imc.org Apple [Page 11] INTERNET-DRAFT Directory Schema Listing Meta Data 17 November 1997 Subject: Registration of text/directory MIME type contactAddress Type name: contactAddress Type purpose: To represent the postal address of the contact person, organization, or role for a schema listing. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): c-addr = postal-string *5(*SPACE "$" *SPACE postal-string) postal-string = 1* SPACE = Type special notes: This type MUST be single-valued. A language parameter MUST NOT be used with this type. 3.11 authLanguage To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type authLanguage Type name: authLanguage Type purpose: To represent the language understood by the listing authority contact for a schema listing. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): lac-lang = Type special notes: This type MAY be multi-valued A language paramter MUST NOT be used with this type. Apple [Page 12] INTERNET-DRAFT Directory Schema Listing Meta Data 17 November 1997 3.12 authName To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type authName Type name: authName Type purpose: To represent the name of the listing authority contact for a schema listing. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): utf8-text = 1* Type special notes: This type MUST be single-valued. A language parameter MUST NOT be used with this type. The value of this type MAY be identical to the value of the 3.13 authEmail To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type authEmail Type name: authEmail Type purpose: To represent the electronic mail address of the listing authority contact for a schema listing. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): c-email = local-part "@" domain-part domain-part = sub-domain *("." sub-domain) sub-domain = 1* Apple [Page 13] INTERNET-DRAFT Directory Schema Listing Meta Data 17 November 1997 CHAR = specials = "(" / ")" / "<" / ">" / "@" ; MUST be in quoted- / "," / ";" / ":" / "\" / <"> ; string, to use / "." / "[" / "]" ; within a word <"> = SPACE = CRLF = CR LF CR = LF = CTL = Type special notes: This type MUST be single-valued. A language parameter MUST NOT be used with this type. The value of this type MAY be identical to the value of the 3.14 authPhone To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type authPhone Type name: authPhone Type purpose: To represent the voice telephone number of the listing authority contact for a schema listing. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): lac-phone = 1* ; MUST use full international form (e.g., +1 908 582 2409) CHAR = CRLF = CR LF Apple [Page 14] INTERNET-DRAFT Directory Schema Listing Meta Data 17 November 1997 CR = LF = CTL = Type special notes: This type MUST be single-valued. A language parameter MUST NOT be used with this type. The value of this type MAY be identical to the value of the 3.15 authAddress To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type authAddress Type name: authAddress Type purpose: To represent the postal address of the listing authority contact for a schema listing. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): lac-addr = postal-string *5(*SPACE "$" *SPACE postal-string) postal-string = 1* SPACE = Type special notes: This type MUST be single-valued. A language parameter MUST NOT be used with this type. The value of this type MAY be identical to the value of the 3.16 contentURL To: ietf-mime-direct@imc.org Apple [Page 15] INTERNET-DRAFT Directory Schema Listing Meta Data 17 November 1997 Subject: Registration of text/directory MIME type contentURL Type name: contentURL Type purpose: To represent a URL corresponding to an available profile of a schema listing. Type encoding: 8bit Type valuetype: uri, formatted as a URL [RFC1738]. Type special notes: This type MAY be multi-valued. A language parameter MUST NOT be used with this type. 3.17 security To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type security Type name: security Type purpose: To represent a description of security considerations for a single available profile of listing content. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): utf8-text = 1* Type special notes: This type MAY be multi-valued. This type MUST have at least one value for each available profile. A language parameter MUST be used with this type. A value of this type is an in-line text description of security considerations for a single available profile of a listed schema and MAY include embedded CRLF characters. Apple [Page 16] INTERNET-DRAFT Directory Schema Listing Meta Data 17 November 1997 3.18 created To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type created Type name: created Type purpose: To represent the date and time at which a schema listing was published. Type encoding: 8bit Type valuetype: date-time, with the following syntax (specified using the BNF in [RFC822]): created = date "T" time "Z" date = 4DIGIT "-" 2DIGIT "-" 2DIGIT ; year-month-day ; e.g., 1997-08-27 time = 2DIGIT ":" 2DIGIT ":" 2DIGIT ; hh:mm:ss ; e.g., 00:00:00 thru 23:59:59 ; MUST be based on GMT DIGIT = Type special notes: This type MUST be single-valued. A language parameter MUST NOT be used with this type. 3.19 moreInfo To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type moreInfo Type name: moreInfo Type purpose: To represent a labeled reference to external content (not stored in the schema listing repository) related to a schema listing. Type encoding: 8bit Apple [Page 17] INTERNET-DRAFT Directory Schema Listing Meta Data 17 November 1997 Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): more = uri *SPACE "(" label ")" ; MAY be multi-valued or single-valued uri = ; in this case the URI is constrained to ; be a URL as specified in [RFC1738] label = option [*SPACE "$" *SPACE checksum] ; only one option is allowed per instance ; of this multi-valued meta data element option = "opaque-schema" / "copyright" / "licensing" / "general" / "image" ; this set of options is intended for use in the initial release ; of the schema listing service additional options may be ; defined in other documents ; "opaque-schema" signifies that a profile of [MIMEIR] or other ; syntax specification for a schema is being referenced checksum = > ; the MD5 checksum MUST be generated in according to ; [GUIDGEN] or [GUIDOTHER] Type special notes: This type MAY be multi-valued. A language parameter MUST be used with this type. The use of this type is REQUIRED if a schema writer wishes to include references to external content related to a schema listing. Otherwise, this type MUST NOT be used in forming schema listing requests or published schema listings. The rationale for including these external references MAY be related to extensive copyright or right-to-use statements, a requirement external to the schema listing service for vendor branding of a listed schema, or a schema specification of a form not expressable using a [MIMEDIR] profile currently supported by the schema listing service. 3.20 caveat To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type caveat Apple [Page 18] INTERNET-DRAFT Directory Schema Listing Meta Data 17 November 1997 Type name: caveat Type purpose: To represent a caveat explaining that content obtained by following external references to information not stored in the schema listing repository is outside of the control of the repository. Type encoding: 8bit Type valuetype: text, consisting of the following in-line text value: Information obtained by following external content references expressed using the moreInfo type are outside of the control of the schema listing service operators. Users of this information should be aware that it is possible for this information to change after the referencing schema listing has been published. Type special notes: This type MAY be multi-valued. A language parameter MUST be used with this type. The use of this type is REQUIRED if a schema writer wishes to include references to external content related to a schema listing. Otherwise, this type MUST NOT be used in forming schema listing requests or published schema listings. 3.21 listingComments To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type listingComments Type name: listingComments Type purpose: To represent which will be attached to a schema listing. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): utf8-text = 1* Apple [Page 19] INTERNET-DRAFT Directory Schema Listing Meta Data 17 November 1997 Type special notes: This type MAY be multi-valued. A language parameter MUST be used with this type. The use of this type is REQUIRED if during review of a schema listing request, the primary listing repository operator is asked by the reviewers to include particular comments or generic caveats with a schema listing prior to publication. Values of this type are in-line text comments or generic caveats associated with a schema listing and MAY include embedded CRLF characters. 4.0 Examples 4.1 Listing Request Use of Profile From: Whomever@wherever.com To: Someone@somewhere.com Subject: schema listing request MIME-Version: 1.0 Message-Id: Content-Type: text/directory; profile="schema-metadata-0"; charset="utf-8" Content-Transfer-Encoding: Quoted-Printable listingName: x-1.1.1 schemaTitle;language=en: Some Schema Title V1.0 schemaUse;language=en: Intended as an example. availableProfile: schema-ldap-0 contactLanguage: en contactName: Whome Ever contactEmail: Whomever@wherever.com contactPhone: +1 908 555 1212 contactAddress: Some Street $ Some City $ Some State $ Some Country authLanguage: en authName: Whome Ever authEmail: Whomever@wherever.com authPhone: +1 908 555 1212 authAddress: Some Street $ Some City $ Some State $ Some Country moreInfo: http://www.wherever.com/schema/= (opaque-schema $ ) caveat: Information obtained by following external content=0D=0A= references expressed using the moreInfo type are=0D=0A= outside of the control of the schema listing service=0D=0A= Apple [Page 20] INTERNET-DRAFT Directory Schema Listing Meta Data 17 November 1997 operators. Users of this information should be aware=0D=0A= that it is possible for this information to change=0D=0A= after the referencing schema listing has been=0D=0A= published. security;language=en: A security analysis was not performed. relatedTo: schema-metadata-1.0 $ obsoletes 4.2 Published Schema Listing Use of Profile Content-Type: text/directory; profile="schema-metadata-0"; charset="utf-8" Content-Transfer-Encoding: Quoted-Printable listingName: 1.1.0 schemaTitle;language=en: Some Schema Title V1.0 schemaUse;language=en: Intended as an example. availableProfile: schema-ldap-0 contactLanguage: en contactName: Whome Ever contactEmail: Whomever@wherever.com contactPhone: +1 908 555 1212 contactAddress: Some Street $ Some City $ Some State $ Some Country authLanguage: en authName: Whome Ever authEmail: Whomever@wherever.com authPhone: +1 908 555 1212 authAddress: Some Street $ Some City $ Some State $ Some Country moreInfo: http://www.wherever.com/schema/= (opaque-schema $ ) caveat: Information obtained by following external content=0D=0A= references expressed using the moreInfo type are=0D=0A= outside of the control of the schema listing service=0D=0A= operators. Users of this information should be aware=0D=0A= that it is possible for this information to change=0D=0A= after the referencing schema listing has been=0D=0A= published. relatedTo: schema-metadata-1.0 $ obsoletes security;language=en: A security analysis was not performed. contentURL: ftp://ftp.somewhere.com/schema/1/1/schema-ldap-1.1 created: 1997-11-17T15:21:00Z listingComments: This listing is only an example. 5.0 Security Considerations The text/directory profile defined in this document does not provide any method for carrying authentication information. Apple [Page 21] INTERNET-DRAFT Directory Schema Listing Meta Data 17 November 1997 The text/directory profile defined in this document allows content external to any schema listing service repository to be referenced in the schema listing and includes an MD5-based fingerprint of the refernced content itself. Users of the schema listing service SHOULD take steps to verify that this external information has not changed since schema listing publication. Users should also be aware that such external content is outside of the control of the schema listing service operators. A MIME body part containing contents structured according to the text/directory profile defined in this document MAY be incorporated in a digitally signed MIME content, which can be used to verify that the body part has not been modified during transit. If a signer has been certified by a trusted third party, it may also be possible to verify the origin of the content. 6.0 Acknowledgements The engineering team for listing service requirements: Chris Apple - AT&T Labs Sanjay Jain - Oracle Michael Mealling - NSI John Strassner - Cisco Sam Sun - CNRI Mark Wahl - Critical Angle Chris Weider - Microsoft 7.0 References [FILESYN] C. Apple, "Directory Schema Listing File Name Syntax", INTERNET-DRAFT , October 1997. [GUIDGEN] P. Leach, R. Salz, "UUIDs and GUIDs", INTERNET-DRAFT , Feb. 1997. [GUIDOTHER] Open Group CAE Specification C309 "DCE: Remote Procedure Call", Aug. 1994. [MIME] [RFC2045], [RFC2046], and [RFC2047]. [MIMEDIR] T. Howes, M. Smith, "A MIME Content-Type for Directory Information", INTERNET-DRAFT , July 1997. [RFC822] D. Crocker, "Standard of the Format of ARPA-Internet Text Messages", STD 11, RFC 822, August 1982. Apple [Page 22] INTERNET-DRAFT Directory Schema Listing Meta Data 17 November 1997 [RFC1321] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RFC1738] T. Berners-Lee, L. Masinter, M. McCahill, "Uniform Resource Locators", RFC 1738, December 1994. [RFC1766] H. Alvestrand, "Tags for the Identification of Languages", RFC 1766, March 1995. [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Level", March 1997. [RFC2044] F. Yergeau, "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, October 1996. [RFC2045] N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC2046] N. Freed & N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [RFC2047] K. Moore, "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996. 8.0 Author's Address Chris Apple AT&T Laboratories 600 - 700 Mountain Ave., Room 2F-165 Murray Hill, NJ 07974-0636 USA E-Mail: capple@att.com Phone: +1 908 582 2409 FAX: +1 908 582 3296 This INTERNET-DRAFT expires on May 17, 1998. Apple [Page 23] From owner-ietf-schema-reg Sun Nov 23 16:53:54 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA24665 for ietf-schema-reg-bks; Sun, 23 Nov 1997 16:53:54 -0800 (PST) Received: from proper.com (proper.com [165.227.249.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA24645 for ; Sun, 23 Nov 1997 16:53:44 -0800 (PST) Received: from prabhava.proper.com (prabhava.proper.com [165.227.249.110]) by proper.com (8.8.7/8.7.3) with SMTP id QAA22415 for ; Sun, 23 Nov 1997 16:51:59 -0800 (PST) Message-Id: <3.0.5.32.19971123162101.00a10610@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sun, 23 Nov 1997 16:21:01 -0800 To: ietf-schema-reg@imc.org From: Paul Hoffman / IMC Subject: "Updating" schemas Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Greetings. I've been reading the drafts with an eye towards implementation, since I'm the one doing the work for the IANA on setting up the listings server and mailing lists. >From draft-apple-schema-rqmts-list-03: > Updated schema listings SHALL be deprecated. > > A new schema listing name SHALL be allocated for each schema listing > publication causing the deprectation of an existing schema listing. I think this is very wrong. Old schema listings should still be available after updates come out. One of the primary motivators for this service is automatic retrieval of a given schema by name. An update might significantly change a schema (such as removing elements that were thought to be not useful), and the application retrieving the updated schema would not be able to use it. Instead, I think these should be worded as: All versions of all schema listings MUST be retained. A simple method for getting the most recent version of a particular schema listing MUST be provided. The contact person for a schema MAY give an earlier schema a higher version number, or may request that the schema get a new schema listing name. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-schema-reg Sun Nov 23 16:54:00 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA24668 for ietf-schema-reg-bks; Sun, 23 Nov 1997 16:54:00 -0800 (PST) Received: from proper.com (proper.com [165.227.249.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA24652 for ; Sun, 23 Nov 1997 16:53:45 -0800 (PST) Received: from prabhava.proper.com (prabhava.proper.com [165.227.249.110]) by proper.com (8.8.7/8.7.3) with SMTP id QAA22424 for ; Sun, 23 Nov 1997 16:52:00 -0800 (PST) Message-Id: <3.0.5.32.19971123165428.00a1c1e0@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sun, 23 Nov 1997 16:54:28 -0800 To: ietf-schema-reg@imc.org From: Paul Hoffman / IMC Subject: Version numbers Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-schema-reg@imc.org Precedence: bulk The current use of version numbers is very problematic. It leads to unpredicatibilty in our file names and difficulty in determining what is the most current version. I propose that we change to the following: All OIDs would be of the form: base . sequence . listversion . type . typeversion sequence = 0*; unique number for the schema listversion = 0*; version of this listing (0 is special) type = 0*; (1 for ldap, 2 for whois++, and so on) typeversion = 0*; version for this type within the ; group (0 is special) A difference from draft-apple-schema-file-list is that "listversion" and "typeversion" are single numbers, not "a.b.c" style version numbers. They are initialized at 1 for the first submission of a schema or of a type. Updates to either a schema or to an individual type cause the version number to be incremented by 1. This also allows a simple way to get the "most recent version": use the special value 0. Access would be as follows: base.12.4: returns the metadata for version 4 of schema 12 base.12.0: returns the metadata for the latest version of schema 12 base.12.4.1.3: returns the schema listing for version 3 of the ldap instantiation of version 4 of schema 12 base.12.4.1.0: returns the schema listing for the latest version of the ldap instantiation of version 4 of schema 12 base.12.0.1.0: returns the schema listing for the latest version of the ldap instantiation of the latest version of schema 12 base: error base.12: error base.12.4.1: error This would also change the human-readable file names. I propose that they become: file-name = "schema-" sequence "-v" listversion "-" typename "-v" typeversion For instance, "schema-12-v4-ldap-v3". The metadata would be called "schema-12-v4-metadata". What do others think of this? I know it's a big change from what we have, but I think it makes much more sense for what is likely to happen with people updating and with automated requests. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-schema-reg Sun Nov 23 16:53:55 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA24667 for ietf-schema-reg-bks; Sun, 23 Nov 1997 16:53:55 -0800 (PST) Received: from proper.com (proper.com [165.227.249.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA24650 for ; Sun, 23 Nov 1997 16:53:45 -0800 (PST) Received: from prabhava.proper.com (prabhava.proper.com [165.227.249.110]) by proper.com (8.8.7/8.7.3) with SMTP id QAA22421 for ; Sun, 23 Nov 1997 16:52:00 -0800 (PST) Message-Id: <3.0.5.32.19971123162443.00a1b120@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sun, 23 Nov 1997 16:24:43 -0800 To: ietf-schema-reg@imc.org From: Paul Hoffman / IMC Subject: Listing request names Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-schema-reg@imc.org Precedence: bulk I think it is a Very Bad Idea to have listing request names, particularly if they are searchable later. This leads to one item that is referenced by two OIDs that are controlled by two different entities, and is sure to lead to confusion. Instead, I suggest that the listing service (IANA) have a simple mechanism whereby someone who wants to submit a schema can send an SMTP message to a specified address and get back in return mail the next unique identifier in the list. They then use this identifier in their initial submission. If someone is given a number and no submission using that number comes in for seven days, the number can be reused. The uniqueness of the identifiers is checked during the review. The only downside to this is that there might be temporary holes in unique numbers, but I think this is trivial relative to the problems of trying to keep two sets of identifiers straight, particularly when you only control one of them. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-schema-reg Sun Nov 23 16:53:55 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA24666 for ietf-schema-reg-bks; Sun, 23 Nov 1997 16:53:55 -0800 (PST) Received: from proper.com (proper.com [165.227.249.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA24647 for ; Sun, 23 Nov 1997 16:53:45 -0800 (PST) Received: from prabhava.proper.com (prabhava.proper.com [165.227.249.110]) by proper.com (8.8.7/8.7.3) with SMTP id QAA22418 for ; Sun, 23 Nov 1997 16:52:00 -0800 (PST) Message-Id: <3.0.5.32.19971123161750.00a16de0@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sun, 23 Nov 1997 16:17:50 -0800 To: ietf-schema-reg@imc.org From: Paul Hoffman / IMC Subject: Repository access wording Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-schema-reg@imc.org Precedence: bulk These may seem like nits, but I'd like to make the following changes to section 2.3 in draft-apple-schema-rqmts-list-03. > The following access functions are REQUIRED: > > a) browse and retrieve schema listing content, listing > meta data, and a list of available schema listings: > > + via HTTP using an HTTP client such as a web browser Should be just "via HTTP requests". I think that many automated retrieval agents will use HTTP without a web browser. > + via FTP using clients such as a GUI- or > command-line-based FTP client or a web browser Should be just "via an FTP client". > + via SMTP using an SMTP-to-FTP gateway Should be just "via requests through an SMTP server". I intend to implement the SMTP access through a program that parses requests in messages, not through a gateway. > b) search a list of available schema listings: > > + via HTTP using an HTTP client to download a copy of the > list and utilizing search capabilities of that client Should be "via HTTP, retrieving either HTML or text listings that can then be searched by the requestor" > + via HTTP by accessing repository-based searching > facilities capable of accepting keywords from > the user and returning schema listing summaries > containing those keywords Should be "via HTTP by accessing repository-based searching facilities such as keyword searching; this can return schema names, schema listings, schema metadata listings, or other useful information" --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-schema-reg Sun Nov 23 17:44:10 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA25086 for ietf-schema-reg-bks; Sun, 23 Nov 1997 17:44:10 -0800 (PST) Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id RAA25081; Sun, 23 Nov 1997 17:44:00 -0800 (PST) Received: (from michael@localhost) by bailey.dscga.com (8.8.2/8.8.2) id UAA01413; Sun, 23 Nov 1997 20:43:15 -0500 (EST) From: Michael Mealling Message-Id: <199711240143.UAA01413@bailey.dscga.com> Subject: Re: Listing request names In-Reply-To: <3.0.5.32.19971123162443.00a1b120@mail.imc.org> from Paul Hoffman / IMC at "Nov 23, 97 04:24:43 pm" To: phoffman@imc.org (Paul Hoffman / IMC) Date: Sun, 23 Nov 1997 20:43:13 -0500 (EST) Cc: ietf-schema-reg@imc.org Reply-To: michaelm@rwhois.net X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Paul Hoffman / IMC said this: > I think it is a Very Bad Idea to have listing request names, particularly > if they are searchable later. This leads to one item that is referenced by > two OIDs that are controlled by two different entities, and is sure to lead > to confusion. Only one OID is required. LDAP, X.500 and friends use OIDs to identify their schema but other directory services do not. This service is meant for all directory services via any protocol so there will most definitly be the case where someone is registering a schema where there are no OIDs at all. No one should be using the service's OID as the primary name for schema. > Instead, I suggest that the listing service (IANA) have a simple mechanism > whereby someone who wants to submit a schema can send an SMTP message to a > specified address and get back in return mail the next unique identifier in > the list. They then use this identifier in their initial submission. If > someone is given a number and no submission using that number comes in for > seven days, the number can be reused. The uniqueness of the identifiers is > checked during the review. > > The only downside to this is that there might be temporary holes in unique > numbers, but I think this is trivial relative to the problems of trying to > keep two sets of identifiers straight, particularly when you only control > one of them. > While this is fine as far as implementation, there needs to be the case where the name the registry uses is divorced from the name the directory service itself uses. Namely because the services requires OIDs for every schema and some schema won't have or understand OIDs. I also maintain that no one should use the schema listing services OIDs as their own name. The entities that own those schema don't own that space and may think they can create subtrees when they don't own that subtree. -MM -- ------------------------------------------------------------------------------ Michael Mealling | 505 Huntmar Park Drive | Phone: (703)742-0400 Software Engineer | Herndon, VA 22070 | Fax: (703)742-9552 Network Solutions | | michaelm@rwhois.net From owner-ietf-schema-reg Sun Nov 23 17:50:56 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA25151 for ietf-schema-reg-bks; Sun, 23 Nov 1997 17:50:56 -0800 (PST) Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id RAA25146; Sun, 23 Nov 1997 17:50:50 -0800 (PST) Received: (from michael@localhost) by bailey.dscga.com (8.8.2/8.8.2) id UAA01434; Sun, 23 Nov 1997 20:50:26 -0500 (EST) From: Michael Mealling Message-Id: <199711240150.UAA01434@bailey.dscga.com> Subject: Re: Version numbers In-Reply-To: <3.0.5.32.19971123165428.00a1c1e0@mail.imc.org> from Paul Hoffman / IMC at "Nov 23, 97 04:54:28 pm" To: phoffman@imc.org (Paul Hoffman / IMC) Date: Sun, 23 Nov 1997 20:50:25 -0500 (EST) Cc: ietf-schema-reg@imc.org Reply-To: michaelm@rwhois.net X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Paul Hoffman / IMC said this: > The current use of version numbers is very problematic. It leads to > unpredicatibilty in our file names and difficulty in determining what is > the most current version. I propose that we change to the following: > > All OIDs would be of the form: > base . sequence . listversion . type . typeversion > > sequence = 0*; unique number for the schema > > listversion = 0*; version of this listing (0 is special) > > type = 0*; (1 for ldap, 2 for whois++, and so on) > > typeversion = 0*; version for this type within the > ; group (0 is special) > > A difference from draft-apple-schema-file-list is that "listversion" and > "typeversion" are single numbers, not "a.b.c" style version numbers. They > are initialized at 1 for the first submission of a schema or of a type. > Updates to either a schema or to an individual type cause the version > number to be incremented by 1. This also allows a simple way to get the > "most recent version": use the special value 0. > > Access would be as follows: > base.12.4: returns the metadata for version 4 of schema 12 > base.12.0: returns the metadata for the latest version of schema 12 > base.12.4.1.3: returns the schema listing for version 3 of the ldap > instantiation of version 4 of schema 12 > base.12.4.1.0: returns the schema listing for the latest version of the > ldap instantiation of version 4 of schema 12 > base.12.0.1.0: returns the schema listing for the latest version of the > ldap instantiation of the latest version of schema 12 > base: error > base.12: error > base.12.4.1: error > > This would also change the human-readable file names. I propose that they > become: > > file-name = "schema-" sequence "-v" listversion "-" > typename "-v" typeversion > > For instance, "schema-12-v4-ldap-v3". The metadata would be called > "schema-12-v4-metadata". > > What do others think of this? I know it's a big change from what we > have, but I think it makes much more sense for what is likely to > happen with people updating and with automated requests. > I'd make the metadata a special type instead of the default of the parent node. E.g. type 0 is the metadata file so that you end up with this: base.12.4.0.0 I just like making the metadata just another instance of the schema for some reason..... -MM -- ------------------------------------------------------------------------------ Michael Mealling | 505 Huntmar Park Drive | Phone: (703)742-0400 Software Engineer | Herndon, VA 22070 | Fax: (703)742-9552 Network Solutions | | michaelm@rwhois.net From owner-ietf-schema-reg Sun Nov 23 18:05:16 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id SAA25285 for ietf-schema-reg-bks; Sun, 23 Nov 1997 18:05:16 -0800 (PST) Received: from proper.com (proper.com [165.227.249.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id SAA25280 for ; Sun, 23 Nov 1997 18:05:12 -0800 (PST) Received: from prabhava.proper.com (prabhava.proper.com [165.227.249.110]) by proper.com (8.8.7/8.7.3) with SMTP id SAA22486; Sun, 23 Nov 1997 18:03:26 -0800 (PST) Message-Id: <3.0.5.32.19971123180612.0098fab0@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sun, 23 Nov 1997 18:06:12 -0800 To: michaelm@rwhois.net From: Paul Hoffman / IMC Subject: Re: Version numbers Cc: ietf-schema-reg@imc.org In-Reply-To: <199711240150.UAA01434@bailey.dscga.com> References: <3.0.5.32.19971123165428.00a1c1e0@mail.imc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-schema-reg@imc.org Precedence: bulk At 08:50 PM 11/23/97 -0500, Michael Mealling wrote: >I just like making the metadata just another instance of the schema for >some reason..... This is counterintuitive to me. Metadata describes all the schema listings in a gang, and isn't a schema itself. Having it accessed at the same "level" as the schema listings seems wrong to me. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-schema-reg Sun Nov 23 18:05:23 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id SAA25294 for ietf-schema-reg-bks; Sun, 23 Nov 1997 18:05:23 -0800 (PST) Received: from proper.com (proper.com [165.227.249.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id SAA25290 for ; Sun, 23 Nov 1997 18:05:18 -0800 (PST) Received: from prabhava.proper.com (prabhava.proper.com [165.227.249.110]) by proper.com (8.8.7/8.7.3) with SMTP id SAA22483; Sun, 23 Nov 1997 18:03:25 -0800 (PST) Message-Id: <3.0.5.32.19971123180411.0098cce0@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sun, 23 Nov 1997 18:04:11 -0800 To: michaelm@rwhois.net From: Paul Hoffman / IMC Subject: Re: Listing request names Cc: ietf-schema-reg@imc.org In-Reply-To: <199711240143.UAA01413@bailey.dscga.com> References: <3.0.5.32.19971123162443.00a1b120@mail.imc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-schema-reg@imc.org Precedence: bulk At 08:43 PM 11/23/97 -0500, Michael Mealling wrote: >Only one OID is required. LDAP, X.500 and friends use OIDs to identify >their schema but other directory services do not. This service is meant >for all directory services via any protocol so there will most definitly >be the case where someone is registering a schema where there are no >OIDs at all. Boy, I'm confused then. The current drafts sure make it look like the registry is going to assign an OID for everything, not just LDAP schemas. That is, I assumed the "serial number" was in fact an OID. >No one should be using the service's OID as the primary >name for schema. Then why create our own OIDs at all? It's always bad to have two names for one item if the two names are controlled by different people. If people agree that the originator shouldn't be using our OIDs, I'd say we should just register what people send us and not create an "internal" OID, or even an internal serial number. What is the need for the serial number, which is just a shadow name for the name they gave? --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-schema-reg Sun Nov 23 19:54:21 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id TAA26126 for ietf-schema-reg-bks; Sun, 23 Nov 1997 19:54:21 -0800 (PST) Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id TAA26122 for ; Sun, 23 Nov 1997 19:54:16 -0800 (PST) Received: (from michael@localhost) by bailey.dscga.com (8.8.2/8.8.2) id WAA01535 for ietf-schema-reg@imc.org; Sun, 23 Nov 1997 22:53:52 -0500 (EST) From: Michael Mealling Message-Id: <199711240353.WAA01535@bailey.dscga.com> Subject: Re: Version numbers (fwd) To: ietf-schema-reg@imc.org Date: Sun, 23 Nov 1997 22:53:52 -0500 (EST) Reply-To: michaelm@rwhois.net X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-schema-reg@imc.org Precedence: bulk ----- Forwarded message from michael ----- From michael Sun Nov 23 22:50:45 1997 Subject: Re: Version numbers In-Reply-To: <3.0.5.32.19971123180612.0098fab0@mail.imc.org> from Paul Hoffman / IMC at "Nov 23, 97 06:06:12 pm" To: phoffman@imc.org (Paul Hoffman / IMC) Date: Sun, 23 Nov 1997 22:50:45 -0500 (EST) Reply-To: michaelm@rwhois.net X-Mailer: ELM [version 2.4ME+ PL31H (25)] Paul Hoffman / IMC said this: > At 08:50 PM 11/23/97 -0500, Michael Mealling wrote: > >I just like making the metadata just another instance of the schema for > >some reason..... > > This is counterintuitive to me. Metadata describes all the schema listings > in a gang, and isn't a schema itself. Having it accessed at the same > "level" as the schema listings seems wrong to me. > Sure. Like I said, I can't give a compelling reason for it so I'll shut up now. ;-) -MM -- ------------------------------------------------------------------------------ Michael Mealling | 505 Huntmar Park Drive | Phone: (703)742-0400 Software Engineer | Herndon, VA 22070 | Fax: (703)742-9552 Network Solutions | | michaelm@rwhois.net ----- End of forwarded message from michael ----- -- ------------------------------------------------------------------------------ Michael Mealling | 505 Huntmar Park Drive | Phone: (703)742-0400 Software Engineer | Herndon, VA 22070 | Fax: (703)742-9552 Network Solutions | | michaelm@rwhois.net From owner-ietf-schema-reg Sun Nov 23 19:54:07 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id TAA26117 for ietf-schema-reg-bks; Sun, 23 Nov 1997 19:54:07 -0800 (PST) Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id TAA26112 for ; Sun, 23 Nov 1997 19:54:02 -0800 (PST) Received: (from michael@localhost) by bailey.dscga.com (8.8.2/8.8.2) id WAA01528 for ietf-schema-reg@imc.org; Sun, 23 Nov 1997 22:53:38 -0500 (EST) From: Michael Mealling Message-Id: <199711240353.WAA01528@bailey.dscga.com> Subject: Re: Listing request names (fwd) To: ietf-schema-reg@imc.org Date: Sun, 23 Nov 1997 22:53:37 -0500 (EST) Reply-To: michaelm@rwhois.net X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-schema-reg@imc.org Precedence: bulk ----- Forwarded message from michael ----- From michael Sun Nov 23 22:17:17 1997 Subject: Re: Listing request names In-Reply-To: <3.0.5.32.19971123180411.0098cce0@mail.imc.org> from Paul Hoffman / IMC at "Nov 23, 97 06:04:11 pm" To: phoffman@imc.org (Paul Hoffman / IMC) Date: Sun, 23 Nov 1997 22:17:17 -0500 (EST) Reply-To: michaelm@rwhois.net X-Mailer: ELM [version 2.4ME+ PL31H (25)] Paul Hoffman / IMC said this: > At 08:43 PM 11/23/97 -0500, Michael Mealling wrote: > >Only one OID is required. LDAP, X.500 and friends use OIDs to identify > >their schema but other directory services do not. This service is meant > >for all directory services via any protocol so there will most definitly > >be the case where someone is registering a schema where there are no > >OIDs at all. > > Boy, I'm confused then. The current drafts sure make it look like the > registry is going to assign an OID for everything, not just LDAP schemas. > That is, I assumed the "serial number" was in fact an OID. It is. But it never really needed to be. The LDAP folx wanted it that way. I was happy with it just being a URN, or simply a filename with version and filetype in it. > >No one should be using the service's OID as the primary name for schema. > > Then why create our own OIDs at all? It's always bad to have two names for > one item if the two names are controlled by different people. If people > agree that the originator shouldn't be using our OIDs, I'd say we should > just register what people send us and not create an "internal" OID, or even > an internal serial number. What is the need for the serial number, which is > just a shadow name for the name they gave? > The serial number was there to serve as version control, not as a _name_ in the sense that LDAP uses OIDs. We needed something to be the serial number for that reason. The LDAP folx wanted everything to use OIDs and we didn't see a reason not to so we went with it. Don't think of it as another name. Think of it as more of the RFC number. E.g. the Internet White Pages Schema RFC is RFC3456 (I can't remember what it is off the top of my head). By calling it RFC3456 we're not saying that the IWPS has two names. Just that the IETF calls it that for the sake of keeping its RFC numbers straight. You could not call it an OID and it still works just fine. I do agree that the draft needs to tone itself down a bit when it comes to calling that thing a NAME for the schema. Sure, its a name in the technical sense, just not in the practical sense. -MM -- ------------------------------------------------------------------------------ Michael Mealling | 505 Huntmar Park Drive | Phone: (703)742-0400 Software Engineer | Herndon, VA 22070 | Fax: (703)742-9552 Network Solutions | | michaelm@rwhois.net ----- End of forwarded message from michael ----- -- ------------------------------------------------------------------------------ Michael Mealling | 505 Huntmar Park Drive | Phone: (703)742-0400 Software Engineer | Herndon, VA 22070 | Fax: (703)742-9552 Network Solutions | | michaelm@rwhois.net From owner-ietf-schema-reg Sun Nov 23 19:53:09 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id TAA26087 for ietf-schema-reg-bks; Sun, 23 Nov 1997 19:53:09 -0800 (PST) Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id TAA26083 for ; Sun, 23 Nov 1997 19:53:05 -0800 (PST) Received: (from michael@localhost) by bailey.dscga.com (8.8.2/8.8.2) id WAA01520 for ietf-schema-reg@imc.org; Sun, 23 Nov 1997 22:52:41 -0500 (EST) From: Michael Mealling Message-Id: <199711240352.WAA01520@bailey.dscga.com> Subject: Re: Listing request names (fwd) To: ietf-schema-reg@imc.org Date: Sun, 23 Nov 1997 22:52:41 -0500 (EST) Reply-To: michaelm@rwhois.net X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-schema-reg@imc.org Precedence: bulk oops...forgot the group reply... ----- Forwarded message from Michael Mealling ----- From owner-ietf-schema-reg@imc.org Sun Nov 23 20:48:16 1997 From: Michael Mealling Message-Id: <199711240143.UAA01413@bailey.dscga.com> Subject: Re: Listing request names In-Reply-To: <3.0.5.32.19971123162443.00a1b120@mail.imc.org> from Paul Hoffman / IMC at "Nov 23, 97 04:24:43 pm" To: phoffman@imc.org (Paul Hoffman / IMC) Date: Sun, 23 Nov 1997 20:43:13 -0500 (EST) Cc: ietf-schema-reg@imc.org Reply-To: michaelm@rwhois.net X-Mailer: ELM [version 2.4ME+ PL31H (25)] Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Paul Hoffman / IMC said this: > I think it is a Very Bad Idea to have listing request names, particularly > if they are searchable later. This leads to one item that is referenced by > two OIDs that are controlled by two different entities, and is sure to lead > to confusion. Only one OID is required. LDAP, X.500 and friends use OIDs to identify their schema but other directory services do not. This service is meant for all directory services via any protocol so there will most definitly be the case where someone is registering a schema where there are no OIDs at all. No one should be using the service's OID as the primary name for schema. > Instead, I suggest that the listing service (IANA) have a simple mechanism > whereby someone who wants to submit a schema can send an SMTP message to a > specified address and get back in return mail the next unique identifier in > the list. They then use this identifier in their initial submission. If > someone is given a number and no submission using that number comes in for > seven days, the number can be reused. The uniqueness of the identifiers is > checked during the review. > > The only downside to this is that there might be temporary holes in unique > numbers, but I think this is trivial relative to the problems of trying to > keep two sets of identifiers straight, particularly when you only control > one of them. > While this is fine as far as implementation, there needs to be the case where the name the registry uses is divorced from the name the directory service itself uses. Namely because the services requires OIDs for every schema and some schema won't have or understand OIDs. I also maintain that no one should use the schema listing services OIDs as their own name. The entities that own those schema don't own that space and may think they can create subtrees when they don't own that subtree. -MM -- ------------------------------------------------------------------------------ Michael Mealling | 505 Huntmar Park Drive | Phone: (703)742-0400 Software Engineer | Herndon, VA 22070 | Fax: (703)742-9552 Network Solutions | | michaelm@rwhois.net ----- End of forwarded message from Michael Mealling ----- -- ------------------------------------------------------------------------------ Michael Mealling | 505 Huntmar Park Drive | Phone: (703)742-0400 Software Engineer | Herndon, VA 22070 | Fax: (703)742-9552 Network Solutions | | michaelm@rwhois.net From owner-ietf-schema-reg Sun Nov 23 20:13:43 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id UAA26303 for ietf-schema-reg-bks; Sun, 23 Nov 1997 20:13:43 -0800 (PST) Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id UAA26297 for ; Sun, 23 Nov 1997 20:13:38 -0800 (PST) Received: (from michael@localhost) by bailey.dscga.com (8.8.2/8.8.2) id XAA01589 for ietf-schema-reg@imc.org; Sun, 23 Nov 1997 23:13:13 -0500 (EST) From: Michael Mealling Message-Id: <199711240413.XAA01589@bailey.dscga.com> Subject: Re: Listing request names (fwd) To: ietf-schema-reg@imc.org Date: Sun, 23 Nov 1997 23:13:13 -0500 (EST) Reply-To: michaelm@rwhois.net X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-schema-reg@imc.org Precedence: bulk I have to remember to group reply! grr.. ----- Forwarded message from michael ----- From michael Sun Nov 23 23:12:13 1997 Subject: Re: Listing request names In-Reply-To: <3.0.5.32.19971123195621.009cf700@mail.imc.org> from Paul Hoffman / IMC at "Nov 23, 97 07:56:21 pm" To: phoffman@imc.org (Paul Hoffman / IMC) Date: Sun, 23 Nov 1997 23:12:13 -0500 (EST) Cc: michaelm@rwhois.net Reply-To: michaelm@rwhois.net X-Mailer: ELM [version 2.4ME+ PL31H (25)] Paul Hoffman / IMC said this: > >The serial number was there to serve as version control, not as a _name_ in > >the sense that LDAP uses OIDs. > > Then letting people access the schemas by version control number seems > minor and trivial. The only way they should be accessing them is by their > proper names. Proper for who? If a schema is named by an OID in one system and a text string in another system which one gets to say it wins? E.g. the IWPS schema might have a version for LDAP and a version for rwhois. One would use OIDs while the other wouldn't. > > This is making things much more difficult, in my mind. Are you *sure* the > other schema systems couldn't use OIDs for their schemas? I didn't see any > other drafts other than LDAP (nudge, nudge). > Leslie might be working on the whois++ version (I think. Leslie?). I'm working on the rwhois one. I don't think either will use OIDs simply because OIDs are alien to both. I'm willing to bet someone will also be registering ph schema and I know they don't use OIDs. Most of the discussions dealing with METAD have been around using text/directory profiles as its schema identification system. Anyway, this is the reason why we decided that, if your going to mandate OIDs to identify the schema that the system would have to create its own. Now, as to the decision to mandate identifying the schema by OID, I personally don't care. As long as the sequence, version, type, stuff is there in the filename/identification string the user sees/uses. -MM -- ------------------------------------------------------------------------------ Michael Mealling | 505 Huntmar Park Drive | Phone: (703)742-0400 Software Engineer | Herndon, VA 22070 | Fax: (703)742-9552 Network Solutions | | michaelm@rwhois.net ----- End of forwarded message from michael ----- -- ------------------------------------------------------------------------------ Michael Mealling | 505 Huntmar Park Drive | Phone: (703)742-0400 Software Engineer | Herndon, VA 22070 | Fax: (703)742-9552 Network Solutions | | michaelm@rwhois.net From owner-ietf-schema-reg Sun Nov 23 20:48:58 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id UAA26653 for ietf-schema-reg-bks; Sun, 23 Nov 1997 20:48:58 -0800 (PST) Received: from folder.critical-angle.com (eden-gw.critical-angle.com [206.81.238.241]) by mail.proper.com (8.8.7/8.7.3) with SMTP id UAA26648 for ; Sun, 23 Nov 1997 20:48:48 -0800 (PST) Received: (qmail 14669 invoked from network); 24 Nov 1997 04:46:19 -0000 Received: from folder.critical-angle.com (206.81.238.241) by folder.critical-angle.com with SMTP; 24 Nov 1997 04:46:19 -0000 From: Mark Wahl To: Paul Hoffman / IMC cc: ietf-schema-reg@imc.org Subject: Re: Listing request names In-reply-to: Your message of "Sun, 23 Nov 1997 16:24:43 PST." <3.0.5.32.19971123162443.00a1b120@mail.imc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 23 Nov 1997 22:46:19 -0600 Message-ID: <14667.880346779@folder.critical-angle.com> Sender: owner-ietf-schema-reg@imc.org Precedence: bulk I also am in agreement with Paul Hoffman's suggested approach, with one modification: I would prefer to have the temporary OID assignment be done with a real-time protocol (e.g. HTTP?) than with a store-and-forward protocol (SMTP). When the user clicks the 'send to listing service' button on their schema design tool, it would allow the tool to obtain an OID and send the message immediately, rather than waiting for an intermediate response to wander through the MTAs. I don't see a problem with missing numbers in the sequence; when in future the listing service becomes pruned there will be more missing numbers. Mark Wahl, Enterprise Directory Integration Critical Angle Inc. From owner-ietf-schema-reg Sun Nov 23 21:06:01 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id VAA26798 for ietf-schema-reg-bks; Sun, 23 Nov 1997 21:06:01 -0800 (PST) Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id VAA26792; Sun, 23 Nov 1997 21:05:57 -0800 (PST) Received: (from michael@localhost) by bailey.dscga.com (8.8.2/8.8.2) id AAA01688; Mon, 24 Nov 1997 00:05:06 -0500 (EST) From: Michael Mealling Message-Id: <199711240505.AAA01688@bailey.dscga.com> Subject: Re: Listing request names In-Reply-To: <14667.880346779@folder.critical-angle.com> from Mark Wahl at "Nov 23, 97 10:46:19 pm" To: M.Wahl@critical-angle.com (Mark Wahl) Date: Mon, 24 Nov 1997 00:05:06 -0500 (EST) Cc: phoffman@imc.org, ietf-schema-reg@imc.org Reply-To: michaelm@rwhois.net X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Mark Wahl said this: > > I also am in agreement with Paul Hoffman's suggested approach, with one > modification: I would prefer to have the temporary OID assignment be done with > a real-time protocol (e.g. HTTP?) than with a store-and-forward protocol (SMTP). > When the user clicks the 'send to listing service' button on their schema > design tool, it would allow the tool to obtain an OID and send the message > immediately, rather than waiting for an intermediate response to wander > through the MTAs. > > I don't see a problem with missing numbers in the sequence; when in future > the listing service becomes pruned there will be more missing numbers. > Mark, What is LDAP going to be doing with the OIDs that the registry assigns? I assume that the above scenario is needed so that you can get and use the registries assigned OID, right? If so are you planning on using the registry's assigned OID as the OID of the actual schema in LDAP? If so then I think that is a bad mistake. That means that not only is the registry acting as a place to hold schema definitions, it has also become an owner of schema definitions and an OID registration service. Neither of which we're ready for yet. -MM -- ------------------------------------------------------------------------------ Michael Mealling | 505 Huntmar Park Drive | Phone: (703)742-0400 Software Engineer | Herndon, VA 22070 | Fax: (703)742-9552 Network Solutions | | michaelm@rwhois.net From owner-ietf-schema-reg Mon Nov 24 10:38:59 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA07366 for ietf-schema-reg-bks; Mon, 24 Nov 1997 10:38:59 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.23]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA07355; Mon, 24 Nov 1997 10:38:55 -0800 (PST) Received: by mail3.microsoft.com with Internet Mail Service (5.5.1960.3) id ; Mon, 24 Nov 1997 10:43:13 -0800 Message-ID: From: Chris Weider To: "'michaelm@rwhois.net'" , M.Wahl@critical-angle.com Cc: phoffman@imc.org, ietf-schema-reg@imc.org Subject: RE: Listing request names Date: Mon, 24 Nov 1997 10:39:53 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Michael: The OID registration service is implicit in the listing being able to assign names to the nameless. Chris > -----Original Message----- > From: Michael Mealling [SMTP:michael@bailey.dscga.com] > Sent: Sunday, November 23, 1997 9:05 PM > To: M.Wahl@critical-angle.com > Cc: phoffman@imc.org; ietf-schema-reg@imc.org > Subject: Re: Listing request names > > Mark Wahl said this: > > > > I also am in agreement with Paul Hoffman's suggested approach, with one > > modification: I would prefer to have the temporary OID assignment be > done with > > a real-time protocol (e.g. HTTP?) than with a store-and-forward protocol > (SMTP). > > When the user clicks the 'send to listing service' button on their > schema > > design tool, it would allow the tool to obtain an OID and send the > message > > immediately, rather than waiting for an intermediate response to wander > > through the MTAs. > > > > I don't see a problem with missing numbers in the sequence; when in > future > > the listing service becomes pruned there will be more missing numbers. > > > > Mark, > What is LDAP going to be doing with the OIDs that the registry assigns? > I assume that the above scenario is needed so that you can get and use > the registries assigned OID, right? If so are you planning on using the > registry's assigned OID as the OID of the actual schema in LDAP? If so > then I think that is a bad mistake. That means that not only is the > registry acting as a place to hold schema definitions, it has also become > an owner of schema definitions and an OID registration service. Neither of > > which we're ready for yet. > > -MM > > -- > -------------------------------------------------------------------------- > ---- > Michael Mealling | 505 Huntmar Park Drive | Phone: > (703)742-0400 > Software Engineer | Herndon, VA 22070 | Fax: > (703)742-9552 > Network Solutions | | michaelm@rwhois.net From owner-ietf-schema-reg Mon Nov 24 10:43:46 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA07423 for ietf-schema-reg-bks; Mon, 24 Nov 1997 10:43:46 -0800 (PST) Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA07417; Mon, 24 Nov 1997 10:43:41 -0800 (PST) Received: (from michael@localhost) by bailey.dscga.com (8.8.2/8.8.2) id NAA02301; Mon, 24 Nov 1997 13:43:01 -0500 (EST) From: Michael Mealling Message-Id: <199711241843.NAA02301@bailey.dscga.com> Subject: Re: Listing request names In-Reply-To: from Chris Weider at "Nov 24, 97 10:39:53 am" To: cweider@microsoft.com (Chris Weider) Date: Mon, 24 Nov 1997 13:43:00 -0500 (EST) Cc: michaelm@rwhois.net, M.Wahl@critical-angle.com, phoffman@imc.org, ietf-schema-reg@imc.org Reply-To: michaelm@rwhois.net X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Chris Weider said this: > Michael: > The OID registration service is implicit in the listing being able to > assign names to the nameless. Sure. But are those the names that the schema is supposed to use within its own system? I.e. are the OIDs the service assigns going to the the OIDs that LDAP uses everywhere? By nameless do you mean schema's that have not yet been created or schema that use names other than OIDs? -MM > > -----Original Message----- > > From: Michael Mealling [SMTP:michael@bailey.dscga.com] > > Sent: Sunday, November 23, 1997 9:05 PM > > To: M.Wahl@critical-angle.com > > Cc: phoffman@imc.org; ietf-schema-reg@imc.org > > Subject: Re: Listing request names > > > > Mark Wahl said this: > > > > > > I also am in agreement with Paul Hoffman's suggested approach, with one > > > modification: I would prefer to have the temporary OID assignment be > > done with > > > a real-time protocol (e.g. HTTP?) than with a store-and-forward protocol > > (SMTP). > > > When the user clicks the 'send to listing service' button on their > > schema > > > design tool, it would allow the tool to obtain an OID and send the > > message > > > immediately, rather than waiting for an intermediate response to wander > > > through the MTAs. > > > > > > I don't see a problem with missing numbers in the sequence; when in > > future > > > the listing service becomes pruned there will be more missing numbers. > > > > > > > Mark, > > What is LDAP going to be doing with the OIDs that the registry assigns? > > I assume that the above scenario is needed so that you can get and use > > the registries assigned OID, right? If so are you planning on using the > > registry's assigned OID as the OID of the actual schema in LDAP? If so > > then I think that is a bad mistake. That means that not only is the > > registry acting as a place to hold schema definitions, it has also become > > an owner of schema definitions and an OID registration service. Neither of > > which we're ready for yet. > > > -- ------------------------------------------------------------------------------ Michael Mealling | 505 Huntmar Park Drive | Phone: (703)742-0400 Software Engineer | Herndon, VA 22070 | Fax: (703)742-9552 Network Solutions | | michaelm@rwhois.net From owner-ietf-schema-reg Mon Nov 24 11:00:22 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA07638 for ietf-schema-reg-bks; Mon, 24 Nov 1997 11:00:22 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.31]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA07633; Mon, 24 Nov 1997 11:00:17 -0800 (PST) Received: by mail5.microsoft.com with Internet Mail Service (5.5.1960.3) id ; Mon, 24 Nov 1997 11:02:25 -0800 Message-ID: From: Chris Weider To: "'michaelm@rwhois.net'" Cc: M.Wahl@critical-angle.com, phoffman@imc.org, ietf-schema-reg@imc.org Subject: RE: Listing request names Date: Mon, 24 Nov 1997 11:01:10 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ietf-schema-reg@imc.org Precedence: bulk > -----Original Message----- > From: Michael Mealling [SMTP:michael@bailey.dscga.com] > Sent: Monday, November 24, 1997 10:43 AM > To: Chris Weider > Cc: michaelm@rwhois.net; M.Wahl@critical-angle.com; phoffman@imc.org; > ietf-schema-reg@imc.org > Subject: Re: Listing request names > > Chris Weider said this: > > Michael: > > The OID registration service is implicit in the listing being able to > > assign names to the nameless. [Chris Weider] > Sure. But are those the names that the schema is supposed to use within > its own system? I.e. are the OIDs the service assigns going to the the > OIDs that LDAP uses everywhere? [Chris Weider] Yes > By nameless do you mean schema's that have not yet been created or > schema that use names other than OIDs? [Chris Weider] Yes, and for schema that do not yet have unique ids assigned (e.g. Dublin Core). > -MM > > > > -----Original Message----- > > > From: Michael Mealling [SMTP:michael@bailey.dscga.com] > > > Sent: Sunday, November 23, 1997 9:05 PM > > > To: M.Wahl@critical-angle.com > > > Cc: phoffman@imc.org; ietf-schema-reg@imc.org > > > Subject: Re: Listing request names > > > > > > Mark Wahl said this: > > > > > > > > I also am in agreement with Paul Hoffman's suggested approach, with > one > > > > modification: I would prefer to have the temporary OID assignment be > > > done with > > > > a real-time protocol (e.g. HTTP?) than with a store-and-forward > protocol > > > (SMTP). > > > > When the user clicks the 'send to listing service' button on their > > > schema > > > > design tool, it would allow the tool to obtain an OID and send the > > > message > > > > immediately, rather than waiting for an intermediate response to > wander > > > > through the MTAs. > > > > > > > > I don't see a problem with missing numbers in the sequence; when in > > > future > > > > the listing service becomes pruned there will be more missing > numbers. > > > > > > > > > > Mark, > > > What is LDAP going to be doing with the OIDs that the registry > assigns? > > > I assume that the above scenario is needed so that you can get and use > > > the registries assigned OID, right? If so are you planning on using > the > > > registry's assigned OID as the OID of the actual schema in LDAP? If so > > > then I think that is a bad mistake. That means that not only is the > > > registry acting as a place to hold schema definitions, it has also > become > > > an owner of schema definitions and an OID registration service. > Neither of > > > which we're ready for yet. > > > > > > > -- > -------------------------------------------------------------------------- > ---- > Michael Mealling | 505 Huntmar Park Drive | Phone: > (703)742-0400 > Software Engineer | Herndon, VA 22070 | Fax: > (703)742-9552 > Network Solutions | | michaelm@rwhois.net From owner-ietf-schema-reg Mon Nov 24 11:03:37 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA07695 for ietf-schema-reg-bks; Mon, 24 Nov 1997 11:03:37 -0800 (PST) Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA07690; Mon, 24 Nov 1997 11:03:32 -0800 (PST) Received: (from michael@localhost) by bailey.dscga.com (8.8.2/8.8.2) id OAA02335; Mon, 24 Nov 1997 14:03:02 -0500 (EST) From: Michael Mealling Message-Id: <199711241903.OAA02335@bailey.dscga.com> Subject: Re: Listing request names In-Reply-To: from Chris Weider at "Nov 24, 97 11:01:10 am" To: cweider@microsoft.com (Chris Weider) Date: Mon, 24 Nov 1997 14:03:01 -0500 (EST) Cc: michaelm@rwhois.net, M.Wahl@critical-angle.com, phoffman@imc.org, ietf-schema-reg@imc.org Reply-To: michaelm@rwhois.net X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Chris Weider said this: > > -----Original Message----- > > From: Michael Mealling [SMTP:michael@bailey.dscga.com] > > Sent: Monday, November 24, 1997 10:43 AM > > To: Chris Weider > > Cc: michaelm@rwhois.net; M.Wahl@critical-angle.com; phoffman@imc.org; > > ietf-schema-reg@imc.org > > Subject: Re: Listing request names > > > > Chris Weider said this: > > > Michael: > > > The OID registration service is implicit in the listing being able to > > > assign names to the nameless. > [Chris Weider] > > Sure. But are those the names that the schema is supposed to use within > > its own system? I.e. are the OIDs the service assigns going to the the > > OIDs that LDAP uses everywhere? > [Chris Weider] Yes > > > By nameless do you mean schema's that have not yet been created or > > schema that use names other than OIDs? > > [Chris Weider] Yes, and for schema that do not yet have unique ids > assigned (e.g. Dublin Core). > Yes to all of 'em? If whois++ wants to list its schema in the service it will have to rename its schema to the OID that the service assigns? -MM > > > > -----Original Message----- > > > > From: Michael Mealling [SMTP:michael@bailey.dscga.com] > > > > Sent: Sunday, November 23, 1997 9:05 PM > > > > To: M.Wahl@critical-angle.com > > > > Cc: phoffman@imc.org; ietf-schema-reg@imc.org > > > > Subject: Re: Listing request names > > > > > > > > Mark Wahl said this: > > > > > > > > > > I also am in agreement with Paul Hoffman's suggested approach, with > > one > > > > > modification: I would prefer to have the temporary OID assignment be > > > > done with > > > > > a real-time protocol (e.g. HTTP?) than with a store-and-forward > > protocol > > > > (SMTP). > > > > > When the user clicks the 'send to listing service' button on their > > > > schema > > > > > design tool, it would allow the tool to obtain an OID and send the > > > > message > > > > > immediately, rather than waiting for an intermediate response to > > wander > > > > > through the MTAs. > > > > > > > > > > I don't see a problem with missing numbers in the sequence; when in > > > > future > > > > > the listing service becomes pruned there will be more missing > > numbers. > > > > > > > > > > > > > Mark, > > > > What is LDAP going to be doing with the OIDs that the registry > > assigns? > > > > I assume that the above scenario is needed so that you can get and use > > > > the registries assigned OID, right? If so are you planning on using > > the > > > > registry's assigned OID as the OID of the actual schema in LDAP? If so > > > > then I think that is a bad mistake. That means that not only is the > > > > registry acting as a place to hold schema definitions, it has also > > become > > > > an owner of schema definitions and an OID registration service. > > Neither of > > > > which we're ready for yet. > > > > > > > > > > > -- > > -------------------------------------------------------------------------- > > ---- > > Michael Mealling | 505 Huntmar Park Drive | Phone: > > (703)742-0400 > > Software Engineer | Herndon, VA 22070 | Fax: > > (703)742-9552 > > Network Solutions | | michaelm@rwhois.net > -- ------------------------------------------------------------------------------ Michael Mealling | 505 Huntmar Park Drive | Phone: (703)742-0400 Software Engineer | Herndon, VA 22070 | Fax: (703)742-9552 Network Solutions | | michaelm@rwhois.net From owner-ietf-schema-reg Mon Nov 24 11:18:38 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA07987 for ietf-schema-reg-bks; Mon, 24 Nov 1997 11:18:38 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.23]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA07982; Mon, 24 Nov 1997 11:18:34 -0800 (PST) Received: by mail3.microsoft.com with Internet Mail Service (5.5.1960.3) id ; Mon, 24 Nov 1997 11:22:56 -0800 Message-ID: From: Chris Weider To: "'michaelm@rwhois.net'" Cc: M.Wahl@critical-angle.com, phoffman@imc.org, ietf-schema-reg@imc.org Subject: RE: Listing request names Date: Mon, 24 Nov 1997 11:17:18 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Object classes, templates, and attributes should have unique identifiers assigned to them. Ideally these identifiers would not be human-friendly names, because human-friendly names are quite likely to be reused. A given protocol does not have to use the unique identifiers in its operations; for example, whois++ can continue to use the human-readable attribute and template names. But there needs to be some disambiguation possible other than "well, it's the version of Name used by the whois++ server at www.foo.com".... Chris > -----Original Message----- > From: Michael Mealling [SMTP:michael@bailey.dscga.com] > Sent: Monday, November 24, 1997 11:03 AM > To: Chris Weider > Cc: michaelm@rwhois.net; M.Wahl@critical-angle.com; phoffman@imc.org; > ietf-schema-reg@imc.org > Subject: Re: Listing request names > > Chris Weider said this: > > > -----Original Message----- > > > From: Michael Mealling [SMTP:michael@bailey.dscga.com] > > > Sent: Monday, November 24, 1997 10:43 AM > > > To: Chris Weider > > > Cc: michaelm@rwhois.net; M.Wahl@critical-angle.com; > phoffman@imc.org; > > > ietf-schema-reg@imc.org > > > Subject: Re: Listing request names > > > > > > Chris Weider said this: > > > > Michael: > > > > The OID registration service is implicit in the listing being able > to > > > > assign names to the nameless. > > [Chris Weider] > > > Sure. But are those the names that the schema is supposed to use > within > > > its own system? I.e. are the OIDs the service assigns going to the the > > > OIDs that LDAP uses everywhere? > > [Chris Weider] Yes > > > > > By nameless do you mean schema's that have not yet been created or > > > schema that use names other than OIDs? > > > > [Chris Weider] Yes, and for schema that do not yet have unique ids > > assigned (e.g. Dublin Core). > > > > Yes to all of 'em? If whois++ wants to list its schema in the service it > will have to rename its schema to the OID that the service assigns? > > -MM > > > > > > -----Original Message----- > > > > > From: Michael Mealling [SMTP:michael@bailey.dscga.com] > > > > > Sent: Sunday, November 23, 1997 9:05 PM > > > > > To: M.Wahl@critical-angle.com > > > > > Cc: phoffman@imc.org; ietf-schema-reg@imc.org > > > > > Subject: Re: Listing request names > > > > > > > > > > Mark Wahl said this: > > > > > > > > > > > > I also am in agreement with Paul Hoffman's suggested approach, > with > > > one > > > > > > modification: I would prefer to have the temporary OID > assignment be > > > > > done with > > > > > > a real-time protocol (e.g. HTTP?) than with a store-and-forward > > > protocol > > > > > (SMTP). > > > > > > When the user clicks the 'send to listing service' button on > their > > > > > schema > > > > > > design tool, it would allow the tool to obtain an OID and send > the > > > > > message > > > > > > immediately, rather than waiting for an intermediate response to > > > wander > > > > > > through the MTAs. > > > > > > > > > > > > I don't see a problem with missing numbers in the sequence; when > in > > > > > future > > > > > > the listing service becomes pruned there will be more missing > > > numbers. > > > > > > > > > > > > > > > > Mark, > > > > > What is LDAP going to be doing with the OIDs that the registry > > > assigns? > > > > > I assume that the above scenario is needed so that you can get and > use > > > > > the registries assigned OID, right? If so are you planning on > using > > > the > > > > > registry's assigned OID as the OID of the actual schema in LDAP? > If so > > > > > then I think that is a bad mistake. That means that not only is > the > > > > > registry acting as a place to hold schema definitions, it has also > > > become > > > > > an owner of schema definitions and an OID registration service. > > > Neither of > > > > > which we're ready for yet. > > > > > > > > > > > > > > > -- > > > > -------------------------------------------------------------------------- > > > ---- > > > Michael Mealling | 505 Huntmar Park Drive | Phone: > > > (703)742-0400 > > > Software Engineer | Herndon, VA 22070 | Fax: > > > (703)742-9552 > > > Network Solutions | | michaelm@rwhois.net > > > > > -- > -------------------------------------------------------------------------- > ---- > Michael Mealling | 505 Huntmar Park Drive | Phone: > (703)742-0400 > Software Engineer | Herndon, VA 22070 | Fax: > (703)742-9552 > Network Solutions | | michaelm@rwhois.net From owner-ietf-schema-reg Mon Nov 24 11:45:49 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA08352 for ietf-schema-reg-bks; Mon, 24 Nov 1997 11:45:49 -0800 (PST) Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA08343; Mon, 24 Nov 1997 11:45:42 -0800 (PST) Received: (from michael@localhost) by bailey.dscga.com (8.8.2/8.8.2) id OAA02402; Mon, 24 Nov 1997 14:44:55 -0500 (EST) From: Michael Mealling Message-Id: <199711241944.OAA02402@bailey.dscga.com> Subject: Re: Listing request names In-Reply-To: from Chris Weider at "Nov 24, 97 11:17:18 am" To: cweider@microsoft.com (Chris Weider) Date: Mon, 24 Nov 1997 14:44:55 -0500 (EST) Cc: michaelm@rwhois.net, M.Wahl@critical-angle.com, phoffman@imc.org, ietf-schema-reg@imc.org Reply-To: michaelm@rwhois.net X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Chris Weider said this: > Object classes, templates, and attributes should have unique identifiers > assigned to them. Ideally these identifiers would not be human-friendly > names, because human-friendly names are quite likely to be reused. A given > protocol does not have to use the unique identifiers in its operations; for > example, whois++ can continue to use the human-readable attribute and > template names. But there needs to be some disambiguation possible other > than "well, it's the version of Name used by the whois++ server at > www.foo.com".... I'm confused. I thought we were just listing schema, not providing a naming service. I was thinking of a system where each entity would end up having several different names: this is what LDAP calls this schema, this is what whois++ calls it, this is what the service itself calls it. But the listing service name has no more importance than any of the others. Anyway, I don't have a problem with the service creating OIDs. I just want them to be used by the service and not used as a directory services native naming scheme. I don't think we understand this stuff well enough to start figuring out how to name ALL schema. My personal opinion is that schema should be named with URNs and not OIDs. (yes, an OID would make a valid URN and I even wrote a draft on it several years back). I havn't gotten into LDAP schema stuff much so I'll ask a question out of shear ignorance: Is there a problem with LDAP schema using OIDs from any subtree? Is there a desire in the LDAP community to start putting schema OIDs into a single standardized tree somewhere? > > > > Chris Weider said this: > > > > > Michael: > > > > > The OID registration service is implicit in the listing being able > > > > > to assign names to the nameless. > > > [Chris Weider] > > > > Sure. But are those the names that the schema is supposed to use > > within its own system? I.e. are the OIDs the service assigns going to the > > the > > > > OIDs that LDAP uses everywhere? > > > [Chris Weider] Yes > > > > > > > By nameless do you mean schema's that have not yet been created or > > > > schema that use names other than OIDs? > > > > > > [Chris Weider] Yes, and for schema that do not yet have unique ids > > > assigned (e.g. Dublin Core). > > > > > > > Yes to all of 'em? If whois++ wants to list its schema in the service it > > will have to rename its schema to the OID that the service assigns? > > -- ------------------------------------------------------------------------------ Michael Mealling | 505 Huntmar Park Drive | Phone: (703)742-0400 Software Engineer | Herndon, VA 22070 | Fax: (703)742-9552 Network Solutions | | michaelm@rwhois.net From owner-ietf-schema-reg Mon Nov 24 14:06:32 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA10225 for ietf-schema-reg-bks; Mon, 24 Nov 1997 14:06:32 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.29]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA10220; Mon, 24 Nov 1997 14:06:28 -0800 (PST) Received: by mail4.microsoft.com with Internet Mail Service (5.5.1960.3) id ; Mon, 24 Nov 1997 13:56:53 -0800 Message-ID: From: Chris Weider To: "'michaelm@rwhois.net'" Cc: M.Wahl@critical-angle.com, phoffman@imc.org, ietf-schema-reg@imc.org Subject: RE: Listing request names Date: Mon, 24 Nov 1997 12:07:07 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ietf-schema-reg@imc.org Precedence: bulk We should provide a unique-identification service for schema elements which do not have them. But again, these can be irrelevant to specific protocols which wish to use specific schema. And LDAP can use any naming tree anywhere, and there's no imperative to put all schema under a single subtree. Chris > -----Original Message----- > From: Michael Mealling [SMTP:michael@bailey.dscga.com] > Sent: Monday, November 24, 1997 11:45 AM > To: Chris Weider > Cc: michaelm@rwhois.net; M.Wahl@critical-angle.com; phoffman@imc.org; > ietf-schema-reg@imc.org > Subject: Re: Listing request names > > Chris Weider said this: > > Object classes, templates, and attributes should have unique identifiers > > assigned to them. Ideally these identifiers would not be human-friendly > > names, because human-friendly names are quite likely to be reused. A > given > > protocol does not have to use the unique identifiers in its operations; > for > > example, whois++ can continue to use the human-readable attribute and > > template names. But there needs to be some disambiguation possible other > > than "well, it's the version of Name used by the whois++ server at > > www.foo.com".... > > I'm confused. I thought we were just listing schema, not providing > a naming service. I was thinking of a system where each > entity would end up having several different names: this is what LDAP > calls this schema, this is what whois++ calls it, this is what the > service itself calls it. But the listing service name has no more > importance > than any of the others. > > Anyway, I don't have a problem with the service creating OIDs. I just > want them to be used by the service and not used as a directory services > native naming scheme. I don't think we understand this stuff well enough > to start figuring out how to name ALL schema. My personal opinion is that > schema should be named with URNs and not OIDs. (yes, an OID would make a > valid URN and I even wrote a draft on it several years back). > > I havn't gotten into LDAP schema stuff much so I'll ask a question out of > shear ignorance: Is there a problem with LDAP schema using OIDs from > any subtree? Is there a desire in the LDAP community to start putting > schema OIDs into a single standardized tree somewhere? > > > > > > Chris Weider said this: > > > > > > Michael: > > > > > > The OID registration service is implicit in the listing being > able > > > > > > to assign names to the nameless. > > > > [Chris Weider] > > > > > Sure. But are those the names that the schema is supposed to use > > > within its own system? I.e. are the OIDs the service assigns going to > the > > > the > > > > > OIDs that LDAP uses everywhere? > > > > [Chris Weider] Yes > > > > > > > > > By nameless do you mean schema's that have not yet been created or > > > > > > schema that use names other than OIDs? > > > > > > > > [Chris Weider] Yes, and for schema that do not yet have > unique ids > > > > assigned (e.g. Dublin Core). > > > > > > > > > > Yes to all of 'em? If whois++ wants to list its schema in the service > it > > > will have to rename its schema to the OID that the service assigns? > > > > > > -- > -------------------------------------------------------------------------- > ---- > Michael Mealling | 505 Huntmar Park Drive | Phone: > (703)742-0400 > Software Engineer | Herndon, VA 22070 | Fax: > (703)742-9552 > Network Solutions | | michaelm@rwhois.net From owner-ietf-schema-reg Mon Nov 24 15:39:13 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA11168 for ietf-schema-reg-bks; Mon, 24 Nov 1997 15:39:13 -0800 (PST) Received: from i.control.att.com (H-135-205-52-126.control.att.com [135.205.52.126] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA11163; Mon, 24 Nov 1997 15:39:08 -0800 (PST) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Mon, 24 Nov 1997 18:39:16 -0500 (EST) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for michaelm@rwhois.net; Mon, 24 Nov 1997 18:39:15 -0500 (EST) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Mon, 24 Nov 1997 18:39:15 -0500 (EST) From: capple@master.control.att.com (Christopher W Apple) To: Chris Weider , "'michaelm@rwhois.net'" Cc: M.Wahl@critical-angle.com, phoffman@imc.org, ietf-schema-reg@imc.org Subject: RE: Listing request names Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Sorry it took me so long to respond to the latest round of comments on the documents. I've been at home sick since I got back from DirConnect2. Names in the listing service are not names of schema, they are names of _listings_, _requests_, and _files_containing_schema_specifications. Concensus as of quite a while ago was not to name individual schema as a part of the service because there was no single method for naming directory service schema. If this is unclear in the documents, and I don't think it is, we should change them. Proposed wording changes would be appreciated if this concept is not clear. About Paul's proposal to change the way of referencing schema specification files in the meta data: as long as there is no requirement that these OIDs be used as general purpose names for a schema, I have no opinion one way or the other. If there is such a requirement, I think this is quite broken, since protocols other than LDAP/X.500 don't make use of this concept as a protocol element. ------------------------------------------------------------------------ Chris Apple Business Site: AnyWho Directory Services Internet Directory Group http://www.anywho.com AT&T Laboratories capple@master.control.att.com +1 908 582 2409 Tired of slow directories? Try AnyWho. ------------------------------------------------------------------------ From owner-ietf-schema-reg Mon Nov 24 15:58:10 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA11349 for ietf-schema-reg-bks; Mon, 24 Nov 1997 15:58:10 -0800 (PST) Received: from i.control.att.com (H-135-205-52-126.control.att.com [135.205.52.126] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA11344; Mon, 24 Nov 1997 15:58:05 -0800 (PST) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Mon, 24 Nov 1997 18:58:13 -0500 (EST) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for michaelm@rwhois.net; Mon, 24 Nov 1997 18:58:13 -0500 (EST) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Mon, 24 Nov 1997 18:58:13 -0500 (EST) From: capple@master.control.att.com (Christopher W Apple) To: Chris Weider , "'michaelm@rwhois.net'" Cc: M.Wahl@critical-angle.com, phoffman@imc.org, ietf-schema-reg@imc.org Subject: RE: Listing request names Sender: owner-ietf-schema-reg@imc.org Precedence: bulk About temporary schema listing request names: I think that the current way of handling this SHOULD be replaced with Paul Hoffman's suggestion of providing schema writers with a way to obtain one or more via some protocol. I see no problem with a real-time protocol from the end-user's perspective, provided that Paul wants to deal with the implementation from the service side. This could be more difficult than its worth because of threaded web servers; he might have to deal with maintaining state across multiple stateless protocol transactions; or maybe there is a way to configure whatever web server he's planning on using to process requests serially? SMTP may be simpler to deal with because the server could be configured to process incoming requests serially. ------------------------------------------------------------------------ Chris Apple Business Site: AnyWho Directory Services Internet Directory Group http://www.anywho.com AT&T Laboratories capple@master.control.att.com +1 908 582 2409 Tired of slow directories? Try AnyWho. ------------------------------------------------------------------------ From owner-ietf-schema-reg Mon Nov 24 16:03:30 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA11423 for ietf-schema-reg-bks; Mon, 24 Nov 1997 16:03:30 -0800 (PST) Received: from folder.critical-angle.com (eden-gw.critical-angle.com [206.81.238.241]) by mail.proper.com (8.8.7/8.7.3) with SMTP id QAA11417 for ; Mon, 24 Nov 1997 16:03:26 -0800 (PST) Received: (qmail 17331 invoked from network); 25 Nov 1997 00:00:59 -0000 Received: from folder.critical-angle.com (206.81.238.241) by folder.critical-angle.com with SMTP; 25 Nov 1997 00:00:59 -0000 From: Mark Wahl To: capple@master.control.att.com (Christopher W Apple) cc: phoffman@imc.org cc: ietf-schema-reg@imc.org Subject: Re: Listing request names In-reply-to: Your message of "Mon, 24 Nov 1997 18:58:13 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 24 Nov 1997 18:00:59 -0600 Message-ID: <17329.880416059@folder.critical-angle.com> Sender: owner-ietf-schema-reg@imc.org Precedence: bulk > I see no problem with a real-time protocol from the end-user's perspective, > provided that Paul wants to deal with the implementation from the service > side. This could be more difficult than its worth because of threaded web > servers; he might have to deal with maintaining state across multiple > stateless protocol transactions; or maybe there is a way to configure > whatever web server he's planning on using to process requests serially? For _temporary_ OIDs I don't think thread state would be needed. Just invoke a CGI script which locks a file, increments a value stored in it, and returns an OID derived from that value. Given the fashion of having web page counters there are likely to be many examples around of how this is implemented for various platforms. Mark Wahl, Enterprise Directory Integration Critical Angle Inc. From owner-ietf-schema-reg Thu Dec 4 14:05:23 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA02022 for ietf-schema-reg-bks; Thu, 4 Dec 1997 13:57:57 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.23]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA02017 for ; Thu, 4 Dec 1997 13:57:53 -0800 (PST) Received: by mail3.microsoft.com with Internet Mail Service (5.5.1960.3) id ; Thu, 4 Dec 1997 14:03:03 -0800 Message-ID: From: Chris Weider To: "'ietf-schema-reg@imc.org'" Cc: "'agenda@ietf.org'" Subject: SCHEMA Agenda Date: Thu, 4 Dec 1997 13:59:23 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Hi gang: Here's the proposed agenda for the Schema Listing Service group, which will be held Wednesday , 12/10 from 15:30 - 17:30. If you wish to participate, you MUST read the documents. Please note that this is now a formal working group in the Applications Area. See you there! Chris Agenda: 1: Document status 2: Discussion of draft-apple-schema-rqmts-list-03.txt 3: Discussion of draft-apple-schema-proc-list-00.txt 4: Discussion of draft-apple-schema-mime-metadata-00.txt 5: Discussion of draft-apple-schema-file-list-01.txt 6: Discussion of operational structure 7: Any other business From owner-ietf-schema-reg Sat Dec 6 14:34:06 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA25191 for ietf-schema-reg-bks; Sat, 6 Dec 1997 14:34:06 -0800 (PST) Received: from www.talweb.com (mail.talweb.com [199.44.243.2]) by mail.proper.com (8.8.7/8.7.3) with SMTP id OAA25134; Sat, 6 Dec 1997 14:32:42 -0800 (PST) From: cfDBR0oni@1blowup.net Received: from eHdAWz4sH (unverified [206.133.65.63]) by www.talweb.com (EMWAC SMTPRS 0.83) with SMTP id ; Sat, 06 Dec 1997 17:20:15 -0500 DATE: 05 Dec 97 5:24:55 PM Message-ID: TO: lasers@44optic.com SUBJECT: Lasers/Optics/Optical Tables - Save! Sender: owner-ietf-schema-reg@imc.org Precedence: bulk MWK INDUSTRIES SALE! JUST A QUICK LETTER TO SHOW YOU SOME LASERS- OPTICS AND OPTICAL TABLES SURPLUS THAT WE JUST RECEIVED. ITEM TRIMMU12 14 WATT ARGON LASER MADE FOR HEART SURGERY, TRIMEDYNE MODEL 900 TEMOO, POLORIZED,220VAC INPUT , WATER COOLED , FIBER LAUNCH, ALL ON ROLLAROUND CART EXCELENT FOR LAB USE, THE POWER WAS MEASURED AT 13 TO 14 WATTS. PRICE $9500 12 MONTH WARRANTEE. ITEM: COHERENT ARTICULATING ARM FROM A MODEL 451 CO2 MEDICAL LASER. ECCELLENT COND. $200 ITEM CO220A: CO2 LASER MADE BY PFIZER ,1990, FOR SURGERY, TATTOO REMOVAL ECT. 20 WATT OUTPUT , TESTED AND IN EXC. COND. 110 VAC INPUT, COST $40,000 NEW OUR PRICE 4,900. MODEL 20-C ITEM:PDA-1U1 SPECTRA PHYSICS QUANTRA RAY PULSED DYE LASER , GOOD FOR SPARE PARTS MODEL PDA-1 $500 ITEM NEWU1 NEWPORT OPTICAL TABLE 16" BY 36" 4" THICK, 1 " HOLE SPACING, COMES WITH A RUBBER ISOLATED TABLE STAND, NOT AIR SUPPORTED, $750 ITEM: HEPSN1 HELIUM NEON POWER SUPPLY KIT OPERATES UP TO A 15 mW LASER, INCLUDES ALL COMPONENTS AND PRINTED CIRCUIT BOARD, ALL YOU HAVE TO DO IS STUFF AND SOLDER THE CIRCUIT BOARD . 4" BY 3" BY 3", PRICE $75 ITEM HENEU12 1 TO 1.5 MW HE-NE LASER 632.8 nM INCLUDES 12VDC INPUT POWER SUPPLY ALL IN A PLASTIC HOUSING 6.25 IN. BY 1.375IN BY 2.25 IN. TEMOO,RANDOM POL. ,1.7 MR DIVERGENCE. 12 MONTH WARRANTEE , PRICE $45 ITEM MELU12 1 TO 2 mW HE-NE LASER 632.8 NM , PULLS FROM MEDICAL EQUIPMENT .EACH UNIT INCLUDES HE-NE HEAD AND POWER SUPPLY[110VAC INPUT]. ALL YOU NEED TO PROVIDE IS A POWER CORD AND A FUSE TO MAKE THE UNIT OPERATIONAL. THE BEAM IS TEM00, POLORIZED WE WILL COVER EACH UNIT WITH A 12 MONTH UNLIMITED HOUR WARRANTEE, EXCELLENT FOR FOR LAB OR HOME USE. NEW THESE COST APPROX. $350 OUR PRICE $85. DIMENSIONS 9.75 BY 1.25 INCHES, P.S. 4.25 BY 3.25BY 1.25 INCHES. ITEM RAMCNS1: RAMAN CELL OPTICS 308 nm AR/AR 4600 A 0=0 DEGREES 1000 MM FL. 2" DIA. NEW. ORIGINAL PRICE $520 OUR PRICE $175 ITEM TFPOLNS1: POLARIZERS , THIN FILM FOR 532 nm , NEW, ORIGINAL COST $590 EACH OUR PRICE $200 EACH 10 MM DIA. ITEM CO2OCNS1: CO2 HIGH REFECTOR AND OUTPUT COUPLER 10.5 MM DIA, OC =79%R NEW. $200 A SET. ITEM 25MNS1: DIELECTRIC BROADBAND MIRRORS 450 TO 700NM , NEW WITH PLASTIC PROTECTIVE COATINGS , 2 SIZES 25 MM SQ. AND 50 MM SQ. RECOMENDED FOR HIGHER POWER LASERS. 25MM SIZE ITEM 25MNS1 $20 50MM SIZE ITEM 50MNS1 $25 ITEM # BSDNS1: 50/50 DIELECTRIC COATED PLATE BEAM SPLITTER 630 TO 660 NM COMES IN A TRIANGLE SHAPE EACH SIDE APPROX. 1" PRICE $20 ITEM # 45NS1 45 DEGREE RED REFLECTOR , PASSES 488 TO 532NM , CAN BE USED TO COMBINE RED AND GREEN/BLUE LASERS TO CREATE A WHITE LIGHT LASER. 1" SQ. PRICE $15 ITEM# PCINS1 PLANO/CONVEX LENS COATED FOR YAG 1064NM , AR COATED, 10MM DIA. NEW, ORIG. COST $250 OUR PRICE $100 ITEM# INFILTER : INTERFERENCE FILTERS USED FOR PASSING A PARTICULAR SPECTRAL LINE , 11.8 MM DIA. CAREFULLY REMOVED FROM MEDICAL EQUIPMENT AND WRAPPED IN LENSE PAPER. THE FOLLOWING WAVE LENGTHS ARE AVAILABLE. 523.5, 547.4 , 572.1, 512.9, 550.6, 488, 505.7 nm price $20 each. FOR A COMPLETE LINE OF NEW AND USED LASERS - OPTICS -ELECTRO OPTICS- LASER SHOWS ORDER A COMPLETE CATALOG AT MWKINDUSTRIES.COM TO: ORDER GO TO OUR WEB SITE MWKINDUSTRIES.COM {SECURE ORDERING SITE} QUESTIONS OR REMOVAL FROM MAILING LIST EMAIL: MWK@WORLDNET.ATT.NET MWK INDUSTRIES 1269 POMONA RD CORONA CA 91720 PHONE 909-278-0563 FAX 909-278-4887 From owner-ietf-schema-reg Mon Dec 8 01:02:20 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id BAA10560 for ietf-schema-reg-bks; Mon, 8 Dec 1997 01:02:20 -0800 (PST) Received: from lsf008.gateway.com (gate4.gateway.com [208.215.59.158]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id BAA10556; Mon, 8 Dec 1997 01:02:16 -0800 (PST) From: 6vc8eqq93@m1Im.net Received: by lsf008.gateway.com; id CAA07961; Mon, 8 Dec 1997 02:55:38 -0600 (CST) Received: from sdn-ts-001fljackp01.dialsprint.net(206.133.84.20) by lsf008.gateway.com via smap (V3.1) id xmala7273; Mon, 8 Dec 97 02:55:10 -0600 DATE: 07 Dec 97 4:02:02 AM Message-ID: TO: ads@4uonthe.net SUBJECT: We bulk Email for You Sender: owner-ietf-schema-reg@imc.org Precedence: bulk LET US DO YOUR BULK MAILINGS!!! ...$350 PER MILLION ADDRESSES SENT ...$250 PER 1/2 MILLION ADDRESSES SENT THE WAY OF THE FUTURE FOR SUCCESS IN YOUR BUSINESS! Our company will do bulk emailing for your product/service. DON'T BE LEFT IN THE DUST OF YOUR COMPETORS, ADVERTISE TODAY!!! Addresses are extracted daily by 6 of our computers, which run 24 hours a day 7 days a week, scanning the net for new addresses. Estimated 60-80,000 addresses extracted daily. They are fresh! Over 40 million addresses on file. More computers with cable modems are being added due to increasing responses. All ads can not be more than 2 pages (50 lines) and 68 characters wide. More than 50 lines, there will be an additional charge of $50 per page or 25 lines or less. No porn, no foul language or sex relative material will be sent. ->->->->->->->-> TARGETED MAILINGS <-<-<-<-<-<-<-<- ->-> $150 per 50,000 addresses extracted or less ->-> This price includes mailing of material ->-> Allow 3-7 days for extracting of addresses ->-> Mailings to US only (general addresses) $500 per 500,000 ->-> Many targeted list on file ->-> Purchased target list $150 per 50,000 or less If you have your own list, we will email your list for $200 per 500,000 or less. All list must be in text format and each address must be on individual lines. ***Mailings are done all at once, not broken down into multiple mailings.*** Addrsses are processed against our remove list of those individuals who have asked to be elimated from any of our mailings. All mailings are de-duped for duplicates. No .mil, .gov or .edu included. There are no lower prices on the net. Your mailing can be done in a matter of hours. Turn around time for mailings range from 3 to 5 days. This time varies according to the demand of mailings. For the fastest service, cheapest prices and cleanest mailings call our processing and new accounts office at 904-282-0945, Monday - Friday 9 - 5 EST (English only). If the line is busy or no repsonse, please keep trying, as bulk mailing is growing fast and we are busy responding to those who are interested in advertsing on the internet. We DO want to work with you to advertise your product/service. No collect calls. Our computers are working 24 hours a day to better serve YOU! To have your name removed, call our processing office. Any negative responses will be dealt with accordingly. From owner-ietf-schema-reg Fri Dec 12 21:53:48 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id VAA17339 for ietf-schema-reg-bks; Fri, 12 Dec 1997 21:53:48 -0800 (PST) Received: from i.control.att.com (H-135-205-52-126.control.att.com [135.205.52.126] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id VAA17334 for ; Fri, 12 Dec 1997 21:53:44 -0800 (PST) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Sat, 13 Dec 1997 00:55:36 -0500 (EST) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for ietf-schema-reg@imc.org; Sat, 13 Dec 1997 00:55:31 -0500 (EST) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Sat, 13 Dec 1997 00:55:31 -0500 (EST) From: capple@master.control.att.com (Christopher W Apple) To: ietf-schema-reg@imc.org Subject: post-Washington work Sender: owner-ietf-schema-reg@imc.org Precedence: bulk I am away from the office and unreachable from 12/13/97 - 12/21/97. Please post comments on the existing documents for the schema listing service to this mailing list (see the WG section of the IMC web site or the WG Agenda on the IETF web site for a list of documents). After I return from vacation on 12/21/97, I'll re-submit the I-D's beginning with draft-apple- as draft-ietf-schema-. These new documents will have comments discussed during the SCHEMA WG meeting incorporated except for those related to the discussion about file names. This topic needs to be discussed further on the list. Please start...and I'll read the postings when I return. I'll also post a set of changes made to each document to the list once they've been sent to the I-D editor. Sorry to disappear for so long; but as you all know, there is no 'good' time to take a vacation. :) ------------------------------------------------------------------------ Chris Apple Business Site: AnyWho Directory Services Internet Directory Group http://www.anywho.com AT&T Laboratories capple@master.control.att.com +1 908 582 2409 Tired of slow directories? Try AnyWho. ------------------------------------------------------------------------ From owner-ietf-schema-reg Fri Dec 19 10:54:56 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA11592 for ietf-schema-reg-bks; Fri, 19 Dec 1997 10:54:56 -0800 (PST) Received: from prabhava.proper.com (prabhava.proper.com [165.227.249.110]) by mail.proper.com (8.8.7/8.7.3) with SMTP id KAA11588 for ; Fri, 19 Dec 1997 10:54:49 -0800 (PST) Message-Id: <3.0.5.32.19971219105726.0085f370@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 19 Dec 1997 10:57:26 -0800 To: ietf-schema-reg@imc.org From: Paul Hoffman / IMC Subject: Listing names, file names, and version numbers Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Sorry about taking so long to get to this. I missed Chris' request that we start in without him. After the discussion in DC, I propose the following: - Each schema has an internal name that is chosen by the schema author. It must be unique, and the vetting group will verify this. People searching the listing service will definitely be able to search on this. - The file names will look like an OID. This works well for the only type currently defined (LDAP). If other types cannot use names that are in number-period-number-period... format, we can come up with an alternate filenaming scheme for them that will use the same numbers as the "base" numbers. - The OID will look like: base . sequence . listversion . type sequence = 0*; unique number for the schema listversion = 0*; version of this listing (0 is special) type = 0*; (1 for ldap, 2 for whois++, and so on) (Note that I got rid of "typeversion" from my previous proposal. At DC, we thought that any change to a type within a particular version of a listing should cause the listing version number to change.) Listversion is initialized at 1 for the first submission of a schema. Updates to either a schema or to an individual type cause the version number to be incremented by 1. When requesting a schema from the listing service, using a listversion of 0 indicates "the highest current listversion number", meaning the most recent version. When requesting the metadata for a schema, no type is given. This means that the OID for the metadata is "base.sequence.listversion" Retrieval would be as follows: base.12.4: returns the metadata for version 4 of schema 12 base.12.0: returns the metadata for the latest version of schema 12 base.12.4.1: returns the schema listing for the ldap instantiation of version 4 of schema 12 base: error base.12: error - An alternaive listname would be: file-name = "schema-" sequence "-v" listversion "-" typename For instance, "schema-12-v4-ldap". The metadata would be called "schema-12-v4-metadata". I am not particularly fond of these human-readable names. I think that calling the schema "schema.12.4.1" is actually more useful than calling it "schema-12-v4-ldap" because then you have the OID immediately. That is, having two external names (a file name and an OID) is worse than having one. All comments are welcome. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-schema-reg Mon Jan 12 08:49:36 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA13862 for ietf-schema-reg-bks; Mon, 12 Jan 1998 08:49:36 -0800 (PST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA13857 for ; Mon, 12 Jan 1998 08:49:32 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA18337; Mon, 12 Jan 1998 11:52:40 -0500 (EST) Message-Id: <199801121652.LAA18337@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ietf-schema-reg@imc.org From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-schema-ldap-00.txt Date: Mon, 12 Jan 1998 11:52:40 -0500 Sender: owner-ietf-schema-reg@imc.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Schema Registration Working Group of the IETF. Title : MIME Directory Profile for LDAP Schema Author(s) : M. Wahl Filename : draft-ietf-schema-ldap-00.txt Pages : 8 Date : 09-Jan-98 This document defines a MIME directory profile [1] for holding an LDAP [2] schema. It is intended for communication with the Internet schema listing service. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-schema-ldap-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-schema-ldap-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-schema-ldap-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19980112114144.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-schema-ldap-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-schema-ldap-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980112114144.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-schema-reg Wed Jan 14 13:20:44 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA26723 for ietf-schema-reg-bks; Wed, 14 Jan 1998 13:20:44 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.29]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA26717 for ; Wed, 14 Jan 1998 13:20:38 -0800 (PST) Received: by INET-04-IMC with Internet Mail Service (5.5.1960.3) id ; Wed, 14 Jan 1998 13:24:56 -0800 Message-ID: From: Chris Weider To: "'ietf-schema-reg@imc.org'" Subject: Draft minutes from the SCHEMA meeting, Washington, D.C. Date: Wed, 14 Jan 1998 13:24:49 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Please send me comments/corrections by Friday 1/16. Thanks! Chris Draft SCHEMA minutes from Washington, D.C. The agenda sent out was as follows: 1: Document Status 2: Discussion of draft-apple-schema-rqmts-list-03.txt 3: Discussion of draft-apple-schema-proc-list-00.txt 4: Discussion of draft-apple-schema-mime-metadata-00.txt 5: Disucssion of draft-apple-schema-file-list-01.txt 6: Discussion of operational structure 7: Any other business One other item was added before the meeting: 8: A discussion of criteria for which schema should be developed in the IETF Chris Apple presented a number of comments on the requirements and listing procedures document: * Wording related to updating and deprecation * Don't use temporary names created by schema writer * Changes to repository access wording in requirements document * Confusion over names in the service: we are naming 3 things: listings, requests, files * Typos in meta data examples * File name syntax spec: octal values <-> hex values * Change title of requirements doc to include word 'initial' * Typos... * File name syntax? * Why no meta schema listings? * Authorization contact -> MV (take to list?) * Conflict resolution for scheaTitle * Caveat words fixed / same for each listing These will be addressed in the next versions of the document. The authorization contact issue will be taken to the list. Next, Paul Hoffman presented a naming scheme for listed schema. There were no comments as people hadn't read the document yet. Please read the document and get comments to Paul and the list. Discussion then started on what types of schema should be developed in the IETF. Harald Alvestrand stated that in his opinion a schema should be developed in the IETF only if it is required for the interoperation of a protocol that the IETF is also working on. Other folks had other opinions, and there was no consensus reached. From owner-ietf-schema-reg Thu Jan 15 15:32:51 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA19135 for ietf-schema-reg-bks; Thu, 15 Jan 1998 15:32:51 -0800 (PST) Received: from davinci.netaxis.COM (davinci.netaxis.com [198.69.103.4]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA19130 for ; Thu, 15 Jan 1998 15:32:47 -0800 (PST) From: RuRHku1KG@a1oI.com Received: from f5mFfXod2 (1Cust69.tnt26.atl2.da.uu.net [208.255.221.69]) by davinci.netaxis.COM (8.8.8/8.7.3) with SMTP id SAA16270; Thu, 15 Jan 1998 18:20:27 -0500 (EST) DATE: 14 Jan 98 6:36:40 PM Message-ID: <15wB1cvB37U8Q5J5> TO: adver@tisenow22.com SUBJECT: Tell The World! Sender: owner-ietf-schema-reg@imc.org Precedence: bulk LET US DO YOUR BULK MAILINGS!!! ..$350 PER MILLION ADDRESSES SENT ..$250 PER 1/2 MILLION ADDRESSES SENT THE WAY OF THE FUTURE FOR SUCCESS IN YOUR BUSINESS! Our company will do bulk emailing for your product/service. Addresses are extracted daily by six of our computers, which run 24 hours a day 7 days a week, scanning the net for new addresses. Estimated 60-80,000 addresses extracted daily. They are fresh! Over 40 million addresses on file. No more than 2 pages (50 lines), no porn and no foul language. $50 per page/25 lines per page beyond 2 pages. We do not do targeted mailings at this price. Targeted mailings: $150 per 50,000 addresses extracted or less. We can extract by country, occupation, organizations, associations, product, etc. If we can not search and extract what you need, then nobody can. There are no lower prices on the net. Your mailing can be done in a matter of hours. We have 6 computers extracting addresses 24/7. For the fastest service, cheapest prices and cleanest mailings call our processing and new accounts office at 904-282-0945, Monday - Friday 9 - 5 EST. If the line is busy, please keep trying, as bulk mailing is growing fast. We do want to work with you to advertise your product. To have your name removed, call our processing office. Any negative responses will be dealt with accordingly. From owner-ietf-schema-reg Fri Jan 16 15:57:25 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA09359 for ietf-schema-reg-bks; Fri, 16 Jan 1998 15:57:25 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.23]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA09355 for ; Fri, 16 Jan 1998 15:57:21 -0800 (PST) Received: by mail3.microsoft.com with Internet Mail Service (5.5.1960.3) id ; Fri, 16 Jan 1998 16:01:50 -0800 Message-ID: From: Chris Weider To: "'minutes@ietf.org'" , "'ietf-schema-reg@imc.org'" Subject: Final minutes from the SCHEMA meeting Date: Fri, 16 Jan 1998 16:01:46 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ietf-schema-reg@imc.org Precedence: bulk No corrections were received. Chris Draft SCHEMA minutes from Washington, D.C. The agenda sent out was as follows: 1: Document Status 2: Discussion of draft-apple-schema-rqmts-list-03.txt 3: Discussion of draft-apple-schema-proc-list-00.txt 4: Discussion of draft-apple-schema-mime-metadata-00.txt 5: Disucssion of draft-apple-schema-file-list-01.txt 6: Discussion of operational structure 7: Any other business One other item was added before the meeting: 8: A discussion of criteria for which schema should be developed in the IETF Chris Apple presented a number of comments on the requirements and listing procedures document: * Wording related to updating and deprecation * Don't use temporary names created by schema writer * Changes to repository access wording in requirements document * Confusion over names in the service: we are naming 3 things: listings, requests, files * Typos in meta data examples * File name syntax spec: octal values <-> hex values * Change title of requirements doc to include word 'initial' * Typos... * File name syntax? * Why no meta schema listings? * Authorization contact -> MV (take to list?) * Conflict resolution for scheaTitle * Caveat words fixed / same for each listing These will be addressed in the next versions of the document. The authorization contact issue will be taken to the list. Next, Paul Hoffman presented a naming scheme for listed schema. There were no comments as people hadn't read the document yet. Please read the document and get comments to Paul and the list. Discussion then started on what types of schema should be developed in the IETF. Harald Alvestrand stated that in his opinion a schema should be developed in the IETF only if it is required for the interoperation of a protocol that the IETF is also working on. Other folks had other opinions, and there was no consensus reached. From owner-ietf-schema-reg Tue Jan 20 15:03:18 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA08995 for ietf-schema-reg-bks; Tue, 20 Jan 1998 15:03:18 -0800 (PST) Received: from paris.ics.uci.edu (mmdf@paris.ics.uci.edu [128.195.1.50]) by mail.proper.com (8.8.7/8.7.3) with SMTP id PAA08990 for ; Tue, 20 Jan 1998 15:03:14 -0800 (PST) Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa29564; 20 Jan 98 13:39 PST Received: by localhost with Microsoft MAPI; Tue, 20 Jan 1998 13:35:41 -0800 Message-ID: <01BD25A8.4D138420.ejw@ics.uci.edu> From: Jim Whitehead Reply-To: "ejw@ics.uci.edu" To: "'ietf-schema-reg@imc.org'" Subject: Registration of non-LDAP schemas? Date: Tue, 20 Jan 1998 13:35:40 -0800 Organization: U.C. Irvine X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-schema-reg@imc.org Precedence: bulk In reading through "Directory Schema Listing Requirements", draft-apple-schema-rqmts-list-03 (currently expired), I notice that there is an intentional and pervasive bais towards limiting the scope of registration activity to just LDAP schemas. However, there are other Internet groups which are in need of schema registration services, and this need is likely to increase in the future. As one major example, the Extensible Markup Language (XML) provides for the creation of "schema" using the Document Type Definition mechanism. There is a large existing base of SGML DTDs, and hence there is an expectation that there will be a large base of XML DTDs in the future, especially as Web browsers and application programs increasingly support XML. Several groups are hard at work defining XML DTDs today, such as the Resource Description Framework, and the IETF WEBDAV working group. It seems to me that the value of a schema repository increases with the amount of information available in the repository, and hence I am in favor of extending the scope of the schema repository to handle a much wider range of metadata than just LDAP schemas. This doesn't appear to require a large change to the requirements document. Requirements which would require change appear to be: Meta data element syntax SHALL be defined based on the concept of tagged attribute type-value pairs. Language tags as specified in [RFC1766] MUST be used in listing content and meta data. Meta data element values MUST be encoded using the UCS Transformation Format - 8 bit form [RFC2044]. Whether you decide to allow non-LDAP metadata to be registered or not, these particular requirements seem to be far too low-level compared with the other requirements in the document. The real requirements here seem to be: Metadata definitions must be consistent with the type of metadata (e.g., a-v pairs for LDAP, DTD for XML, etc.) Listing of content and metadata must be consistent with the IETF character set policy [Alvestrand, 1998]. So, the question I raise is: should non-LDAP schemas be capable of registration and retrieval using the mechanisms defined by this working group? - Jim From owner-ietf-schema-reg Tue Jan 20 16:11:57 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA09445 for ietf-schema-reg-bks; Tue, 20 Jan 1998 16:11:57 -0800 (PST) Received: from om.proper.com (om.proper.com [165.227.249.115]) by mail.proper.com (8.8.7/8.7.3) with SMTP id QAA09441; Tue, 20 Jan 1998 16:11:51 -0800 (PST) Message-Id: <199801210011.QAA09441@mail.proper.com> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 20 Jan 1998 16:14:59 -0800 To: "ejw@ics.uci.edu" , "'ietf-schema-reg@imc.org'" From: Paul Hoffman / IMC Subject: Re: Registration of non-LDAP schemas? In-Reply-To: <01BD25A8.4D138420.ejw@ics.uci.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-schema-reg@imc.org Precedence: bulk It has always been the intention that this was for many kinds of schemas. All you need for XML schemas to be listed is to create a document similar to <http://www.imc.org/draft-ietf-s chema-ldap> that covers XML. Personally, I think that XML schema listings will be just as valuable as LDAP schema listings, but to a different group of people. You might want to talk to other groups who are working heavily on XML, like Microsoft, about putting together a schema-xml draft. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-schema-reg Fri Jan 23 20:03:21 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id UAA14140 for ietf-schema-reg-bks; Fri, 23 Jan 1998 20:03:21 -0800 (PST) Received: from netra01.origin.com.br (netra01.origin.com.br [200.246.218.1]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id UAA14136 for ; Fri, 23 Jan 1998 20:03:08 -0800 (PST) From: noGkGm38q@upnor1th.com Received: from p9GF17zZU (1Cust222.tnt26.atl2.da.uu.net [208.255.221.222]) by netra01.origin.com.br (8.8.6/8.8.5) with SMTP id BAA23430; Sat, 24 Jan 1998 01:53:20 -0200 (EDT) DATE: 22 Jan 98 11:04:04 PM Message-ID: TO: happyis@doingood39.net SUBJECT: Are You Happy? Sender: owner-ietf-schema-reg@imc.org Precedence: bulk There is brilliant information available to you, that will enable you to fully understand yourself and everybody else. This knowledge can benefit you tremendously in many ways. It can help you to get the very best out of your career, or discover your most suitable new career, and of course being happy at work, really improves the finances. It can also really enhance your love life. If you're in a relationship, it works great, because you are able to fully understand your own and your partner's emotions and motivations. If you're not, you will know exactly what you want from your perfect mate and what they will find attractive about you. Another big advantage to becoming balanced and happy is that good health runs hand in hand. Take a closer look two free pages of information at: http://www.po9.com From owner-ietf-schema-reg Wed Jan 28 23:08:00 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id XAA06044 for ietf-schema-reg-bks; Wed, 28 Jan 1998 23:08:00 -0800 (PST) Received: from i.control.att.com (H-135-205-52-126.control.att.com [135.205.52.126] (may be forged)) by mail.proper.com (8.8.8/8.7.3) with ESMTP id XAA06040 for ; Wed, 28 Jan 1998 23:07:56 -0800 (PST) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Thu, 29 Jan 1998 02:12:34 -0500 (EST) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for ietf-schema-reg@imc.org; Thu, 29 Jan 1998 02:12:29 -0500 (EST) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Thu, 29 Jan 1998 02:12:29 -0500 (EST) From: capple@master.control.att.com (Christopher W Apple) To: "ejw@ics.uci.edu" , "'ietf-schema-reg@imc.org'" Subject: Re: Registration of non-LDAP schemas? Sender: owner-ietf-schema-reg@imc.org Precedence: bulk >In reading through "Directory Schema Listing Requirements", >draft-apple-schema-rqmts-list-03 (currently expired) The expire date in the document that I sent to the I-D Editor was May 8, 1998. Are you saying that you can no longer find it in any of the I-D repositories? >, I notice that there >is an intentional and pervasive bais towards limiting the scope of >registration activity to just LDAP schemas. This is not true. The documents explicitly allow for non-LDAP schemas to be listed. The document does currently limit schema listed for the initial deployment of the service to being schema associated with directory service protocols (LDAP, WHOIS++, RWHOIS, with a request to add WHOIS). > However, there are other >Internet groups which are in need of schema registration services, and this >need is likely to increase in the future. True. We are exploring options and modifications to all schema listing service documents that will allow the initial deployment of the service to scale towards handling the breadth of schema listing service flavors that you imply. Re: your comments on XML/SGML DTDs; we have been discussing this on the engineering team. Since the need for this one appears to be rather pressing for a wide community of interest, it may be supported in the initial release of the schema listing service. But you should consider that as strictly tentative until such time as the SCHEMA WG achieves concensus on supporting it. >This doesn't appear to require a large change to the requirements document. You're correct. But the requirements document is not really the issue. Its all the other documents that require oodles of changes, unless you have separate listing procedures documents for each protocol/technology/mark-up language for which you wish to list schema. While, I'm pretty sure that there is some happy middle ground between having 1 procedures document for all such schema listing types and having 1 procedures doc for _each_ schema listing type, I'm not sure that anyone has a good answer to where and how such happiness can be achieved. At least not yet. I think this evolve over time and that we should not try to come up with a procedures document overnight that covers every type of schema listing possible. > Requirements which would require change appear to be: > > Meta data element syntax SHALL be defined based on the concept of > tagged attribute type-value pairs. > > Language tags as specified in [RFC1766] MUST be used in listing > content and meta data. > > Meta data element values MUST be encoded using the UCS Transformation > Format - 8 bit form [RFC2044]. > >Whether you decide to allow non-LDAP metadata to be registered or not, >these particular requirements seem to be far too low-level compared with >the other requirements in the document. The real requirements here seem to >be: > >Metadata definitions must be consistent with the type of metadata (e.g., >a-v pairs for LDAP, DTD for XML, etc.) I would argue that DTDs for XML schema listings are part of the content and not of the metadata. Schema listing service metadata is used to catalog listings and should not contain information which actually helps to specify the details of a particular schema. Thus, I think that it is still appropriate to constrain metadata structure as the requirements document currently does. But, I confess to not being an expert on DTDs. If my understanding of them is misguided or mistaken, could someone chime in and explain why XML listings would need a different metadata structure than any other listings stored in the repository? If you were concerned about being able to search through DTDs for tags or key words, we have added requirements for the repository operator to provide searching facilities capable of pawing (how's _that_ for a hi-tech term? :) through listing content. >Listing of content and metadata must be consistent with the IETF character >set policy [Alvestrand, 1998]. I'll take this comment to the engineering team for consideration. >So, the question I raise is: should non-LDAP schemas be capable of >registration and retrieval using the mechanisms defined by this working >group? > >- Jim Eventually. The timeframe in which the service is opened up to non-directory-service schemas is open for debate. The only answer that is plausible (in the most general sense): not immediately. ------------------------------------------------------------------------ Chris Apple Business Site: AnyWho Directory Service Internet Directory Group http://www.anywho.com AT&T Laboratories capple@master.control.att.com +1 908 582 2409 Tired of slow directories? Try AnyWho. ------------------------------------------------------------------------ From owner-ietf-schema-reg Thu Jan 29 05:45:20 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id FAA10065 for ietf-schema-reg-bks; Thu, 29 Jan 1998 05:45:20 -0800 (PST) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id FAA10061 for ; Thu, 29 Jan 1998 05:45:16 -0800 (PST) From: Frank_Dawson/CAM/Lotus@lotus.com Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.8.8/8.8.7) with ESMTP id IAA14759; Thu, 29 Jan 1998 08:55:44 -0500 (EST) Received: from mta2.lotus.com (MTA2.lotus.com [9.95.5.6]) by internet2.lotus.com (8.8.8/8.8.7) with SMTP id IAA00979; Thu, 29 Jan 1998 08:36:30 -0500 (EST) Received: by mta2.lotus.com(Lotus SMTP MTA Internal build v4.6.1 (556.2 1-21-1998)) id 8525659B.004C410B ; Thu, 29 Jan 1998 08:52:53 -0500 X-Lotus-FromDomain: LOTUS@MTA To: capple@master.control.att.com (Christopher W Apple) cc: "ejw@ics.uci.edu" , "'ietf-schema-reg@imc.org'" Message-ID: <8525659B.004BFCFB.00@mta2.lotus.com> Date: Thu, 29 Jan 1998 08:53:40 -0500 Subject: Re: Registration of non-LDAP schemas? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Chris Apple wrote, in part: "I would argue that DTDs for XML schema listings are part of the content and not of the metadata. Schema listing service metadata is used to catalog listings and should not contain information which actually helps to specify the details of a particular schema." I would disagree with your comment that DTDs are not part of the metadata of a schema. Indeed, the structural information in a DTD provides the relationship information about data in a schema. There is also information about the data type for the data in the schema. This is certainly "data about data". For example, a Document Type Definition tells one what elements the object may be composed of, but not what the elements semantics are. The inclusion of the DTD in the schema listing, versus a reference to the DTD is another story. - - Frank Dawson From owner-ietf-schema-reg Thu Jan 29 10:05:22 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id KAA12155 for ietf-schema-reg-bks; Thu, 29 Jan 1998 10:05:22 -0800 (PST) Received: from i.control.att.com (H-135-205-52-126.control.att.com [135.205.52.126] (may be forged)) by mail.proper.com (8.8.8/8.7.3) with ESMTP id KAA12147 for ; Thu, 29 Jan 1998 10:05:18 -0800 (PST) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Thu, 29 Jan 1998 13:09:59 -0500 (EST) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for ietf-schema-reg@imc.org; Thu, 29 Jan 1998 13:09:55 -0500 (EST) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Thu, 29 Jan 1998 13:09:55 -0500 (EST) From: capple@master.control.att.com (Christopher W Apple) To: ietf-schema-reg@imc.org Subject: Re: Registration of non-LDAP schemas? Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Frank Dawson wrote: >Chris Apple wrote, in part: > >"I would argue that DTDs for XML schema listings are part of the content >and not of the metadata. Schema listing service metadata is used to catalog >listings and should not contain information which actually helps to specify >the details of a particular schema." > >I would disagree with your comment that DTDs are not part of the metadata >of a schema. Indeed, the structural information in a DTD provides the >relationship information about data in a schema. There is also information >about the data type for the data in the schema. This is certainly "data >about data". For example, a Document Type Definition tells one what >elements the object may be composed of, but not what the elements semantics >are. The inclusion of the DTD in the schema listing, versus a reference to >the DTD is another story. > >- - Frank Dawson A schema listing, in the context of the listing service that we propose, is defined to be a combination of metadata and listing content. Metadata, within the context of the listing service, is limited to data about the listing, and will not include data about the details of the listing content (which is what I think you are describing above). References to listing content (in the case of XML, I'm viewing a DTD as at least one part of the listing content) are to be included in the listing metadata. Listing content and listing metadata are currently prohibited from being stored in the same file. As an example, consider how you could use an argument similar to that above to talk about how an LDAP object class really contains metadata. Specifying one completely requires that you document its optional and mandatory attribute membership and either include or reference attribute type, attribute syntax, and matching rule definitions. This clearly can contain "data about data" in a generic sense. The concensus that we have to date is that each LDAP-specific schema listing will have a single object class definition as its listing content and that the listing metadata will include characteristics of the listing such as who wrote it, when it was written or updated, the listing title (in this case, object class name), the schema listing name (unique across time within the service), references to schema listing content both within and outside of the schema listing repository, etc. ------------------------------------------------------------------------ Chris Apple Business Site: AnyWho Directory Service Internet Directory Group http://www.anywho.com AT&T Labs capple@master.control.att.com +1 908 582 2409 Tired of slow directories? Try AnyWho. ------------------------------------------------------------------------ From owner-ietf-schema-reg Thu Jan 29 16:53:53 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id QAA17274 for ietf-schema-reg-bks; Thu, 29 Jan 1998 16:53:53 -0800 (PST) Received: from paris.ics.uci.edu (mmdf@paris.ics.uci.edu [128.195.1.50]) by mail.proper.com (8.8.8/8.7.3) with SMTP id QAA17270 for ; Thu, 29 Jan 1998 16:53:50 -0800 (PST) Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa09921; 29 Jan 98 16:15 PST Received: by localhost with Microsoft MAPI; Thu, 29 Jan 1998 16:11:01 -0800 Message-ID: <01BD2CD0.7E07C4E0.ejw@ics.uci.edu> From: Jim Whitehead Reply-To: "ejw@ics.uci.edu" To: "'Christopher W Apple'" , "'ietf-schema-reg@imc.org'" Subject: RE: Registration of non-LDAP schemas? Date: Thu, 29 Jan 1998 16:11:00 -0800 Organization: U.C. Irvine X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Comments below: On Wednesday, January 28, 1998 11:12 PM, Christopher W Apple [SMTP:capple@master.control.att.com] wrote: > >In reading through "Directory Schema Listing Requirements", > >draft-apple-schema-rqmts-list-03 (currently expired) > > The expire date in the document that I sent to the I-D Editor > was May 8, 1998. Are you saying that you can no longer find it > in any of the I-D repositories? No, I apparently misread the submission date as the expiration date, my bad. I can still retrieve the spec. from the I-D repository. > >This doesn't appear to require a large change to the requirements document. > > You're correct. But the requirements document is not really the issue. Its > all the other documents that require oodles of changes, unless you have > separate listing procedures documents for each protocol/technology/mark-up > language for which you wish to list schema. While, I'm pretty sure that > there is some happy middle ground between having 1 procedures document for > all such schema listing types and having 1 procedures doc for _each_ > schema listing type, I'm not sure that anyone has a good answer to where > and how such happiness can be achieved. At least not yet. I think this > evolve over time and that we should not try to come up with a procedures > document overnight that covers every type of schema listing possible. Since the technical approach of using {attribute name}: {attribute value} type a-v pairs runs through the other documents, it does seem likely that different schemas, such as XML, will require a different approach. > I would argue that DTDs for XML schema listings are part of the content > and not of the metadata. Schema listing service metadata is used to catalog > listings and should not contain information which actually helps to specify > the details of a particular schema. Thus, I think that it is still appropriate > to constrain metadata structure as the requirements document currently does. > But, I confess to not being an expert on DTDs. If my understanding of them > is misguided or mistaken, could someone chime in and explain why XML > listings would need a different metadata structure than any other listings > stored in the repository? Hmm, to the best of my understanding, I think you're saying this is a "by-reference" vs. "by-value" issue. The approach of this group seems to be a "by-reference" approach, whereas you're feeling that the DTDs are a "by-value" approach. Is this a good summary? > >So, the question I raise is: should non-LDAP schemas be capable of > >registration and retrieval using the mechanisms defined by this working > >group? > > > >- Jim > > Eventually. The timeframe in which the service is opened up to > non-directory-service schemas is open for debate. The only answer > that is plausible (in the most general sense): not immediately. Staged implementation of the listing service sounds OK to me, but I do want to make sure that in the haste to create a listing for directory schemas, listing of other schemas isn't made more difficult, or awkward. - Jim From owner-ietf-schema-reg Thu Jan 29 23:03:47 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id XAA19649 for ietf-schema-reg-bks; Thu, 29 Jan 1998 23:03:47 -0800 (PST) Received: from i.control.att.com (H-135-205-52-126.control.att.com [135.205.52.126] (may be forged)) by mail.proper.com (8.8.8/8.7.3) with ESMTP id XAA19645 for ; Thu, 29 Jan 1998 23:03:43 -0800 (PST) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Fri, 30 Jan 1998 02:08:19 -0500 (EST) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for ietf-schema-reg@imc.org; Fri, 30 Jan 1998 02:08:15 -0500 (EST) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Fri, 30 Jan 1998 02:08:15 -0500 (EST) From: capple@master.control.att.com (Christopher W Apple) To: "ejw@ics.uci.edu" , "'ietf-schema-reg@imc.org'" Subject: RE: Registration of non-LDAP schemas? Sender: owner-ietf-schema-reg@imc.org Precedence: bulk >Hmm, to the best of my understanding, I think you're saying this is a >"by-reference" vs. "by-value" issue. The approach of this group seems to >be a "by-reference" approach, whereas you're feeling that the DTDs are a >"by-value" approach. Is this a good summary? Yes, I believe so. Viewing the service from a high-level point of view, the metadata in the listing service really serves a single purpose: cataloging listings by characteristics not contained within detailed specifications of discrete schema elements. Such discrete schema elements are referenced in the metadata by a URL based on the file name that contains the specification of the details. A DTD could be considered one such discrete schema element type for the case of listing XML schema. >> >So, the question I raise is: should non-LDAP schemas be capable of >> >registration and retrieval using the mechanisms defined by this working >> >group? >> > >> >- Jim >> >> Eventually. The timeframe in which the service is opened up to >> non-directory-service schemas is open for debate. The only answer >> that is plausible (in the most general sense): not immediately. > >Staged implementation of the listing service sounds OK to me, but I do want >to make sure that in the haste to create a listing for directory schemas, >listing of other schemas isn't made more difficult, or awkward. > >- Jim To a certain degree this will be unavoidable. We cannot accurately predict requirements for listing schema of yet-to-be-invented (or even all existing) protocols/technology. We are revising the various documents published to date to make them and the service platform as extensible as time permits. They _should_ be on their way to the I-D editor before monday, next week. Stay tuned... ------------------------------------------------------------------------ Chris Apple Business Site: AnyWho Directory Service Internet Directory Group http://www.anywho.com AT&T Labs capple@master.control.att.com +1 908 582 2409 Tired of slow directories? Try AnyWho. ------------------------------------------------------------------------ From owner-ietf-schema-reg Sat Jan 31 04:32:44 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id EAA22851 for ietf-schema-reg-bks; Sat, 31 Jan 1998 04:32:44 -0800 (PST) Received: from ns.owlseye.com (owl@ns.owlseye.com [199.173.193.212]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id EAA22827 for ; Sat, 31 Jan 1998 04:32:36 -0800 (PST) Received: (from owl@localhost) by ns.owlseye.com (8.8.8/8.7.3) id HAA14167; Sat, 31 Jan 1998 07:20:03 -0500 (EST) Date: Sat, 31 Jan 1998 07:20:03 -0500 (EST) Message-Id: <199801311220.HAA14167@ns.owlseye.com> From: owl@owlseye.com To: ietf-schema-reg@imc.org Reply-To: owl@owlseye.com Subject: OK to send e-mail? Sender: owner-ietf-schema-reg@imc.org Precedence: bulk OK to send an e-mail to ietf-schema-reg@imc.org? From owner-ietf-schema-reg Sun Feb 1 02:16:09 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id CAA07406 for ietf-schema-reg-bks; Sun, 1 Feb 1998 02:16:09 -0800 (PST) Received: from i.control.att.com (H-135-205-52-126.control.att.com [135.205.52.126] (may be forged)) by mail.proper.com (8.8.8/8.7.3) with ESMTP id CAA07401; Sun, 1 Feb 1998 02:16:03 -0800 (PST) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Sun, 1 Feb 1998 05:20:23 -0500 (EST) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for cweider@microsoft.com; Sun, 1 Feb 1998 05:20:19 -0500 (EST) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Sun, 1 Feb 1998 05:20:19 -0500 (EST) From: capple@master.control.att.com (Christopher W Apple) To: internet-drafts@ietf.org Cc: ietf-schema-reg@imc.org, phoffman@imc.org, cweider@microsoft.com Subject: draft-ietf-schema-file-list-00.txt Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Please replace the I-D: draft-apple-schema-file-list-01.txt with the I-D included below. ------------------------------------------------------------------------ Chris Apple Business Site: AnyWho Directory Service Internet Directory Group http://www.anywho.com AT&T Laboratories capple@master.control.att.com +1 908 582 2409 Tired of slow directories? Try AnyWho. ------------------------------------------------------------------------ INTERNET-DRAFT C. Apple AT&T Labs Expires: July 31, 1998 31 January 1998 Directory Schema Listing File Names Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This memo specifies a file name syntax for use by the primary listing repository operator of the directory schema listing service. 1.0 Introduction The fastest route to interoperable directory services is through standard object classes and attribute types. There is a growing number of places where schema for Internet Directory Services and Internet Operations are being defined, with varying degrees of documentation. This plethora of schema is unavoidable in the light of the needs of different service communities, but makes it difficult for directory service builders to find and make use of an existing schema that will serve their needs and increase interoperability with other systems. A listing service providing a single point of discovery for directory service schema will promote schema reuse, reduce duplication of effort, and thus promote directory service interoperability. Schema listings will be stored in multiple files based on the different types of information associated with a Apple [Page 1] INTERNET-DRAFT Directory Schema Listing File Names 31 January 1998 listing: meta data and one or more syntax specifications. 1.1 Scope A file name syntax specification intended for use during the initial release of a directory schema listing service is inside the scope of this document. 1.2 Terms and Definitions Information Object - a descriptive abstraction of some real-world object Object Attribute - a descriptive property of an information object; typically, object attributes are defined in terms of semantic and syntactic definitions Schema - a collection of definitions for related information objects Schema Unit - a related or grouped set of object attributes that form a discrete unit within the context of a schema for a particular protocol; examples include an LDAP object class or a WHOIS++ template Schema Pak - a related or grouped set of schema units that collectively specify a schema associated with a particular protocol; an example of a schema pak is the set of LDAP object classes specified in [RFC225X] Metadata - characteristics that differentiate one schema unit or schema pak from another; used to catalog listing service content; structured using a profile of [MIMEDIR]; also contains references to files stored within and outside of a listing repository Schema Unit Content - a formal specification of a schema unit using a profile of [MIMEDIR] Schema Unit Listing - the combination of a single schema unit content file intended for use within the context of a particular protocol and a file containing metadata describing the schema unit specified within that schema unit content file Schema Pak Listing - a single metadata file containing information describing and referring to a set of related or grouped schema unit content files Repository - a database in which listings are stored Listing Request - a proposed schema unit listing or schema pak listing formatted using [MIME] constructs that is submitted for consideration as a listing to be published in a repository Apple [Page 2] INTERNET-DRAFT Directory Schema Listing File Names 31 January 1998 Operator - an organization that administers and maintains a repository Primary Repository - the repository that masters the schema listings database Shadow Repository - a repository that mirrors the primary repository Contact Person - the name of the individual who holds the authority to update a listing and who should be contacted if questions or concerns arise related to a listing or listing request Listing Authority Contact - the name of the individual who holds authority to replace a contact person; can be either the contact person for a listing or an alternate contact within the organization to which the contact person belongs (this allows one person organizations to list schema) The terms for specifying requirement level defined in [RFC2119] are used in this document. 2.0 File Name Syntax All file names for listing meta data and listing content MUST comply with the following BNF [RFC822] grammar: file-name = base "." sequence "." listversion "." type base = "base" / oid oid = 1*["." oid] sequence = ("0" / "current") / NZDIGIT 0* ; initialized to one (1) for first schema listing ; increments by one (1) for each successive schema ; listing name Apple [Page 3] INTERNET-DRAFT Directory Schema Listing File Names 31 January 1998 type = ("0" / "meta-unit") / ; these values are defined ("1" / "ldap") / ; for the initial release of the ("2" / "pak-ldap") / ; schema listing service ("3" / "whois++") / ("4" / "pak-whois++") / ; other values may be defined ("5" / "rwhois") / ; according to community needs in ("6" / "pak-rwhois") / ; the future ("7" / "whois") / ("8" / "pak-whois") / ; this document will be updated or ("9" / "xml") / ; obsoleted when additional ("10" / "pak-xml") ; values are defined listversion = 1* NZDIGIT = DIGIT = Other possible values of the type component of a file name MAY be defined in the future to accomodate schema listings specified using [MIMEDIR] profiles other than those defined for containing LDAP [RFC2251], WHOIS++ [RFC1835], and RWHOIS [RFC1714] schema listing content. 3.0 Intended Use of File Names Schema writers, implementors, and users of the schema listing service SHOULD make use of the form of file names which includes descriptive alphabetic tokens as the value for the part of a file name. This recommendation is made because it MAY be necessary in future versions of the schema listing service to change the mapping (specified above in the rule) between these more human friendly file names and the underlying OID-like representation of the file names. For the initial release of the service the behaviors documented in Section 4.0 for file retrieval based on file name will be supported. Schema writers, implementors, and users of the schema listing service SHOULD NOT rely on future support of such file retrieval behavior for the file name examples that are missing alphabetic tokens. The behavior of file retrieval based on file names containing alphabetic tokens MUST be preserved permanently by the schema listing Apple [Page 4] INTERNET-DRAFT Directory Schema Listing File Names 31 January 1998 repository operators. 4.0 Example File Names Generally, file names will be of the following form: "base.sequence.listversion.type" The 'base' part of a file name consists of the base OID used by the primary listing repository operator to assign a globally unique name to each listing. The token "base" can be used in place of the actual OID value. The 'sequence' part of a file name consists of a serial number generated by the primary listing repository operator and is unique within the context of the schema listing service. When referring to a listing, a 'listversion' of "0" always represents the most current version (the highest current listversion number) published in the repository. Alternately, the token "current" may be used to request the most current version of a listing file. Otherwise, the listversion part of a file name represents the version number of a listing within the context of the schema listing service. The 'type' part of a file name consists of a token or number representing a file type. This token is unique within the context of the schema listing service and reflects the nature of file content. Retrieval of files will exhibit the following behavior for the initial release of the service (NOTE: a value of 1 is used as the base OID in these examples, the real base OID will be different): 1.12.4.0: returns schema unit metadata for version 4 of listing 12. base.12.4.meta-unit: returns schema unit metadata for version 4 of listing 12 1.12.0.0: returns schema unit metadata for latest version of listing 12 base.12.current.meta-unit: returns schema unit metadata for latest version of listing 12 1.12.4.1: returns ldap schema unit content for version 4 of listing 12 base.12.4.ldap: returns ldap schema unit content for version 4 of listing 12 Apple [Page 5] INTERNET-DRAFT Directory Schema Listing File Names 31 January 1998 1.12.0.1: returns ldap schema unit content for latest version of listing 12 base.12.current.ldap: returns ldap schema unit content for latest version of listing 12 1.13.2.2: returns metadata for version 4 of listing 12 base.13.2.pak-ldap: returns ldap schema pak metadata for version 2 of listing 13 1.13.0.2: returns ldap schema pak metadata for latest version of listing 13 base.13.current.pak-ldap: returns ldap schema pak metadata for latest version of listing 13 5.0 Security Considerations There are no known security concerns associated with the file name syntax specified in this document. 6.0 Acknowledgements Leslie Daigle of Bunyip Information Systems reviewed and provided valuable comments on the syntax specification content in this document. The schema listing service engineering team: Chris Apple - AT&T Labs Sanjay Sain - Oracle Michael Mealling - NSI John Strassner - Cisco Sam Sun - CNRI Mark Wahl - Critical Angle Chris Weider - Microsoft Paul Hoffman for review and comment resulting from his effort to develop a platform for the initial release of the listing service. 7.0 References [MIMEDIR] T. Howes, M. Smith, "A MIME Content-Type for Directory Information", INTERNET-DRAFT , November 1997. Apple [Page 6] INTERNET-DRAFT Directory Schema Listing File Names 31 January 1998 [RFC822] D. Crocker, "Standard of the Format of ARPA-Internet Text Messages", STD 11, RFC 822, August 1982. [RFC1835] P. Deutsch, R. Schoultz, P. Faltstrom, C. Weider, "Architecture of the WHOIS++ Service", RFC 1835, August, 1995. [RFC1714] S. Williamson, M. Kosters,"Referral Whois Protocol (RWhois)", RFC 1714, November 1994 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Level", RFC 2119, March 1997. [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol (Version 3)", RFC 2251, December 1997. 8.0 Author's Address Chris Apple AT&T Labs 600 - 700 Mountain Ave., Room 2F-165 Murray Hill, NJ 07974-0636 USA E-Mail: capple@att.com Phone: +1 908 582 2409 FAX: +1 908 582 3296 This INTERNET-DRAFT expires on July 31, 1998. Apple [Page 7] From owner-ietf-schema-reg Sun Feb 1 02:09:06 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id CAA07364 for ietf-schema-reg-bks; Sun, 1 Feb 1998 02:09:06 -0800 (PST) Received: from i.control.att.com (H-135-205-52-126.control.att.com [135.205.52.126] (may be forged)) by mail.proper.com (8.8.8/8.7.3) with ESMTP id CAA07359; Sun, 1 Feb 1998 02:09:00 -0800 (PST) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Sun, 1 Feb 1998 05:13:20 -0500 (EST) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for cweider@microsoft.com; Sun, 1 Feb 1998 05:13:15 -0500 (EST) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Sun, 1 Feb 1998 05:13:15 -0500 (EST) From: capple@master.control.att.com (Christopher W Apple) To: internet-drafts@ietf.org Cc: ietf-schema-reg@imc.org, phoffman@imc.org, cweider@microsoft.com Subject: draft-ietf-schema-rqmts-list-00.txt Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Please replace the I-D: draft-apple-schema-rqmts-list-03.txt with the I-D included below. ------------------------------------------------------------------------ Chris Apple Business Site: AnyWho Directory Service Internet Directory Group http://www.anywho.com AT&T Laboratories capple@master.control.att.com +1 908 582 2409 Tired of slow directories? Try AnyWho. ------------------------------------------------------------------------ INTERNET-DRAFT C. Apple AT&T Labs Expires: July 31, 1998 31 January 1998 Requirements for the Initial Release of a Directory Schema Listing Service Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This memo documents requirements for listing directory services schema in a centrally operated, administered, and maintained repository. This repository will be available as a resource to directory protocol and service implementors to facilitate schema discovery. Apple [Page 1] INTERNET-DRAFT Directory Schema Listing Requirements 31 January 1998 Table of Contents 1.0 Introduction . . . . . . . . . . . . . . . . . . . . . 3 1.1 Scope. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Terms and Definitions. . . . . . . . . . . . . . . . . 4 1.3 Usage Scenarios. . . . . . . . . . . . . . . . . . . . 5 1.3.1 Location/Retrieval of the vCard Schema for LDAPv3. . 5 1.3.2 Submission of a New Schema Listing via SMTP. . . . . 5 2.0 Listing Service Requirements . . . . . . . . . . . . . 6 2.1 Functional Requirements. . . . . . . . . . . . . . . . 6 2.2 Operational Requirements . . . . . . . . . . . . . . . 6 2.3 Repository Access Functionality. . . . . . . . . . . . 7 3.0 Listing Service Namespace Requirements . . . . . . . . 8 4.0 Listing Requirements . . . . . . . . . . . . . . . . . 8 5.0 Listing Storage Requirements . . . . . . . . . . . . . 9 6.0 Security Considerations. . . . . . . . . . . . . . . . 9 6.1 Compromisable Assets . . . . . . . . . . . . . . . . . 9 6.2 Attack Scenarios . . . . . . . . . . . . . . . . . . . 9 6.2.1 Denial-of-Service Attack Scenarios . . . . . . . . . 10 6.2.2 Confuse-the-User Attack Scenarios. . . . . . . . . . 10 6.3 Security Requirements on Schema Listing Procedures . . 10 7.0 Acknowledgements . . . . . . . . . . . . . . . . . . . 11 8.0 References . . . . . . . . . . . . . . . . . . . . . . 12 9.0 Author's Address . . . . . . . . . . . . . . . . . . . 13 Apple [Page 2] INTERNET-DRAFT Directory Schema Listing Requirements 31 January 1998 1.0 Introduction The fastest route to interoperable directory services is through standard object classes and attribute types. There is a growing number of places where schema for Internet Directory Services and Internet Operations are being defined, with varying degrees of documentation. This plethora of schema is unavoidable in the light of the needs of different service communities, but it makes it difficult for directory service builders to find and make use of an existing schema that will serve their needs and increase interoperability with other systems. A listing service providing a single point of discovery for directory service schema will promote schema reuse, reduce duplication of effort, and thus promote directory service interoperability. The intent is to offer a schema listing service with public read access and restricted, moderated write access. Many hard-coded choices and constraints have been reflected in this requirements document for the purpose of expediting deployment. Future releases of the service may require an update of this document. Initially, such a listing service will be centrally operated, administered, and maintained. The schema listing repository database may also be mirrored to ensure some level of redundancy for read access in the event of service interruption. Eventually, the operations, administration, and maintenance of such a listing service may evolve to use a more distributed deployment scenario. The schema listing service is also intended to be largely automated, with minimal human involvement. Human involvement is likely to be limited to the following types of activities: + handling repository access problems + trouble resolution for computing and communications facilities + dealing with reasonable requests that fall outside of the scope of normal schema listing repository operations + reviewing schema listing requests on a mailing list prior to publishing in the listing repository Future releases of the service may automate some of these tasks. 1.1 Scope Requirements for the initial release of a directory schema listing service are inside the scope of this document. Specifications for syntaxes and grammars to be used in the initial release of the directory schema listing service are outside the scope Apple [Page 3] INTERNET-DRAFT Directory Schema Listing Requirements 31 January 1998 of this document. Documentation of schema listing procedures is outside the scope of this document. 1.2 Terms and Definitions Information Object - a descriptive abstraction of some real-world object Object Attribute - a descriptive property of an information object; typically, object attributes are defined in terms of semantic and syntactic definitions Schema - a collection of definitions for related information objects Schema Unit - a related or grouped set of object attributes that form a discrete unit within the context of a schema for a particular protocol; examples include an LDAP object class or a WHOIS++ template Schema Pak - a related or grouped set of schema units that collectively specify a schema associated with a particular protocol; an example of a schema pak is the set of LDAP object classes specified in [RFC225X] Metadata - characteristics that differentiate one schema unit or schema pak from another; used to catalog listing service content; structured using a profile of [MIMEDIR]; also contains references to files stored within and outside of a listing repository Schema Unit Content - a formal specification of a schema unit using a profile of [MIMEDIR] Schema Unit Listing - the combination of a single schema unit content file intended for use within the context of a particular protocol and a file containing metadata describing the schema unit specified within that schema unit content file Schema Pak Listing - a single metadata file containing information describing and referring to a set of related or grouped schema unit content files Repository - a database in which listings are stored Listing Request - a proposed schema unit listing or schema pak listing formatted using [MIME] constructs that is submitted for consideration as a listing to be published in a repository Apple [Page 4] INTERNET-DRAFT Directory Schema Listing Requirements 31 January 1998 Operator - an organization that administers and maintains a repository Primary Repository - the repository that masters the schema listings database Shadow Repository - a repository that mirrors the primary repository Contact Person - the name of the individual who holds the authority to update a listing and who should be contacted if questions or concerns arise related to a listing or listing request Listing Authority Contact - the name of the individual who holds authority to replace a contact person; can be either the contact person for a listing or an alternate contact within the organization to which the contact person belongs (this allows one person organizations to list schema) The terms for specifying requirement level defined in [RFC2119] are used in this document. 1.3 Usage Scenarios 1.3.1 Location/Retrieval of the vCard Schema for LDAPv3 A user of the schema listing service wants to locate a copy of the vCard schema for LDAPv3 [RFC2251] so that they can use it in a prototyping project. First, they point their web browser at a schema listing repository web site and download the list of available schema. Next, they use the search command on their browser to locate occurances of the string "vCard". The browser automatically scrolls down to the appropriate place in the list of available schema and the user clicks on a link to view the listing metadata to verify that this is indeed the vCard schema for use with version 3 of the LDAP protocol. Included in the web-based representation of the listing metadata are ftp URLs pointing to available profiles containing listing content for this schema. The user clicks on the link for the profile that they can use. 1.3.2 Submission of a New Schema Listing via SMTP A schema writer wishes to list a schema they have created and prepares the listing metadata and listing content according to one or more appropriate [MIMEDIR] profiles. The schema writer will obtain a permanent, unique schema listing name for the request. The schema writer sends an SMTP message including the listing meta data and all available listing content in multipart-related [MIME] Apple [Page 5] INTERNET-DRAFT Directory Schema Listing Requirements 31 January 1998 format to a listing request review mailing list. After a short review period, the listing repository operator validates the request, and if properly formed, publishes the listing according to the listing procedures. An announcement of the newly published schema listing is sent to a mailing list reserved for this purpose. 2.0 Listing Service Requirements 2.1 Functional Requirements Listed schema MAY be published as an RFC. A list of available listings MUST be maintained. Listings MUST be named according to the namespace requirements defined in section 3. The listing service SHALL maintain information about schema units, beyond their definition. This information is referred to as metadata and will consist of information used for cataloging listings in the repositories. The particular set of metadata elements used during the initial deployment of the listing service will be defined in other documents. Listing metadata and listing content MUST be parsable. 2.2 Operational Requirements The process of listing schema MUST be centralized for the initial deployment. All versions of all listings MUST be retained. A simple method for getting the most recent version of a particular listing MUST be provided. The contact person for a listing MAY give an earlier listing a higher version number, or MAY request that the listing get a new name. The listing repository MUST be centrally administered. The listing repository MAY be mirrored. The primary repository operator MUST obtain an OID subtree for which they hold sub-allocation authority for use in the schema listing service. Listing requests MAY be signed using PGP/MIME as described in [RFC2015]. The primary listing repository operator MUST be able to Apple [Page 6] INTERNET-DRAFT Directory Schema Listing Requirements 31 January 1998 accept schema listing requests in PGP/MIME messages, although they are NOT REQUIRED to validate the signatures. The method for validating and determining trust of signatures is outside the scope of this document and is determined by the parties in the exchange. The method for determining and validating trust in an unsigned request is outside the scope of this document, as is the method for determining trust in schema listing repository or its content. A mailing list MUST be created for the purpose of submitting listing requests for review prior to publishing in the schema listing repository. The schema listing repository publication process MUST be moderated via this mailing list. Listing requests MUST be subjected to community review on this mailing list for a period of at least 2 weeks. If no comments are received, properly formed schema listing requests SHALL be published as listings; otherwise, the request MAY either denied or the listing MAY published subject to incorporation of comments. A mailing list MUST be created for announcing new and updated listings. A mailbox MUST be created for the purpose of receiving service trouble requests from users. Listing repository operators (of primary and shadow sites) MUST provide a free means of accessing the listing service consistent with the functionality documented in paragraph 2.3. 2.3 Repository Access Functionality The following schema listing repository access protocols MUST be supported: FTP [RFC959], HTTP 1.1 [RFC2068], and SMTP [RFC821]. The following access functions are REQUIRED: a) browse and retrieve schema unit content, metadata, and a list of available listings: + via HTTP requests + via FTP clients + via requests through an SMTP server b) search a list of available listings: + via HTTP, retrieving either HTML or text listings that can then be searched by the requestor Apple [Page 7] INTERNET-DRAFT Directory Schema Listing Requirements 31 January 1998 + via HTTP by accessing repository-based searching facilities such as keyword searching; this can return listing names, schema unit listings, schema pak listings, metadata, or other useful information c) add and update listings by submitting a formatted request to a mailing list for community review: + via SMTP using appropriate MIME constructs as described in section 4.0 Other access functions, including the following, MAY be supported, but will be defined in other documents in the future: a) search schema unit content b) search metadata 3.0 Listing Service Namespace Requirements The listing service namespace MUST be protocol-independent. The listing service namespace SHALL be based on OIDs. Listing names: + MUST be permanent + MUST be globally unique + MUST be publicly available + MUST NOT be recycled or re-used + MUST be created within the OID subtree reserved for use in the schema listing service and administered by the primary listing repository operator 4.0 Listing Requirements Schema unit content SHALL be limited to the information actually required to specify and encode the schema for storage and transfer. Metadata SHALL be composed of information used to catalog listings. Metadata element syntax SHALL be defined based on the concept of tagged attribute type-value pairs. Apple [Page 8] INTERNET-DRAFT Directory Schema Listing Requirements 31 January 1998 Language tags as specified in [RFC1766] MUST be used in all listings. Metadata element values MUST be encoded using the UCS Transformation Format - 8 bit form [RFC2044]. For the purposes of submitting a listing request, schema unit content and metadata SHOULD be structured according to appropriate profiles of [MIMEDIR] defined in other documents. Content associated with a listing, but not stored in the schema listing repository (such as large copyright notices and vendor logo images) MAY be included by reference in the metadata. If such external references are included in a particular schema listing, a fingerprint of the external content generated prior to schema listing request creation MUST be included along with these references in the request. Details associated with the creation of these external content references, including the algorithm to be used for generation of a content fingerprint and the syntax of the reference, will be defined in the [MIMEDIR] profile used to format and encode listing metadata for storage and transfer. 5.0 Listing Storage Requirements Listing repository file names MUST be permanent, globally unique, and publicly available. Listing repository file names SHOULD be constructed in a manner that allows human and machine users to determine the nature of file content by inspecting the file names. Schema unit content and metadata MUST be stored in separate files. 6.0 Security Considerations 6.1 Compromisable Assets One or more of the following assets could be compromised if the service is attacked: + Metadata + Schema unit content + Repository Hardware & Software + Networking Facilities Connecting Repository to the Internet + Repository Mirror Sites 6.2 Attack Scenarios Allowable methods for submitting listing requests are: Apple [Page 9] INTERNET-DRAFT Directory Schema Listing Requirements 31 January 1998 a) sending an e-mail message to a mail box b) submitting requests using web-based forms Based on these request submission methods, there are a number of known repository attack scenarios that must be considered during the implementation of schema listing procedures and the software and operational processes required to support them. 6.2.1 Denial-of-Service Attack Scenarios Scenario A: someone could send in a large number of improperly formed requests Scenario B: someone could send in a large number of properly formed, but frivolous, useless, or trivial requests 6.2.2 Confuse-the-User Attack Scenarios Scenario A: someone could send in a large number of valid, but frivolous, useless, or trivial requests and some or all of these requests actually become listings in the repository Scenario B: someone could maliciously submit one or more slightly modified versions of existing listings which are popular or widely used 6.3 Security Requirements on Schema Listing Procedures The following contextual definitions apply to the requirements listed in the remainder of this paragraph: Verification - a process of determining authenticity of facts implied or explicitly specified by a contact person during the process of submitting a schema listing request; the methods used to implement such a process MAY or MAY NOT be based on an IETF-sanctioned security protocol; specification of the methods used to implement such a process as well as the trust relationships relevant to the process are outside the scope of this document. High-Quality Directory Schema - a directory schema that serves some useful purpose (e.g., a related set of attribute and object class definitions for holding information about people in a LDAP directory); a schema that is _not_ merely trivial or frivolous (e.g., a trivial schema might consist of a related set of attribute and object class definitions for holding information about the two possible binary bit values in a directory). The schema listing procedures SHOULD be designed to enable: Apple [Page 10] INTERNET-DRAFT Directory Schema Listing Requirements 31 January 1998 a) verification that all properly formed schema listing requests are submitted by the contact person claiming to originate them b) methods of ensuring that only properly-formed, high-quality directory schema are published in the schema listing repository c) verifcation that requests to change the identity of the contact person for a listing originate from the listing authority contact or the contact person d) coping with the situation in which the contact person and/or listing authority contact for a schema is no longer available or is unable to submit updates to the listing for which they hold update authority For the initial release of the service, there is NO REQUIREMENT on any participant, user, or application to retain signature information as it applies to an entire schema listing request. Fingerprints included with external content reference metadata elements MUST be retained and included in published listing request. Users of the schema listing service SHOULD verify that fingerprints of referenced content match corresponding fingerprints included with external references as a part of the published schema listing. If purported (included in the listing) and actual (computed by the user) fingerprints are different, users of the service SHOULD consider the possibility that the referenced content has changed since publication of the schema listing and that such a change could affect the way in which associated content can be used. Referenced content is outside of the control of the schema listing service. A caveat explaining this concept MUST be included in the metadata of all published listings if external references are included in corresponding listing requests. 7.0 Acknowledgements Leslie Daigle of Bunyip Information Systems and Chris Weider of Microsoft provided valuable comments on multiple versions of this document. The engineering team for listing service requirements: Chris Apple - AT&T Labs Apple [Page 11] INTERNET-DRAFT Directory Schema Listing Requirements 31 January 1998 Sanjay Jain - Oracle Michael Mealling - NSI John Strassner - Cisco Sam Sun - CNRI Mark Wahl - Critical Angle Chris Weider - Microsoft Paul Hoffman, for review and comment during his effort to implement the primary directory schema listing service platform. The members of the ietf-schema-reg@imc.org mailing list. 8.0 References [CHARSET] Internet Assigned Numbers Authority, "CHARACTER SETS", . [MIME] [RFC2045], [RFC2046], and [RFC2047]. [MIMEDIR] T. Howes, M. Smith, "A MIME Content-Type for Directory Information", INTERNET-DRAFT , July 1997. [RFC821] J. Postel, "Simple Mail Transfer Protocol", RFC 821, August 1982. [RFC959] J. Postel, J.K. Reynolds, "File Transfer Protocol", RFC 959, October 1985. [RFC1766] H. Alvestrand, "Tags for the Identification of Languages", RFC 1766, March 1995. [RFC2015] M. Elkins, "MIME Security with Pretty Good Privacy (PGP)", RFC 2015, October 1996. [RFC2044] F. Yergeau, "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, October 1996. [RFC2045] N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC2046] N. Freed & N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [RFC2047] K. Moore, "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996. Apple [Page 12] INTERNET-DRAFT Directory Schema Listing Requirements 31 January 1998 [RFC2068] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners- Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997. [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Level", March 1997. [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol (Version 3)", RFC 2251, December 1997. 9.0 Author's Address Chris Apple AT&T Labs 600 - 700 Mountain Ave., Room 2F-165 Murray Hill, NJ 07974-0636 USA E-Mail: capple@att.com Phone: +1 908 582 2409 FAX: +1 908 582 3296 This INTERNET-DRAFT expires on July 31, 1998. Apple [Page 13] From owner-ietf-schema-reg Sun Feb 1 02:12:23 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id CAA07384 for ietf-schema-reg-bks; Sun, 1 Feb 1998 02:12:23 -0800 (PST) Received: from i.control.att.com (H-135-205-52-126.control.att.com [135.205.52.126] (may be forged)) by mail.proper.com (8.8.8/8.7.3) with ESMTP id CAA07379; Sun, 1 Feb 1998 02:12:17 -0800 (PST) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Sun, 1 Feb 1998 05:16:37 -0500 (EST) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for cweider@microsoft.com; Sun, 1 Feb 1998 05:16:33 -0500 (EST) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Sun, 1 Feb 1998 05:16:33 -0500 (EST) From: capple@master.control.att.com (Christopher W Apple) To: internet-drafts@ietf.org Cc: ietf-schema-reg@imc.org, phoffman@imc.org, cweider@microsoft.com Subject: draft-ietf-schema-mime-metadata-00.txt Sender: owner-ietf-schema-reg@imc.org Precedence: bulk Please replace the I-D: draft-apple-schema-mime-metadata-00.txt with the I-D included below. ------------------------------------------------------------------------ Chris Apple Business Site: AnyWho Directory Service Internet Directory Group http://www.anywho.com AT&T Laboratories capple@master.control.att.com +1 908 582 2409 Tired of slow directories? Try AnyWho. ------------------------------------------------------------------------ INTERNET-DRAFT C. Apple AT&T Labs Expires: July 31, 1998 31 January 1998 Directory Schema Listing Meta Data Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This memo defines a MIME directory profile for content transfer and encoding of metadata elements used for cataloging schema listings in a directory schema listing service. Apple [Page 1] INTERNET-DRAFT Directory Schema Listing Meta Data 31 January 1998 Table of Contents 1.0 Introduction. . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terms and Definitions . . . . . . . . . . . . . . . . . . . 3 2.0 The "schema-metadata-0" MIME Directory Profile Registration 4 3.0 MIME Directory Type Registrations . . . . . . . . . . . . . 6 3.1 listingName . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2 listingTitle. . . . . . . . . . . . . . . . . . . . . . . . 7 3.3 listingUse. . . . . . . . . . . . . . . . . . . . . . . . . 8 3.4 specFile. . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.5 relatedTo . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.6 contactLanguage . . . . . . . . . . . . . . . . . . . . . . 10 3.7 contactName . . . . . . . . . . . . . . . . . . . . . . . . 11 3.8 contactEmail. . . . . . . . . . . . . . . . . . . . . . . . 11 3.9 contactPhone. . . . . . . . . . . . . . . . . . . . . . . . 12 3.10 contactAddress . . . . . . . . . . . . . . . . . . . . . . 13 3.11 authLanguage . . . . . . . . . . . . . . . . . . . . . . . 13 3.12 authName . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.13 authEmail. . . . . . . . . . . . . . . . . . . . . . . . . 15 3.14 authPhone. . . . . . . . . . . . . . . . . . . . . . . . . 16 3.15 authAddress. . . . . . . . . . . . . . . . . . . . . . . . 16 3.16 specURL. . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.17 security . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.18 created. . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.19 moreInfo . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.20 caveat . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.21 listingComments. . . . . . . . . . . . . . . . . . . . . . 21 3.22 schemaPak. . . . . . . . . . . . . . . . . . . . . . . . . 22 3.23 pakMember. . . . . . . . . . . . . . . . . . . . . . . . . 22 4.0 Examples. . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.1 Schema Unit Listing Request Use of Profile. . . . . . . . . 23 4.2 Published Schema Unit Listing Use of Profile. . . . . . . . 24 4.3 Schema Pak Listing Request Use of Profile . . . . . . . . . 25 4.4 Published Schema Pak Listing Use of Profile . . . . . . . . 25 5.0 Security Considerations . . . . . . . . . . . . . . . . . . 26 6.0 Acknowledgements. . . . . . . . . . . . . . . . . . . . . . 27 7.0 References. . . . . . . . . . . . . . . . . . . . . . . . . 27 8.0 Author's Address. . . . . . . . . . . . . . . . . . . . . . 28 Apple [Page 2] INTERNET-DRAFT Directory Schema Listing Meta Data 31 January 1998 1.0 Introduction The fastest route to interoperable directory services is through standard object classes and attribute types. There is a growing number of places where schema for Internet Directory Services and Internet Operations are being defined, with varying degrees of documentation. This plethora of schema is unavoidable in the light of the needs of different service communities, but it makes it difficult for directory service builders to find and make use of an existing schema that will serve their needs and increase interoperability with other systems. A listing service providing a single point of discovery for directory service schema will promote schema reuse, reduce duplication of effort, and thus promote directory service interoperability. Metadata will be used to catalog and distinguish schema listings in this service. This document defines a [MIMEDIR] profile for metadata content transfer and encoding. 1.1 Terms and Definitions Information Object - a descriptive abstraction of some real-world object Object Attribute - a descriptive property of an information object; typically, object attributes are defined in terms of semantic and syntactic definitions Schema - a collection of definitions for related information objects Schema Unit - a related or grouped set of object attributes that form a discrete unit within the context of a schema for a particular protocol; examples include an LDAP object class or a WHOIS++ template Schema Pak - a related or grouped set of schema units that collectively specify a schema associated with a particular protocol; an example of a schema pak is the set of LDAP object classes specified in [RFC225X] Metadata - characteristics that differentiate one schema unit or schema pak from another; used to catalog listing service content; structured using a profile of [MIMEDIR]; also contains references to files stored within and outside of a listing repository Schema Unit Content - a formal specification of a schema unit using a profile of [MIMEDIR] Schema Unit Listing - the combination of a single schema unit content file intended for use within the context of a particular protocol and Apple [Page 3] INTERNET-DRAFT Directory Schema Listing Meta Data 31 January 1998 a file containing metadata describing the schema unit specified within that schema unit content file Schema Pak Listing - a single metadata file containing information describing and referring to a set of related or grouped schema unit content files Repository - a database in which listings are stored Listing Request - a proposed schema unit listing or schema pak listing formatted using [MIME] constructs that is submitted for consideration as a listing to be published in a repository Operator - an organization that administers and maintains a repository Primary Repository - the repository that masters the schema listings database Shadow Repository - a repository that mirrors the primary repository Contact Person - the name of the individual who holds the authority to update a listing and who should be contacted if questions or concerns arise related to a listing or listing request Listing Authority Contact - the name of the individual who holds authority to replace a contact person; can be either the contact person for a listing or an alternate contact within the organization to which the contact person belongs (this allows one person organizations to list schema) The terms for specifying requirement level defined in [RFC2119] are used in this document. 2.0 The "schema-metadata-0" MIME Directory Profile Registration This profile is identified by the following registration template information. To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME profile "schema-metadata-0" Profile Name: schema-metadata-0 Profile Purpose: To represent metadata for a schema listing stored in the repository or a schema listing request under community Apple [Page 4] INTERNET-DRAFT Directory Schema Listing Meta Data 31 January 1998 review. Profile Types: listingName, listingTitle, listingUse, specFile, relatedTo, contactLanguage, contactName, contactEmail, contactPhone, contactAddress, authLanguage, authName, authEmail, authPhone, authAddress, specURL, security, created, moreInfo, caveat, listingComments, schemaPak, pakMember Profile Special Notes: The charset parameter MUST be present in the MIME content header and the value of this parameter MUST be "utf-8". Neither the "BEGIN", "END", nor "SOURCE" type is used in the contents of this profile. Type grouping is not used in the contents of this profile. Each MIME Directory Type Registration that follows in section 3 of this document includes a specification of whether or not a particular type is constrained to be single-valued or permitted to be multi-valued. Types that are permitted to be multi-valued MUST have at least one value, unless otherwise noted in the 'Type special notes' component of a type definition. Implementors should note that there will likely be values of profile types in some contents much longer than 76 bytes. In addition, there may be non-ASCII characters and embedded CRLFs inside of values, which could require either quoting of the value or use of a content transfer encoding. The following types MUST be included by schema writers in schema unit listing requests: listingName, listingTitle, listingUse, specFile, contactLanguage, contactName, contactEmail, contactPhone, contactAddress, authLanguage, authName, authEmail, authPhone, authAddress, and security. The following types MUST be included by schema writers in schema pak listing requests: listingName, listingTitle, listingUse, specFile, contactLanguage, contactName, contactEmail, contactPhone, contactAddress, authLanguage, authName, authEmail, authPhone, authAddress, and security. The 'listingName' type value MUST be created by the primary listing repository operator. The 'relatedTo' type value MUST be provided by the schema writer as a part of a listing request if the listing proposed in the request Apple [Page 5] INTERNET-DRAFT Directory Schema Listing Meta Data 31 January 1998 has a relationship to published listings and/or other listing requests being reviewed. Values for the following types MUST be provided by the primary schema listing repository operator and MUST NOT be accepted from the schema writer: specURL, created, listingComments, and pakMember. The schemaPak type value MAY be provided by either the primary schema listing repository operator or the schema writer when required. The moreInfo type value is OPTIONAL, but MUST be provided by the schema writer. if this metadata element is to be included in a published listing. Intended Usage: COMMON 3.0 MIME Directory Type Registrations This document defines all types use in the schema-metadata-0 profile. These types are intended for use in the "schema-metadata-0" profile, although they may be applicable to other profiles defined in the future. 3.1 listingName To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type listingName Type name: listingName Type purpose: To represent a globally unique identifier for the listing name. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): name = oid "." sequence "." version oid = oid-component *("." oid-component) oid-component = 1*DIGIT DIGIT = Apple [Page 6] INTERNET-DRAFT Directory Schema Listing Meta Data 31 January 1998 sequence = NZDIGIT *DIGIT NZDIGIT = version = version-component *("." version-component) version-component = 1*DIGIT Type special notes: This type MUST be single-valued. A language parameter MUST NOT be used with this type. For published listings and listing requests, a value of this type is an OID constructed by the primary listing repository operator based on a root OID administered by that operator, a listing sequence number generated by that operator, a listing version number assigned by that operator, and a file type indicator. 3.2 listingTitle To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type listingTitle Type name: listingTitle Type purpose: To represent a real world title of a listed schema unit or schema pak. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): utf8-text = 1* Type special notes: This type MAY be multi-valued. A language parameter MUST be used with this type. A value of this type MAY contain local or native version numbers or other version indicators for listed schema. Such schema version information MUST be treated as opaque by implementors. Apple [Page 7] INTERNET-DRAFT Directory Schema Listing Meta Data 31 January 1998 3.3 listingUse To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type listingUse Type name: listingUse Type purpose: To represent a statement of intended use for a listing. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): utf8-text = 1* Type special notes: This type MAY be multi-valued. A language parameter MUST be used with this type. A value of this type is an in-line text description of the intended use of a listing and MAY include embedded CRLF characters. 3.4 specFile To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type specFile Type name: specFile Type purpose: To represent a file name in the schema listing repository for a schema unit content constructed using an appropriate profile of [MIMEDIR]. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): fname = ; all [FILESYN] values except "meta-unit" and "0" ; MAY be used to construct values Type special notes: Apple [Page 8] INTERNET-DRAFT Directory Schema Listing Meta Data 31 January 1998 When used in schema unit listings and schema unit listing requests, this type MUST be single-valued. When used in schema pak listings and schema pak listing requests, this type MUST be multi-valued. A language parameter MUST NOT be used with this type. Currently, there are five [MIMEDIR] profiles defined for containing schema unit content: [MIMELDAP], [MIMEWHOISPP], [MIMEWHOIS], [MIMERWHOIS], and [MIMEXML]. Additional profiles may be defined in other documents. Each of these profiles is identified by a sort text string representative of the profile name. 3.5 relatedTo To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type relatedTo Type name: relatedTo Type purpose: To represent an indication of a relationship of a published listing or listing request with another published listing or listing request. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): related = md-filename *SPACE "$" *SPACE related-option md-filename = related-option = "obsoletes" / "obsoleted-by" / "updates" / "inherits" / vendor-option vendor-option = ("x-" / "X-") vendor-name "-" vendor-specific-relationship vendor-name = 1*TOKEN vendor-specific-relationship = 1*TOKEN TOKEN = CHAR = Apple [Page 9] INTERNET-DRAFT Directory Schema Listing Meta Data 31 January 1998 specials = "(" / ")" / "<" / ">" / "@" ; MUST be in quoted- / "," / ";" / ":" / "\" / <"> ; string, to use / "." / "[" / "]" ; within a word <"> = SPACE = CRLF = CR LF CR = LF = CTL = Type special notes: This type MAY be multi-valued. If a listing is related to another listing, this type is REQUIRED, otherwise the use of this type is OPTIONAL. A language parameter MUST NOT be used with this type. This type is used to indicate relationships between published listings and listing requests as well as between one or more listing requests being submitted for review in parallel. Examples of such relationships include deprecation, revision, inheritance, and those specific to a particular vendor. 3.6 contactLanguage To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type contactLanguage Type name: contactLanguage Type purpose: To represent a language understood by the contact person, organization, or role for a listing. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): Apple [Page 10] INTERNET-DRAFT Directory Schema Listing Meta Data 31 January 1998 c-lang = Type special notes: This type MAY be multi-valued. A language parameter MUST NOT be used with this type. 3.7 contactName To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type contactName Type name: contactName Type purpose: To represent the name of the contact person, organization, or role for a listing. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): utf8-text = 1* Type special notes: This type MUST be single-valued. A language parameter MUST NOT be used with this type. 3.8 contactEmail To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type contactEmail Type name: contactEmail Type purpose: To represent the electronic mail address of the contact person, organization, or role for a listing. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): Apple [Page 11] INTERNET-DRAFT Directory Schema Listing Meta Data 31 January 1998 c-email = local-part "@" domain-part domain-part = sub-domain *("." sub-domain) sub-domain = 1* CHAR = specials = "(" / ")" / "<" / ">" / "@" ; MUST be in quoted- / "," / ";" / ":" / "\" / <"> ; string, to use / "." / "[" / "]" ; within a word <"> = SPACE = CRLF = CR LF CR = LF = CTL = Type special notes: This type MUST be single-valued. A language parameter MUST NOT be used with this type. 3.9 contactPhone To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type contactPhone Type name: contactPhone Type purpose: To represent the voice telephone number of the contact person, organization, or role for a listing. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): c-phone = 1* ; MUST use full international form (e.g., +1 908 582 2409) Apple [Page 12] INTERNET-DRAFT Directory Schema Listing Meta Data 31 January 1998 ; as specified in [E.123] CHAR = CRLF = CR LF CR = LF = CTL = Type special notes: This type MUST be single-valued. A language parameter MUST NOT be used with this type. 3.10 contactAddress To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type contactAddress Type name: contactAddress Type purpose: To represent the postal address of the contact person, organization, or role for a listing. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): c-addr = postal-string *5(*SPACE "$" *SPACE postal-string) postal-string = 1* SPACE = Type special notes: This type MUST be single-valued. A language parameter MUST NOT be used with this type. 3.11 authLanguage Apple [Page 13] INTERNET-DRAFT Directory Schema Listing Meta Data 31 January 1998 To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type authLanguage Type name: authLanguage Type purpose: To represent the language understood by the listing authority contact for a listing. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): lac-lang = Type special notes: This type MAY be multi-valued A language paramter MUST NOT be used with this type. 3.12 authName To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type authName Type name: authName Type purpose: To represent the name of the listing authority contact for a listing. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): utf8-text = 1* Type special notes: This type MUST be single-valued. A language parameter MUST NOT be used with this type. The value of this type MAY be identical to the value of the 'contactName' type defined above. Apple [Page 14] INTERNET-DRAFT Directory Schema Listing Meta Data 31 January 1998 3.13 authEmail To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type authEmail Type name: authEmail Type purpose: To represent the electronic mail address of the listing authority contact for a listing. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): c-email = local-part "@" domain-part domain-part = sub-domain *("." sub-domain) sub-domain = 1* CHAR = specials = "(" / ")" / "<" / ">" / "@" ; MUST be in quoted- / "," / ";" / ":" / "\" / <"> ; string, to use / "." / "[" / "]" ; within a word <"> = SPACE = CRLF = CR LF CR = LF = CTL = Type special notes: This type MUST be single-valued. A language parameter MUST NOT be used with this type. The value of this type MAY be identical to the value of the 'contactEmail' type defined above. Apple [Page 15] INTERNET-DRAFT Directory Schema Listing Meta Data 31 January 1998 3.14 authPhone To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type authPhone Type name: authPhone Type purpose: To represent the voice telephone number of the listing authority contact for a listing. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): lac-phone = 1* ; MUST use full international form (e.g., +1 908 582 2409) ; as specified in [E.123] CHAR = CRLF = CR LF CR = LF = CTL = Type special notes: This type MUST be single-valued. A language parameter MUST NOT be used with this type. The value of this type MAY be identical to the value of the 'contactPhone' type defined above. 3.15 authAddress To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type authAddress Type name: authAddress Type purpose: To represent the postal address of the listing Apple [Page 16] INTERNET-DRAFT Directory Schema Listing Meta Data 31 January 1998 authority contact for a listing. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): lac-addr = postal-string *5(*SPACE "$" *SPACE postal-string) postal-string = 1* SPACE = Type special notes: This type MUST be single-valued. A language parameter MUST NOT be used with this type. The value of this type MAY be identical to the value of the 'contactAddr' type defined above. 3.16 specURL To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type specURL Type name: specURL Type purpose: To represent a URL referring to a single schema unit content file. Type encoding: 8bit Type valuetype: uri, formatted as a URL [RFC1738]. Type special notes: This type MAY be multi-valued. A language parameter MUST NOT be used with this type. 3.17 security To: ietf-mime-direct@imc.org Apple [Page 17] INTERNET-DRAFT Directory Schema Listing Meta Data 31 January 1998 Subject: Registration of text/directory MIME type security Type name: security Type purpose: To represent a description of security considerations for a single schema unit or schema pak. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): utf8-text = 1* Type special notes: This type MAY be multi-valued if it is used within a schema unit listing metadata file. This type MUST have at least two values if present in a schema pak listing file. One of these values MUST be a security considerations description for the shcema pak itself. The other value MUST consist of the following text: Users of this schema pak listing should read the security type values contained in the metadata file associated with each schema unit content file referenced by a pakMember type value. A language parameter MUST be used with this type. A value of this type is an in-line text description of security considerations and MAY include embedded CRLF characters. 3.18 created To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type created Type name: created Type purpose: To represent the date and time at which a listing was published. Type encoding: 8bit Type valuetype: date-time, with the following syntax (specified using the BNF in [RFC822]): Apple [Page 18] INTERNET-DRAFT Directory Schema Listing Meta Data 31 January 1998 created = date "T" time "Z" date = 4DIGIT "-" 2DIGIT "-" 2DIGIT ; year-month-day ; e.g., 1997-08-27 time = 2DIGIT ":" 2DIGIT ":" 2DIGIT ; hh:mm:ss ; e.g., 00:00:00 thru 23:59:59 ; MUST be based on GMT DIGIT = Type special notes: This type MUST be single-valued. A language parameter MUST NOT be used with this type. 3.19 moreInfo To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type moreInfo Type name: moreInfo Type purpose: To represent a labeled reference to external content (not stored in the schema listing repository) related to a listing. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): more = uri *SPACE "(" label ")" ; MAY be multi-valued or single-valued uri = ; in this case the URI is constrained to ; be a URL as specified in [RFC1738] label = option [*SPACE "$" *SPACE checksum] ; only one option is allowed per instance ; of this multi-valued metadata element option = "opaque-schema" / "copyright" / "licensing" / "general" Apple [Page 19] INTERNET-DRAFT Directory Schema Listing Meta Data 31 January 1998 / "image" ; this set of options is intended for use in the initial release ; of the schema listing service additional options may be ; defined in other documents ; "opaque-schema" signifies that a file containing ; a [MIMEDIR]-based schema unit content not currently ; supported by the listing service or other syntax ; specification for a schema unit is being referenced checksum = > Type special notes: This type MAY be multi-valued. A language parameter MUST be used with this type. The use of this type is REQUIRED if a schema writer wishes to include references to external content related to a listing. Otherwise, this type MUST NOT be used in forming listing requests or published listings. The rationale for including these external references MAY be related to extensive copyright or right-to-use statements, a requirement external to the schema listing service for vendor branding of a listed schema, or a schema specification of a form not expressable using a [MIMEDIR] profile currently supported by the schema listing service. 3.20 caveat To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type caveat Type name: caveat Type purpose: To represent a caveat explaining that content obtained by following external references to information not stored in the schema listing repository is outside of the control of the repository. Type encoding: 8bit Type valuetype: text, consisting of the following in-line text value: Information obtained by following external content references expressed using the moreInfo type are outside of the control of the schema listing service Apple [Page 20] INTERNET-DRAFT Directory Schema Listing Meta Data 31 January 1998 operators. Users of this information should be aware that it is possible for this information to change after the referencing listing has been published. Type special notes: This type MAY be multi-valued. A language parameter MUST be used with this type. The use of this type is REQUIRED if a schema writer wishes to include references to external content related to a listing. Otherwise, this type MUST NOT be used in forming listing requests or published listings. 3.21 listingComments To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type listingComments Type name: listingComments Type purpose: To represent comments which will be attached to a listing. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): utf8-text = 1* Type special notes: This type MAY be multi-valued. A language parameter MUST be used with this type. The use of this type is REQUIRED if during review of a listing request, the primary listing repository operator is asked by the reviewers to include particular comments or generic caveats with a listing prior to publication. Values of this type are in-line text comments or generic caveats associated with a schema listing and MAY include embedded CRLF characters. Apple [Page 21] INTERNET-DRAFT Directory Schema Listing Meta Data 31 January 1998 3.22 schemaPak To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type schemaPak Type name: schemaPak Type purpose: To represent a reference to a schema pak listing of which a schema unit content file is a member. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): pak-ref = uri *SPACE "(" label ")" ; MAY be multi-valued or ; single-valued uri = ; in this case the URI is ; constrained to be a URL as ; specified in [RFC1738] ; and corresponds to a ; pak listing file label = "ldap" / "whois++" / "rwhois" / "whois" / "xml" Type Special Notes: Only one ; in this case the URI is ; constrained to be a URL as ; specified in [RFC1738] ; and refers to a schema ; unit content file label = "ldap" / "whois++" / "rwhois" / "whois" / "xml" Type Special Notes: A schema pak MUST consist of more than one schema unit. Therefore, this element MUST be multi-valued A schema pak listing MUST only contain member references for a single protocol. Therefore, only one Apple [Page 8] INTERNET-DRAFT Directory Schema Listing Meta Data 21 April 1998 ; all [FILESYN] values except "meta-unit" and "0" ; MAY be used to construct values Type special notes: When used in schema unit listings and schema unit listing requests, this type MUST be single-valued. When used in schema pak listings and schema pak listing requests, this type MUST be multi-valued. A language parameter MUST NOT be used with this type. Currently, there are five [MIMEDIR] profiles defined for containing schema unit content: [MIMELDAP], [MIMEWHOISPP], [MIMEWHOIS], and [MIMERWHOIS]. Additional profiles may be defined in other documents. Each of these profiles is identified by a short text string representative of the profile name. 3.5 relatedTo To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type relatedTo Type name: relatedTo Type purpose: To represent an indication of a relationship of a published listing or listing request with another published listing or listing request. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): related = md-filename *SPACE "$" *SPACE related-option md-filename = related-option = "obsoletes" / "obsoleted-by" / "updates" / "inherits" / vendor-option vendor-option = ("x-" / "X-") vendor-name "-" vendor-specific-relationship vendor-name = 1*TOKEN Apple [Page 9] INTERNET-DRAFT Directory Schema Listing Meta Data 21 April 1998 vendor-specific-relationship = 1*TOKEN TOKEN = CHAR = specials = "(" / ")" / "<" / ">" / "@" ; MUST be in quoted- / "," / ";" / ":" / "\" / <"> ; string, to use / "." / "[" / "]" ; within a word <"> = SPACE = CRLF = CR LF CR = LF = CTL = Type special notes: This type MAY be multi-valued. If a listing is related to another listing, this type is REQUIRED, otherwise the use of this type is OPTIONAL. A language parameter MUST NOT be used with this type. This type is used to indicate relationships between published listings and listing requests as well as between one or more listing requests being submitted for review in parallel. Examples of such relationships include deprecation, revision, inheritance, and those specific to a particular vendor. 3.6 contactLanguage To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type contactLanguage Type name: contactLanguage Type purpose: To represent a language understood by the contact person, organization, or role for a listing. Apple [Page 10] INTERNET-DRAFT Directory Schema Listing Meta Data 21 April 1998 Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): c-lang = Type special notes: This type MAY be multi-valued. A language parameter MUST NOT be used with this type. 3.7 contactName To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type contactName Type name: contactName Type purpose: To represent the name of the contact person, organization, or role for a listing. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): utf8-text = 1* Type special notes: This type MUST be single-valued. A language parameter MUST NOT be used with this type. 3.8 contactEmail To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type contactEmail Type name: contactEmail Type purpose: To represent the electronic mail address of the contact person, organization, or role for a listing. Apple [Page 11] INTERNET-DRAFT Directory Schema Listing Meta Data 21 April 1998 Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): c-email = local-part "@" domain-part domain-part = sub-domain *("." sub-domain) sub-domain = 1* CHAR = specials = "(" / ")" / "<" / ">" / "@" ; MUST be in quoted- / "," / ";" / ":" / "\" / <"> ; string, to use / "." / "[" / "]" ; within a word <"> = SPACE = CRLF = CR LF CR = LF = CTL = Type special notes: This type MUST be single-valued. A language parameter MUST NOT be used with this type. 3.9 contactPhone To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type contactPhone Type name: contactPhone Type purpose: To represent the voice telephone number of the contact person, organization, or role for a listing. Type encoding: 8bit Apple [Page 12] INTERNET-DRAFT Directory Schema Listing Meta Data 21 April 1998 Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): c-phone = 1* ; MUST use full international form (e.g., +1 908 582 2409) ; as specified in [E.123] CHAR = CRLF = CR LF CR = LF = CTL = Type special notes: This type MUST be single-valued. A language parameter MUST NOT be used with this type. 3.10 contactAddress To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type contactAddress Type name: contactAddress Type purpose: To represent the postal address of the contact person, organization, or role for a listing. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): c-addr = postal-string *5(*SPACE "$" *SPACE postal-string) postal-string = 1* SPACE = Type special notes: Apple [Page 13] INTERNET-DRAFT Directory Schema Listing Meta Data 21 April 1998 This type MUST be single-valued. A language parameter MUST NOT be used with this type. 3.11 authLanguage To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type authLanguage Type name: authLanguage Type purpose: To represent the language understood by the listing authority contact for a listing. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): lac-lang = Type special notes: This type MAY be multi-valued A language paramter MUST NOT be used with this type. 3.12 authName To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type authName Type name: authName Type purpose: To represent the name of the listing authority contact for a listing. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): utf8-text = 1* Type special notes: Apple [Page 14] INTERNET-DRAFT Directory Schema Listing Meta Data 21 April 1998 This type MUST be single-valued. A language parameter MUST NOT be used with this type. The value of this type MAY be identical to the value of the 'contactName' type defined above. 3.13 authEmail To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type authEmail Type name: authEmail Type purpose: To represent the electronic mail address of the listing authority contact for a listing. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): c-email = local-part "@" domain-part domain-part = sub-domain *("." sub-domain) sub-domain = 1* CHAR = specials = "(" / ")" / "<" / ">" / "@" ; MUST be in quoted- / "," / ";" / ":" / "\" / <"> ; string, to use / "." / "[" / "]" ; within a word <"> = SPACE = CRLF = CR LF CR = LF = CTL = Type special notes: Apple [Page 15] INTERNET-DRAFT Directory Schema Listing Meta Data 21 April 1998 This type MUST be single-valued. A language parameter MUST NOT be used with this type. The value of this type MAY be identical to the value of the 'contactEmail' type defined above. 3.14 authPhone To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type authPhone Type name: authPhone Type purpose: To represent the voice telephone number of the listing authority contact for a listing. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): lac-phone = 1* ; MUST use full international form (e.g., +1 908 582 2409) ; as specified in [E.123] CHAR = CRLF = CR LF CR = LF = CTL = Type special notes: This type MUST be single-valued. A language parameter MUST NOT be used with this type. The value of this type MAY be identical to the value of the 'contactPhone' type defined above. 3.15 authAddress Apple [Page 16] INTERNET-DRAFT Directory Schema Listing Meta Data 21 April 1998 To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type authAddress Type name: authAddress Type purpose: To represent the postal address of the listing authority contact for a listing. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): lac-addr = postal-string *5(*SPACE "$" *SPACE postal-string) postal-string = 1* SPACE = Type special notes: This type MUST be single-valued. A language parameter MUST NOT be used with this type. The value of this type MAY be identical to the value of the 'contactAddr' type defined above. 3.16 specURL To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type specURL Type name: specURL Type purpose: To represent a URL referring to a single schema unit content file. Type encoding: 8bit Type valuetype: uri, formatted as a URL [RFC1738]. Type special notes: This type MAY be multi-valued. Apple [Page 17] INTERNET-DRAFT Directory Schema Listing Meta Data 21 April 1998 A language parameter MUST NOT be used with this type. 3.17 security To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type security Type name: security Type purpose: To represent a description of security considerations for a single schema unit or schema pak. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): utf8-text = 1* Type special notes: This type MAY be multi-valued if it is used within a schema unit listing metadata file. This type MUST have at least two values if present in a schema pak listing file. One of these values MUST be a security considerations description for the shcema pak itself. The other value MUST consist of the following text: Users of this schema pak listing should read the security type values contained in the metadata file associated with each schema unit content file referenced by a pakMember type value. A language parameter MUST be used with this type. A value of this type is an in-line text description of security considerations and MAY include embedded CRLF characters. 3.18 created To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type created Type name: created Type purpose: To represent the date and time at which a listing Apple [Page 18] INTERNET-DRAFT Directory Schema Listing Meta Data 21 April 1998 was published. Type encoding: 8bit Type valuetype: date-time, with the following syntax (specified using the BNF in [RFC822]): created = date "T" time "Z" date = 4DIGIT "-" 2DIGIT "-" 2DIGIT ; year-month-day ; e.g., 1997-08-27 time = 2DIGIT ":" 2DIGIT ":" 2DIGIT ; hh:mm:ss ; e.g., 00:00:00 thru 23:59:59 ; MUST be based on GMT DIGIT = Type special notes: This type MUST be single-valued. A language parameter MUST NOT be used with this type. 3.19 moreInfo To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type moreInfo Type name: moreInfo Type purpose: To represent a labeled reference to external content (not stored in the schema listing repository) related to a listing. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): more = uri *SPACE "(" label ")" ; MAY be multi-valued or single-valued uri = ; in this case the URI is constrained to Apple [Page 19] INTERNET-DRAFT Directory Schema Listing Meta Data 21 April 1998 ; be a URL as specified in [RFC1738] label = option [*SPACE "$" *SPACE checksum] ; only one option is allowed per instance ; of this multi-valued metadata element option = "opaque-schema" / "copyright" / "licensing" / "general" / "image" ; this set of options is intended for use in the initial release ; of the schema listing service additional options may be ; defined in other documents ; "opaque-schema" signifies that a file containing ; a [MIMEDIR]-based schema unit content not currently ; supported by the listing service or other syntax ; specification for a schema unit is being referenced checksum = > Type special notes: This type MAY be multi-valued. A language parameter MUST be used with this type. The use of this type is REQUIRED if a schema writer wishes to include references to external content related to a listing. Otherwise, this type MUST NOT be used in forming listing requests or published listings. The rationale for including these external references MAY be related to extensive copyright or right-to-use statements, a requirement external to the schema listing service for vendor branding of a listed schema, or a schema specification of a form not expressable using a [MIMEDIR] profile currently supported by the schema listing service. 3.20 caveat To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type caveat Type name: caveat Type purpose: To represent a caveat explaining that content obtained by following external references to information not stored in the schema listing repository is outside of the control of the repository. Apple [Page 20] INTERNET-DRAFT Directory Schema Listing Meta Data 21 April 1998 Type encoding: 8bit Type valuetype: text, consisting of the following in-line text value: Information obtained by following external content references expressed using the moreInfo type are outside of the control of the schema listing service operators. Users of this information should be aware that it is possible for this information to change after the referencing listing has been published. Type special notes: This type MAY be multi-valued. A language parameter MUST be used with this type. The use of this type is REQUIRED if a schema writer wishes to include references to external content related to a listing. Otherwise, this type MUST NOT be used in forming listing requests or published listings. 3.21 listingComments To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type listingComments Type name: listingComments Type purpose: To represent comments which will be attached to a listing. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): utf8-text = 1* Type special notes: This type MAY be multi-valued. A language parameter MUST be used with this type. The use of this type is REQUIRED if during review of a listing Apple [Page 21] INTERNET-DRAFT Directory Schema Listing Meta Data 21 April 1998 request, the primary listing repository operator is asked by the reviewers to include particular comments or generic caveats with a listing prior to publication. Values of this type are in-line text comments or generic caveats associated with a schema listing and MAY include embedded CRLF characters. 3.22 schemaPak To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type schemaPak Type name: schemaPak Type purpose: To represent a reference to a schema pak listing of which a schema unit content file is a member. Type encoding: 8bit Type valuetype: text, with the following syntax (specified using the BNF in [RFC822]): pak-ref = uri *SPACE "(" label ")" ; MAY be multi-valued or ; single-valued uri = ; the URI is constrained ; to be a URL as ; specified in [RFC1738] ; and corresponds to a ; pak listing file label = "ldap" / "whoispp" / "rwhois" / "whois" Type Special Notes: Only one ; the URI is constrained ; to be a URL as ; specified in [RFC1738] ; and refers to a schema ; unit content file label = "ldap" / "whoispp" / "rwhois" / "whois" Type Special Notes: A schema pak MUST consist of more than one schema unit. Therefore, this element MUST be multi-valued A schema pak listing MUST only contain member references for a single protocol. Therefore, only one