draft-ietf-schema-proc-list-00.txt   draft-ietf-schema-proc-list-01.txt 
INTERNET-DRAFT C. Apple INTERNET-DRAFT C. Apple
<draft-ietf-schema-proc-list-00.txt> AT&T Labs <draft-ietf-schema-proc-list-01.txt> AT&T Labs
Expires: July 31, 1998 M. Mealling Expires: October 21, 1998 M. Mealling
Network Solutions, Inc. Network Solutions, Inc.
31 January 1998
Directory Schema Listing Procedures Directory Schema Listing Procedures
<draft-ietf-schema-proc-list-00.txt> <draft-ietf-schema-proc-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 ``1id-abstracts.txt'' listing contained in the Internet- Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), Shadow 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 documents procedures for listing directory service schemas This memo documents procedures for listing directory service schemas
in a centrally operated, administered, and maintained repository. in a centrally operated, administered, and maintained repository.
This repository will be available as a resource to directory protocol This repository will be available as a resource to directory protocol
and service implementors to facilitate schema discovery. and service implementors to facilitate schema discovery.
Table of Contents Table of Contents
skipping to change at page 3, line 25 skipping to change at page 3, line 25
schema reuse, reduce duplication of effort, and thus promote schema reuse, reduce duplication of effort, and thus promote
directory service interoperability. Listed schema will be assiged a directory service interoperability. Listed schema will be assiged a
permanent, unique listing listing name as a part of the creating permanent, unique listing listing name as a part of the creating
schema listing requests; which starts the schema listing process. schema listing requests; which starts the schema listing process.
This listing process was defined to ensure that directory service This listing process was defined to ensure that directory service
schema writers can publish their schema in a public forum so that schema writers can publish their schema in a public forum so that
they will be re-used. they will be re-used.
The IETF schema listing service has public read access and The IETF schema listing service has public read access and
restricted, moderated write access. Currently, this listing service restricted, moderated write access. Currently, this listing service
is centrally operated, administered, and maintained by TBD. The is centrally operated, administered, and maintained by the Internet
schema listing repository is mirrored to ensure some level of Directory Consortium. The schema listing repository is mirrored to
redundancy for read access. ensure some level of redundancy for read access.
This document defines schema listing procedures which use TBD as the This document defines schema listing procedures which use the
primary listing repository operator. Internet Directory Consortium as the primary listing repository
operator.
1.1 Terms and Definitions 1.1 Terms and Definitions
Information Object - a descriptive abstraction of some real-world Information Object - a descriptive abstraction of some real-world
object object
Object Attribute - a descriptive property of an information object; Object Attribute - a descriptive property of an information object;
typically, object attributes are defined in terms of semantic and typically, object attributes are defined in terms of semantic and
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 Schema Unit - a related or grouped set of object attributes that form
a discrete unit within the context of a schema for a particular a discrete unit within the context of a schema for a particular
protocol; examples include an LDAP object class or a WHOIS++ template protocol; examples include an LDAP object class or a WHOIS++ template
Schema Pak - a related or grouped set of schema units that Schema Pak - a related or grouped set of schema units that
collectively specify a schema associated with a particular protocol; collectively specify a schema associated with a particular protocol;
an example of a schema pak is the set of LDAP object classes an example of a schema pak is the set of LDAP object classes
specified in [RFC225X] specified in [RFC2256]
Metadata - characteristics that differentiate one schema unit or Metadata - characteristics that differentiate one schema unit or
schema pak from another; used to catalog listing service content; schema pak from another; used to catalog listing service content;
structured using a profile of [MIMEDIR]; also contains references to structured using a profile of [MIMEDIR]; also contains references to
files stored within and outside of a listing repository files stored 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
file intended for use within the context of a particular protocol and file intended for use within the context of a particular protocol and
skipping to change at page 6, line 31 skipping to change at page 6, line 31
that differentiate listings. that differentiate listings.
Schema unit content MUST be limited to the specification of a single Schema unit content MUST be limited to the specification of a single
schema unit. schema unit.
2.2.2 Naming Requirements 2.2.2 Naming Requirements
All listings MUST have a valid OID as their name. All listings MUST have a valid OID as their name.
The primary listing repository operator MUST provide schema writers The primary listing repository operator MUST provide schema writers
with a name for each listing request based on the combination of with the following components of a listing request name:
+ a root OID obtained from IANA specifically
for use in the schema listing service
+ a sequence number assigned to each + a sequence number assigned to each listing
listing by the primary repository operator by the primary repository operator
+ a version number assigned to each + a version number assigned to each listing
listing by the primary repository operator version by the primary repository operator
2.2.3 Content Formatting and Transfer Encoding Requirements 2.2.3 Content Formatting and Transfer Encoding Requirements
All listings MUST employ a common data format. All listings MUST employ a common data format.
Metadata and schema unit content format and transfer encoding MUST Metadata and schema unit content format and transfer encoding MUST
utilize appropriate [MIMEDIR] profiles. utilize appropriate [MIMEDIR] profiles.
Currently, six [MIMEDIR] profiles have been defined for use in the Currently, five [MIMEDIR] profiles have been defined for use in the
schema listing service: schema listing service:
[MIMELDAP] MUST be used to format and encode LDAPv3 schema unit [MIMELDAP] MUST be used to format and encode LDAPv3 schema unit
content. content.
[MIMEWHOISPP] MUST be used to format and encode WHOIS++ schema [MIMEWHOISPP] MUST be used to format and encode WHOIS++ schema
unit content. unit content.
[MIMEWHOIS] MUST be used to format and encode WHOIS schema unit [MIMEWHOIS] MUST be used to format and encode WHOIS schema unit
content. content.
[MIMERWHOIS] MUST be used to format and encode RWHOIS schema unit [MIMERWHOIS] MUST be used to format and encode RWHOIS schema unit
content. content.
[MIMEXML] MUST be used to format and encode XML schema unit
content.
[METASYN] MUST be used to format and encode metadata for all [METASYN] MUST be used to format and encode metadata for all
schema unit listings, schema pak listings, and listing requests. schema unit listings, schema pak listings, and listing requests.
Other [MIMEDIR] profiles MAY be defined for use in the schema listing Other [MIMEDIR] profiles MAY be defined for use in the schema listing
service; this procedures document will be updated reflect such service; this procedures document will be updated reflect such
changes. changes.
2.2.4 Security Requirements 2.2.4 Security Requirements
An analysis of security issues for listed schema SHOULD be performed An analysis of security issues for listed schema SHOULD be performed
skipping to change at page 9, line 23 skipping to change at page 9, line 17
The following procedure has been implemented by the primary listing The following procedure has been implemented by the primary listing
repository operator for review and approval of new listings. This is repository operator for review and approval of new listings. This is
not a formal standards process, but rather an administrative not a formal standards process, but rather an administrative
procedure intended to foster re-use of directory services schema and procedure intended to foster re-use of directory services schema and
to provide a method for collecting schema in a publicly accessible to provide a method for collecting schema in a publicly accessible
repository. repository.
Submitting listing requests can be done via mail, treating posting of Submitting listing requests can be done via mail, treating posting of
a formatted request containing the specification of schema unit a formatted request containing the specification of schema unit
content for a particular protocol and/or metadata to the ietf- content for a particular protocol and/or metadata to the mailing list
schema-review@TBD list, as a first step.
ietf-schema-review@pilot.schema.dir.reg.int
as a first step.
2.3.1 Announcement and Community Review 2.3.1 Announcement and Community Review
While listed schema are NOT REQUIRED to be published as RFCs, listing While listed schema are NOT REQUIRED to be published as RFCs, listing
requests documenting them MUST be posted to the ietf-schema- requests documenting them MUST be posted to the mailing list
review@TBD list, allowing a review and comment period of at least 2
weeks. This is necessary to prevent the malicious as well as ietf-schema-review@pilot.schema.dir.reg.int,
unintended introduction of obviously bogus or frivolous schema into
the listing repository. allowing a review and comment period of at least 2 weeks. This is
necessary to prevent the malicious as well as unintended introduction
of obviously bogus or frivolous schema into the listing repository.
Schema writers wishing to have their schema listed by the primary Schema writers wishing to have their schema listed by the primary
listing repository operator, MUST specify any such schema (may listing repository operator, MUST specify any such schema (may
require the creation/submission of more than one request) according require the creation/submission of more than one request) according
to one of the following [MIMEDIR] profiles: [MIMELDAP], to one of the following [MIMEDIR] profiles: [MIMELDAP],
[MIMEWHOISPP], [MIMEWHOIS], [MIMERWHOIS], or [MIMEXML]. Other such [MIMEWHOISPP], [MIMEWHOIS], or [MIMERWHOIS]. Other such profiles may
profiles may be defined elsewhere and this procedures document will be defined elsewhere and this procedures document will be update to
be update to reflect such process changes. reflect such process changes.
Metadata, as specified in [METASYN], MUST also be included in this Metadata, as specified in [METASYN], MUST also be included in this
request. A template for listing requests is specified in paragraph request. A template for listing requests is specified in paragraph
2.8. Schema writers MUST use this template. 2.8. Schema writers MUST use this template.
Schema writers MUST also obtain a unique listing name for each Schema writers MUST also construct a unique listing request name for
request being constructed. The method of obtaining such listing names each request being created. Listing names are constructed according
is TBD. to the type valuetype syntax and type special notes for the
'listingName' MIME Directory Type [METASYN].
Once constructed, the request should be sent to ietf-schema- Once created, the listing request should be sent to ietf-schema-
review@TBD. review@pilot.schema.dir.reg.int.
2.3.2 Community Review and Assessment 2.3.2 Community Review and Assessment
Moderated discussions on the ietf-schema-review@TBD mailing list will Moderated discussions on the ietf-schema-
enable a means of gauging concensus as to whether or not the schema review@pilot.schema.dir.reg.int mailing list will enable a means of
being proposed is bogus. If there is no significant reason to believe gauging concensus as to whether or not the schema being proposed is
that a schema is useful or if it appears to be a bogus or malicious bogus. If there is no significant reason to believe that a schema is
request, the moderator will not submit a listing request to the useful or if it appears to be a bogus or malicious request, the
primary listing repository operator; otherwise, they may do so. moderator will not submit a listing request to the primary listing
repository operator; otherwise, they may do so.
2.3.3 Primary Repository Operator Listing 2.3.3 Primary Repository Operator Listing
Provided that the schema listing request meets the requirements Provided that the schema listing request meets the requirements
defined in paragraph 2.1, the ietf-schema-review@TBD list moderator defined in paragraph 2.1, the ietf-schema-
will send that listing request to the primary repository operator, review@pilot.schema.dir.reg.int list moderator will send that listing
which will check this listing request for validity, and make the request to the primary repository operator, which will check this
listing available to the community. listing request for validity, and make the listing available to the
community.
2.4 Comments on Schema Listings 2.4 Comments on Schema Listings
Comments on listings may be submitted by members of the IETF Comments on listings may be submitted by members of the IETF
community to for consideration by the rest of the community and the community to for consideration by the rest of the community and the
primary listing repository operator. These comments will be passed on primary listing repository operator. These comments will be passed on
to the contact person for the listing if possible. Submitters of to the contact person for the listing if possible. Submitters of
comments may request that their comment be attached to the listing comments may request that their comment be attached to the listing
itself. If the ietf-schema-review@TBD list moderator is able to gauge itself. If the ietf-schema-review@pilot.schema.dir.reg.int list
concensus affirming the inclusion of such a comment, it will be made moderator is able to gauge concensus affirming the inclusion of such
accessible in conjunction with the listing itself. a comment, it will be made accessible in conjunction with the listing
itself.
2.5 Location of List of Available Schema 2.5 Location of List of Available Schema
Listings will be posted in the anonymous FTP directory Listings will be posted in the anonymous FTP directory
"ftp://TBD.host.name/schema/" and all listings will be summarized in "ftp://www.pilot.schema.dir.reg.int/schema/" and all listings will be
a periodically issued RFC. Schema unit content, schema pak listings, summarized in a periodically issued RFC. Schema unit content, schema
and/or other supporting material may also be published as an pak listings, and/or other supporting material may also be published
Informational RFC by sending it to "rfc-editor@isi.edu" (please as an Informational RFC by sending it to "rfc-editor@isi.edu" (please
follow the instructions to RFC authors [RFC2223]). follow the instructions to RFC authors [RFC2223]).
2.6 Primary Repository Operator Procedures for Listing Schemas 2.6 Primary Repository Operator Procedures for Listing Schemas
Listings will be published by the primary repository operator Listings will be published by the primary repository operator
automatically and without any formal review as long as the following automatically and without any formal review as long as the following
minimal conditions are met: minimal conditions are met:
(1) All listings MUST have a valid OID as their name. (1) All listings MUST have a valid OID as their name.
skipping to change at page 11, line 18 skipping to change at page 11, line 22
(4) Metadata MUST comply with [METASYN]. (4) Metadata MUST comply with [METASYN].
(5) Schema unit content MUST be compliant with at one (5) Schema unit content MUST be compliant with at one
of the following [MIMEDIR] profiles: of the following [MIMEDIR] profiles:
+ [MIMELDAP] (for LDAPv3 schema specifications) + [MIMELDAP] (for LDAPv3 schema specifications)
+ [MIMEWHOISPP] (for WHOIS++ schema specifications) + [MIMEWHOISPP] (for WHOIS++ schema specifications)
+ [MIMEWHOIS] (for WHOIS schema specifications) + [MIMEWHOIS] (for WHOIS schema specifications)
+ [MIMERWHOIS] (for RWHOIS schema specifications) + [MIMERWHOIS] (for RWHOIS schema specifications)
+ [MIMERXML] (for XML schema specifications)
Other [MIMEDIR] profiles may be defined in the future and this Other [MIMEDIR] profiles may be defined in the future and this
document will be updated to reflect such additional profiles. document will be updated to reflect such additional profiles.
(6) Any security considerations given must not be obviously (6) Any security considerations given must not be obviously
bogus. It is neither possible nor necessary for the bogus. It is neither possible nor necessary for the
primary listing repository operator to conduct a primary listing repository operator to conduct a
comprehensive security review of listings. comprehensive security review of listings.
However, the listing request review committee However, the listing request review committee
(the members of the listing request review (the members of the listing request review
skipping to change at page 12, line 16 skipping to change at page 12, line 17
Once a listing has been published by the primary repository operator, Once a listing has been published by the primary repository operator,
the contact person may request a change to its definition. The the contact person may request a change to its definition. The
contact person for a listed schema is defined to be the person or contact person for a listed schema is defined to be the person or
organizational role or entity who submitted the original listing organizational role or entity who submitted the original listing
request. request.
The change request follows the same procedure as the listing request The change request follows the same procedure as the listing request
(1) Publish the revised listing request on the (1) Publish the revised listing request on the
ietf-schema-review@TBD list. ietf-schema-review@pilot.schema.dir.reg.int list.
(2) Leave at least two weeks for comments. (2) Leave at least two weeks for comments.
(3) Publish using the primary listing repository (3) Publish using the primary listing repository
operator after formal review if required. operator after formal review if required.
Changes MAY be requested when there are serious omissions or errors Changes MAY be requested when there are serious omissions or errors
in the published listing or when other factors which would justify a in the published listing or when other factors which would justify a
change request, such as an emerging need of the user community for a change request, such as an emerging need of the user community for a
listed schema which cannot be addressed by that listed schema in its listed schema which cannot be addressed by that listed schema in its
present form. When review is required, a change request MAY be denied present form. When review is required, a change request MAY be denied
if it renders entities that were valid under the previous definition if it renders entities that were valid under the previous definition
invalid under the new definition. invalid under the new definition.
The primary listing repository provider SHOULD attempt to verify the The primary listing repository provider SHOULD attempt to verify the
authority of a person claiming to be the contact for a listing, prior authority of a person claiming to be the contact for a listing, prior
to implementing such changes. to implementing such changes.
The contact person for a listing MAY pass responsibility for that The contact person for a listing MAY pass responsibility for that
listing to another person or agency by informing the primary listing listing to another person or agency by informing the primary listing
repository operator and the ietf-schema-announce@TBD list; this can repository operator and the ietf-schema-
be done without discussion or review. announce@pilot.schema.dir.reg.int list; this can be done without
discussion or review.
The IESG may reassign responsibility for a listing. The most common The IESG may reassign responsibility for a listing. The most common
case of this will be to enable changes to be made to types where the case of this will be to enable changes to be made to types where the
contact person for the listing has died, moved out of contact, or is contact person for the listing has died, moved out of contact, or is
otherwise unable to make changes that are important to the community. otherwise unable to make changes that are important to the community.
Listings will not be deleted; listings which are no longer believed Listings will not be deleted; listings which are no longer believed
appropriate for use can be declared OBSOLETE by a change to their appropriate for use can be declared OBSOLETE by a change to their
"intended use" field; such listings will be clearly marked in "intended use" field; such listings will be clearly marked in
repository content summary RFCs published by the primary listing repository content summary RFCs published by the primary listing
repository operator. repository operator.
2.8 Listing Request Formats 2.8 Listing Request Formats
2.8.1 Schema Unit Listing Request Format 2.8.1 Schema Unit Listing Request Format
To: ietf-schema-review@TBD To: ietf-schema-review@pilot.schema.dir.reg.int
Subject: schema unit listing request Subject: schema unit listing request
MIME-Version: 1.0 MIME-Version: 1.0
Message-Id: <ids1@wherever.com> Message-Id: <ids1@wherever.com>
Content-Type: multipart/related; start=3@foo.com; boundary="boundary" Content-Type: multipart/related; start=3@foo.com; boundary="boundary"
Content-ID: top@foo.com Content-ID: top@foo.com
--boundary --boundary
Content-Type: text/directory; Content-Type: text/directory;
profile="schema-metadata-0"; profile="schema-metadata-0";
charset="utf-8" charset="utf-8"
skipping to change at page 13, line 40 skipping to change at page 13, line 40
Content-Transfer-Encoding: Quoted-Printable Content-Transfer-Encoding: Quoted-Printable
Content-ID: 3@foo.com Content-ID: 3@foo.com
(a schema specification compliant with a profile of [MIMEDIR] (a schema specification compliant with a profile of [MIMEDIR]
corresponding to the value of <mimedir-profile-type>) corresponding to the value of <mimedir-profile-type>)
--boundary --boundary
Where: Where:
<mimedir-profile-type> = "schema-ldap-0" / "schema-whois++-0" / <mimedir-profile-type> = "schema-ldap-0" / "schema-whoispp-0" /
"schema-whois-0" / "schema-rwhois-0" / "schema-whois-0" / "schema-rwhois-0"
"schema-xml-0"
2.8.2 Schema Pak Listing Request Format 2.8.2 Schema Pak Listing Request Format
To: ietf-schema-review@TBD To: ietf-schema-review@pilot.schema.dir.reg.int
Subject: schema pak listing request Subject: schema pak listing request
MIME-Version: 1.0 MIME-Version: 1.0
Message-Id: <ids1@wherever.com> Message-Id: <ids1@wherever.com>
Content-Type: text/directory; Content-Type: text/directory;
profile="schema-metadata-0"; profile="schema-metadata-0";
charset="utf-8" charset="utf-8"
Content-Transfer-Encoding: Quoted-Printable Content-Transfer-Encoding: Quoted-Printable
(metadata elements and values as specified in [METASYN] and embedded (metadata elements and values as specified in [METASYN] and embedded
in a text/directory MIME component of profile "schema-meta-0") in a text/directory MIME component of profile "schema-meta-0")
skipping to change at page 15, line 40 skipping to change at page 15, line 40
Mark Wahl - Critical Angle Mark Wahl - Critical Angle
Chris Weider - Microsoft Chris Weider - Microsoft
Paul Hoffman for review and comments resulting from his effort to Paul Hoffman for review and comments resulting from his effort to
develop a platform for the initial release of the schema listing develop a platform for the initial release of the schema listing
service. service.
5.0 References 5.0 References
[FILESYN] C. Apple, "Directory Schema Listing File Name Syntax", [FILESYN] C. Apple, "Directory Schema Listing File Name Syntax",
INTERNET-DRAFT <draft-ietf-schema-file-list-00.txt>, January 1998. INTERNET-DRAFT <draft-ietf-schema-file-list-01.txt>, April 1998.
[LISTRQMT] C. Apple, "Requirements for the Initial Release of a [LISTRQMT] C. Apple, "Requirements for the Initial Release of a
Directory Schema Listing Service", INTERNET-DRAFT <draft-ietf- Directory Schema Listing Service", INTERNET-DRAFT <draft-ietf-
schema-rqmts-list-00.txt>, January 1998. schema-rqmts-list-01.txt>, April 1998.
[METASYN] C. Apple, "A MIME Directory Profile for Schema Listing Meta [METASYN] C. Apple, "A MIME Directory Profile for Schema Listing Meta
Data", INTERNET-DRAFT <draft-ietf-schema-mime-metadata-00.txt>, Data", INTERNET-DRAFT <draft-ietf-schema-mime-metadata-01.txt>, April
January 1998. 1998.
[MIMELDAP] M. Wahl, "A MIME Directory Profile for LDAP Schema", [MIMELDAP] M. Wahl, "A MIME Directory Profile for LDAP Schema",
INTERNET-DRAFT <draft-ietf-schema-ldap-00.txt>, January 1998. INTERNET-DRAFT <draft-ietf-schema-ldap-00.txt>, January 1998.
[MIMEWHOISPP] TBP. [MIMEWHOISPP] L. Daigle, "A MIME Directory Profile for Whois++
Schema", INTERNET-DRAFT <draft-ietf-schema-whois++-00.txt>, April
[MIMEWHOIS] TBP. 1998.
[MIMERWHOIS] TBP. [MIMEWHOIS] R. Moats, "A MIME Content-Type for WHOIS", INTERNET-DRAFT
<draft-ietf-schema-whois-00.txt>, April 1998.
[MIMERXML] TBP. [MIMERWHOIS] M. Mealling, "A MIME Directory Profile for RWhois 1.5
Schema", INTERNET-DRAFT <draft-ietf-schema-rwhois-00.txt>, March
1998.
[RFC1321] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1321] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. April 1992.
[RFC1630] T. Berners-Lee, "Universal Resource Identifiers in WWW",
RFC 1630, June 1994.
[RFC2015] M. Elkins, "MIME Security with Pretty Good Privacy (PGP)", [RFC2015] M. Elkins, "MIME Security with Pretty Good Privacy (PGP)",
RFC 2015, October 1996. RFC 2015, October 1996.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Level", RFC 2119, March 1997.
[RFC2048] N. Freed, J. Klensin, J. Postel, "Multipurpose Internet [RFC2048] N. Freed, J. Klensin, J. Postel, "Multipurpose Internet
Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048,
November 1997. November 1997.
[RFC2223] J. Postel, J. Reynolds, "Instructions to RFC Authors", RFC [RFC2223] J. Postel, J. Reynolds, "Instructions to RFC Authors", RFC
2223, October 1997. 2223, October 1997.
6.0 Authors' Address 6.0 Authors' Address
Chris Apple Chris Apple
skipping to change at page 16, line 43 skipping to change at page 17, line 4
US US
Phone: +1 908 582 2409 Phone: +1 908 582 2409
Fax: +1 908 582 3296 Fax: +1 908 582 3296
Email: capple@att.com Email: capple@att.com
Michael Mealling Michael Mealling
505 Huntmar Park Drive 505 Huntmar Park Drive
Herndon, VA 22070 Herndon, VA 22070
US US
Phone: +1 703 742 0400 Phone: +1 703 742 0400
Fax: +1 703 742 9552 Fax: +1 703 742 9552
Email: michaelm@rwhois.net Email: michaelm@rwhois.net
This Internet-Draft expires on July 31, 1998. This Internet-Draft expires on October 21, 1998.
 End of changes. 37 change blocks. 
76 lines changed or deleted 84 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/