draft-ietf-schema-file-list-00.txt   draft-ietf-schema-file-list-01.txt 
INTERNET-DRAFT C. Apple INTERNET-DRAFT C. Apple
<draft-ietf-schema-file-list-00.txt> AT&T Labs <draft-ietf-schema-file-list-01.txt> AT&T Labs
Expires: July 31, 1998 31 January 1998
Directory Schema Listing File Names Directory Schema Listing File Names
<draft-ietf-schema-file-list-00.txt> <draft-ietf-schema-file-list-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.'' material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or munnari.oz.au (Pacific Rim), or ftp.isi.edu (US West Coast).
ftp.isi.edu (US West Coast).
Abstract Abstract
This memo specifies a file name syntax for use by the primary listing This memo specifies a file name syntax for use by the primary listing
repository operator of the directory schema listing service. repository operator of the directory schema listing service.
1.0 Introduction 1.0 Introduction
The fastest route to interoperable directory services is through The fastest route to interoperable directory services is through
standard object classes and attribute types. There is a growing standard object classes and attribute types. There is a growing
skipping to change at page 2, line 28 skipping to change at page 2, line 27
syntactic definitions syntactic definitions
Schema - a collection of definitions for related information objects Schema - a collection of definitions for related information objects
Schema Unit - a related or grouped set of object attributes that form a Schema Unit - a related or grouped set of object attributes that form a
discrete unit within the context of a schema for a particular protocol; discrete unit within the context of a schema for a particular protocol;
examples include an LDAP object class or a WHOIS++ template examples include an LDAP object class or a WHOIS++ template
Schema Pak - a related or grouped set of schema units that collectively Schema Pak - a related or grouped set of schema units that collectively
specify a schema associated with a particular protocol; an example of a specify a schema associated with a particular protocol; an example of a
schema pak is the set of LDAP object classes specified in [RFC225X] schema pak is the set of LDAP object classes specified in [RFC2256]
Metadata - characteristics that differentiate one schema unit or schema Metadata - characteristics that differentiate one schema unit or schema
pak from another; used to catalog listing service content; structured pak from another; used to catalog listing service content; structured
using a profile of [MIMEDIR]; also contains references to files stored using a profile of [MIMEDIR]; also contains references to files stored
within and outside of a listing repository within and outside of a listing repository
Schema Unit Content - a formal specification of a schema unit using a Schema Unit Content - a formal specification of a schema unit using a
profile of [MIMEDIR] profile of [MIMEDIR]
Schema Unit Listing - the combination of a single schema unit content Schema Unit Listing - the combination of a single schema unit content
skipping to change at page 3, line 30 skipping to change at page 3, line 28
schema) schema)
The terms for specifying requirement level defined in [RFC2119] are used The terms for specifying requirement level defined in [RFC2119] are used
in this document. in this document.
2.0 File Name Syntax 2.0 File Name Syntax
All file names for listing meta data and listing content MUST comply All file names for listing meta data and listing content MUST comply
with the following BNF [RFC822] grammar: with the following BNF [RFC822] grammar:
file-name = base "." sequence "." listversion "." type file-name = sequence "." listversion "." type
base = "base" / oid
oid = 1*<DIGIT>["." oid]
sequence = ("0" / "current") / NZDIGIT 0*<DIGIT> sequence = ("0" / "current") / NZDIGIT 0*<DIGIT>
; initialized to one (1) for first schema listing ; initialized to one (1) for first schema listing
; increments by one (1) for each successive schema ; increments by one (1) for each successive schema
; listing name ; listing name
type = ("0" / "meta-unit") / ; these <type> values are defined
("1" / "ldap") / ; for the initial release of the
("2" / "pak-ldap") / ; schema listing service
("3" / "whois++") /
("4" / "pak-whois++") / ; other <type> values may be defined
("5" / "rwhois") / ; according to community needs in
("6" / "pak-rwhois") / ; the future
("7" / "whois") /
("8" / "pak-whois") / ; this document will be updated or
("9" / "xml") / ; obsoleted when additional <type>
("10" / "pak-xml") ; values are defined
listversion = 1*<DIGIT> type = "meta-unit" / ; these <type> values are defined
"ldap" / ; for the initial release of the
"pak-ldap" / ; schema listing service
"whois++" /
"pak-whois++" / ; other <type> values may be defined
"rwhois" / ; according to community needs in
"pak-rwhois" / ; the future
"whois" /
"pak-whois" ; this document will be updated or
; obsoleted when additional <type>
; values are defined
listversion = 1*<DIGIT>
NZDIGIT = <any DIGIT except "0" (0x30)> NZDIGIT = <any DIGIT except "0" (0x30)>
DIGIT = <any ASCII decimal digit (0x30 - 0x39)> DIGIT = <any ASCII decimal digit (0x30 - 0x39)>
Other possible values of the type component of a file name MAY be Other possible values of the type component of a file name MAY be
defined in the future to accomodate schema listings specified using defined in the future to accomodate schema listings specified using
[MIMEDIR] profiles other than those defined for containing LDAP [MIMEDIR] profiles other than those defined for containing LDAP
[RFC2251], WHOIS++ [RFC1835], and RWHOIS [RFC1714] schema listing [RFC2251], WHOIS++ [RFC1835], and RWHOIS [RFC1714] schema listing
content. content.
3.0 Intended Use of File Names 3.0 Intended Use of File Names
Schema writers, implementors, and users of the schema listing service Schema writers, implementors, and users of the schema listing service
SHOULD make use of the form of file names which includes descriptive SHOULD make use of the form of file names which includes descriptive
alphabetic tokens as the value for the <type> part of a file name. alphabetic tokens as the value for the <type> part of a file name.
This recommendation is made because it MAY be necessary in future
versions of the schema listing service to change the mapping Filenames MAY be specified as an OID by prepending the OID value used
(specified above in the <type> rule) between these more human as a root for the service filename and swapping alphabetic tokens for
friendly file names and the underlying OID-like representation of the their numeric equivalent according to the following table:
file names.
Token Number
----------- ------
current 0
meta-unit 0
ldap 1
pak-ldap 2
whoispp 3
pak-whoispp 4
rwhois 5
pak-rwhois 6
whois 7
pak-whois 8
For the initial release of the service the behaviors documented in For the initial release of the service the behaviors documented in
Section 4.0 for file retrieval based on file name will be supported. Section 4.0 for file retrieval based on file name will be supported.
Schema writers, implementors, and users of the schema listing service Schema writers, implementors, and users of the schema listing service
SHOULD NOT rely on future support of such file retrieval behavior for SHOULD NOT rely on future support of such file retrieval behavior for
the file name examples that are missing alphabetic tokens. the file name examples that are missing alphabetic tokens.
The behavior of file retrieval based on file names containing The behavior of file retrieval based on file names containing
alphabetic tokens MUST be preserved permanently by the schema listing alphabetic tokens MUST be preserved permanently by the schema listing
repository operators. repository operators.
skipping to change at page 5, line 7 skipping to change at page 5, line 4
Section 4.0 for file retrieval based on file name will be supported. Section 4.0 for file retrieval based on file name will be supported.
Schema writers, implementors, and users of the schema listing service Schema writers, implementors, and users of the schema listing service
SHOULD NOT rely on future support of such file retrieval behavior for SHOULD NOT rely on future support of such file retrieval behavior for
the file name examples that are missing alphabetic tokens. the file name examples that are missing alphabetic tokens.
The behavior of file retrieval based on file names containing The behavior of file retrieval based on file names containing
alphabetic tokens MUST be preserved permanently by the schema listing alphabetic tokens MUST be preserved permanently by the schema listing
repository operators. repository operators.
4.0 Example File Names 4.0 Example File Names
Generally, file names will be of the following form: Generally, file names will be of the following form:
"base.sequence.listversion.type" "sequence.listversion.type"
The 'base' part of a file name consists of the base OID used by the
primary listing repository operator to assign a globally unique name
to each listing. The token "base" can be used in place of the actual
OID value.
The 'sequence' part of a file name consists of a serial number The 'sequence' part of a file name consists of a serial number
generated by the primary listing repository operator and is unique generated by the primary listing repository operator and is unique
within the context of the schema listing service. within the context of the schema listing service.
When referring to a listing, a 'listversion' of "0" always represents When referring to a listing, a 'listversion' of "0" always represents
the most current version (the highest current listversion number) the most current version (the highest current listversion number)
published in the repository. Alternately, the token "current" may be published in the repository. Alternately, the token "current" may be
used to request the most current version of a listing file. used to request the most current version of a listing file.
Otherwise, the listversion part of a file name represents the version Otherwise, the listversion part of a file name represents the version
number of a listing within the context of the schema listing service. number of a listing within the context of the schema listing service.
The 'type' part of a file name consists of a token or number The 'type' part of a file name consists of a token or number
representing a file type. This token is unique within the context of representing a file type. This token is unique within the context of
the schema listing service and reflects the nature of file content. the schema listing service and reflects the nature of file content.
If an OID is used to retrieve a file, the base OID used by the
primary listing repository operator MUST be prepended to the numeric
representation of the filename.
Retrieval of files will exhibit the following behavior for the Retrieval of files will exhibit the following behavior for the
initial release of the service (NOTE: a value of 1 is used as the initial release of the service (NOTE: a value of 1 is used as the
base OID in these examples, the real base OID will be different): base OID in these examples, the real base OID will be different):
1.12.4.0: returns schema unit metadata for version 4 of listing 12. 1.12.4.0: returns schema unit metadata for version 4 of listing 12.
base.12.4.meta-unit: returns schema unit metadata for version 4 of 12.4.meta-unit: returns schema unit metadata for version 4 of listing
listing 12 12
1.12.0.0: returns schema unit metadata for latest version of listing 1.12.0.0: returns schema unit metadata for latest version of listing
12 12
base.12.current.meta-unit: returns schema unit metadata for latest 12.current.meta-unit: returns schema unit metadata for latest version
version of listing 12 of listing 12
1.12.4.1: returns ldap schema unit content for version 4 of listing 1.12.4.1: returns ldap schema unit content for version 4 of listing
12 12
base.12.4.ldap: returns ldap schema unit content for version 4 of 12.4.ldap: returns ldap schema unit content for version 4 of listing
listing 12 12
1.12.0.1: returns ldap schema unit content for latest version of 1.12.0.1: returns ldap schema unit content for latest version of
listing 12 listing 12
12.current.ldap: returns ldap schema unit content for latest version
base.12.current.ldap: returns ldap schema unit content for latest of listing 12
version of listing 12
1.13.2.2: returns metadata for version 4 of listing 12 1.13.2.2: returns metadata for version 4 of listing 12
base.13.2.pak-ldap: returns ldap schema pak metadata for version 2 of 13.2.pak-ldap: returns ldap schema pak metadata for version 2 of
listing 13 listing 13
1.13.0.2: returns ldap schema pak metadata for latest version of 1.13.0.2: returns ldap schema pak metadata for latest version of
listing 13 listing 13
base.13.current.pak-ldap: returns ldap schema pak metadata for latest 13.current.pak-ldap: returns ldap schema pak metadata for latest
version of listing 13 version of listing 13
5.0 Security Considerations 5.0 Security Considerations
There are no known security concerns associated with the file name There are no known security concerns associated with the file name
syntax specified in this document. syntax specified in this document.
6.0 Acknowledgements 6.0 Acknowledgements
Leslie Daigle of Bunyip Information Systems reviewed and provided Leslie Daigle of Bunyip Information Systems reviewed and provided
skipping to change at page 7, line 8 skipping to change at page 7, line 5
7.0 References 7.0 References
[MIMEDIR] T. Howes, M. Smith, "A MIME Content-Type for Directory [MIMEDIR] T. Howes, M. Smith, "A MIME Content-Type for Directory
Information", INTERNET-DRAFT <draft-ietf-asid-mime-direct-05.txt>, Information", INTERNET-DRAFT <draft-ietf-asid-mime-direct-05.txt>,
November 1997. November 1997.
[RFC822] D. Crocker, "Standard of the Format of ARPA-Internet Text [RFC822] D. Crocker, "Standard of the Format of ARPA-Internet Text
Messages", STD 11, RFC 822, August 1982. Messages", STD 11, RFC 822, August 1982.
[RFC1630] T. Berners-Lee, "Universal Resource Identifiers in WWW",
RFC 1630, June 1994.
[RFC1835] P. Deutsch, R. Schoultz, P. Faltstrom, C. Weider, [RFC1835] P. Deutsch, R. Schoultz, P. Faltstrom, C. Weider,
"Architecture of the WHOIS++ Service", RFC 1835, August, 1995. "Architecture of the WHOIS++ Service", RFC 1835, August, 1995.
[RFC1714] S. Williamson, M. Kosters,"Referral Whois Protocol [RFC1714] S. Williamson, M. Kosters,"Referral Whois Protocol
(RWhois)", RFC 1714, November 1994 (RWhois)", RFC 1714, November 1994
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Level", RFC 2119, March 1997. Requirement Level", RFC 2119, March 1997.
[RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
skipping to change at page 7, line 32 skipping to change at page 7, line 32
Chris Apple Chris Apple
AT&T Labs AT&T Labs
600 - 700 Mountain Ave., Room 2F-165 600 - 700 Mountain Ave., Room 2F-165
Murray Hill, NJ 07974-0636 Murray Hill, NJ 07974-0636
USA USA
E-Mail: capple@att.com E-Mail: capple@att.com
Phone: +1 908 582 2409 Phone: +1 908 582 2409
FAX: +1 908 582 3296 FAX: +1 908 582 3296
This INTERNET-DRAFT expires on July 31, 1998. This INTERNET-DRAFT expires on October 21, 1998.
 End of changes. 20 change blocks. 
47 lines changed or deleted 53 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/