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