{ |!
`
`
`
`DECLARATION OF SANDY GINOZA FOR IETF
`RFC: 2026 THE INTERNET STANDARDS PROCESS — REVISION 3
`
`I, Sandy Ginoza, based on my personal knowledge and information, hereby declare as
`
`follows:
`
`1.
`
`Tam an employee of Association Management Solutions, LLC (AMS), which
`
`act under contract to the IETF Administration LLC (IETF)as the operator of the RFC
`
`Production Center. The RFC Production Center is part of the "RFC Editor" function, which
`
`prepares documents for publication and placesfiles in an online repository for the
`
`authoritative Request for Comments (RFC) series of documents (RFC Series), and preserves
`
`records relating to these documents. The RFC Series includes, among other things, the series
`
`of Internet standards developed by the IETF.I hold the position of Director of the RFC
`
`Production Center, I began employment with AMSin this capacity on 6 January 2010.
`
`2.
`
`Among my responsibilities as Director of the RFC Production Center, I act as
`
`the custodian of records relating to the RFC Series, and I am familiar with the record keeping
`
`practices relating to the RFC Series, including the creation and maintenance of such records.
`
`3,
`
`From June 1999 to 5 January 2010, I was an employee of the Information
`
`Sciences Institute at University of Southern California (ISI). I held various position titles with
`
`the RFC Editor project at ISH, ending with Senior Editor.
`
`4.
`
`The RFC Editor function was conducted by ISI under contract to the United
`
`States governmentprior to 1998. In 1998, ISOC,in furtherance of its IETF activity, entered into
`
`the first in a series of contracts with ISI providing for ISI's performance of the RFC Editor
`
`function. Beginning in 2010, certain aspects of the RFC Editor function were assumed by the
`
`RFC Production Center operation of AMS under contract to ISOC (acting through its IETF
`
`Apple Inc.
`Ex. 1024 - Page 1
`
`Apple Inc.
`Ex. 1024 - Page 1
`
`

`

` i i! |
`
`
`
`
`
`
`
`function and, in particular, the IETF Administrative Oversight Committee (now the
`
`IETF Administration LLC (IETF)). The business records of the RFC Editor function as it was
`
`conducted by ISI are currently housed on the computer systems of AMS,as contractor to the
`
`IETF.
`
`5.
`
`I make this declaration based on my personal knowledge and information
`
`contained in the business records of the RFC Editor as they are currently housed at AMS, or
`
`confirmation with other responsible RFC Editor personnel with such knowledge.
`
`6.
`
`Prior to 1998, the RFC Editor's reguiarpractice was to publish RFCs, making
`
`them available from a repository via FTP. When a new RFC waspublished, an announcement
`
`of its publication, with information on how to access the RFC, would be typically sent out
`
`within 24 hours of the publication.
`
`7.
`
`Any RFC published on the RFC Editor website or via FTP was reasonably
`
`accessible to the public and was disseminated or otherwise available to the extent that persons
`
`interested and ordinarily skilled in the subject matter or art exercising reasonable diligence could
`
`have locatedit. In particular, the RFCs were indexed andplaced in a public repository.
`
`8.
`
`The RFCsare kept in an online repository in the course of the RFC Editor's
`
`regularly conducted activity and ordinary course of business. The records are made pursuantto
`
`established procedures and are relied upon by the RFC Editor in the performance ofits functions,
`
`9,
`
`It is the regular practice of the RFC Editor to make and keep the RFC records.
`
`10. Based on the business records for the RFC Editor and the RFC Editor’s course of
`
`conduct in publishing RFCs, I have determined that the publication date of RFC 2026 was no
`
`later than October 1996, at which time it was reasonably accessible to the public either on the
`
`Apple Inc.
`Ex. 1024 - Page 2
`
`Apple Inc.
`Ex. 1024 - Page 2
`
`

`

`REC Editor website or via FTP from a repository. A copy of that RFC is attached to this
`
`declaration as an exhibit.
`
`Pursuant to Section 1746 of Title 28 of United States Code, I declare under penalty of
`
`perjury underthe laws of the United States of America that the foregoing is true and correct
`
`and that the foregoing is based upon personal knowledge and information andis believed to be
`
`true.
`
`Date:
`
`(4 Wo
`
`201g
`
`By:
`
`ndy\Ginoza
`
`4837-5081-8937.1
`
`ATTACHEDCALIF,eamesJ \\ \\a12.
`
`Apple Inc.
`Ex. 1024 - Page 3
`
`Apple Inc.
`Ex. 1024 - Page 3
`
`

`

`
`
` CALIFORNIA ALL-PURPOSE ACKNOWLEDGMENT CIVIL CODE§ 1189
`
`A notary public or other officer completing this certificate verifies only the identity of the Individual who signed the
`document to which this certificate is attached, and not the truthfulness, accuracy, or validity of that document.
`
`
`State of California
`
`
`)
`
`)
`
`;
`County of \ os Anaeee !
`, Pere: —
`P bi C
`On
`\\
`| \\ iG.
`before me,
`“GsInsertNameandTitle.theOfficer
`Date
`&Andy. Gino
`personallyappeared
`who proved to me on the basis of Satisfactoryevidence to be th sper ssi
`nes
`es
`“Glin
`sub scribed to the within instrument and Aeeyledgefeiiveme that
`ytiey executed th
`ferns uthorizedcapacity{iag},andsorte
`Nytsignatur
`theinstrumenttheperson,
`ort
`y upon behalf of which he personRetePontysig the instrument.
`
`
`
`Signer
`got
`lame
`
`
`i certify under PENALTY OF PERJURY underthe laws
`of the State of California that the foregoing paragraph
`is true and correct.
`
`
`
`
`ey
`M.L. PEREZ
`
`a Notary Public ~ California
`
`25
`i
`Los Angeles County
`
`i
`Seiestir
`Commission # 2213639
`
`MyComm,ExpiresSep iG, 2021
`Es
`
`
`“PEASAEONTYAREEE ice
`
`WITNESS my hand and official d)
`Signature L)( .XL
`
`Place Notary Seal Above
`
`OPTIONAL
`Though this section is optional, completing this information can deteralteration of the documentor
`fraudulent reattachment of this form to an unintended docurnerit.
`
`Pescription of Attached Document
`
`Title or Type of Document:
`]
`
`
`
`
`Number of Pages:
`Document Date:
`
`Signer(s) Other Than Named Above:
`
`TE RIC: 2026
`
`
`Capacity(ies) Claimed by Signer(s)
`
`Signer’s Name:
`["] Corporate Officer — Titla(s):
`[] Partner --
`[1 Limited
`([ General
`C7 Individual
`(_] Attorney in Fact
`CI Trustee
`L] Guardian or Conservator
`F Other:
`
`Signer’s Name:
`-] Corporate Officer — Title(s):
`(] Partner — Ci Limited
`[4 General
`(J Inclividual
`LI Attorney in Fact
`[J Trustee
`C] Guardian or Conservator
`[ Other:
`
`
`
`
`
`Signer Is Representing: Signer Is Representing:
`
`
` ©2016 National Notary fAssociation - www.w NationalNotary,org * ; “800-US NOTARYY (1--800-"876-6827) Item 5907
`
`
`
`Apple Inc.
`Ex. 1024 - Page 4
`
`Apple Inc.
`Ex. 1024 - Page 4
`
`

`

`Network Working Group S. Bradner
`Request for Comments: 2026 Harvard University
`BCP: 9 October 1996
`Obsoletes: 1602
`Category: Best Current Practice
`
` The Internet Standards Process -- Revision 3
`
`Status of this Memo
`
` This document specifies an Internet Best Current Practices for the
` Internet Community, and requests discussion and suggestions for
` improvements. Distribution of this memo is unlimited.
`
`Abstract
`
` This memo documents the process used by the Internet community for
` the standardization of protocols and procedures. It defines the
` stages in the standardization process, the requirements for moving a
` document between stages and the types of documents used during this
` process. It also addresses the intellectual property rights and
` copyright issues associated with the standards process.
`
`Table of Contents
`
` 1. INTRODUCTION....................................................2
` 1.1 Internet Standards...........................................3
` 1.2 The Internet Standards Process...............................3
` 1.3 Organization of This Document................................5
` 2. INTERNET STANDARDS-RELATED PUBLICATIONS.........................5
` 2.1 Requests for Comments (RFCs).................................5
` 2.2 Internet-Drafts..............................................7
` 3. INTERNET STANDARD SPECIFICATIONS................................8
` 3.1 Technical Specification (TS).................................8
` 3.2 Applicability Statement (AS).................................8
` 3.3 Requirement Levels...........................................9
` 4. THE INTERNET STANDARDS TRACK...................................10
` 4.1 Standards Track Maturity Levels.............................11
` 4.1.1 Proposed Standard.......................................11
` 4.1.2 Draft Standard..........................................12
` 4.1.3 Internet Standard.......................................13
` 4.2 Non-Standards Track Maturity Levels.........................13
` 4.2.1 Experimental............................................13
` 4.2.2 Informational...........................................14
` 4.2.3 Procedures for Experimental and Informational RFCs......14
` 4.2.4 Historic................................................15
`
`Bradner Best Current Practice [Page 1]
`
`Apple Inc.
`Ex. 1024 - Page 5
`
`

`

`
`RFC 2026 Internet Standards Process October 1996
`
` 5. Best Current Practice (BCP) RFCs...............................15
` 5.1 BCP Review Process..........................................16
` 6. THE INTERNET STANDARDS PROCESS.................................17
` 6.1 Standards Actions...........................................17
` 6.1.1 Initiation of Action....................................17
` 6.1.2 IESG Review and Approval................................17
` 6.1.3 Publication.............................................18
` 6.2 Advancing in the Standards Track............................19
` 6.3 Revising a Standard.........................................20
` 6.4 Retiring a Standard.........................................20
` 6.5 Conflict Resolution and Appeals.............................21
` 6.5.1 Working Group Disputes...................................21
` 6.5.2 Process Failures.........................................22
` 6.5.3 Questions of Applicable Procedure........................22
` 6.5.4 Appeals Procedure........................................23
` 7. EXTERNAL STANDARDS AND SPECIFICATIONS..........................23
` 7.1 Use of External Specifications..............................24
` 7.1.1 Incorporation of an Open Standard.......................24
` 7.1.2 Incorporation of a Other Specifications.................24
` 7.1.3 Assumption..............................................25
` 8. NOTICES AND RECORD KEEPING......................................25
` 9. VARYING THE PROCESS.............................................26
` 9.1 The Variance Procedure.......................................26
` 9.2 Exclusions...................................................27
` 10. INTELLECTUAL PROPERTY RIGHTS..................................27
` 10.1. General Policy............................................27
` 10.2 Confidentiality Obligations...............................28
` 10.3. Rights and Permissions....................................28
` 10.3.1. All Contributions......................................28
` 10.3.2. Standards Track Documents..............................29
` 10.3.3 Determination of Reasonable and
` Non-discriminatory Terms................................30
` 10.4. Notices...................................................30
` 11. ACKNOWLEDGMENTS................................................32
` 12. SECURITY CONSIDERATIONS........................................32
` 13. REFERENCES.....................................................33
` 14. DEFINITIONS OF TERMS...........................................33
` 15. AUTHOR’S ADDRESS...............................................34
` APPENDIX A: GLOSSARY OF ACRONYMS...................................35
`
`Bradner Best Current Practice [Page 2]
`
`Apple Inc.
`Ex. 1024 - Page 6
`
`

`

`
`RFC 2026 Internet Standards Process October 1996
`
`1. INTRODUCTION
`
` This memo documents the process currently used by the Internet
` community for the standardization of protocols and procedures. The
` Internet Standards process is an activity of the Internet Society
` that is organized and managed on behalf of the Internet community by
` the Internet Architecture Board (IAB) and the Internet Engineering
` Steering Group (IESG).
`
`1.1 Internet Standards
`
` The Internet, a loosely-organized international collaboration of
` autonomous, interconnected networks, supports host-to-host
` communication through voluntary adherence to open protocols and
` procedures defined by Internet Standards. There are also many
` isolated interconnected networks, which are not connected to the
` global Internet but use the Internet Standards.
`
` The Internet Standards Process described in this document is
` concerned with all protocols, procedures, and conventions that are
` used in or by the Internet, whether or not they are part of the
` TCP/IP protocol suite. In the case of protocols developed and/or
` standardized by non-Internet organizations, however, the Internet
` Standards Process normally applies to the application of the protocol
` or procedure in the Internet context, not to the specification of the
` protocol itself.
`
` In general, an Internet Standard is a specification that is stable
` and well-understood, is technically competent, has multiple,
` independent, and interoperable implementations with substantial
` operational experience, enjoys significant public support, and is
` recognizably useful in some or all parts of the Internet.
`
`1.2 The Internet Standards Process
`
` In outline, the process of creating an Internet Standard is
` straightforward: a specification undergoes a period of development
` and several iterations of review by the Internet community and
` revision based upon experience, is adopted as a Standard by the
` appropriate body (see below), and is published. In practice, the
` process is more complicated, due to (1) the difficulty of creating
` specifications of high technical quality; (2) the need to consider
` the interests of all of the affected parties; (3) the importance of
` establishing widespread community consensus; and (4) the difficulty
` of evaluating the utility of a particular specification for the
` Internet community.
`
`Bradner Best Current Practice [Page 3]
`
`Apple Inc.
`Ex. 1024 - Page 7
`
`

`

`
`RFC 2026 Internet Standards Process October 1996
`
` The goals of the Internet Standards Process are:
` o technical excellence;
` o prior implementation and testing;
` o clear, concise, and easily understood documentation;
` o openness and fairness; and
` o timeliness.
`
` The procedures described in this document are designed to be fair,
` open, and objective; to reflect existing (proven) practice; and to
` be flexible.
`
` o These procedures are intended to provide a fair, open, and
` objective basis for developing, evaluating, and adopting Internet
` Standards. They provide ample opportunity for participation and
` comment by all interested parties. At each stage of the
` standardization process, a specification is repeatedly discussed
` and its merits debated in open meetings and/or public electronic
` mailing lists, and it is made available for review via world-wide
` on-line directories.
`
` o These procedures are explicitly aimed at recognizing and adopting
` generally-accepted practices. Thus, a candidate specification
` must be implemented and tested for correct operation and
` interoperability by multiple independent parties and utilized in
` increasingly demanding environments, before it can be adopted as
` an Internet Standard.
`
` o These procedures provide a great deal of flexibility to adapt to
` the wide variety of circumstances that occur in the
` standardization process. Experience has shown this flexibility to
` be vital in achieving the goals listed above.
`
` The goal of technical competence, the requirement for prior
` implementation and testing, and the need to allow all interested
` parties to comment all require significant time and effort. On the
` other hand, today’s rapid development of networking technology
` demands timely development of standards. The Internet Standards
` Process is intended to balance these conflicting goals. The process
` is believed to be as short and simple as possible without sacrificing
` technical excellence, thorough testing before adoption of a standard,
` or openness and fairness.
`
` From its inception, the Internet has been, and is expected to remain,
` an evolving system whose participants regularly factor new
` requirements and technology into its design and implementation. Users
` of the Internet and providers of the equipment, software, and
` services that support it should anticipate and embrace this evolution
` as a major tenet of Internet philosophy.
`
`Bradner Best Current Practice [Page 4]
`
`Apple Inc.
`Ex. 1024 - Page 8
`
`

`

`
`RFC 2026 Internet Standards Process October 1996
`
` The procedures described in this document are the result of a number
` of years of evolution, driven both by the needs of the growing and
` increasingly diverse Internet community, and by experience.
`
`Bradner Best Current Practice [Page 5]
`
`Apple Inc.
`Ex. 1024 - Page 9
`
`

`

`
`RFC 2026 Internet Standards Process October 1996
`
`1.3 Organization of This Document
`
` Section 2 describes the publications and archives of the Internet
` Standards Process. Section 3 describes the types of Internet
` standard specifications. Section 4 describes the Internet standards
` specifications track. Section 5 describes Best Current Practice
` RFCs. Section 6 describes the process and rules for Internet
` standardization. Section 7 specifies the way in which externally-
` sponsored specifications and practices, developed and controlled by
` other standards bodies or by others, are handled within the Internet
` Standards Process. Section 8 describes the requirements for notices
` and record keeping Section 9 defines a variance process to allow
` one-time exceptions to some of the requirements in this document
` Section 10 presents the rules that are required to protect
` intellectual property rights in the context of the development and
` use of Internet Standards. Section 11 includes acknowledgments of
` some of the people involved in creation of this document. Section 12
` notes that security issues are not dealt with by this document.
` Section 13 contains a list of numbered references. Section 14
` contains definitions of some of the terms used in this document.
` Section 15 lists the author’s email and postal addresses. Appendix A
` contains a list of frequently-used acronyms.
`
`2. INTERNET STANDARDS-RELATED PUBLICATIONS
`
`2.1 Requests for Comments (RFCs)
`
` Each distinct version of an Internet standards-related specification
` is published as part of the "Request for Comments" (RFC) document
` series. This archival series is the official publication channel for
` Internet standards documents and other publications of the IESG, IAB,
` and Internet community. RFCs can be obtained from a number of
` Internet hosts using anonymous FTP, gopher, World Wide Web, and other
` Internet document-retrieval systems.
`
` The RFC series of documents on networking began in 1969 as part of
` the original ARPA wide-area networking (ARPANET) project (see
` Appendix A for glossary of acronyms). RFCs cover a wide range of
` topics in addition to Internet Standards, from early discussion of
` new research concepts to status memos about the Internet. RFC
` publication is the direct responsibility of the RFC Editor, under the
` general direction of the IAB.
`
`Bradner Best Current Practice [Page 6]
`
`Apple Inc.
`Ex. 1024 - Page 10
`
`

`

`
`RFC 2026 Internet Standards Process October 1996
`
` The rules for formatting and submitting an RFC are defined in [5].
` Every RFC is available in ASCII text. Some RFCs are also available
` in other formats. The other versions of an RFC may contain material
` (such as diagrams and figures) that is not present in the ASCII
` version, and it may be formatted differently.
`
` *********************************************************
` * *
` * A stricter requirement applies to standards-track *
` * specifications: the ASCII text version is the *
` * definitive reference, and therefore it must be a *
` * complete and accurate specification of the standard, *
` * including all necessary diagrams and illustrations. *
` * *
` *********************************************************
`
` The status of Internet protocol and service specifications is
` summarized periodically in an RFC entitled "Internet Official
` Protocol Standards" [1]. This RFC shows the level of maturity and
` other helpful information for each Internet protocol or service
` specification (see section 3).
`
` Some RFCs document Internet Standards. These RFCs form the ’STD’
` subseries of the RFC series [4]. When a specification has been
` adopted as an Internet Standard, it is given the additional label
` "STDxxx", but it keeps its RFC number and its place in the RFC
` series. (see section 4.1.3)
`
` Some RFCs standardize the results of community deliberations about
` statements of principle or conclusions about what is the best way to
` perform some operations or IETF process function. These RFCs form
` the specification has been adopted as a BCP, it is given the
` additional label "BCPxxx", but it keeps its RFC number and its place
` in the RFC series. (see section 5)
`
` Not all specifications of protocols or services for the Internet
` should or will become Internet Standards or BCPs. Such non-standards
` track specifications are not subject to the rules for Internet
` standardization. Non-standards track specifications may be published
` directly as "Experimental" or "Informational" RFCs at the discretion
` of the RFC Editor in consultation with the IESG (see section 4.2).
`
`Bradner Best Current Practice [Page 7]
`
`Apple Inc.
`Ex. 1024 - Page 11
`
`

`

`
`RFC 2026 Internet Standards Process October 1996
`
` ********************************************************
` * *
` * It is important to remember that not all RFCs *
` * are standards track documents, and that not all *
` * standards track documents reach the level of *
` * Internet Standard. In the same way, not all RFCs *
` * which describe current practices have been given *
` * the review and approval to become BCPs. See *
` * RFC-1796 [6] for further information. *
` * *
` ********************************************************
`
`2.2 Internet-Drafts
`
` During the development of a specification, draft versions of the
` document are made available for informal review and comment by
` placing them in the IETF’s "Internet-Drafts" directory, which is
` replicated on a number of Internet hosts. This makes an evolving
` working document readily available to a wide audience, facilitating
` the process of review and revision.
`
` An Internet-Draft that is published as an RFC, or that has remained
` unchanged in the Internet-Drafts directory for more than six months
` without being recommended by the IESG for publication as an RFC, is
` simply removed from the Internet-Drafts directory. At any time, an
` Internet-Draft may be replaced by a more recent version of the same
` specification, restarting the six-month timeout period.
`
` An Internet-Draft is NOT a means of "publishing" a specification;
` specifications are published through the RFC mechanism described in
` the previous section. Internet-Drafts have no formal status, and are
` subject to change or removal at any time.
`
` ********************************************************
` * *
` * Under no circumstances should an Internet-Draft *
` * be referenced by any paper, report, or Request- *
` * for-Proposal, nor should a vendor claim compliance *
` * with an Internet-Draft. *
` * *
` ********************************************************
`
`Bradner Best Current Practice [Page 8]
`
`Apple Inc.
`Ex. 1024 - Page 12
`
`

`

`
`RFC 2026 Internet Standards Process October 1996
`
` Note: It is acceptable to reference a standards-track specification
` that may reasonably be expected to be published as an RFC using the
` phrase "Work in Progress" without referencing an Internet-Draft.
` This may also be done in a standards track document itself as long
` as the specification in which the reference is made would stand as a
` complete and understandable document with or without the reference to
` the "Work in Progress".
`
`3. INTERNET STANDARD SPECIFICATIONS
`
` Specifications subject to the Internet Standards Process fall into
` one of two categories: Technical Specification (TS) and
` Applicability Statement (AS).
`
`3.1 Technical Specification (TS)
`
` A Technical Specification is any description of a protocol, service,
` procedure, convention, or format. It may completely describe all of
` the relevant aspects of its subject, or it may leave one or more
` parameters or options unspecified. A TS may be completely self-
` contained, or it may incorporate material from other specifications
` by reference to other documents (which might or might not be Internet
` Standards).
`
` A TS shall include a statement of its scope and the general intent
` for its use (domain of applicability). Thus, a TS that is inherently
` specific to a particular context shall contain a statement to that
` effect. However, a TS does not specify requirements for its use
` within the Internet; these requirements, which depend on the
` particular context in which the TS is incorporated by different
` system configurations, are defined by an Applicability Statement.
`
`3.2 Applicability Statement (AS)
`
` An Applicability Statement specifies how, and under what
` circumstances, one or more TSs may be applied to support a particular
` Internet capability. An AS may specify uses for TSs that are not
` Internet Standards, as discussed in Section 7.
`
` An AS identifies the relevant TSs and the specific way in which they
` are to be combined, and may also specify particular values or ranges
` of TS parameters or subfunctions of a TS protocol that must be
` implemented. An AS also specifies the circumstances in which the use
` of a particular TS is required, recommended, or elective (see section
` 3.3).
`
`Bradner Best Current Practice [Page 9]
`
`Apple Inc.
`Ex. 1024 - Page 13
`
`

`

`
`RFC 2026 Internet Standards Process October 1996
`
` An AS may describe particular methods of using a TS in a restricted
` "domain of applicability", such as Internet routers, terminal
` servers, Internet systems that interface to Ethernets, or datagram-
` based database servers.
`
` The broadest type of AS is a comprehensive conformance specification,
` commonly called a "requirements document", for a particular class of
` Internet systems, such as Internet routers or Internet hosts.
`
` An AS may not have a higher maturity level in the standards track
` than any standards-track TS on which the AS relies (see section 4.1).
` For example, a TS at Draft Standard level may be referenced by an AS
` at the Proposed Standard or Draft Standard level, but not by an AS at
` the Standard level.
`
`3.3 Requirement Levels
`
` An AS shall apply one of the following "requirement levels" to each
` of the TSs to which it refers:
`
` (a) Required: Implementation of the referenced TS, as specified by
` the AS, is required to achieve minimal conformance. For example,
` IP and ICMP must be implemented by all Internet systems using the
` TCP/IP Protocol Suite.
`
` (b) Recommended: Implementation of the referenced TS is not
` required for minimal conformance, but experience and/or generally
` accepted technical wisdom suggest its desirability in the domain
` of applicability of the AS. Vendors are strongly encouraged to
` include the functions, features, and protocols of Recommended TSs
` in their products, and should omit them only if the omission is
` justified by some special circumstance. For example, the TELNET
` protocol should be implemented by all systems that would benefit
` from remote access.
`
` (c) Elective: Implementation of the referenced TS is optional
` within the domain of applicability of the AS; that is, the AS
` creates no explicit necessity to apply the TS. However, a
` particular vendor may decide to implement it, or a particular user
` may decide that it is a necessity in a specific environment. For
` example, the DECNET MIB could be seen as valuable in an
` environment where the DECNET protocol is used.
`
`Bradner Best Current Practice [Page 10]
`
`Apple Inc.
`Ex. 1024 - Page 14
`
`

`

`
`RFC 2026 Internet Standards Process October 1996
`
` As noted in section 4.1, there are TSs that are not in the
` standards track or that have been retired from the standards
` track, and are therefore not required, recommended, or elective.
` Two additional "requirement level" designations are available for
` these TSs:
`
` (d) Limited Use: The TS is considered to be appropriate for use
` only in limited or unique circumstances. For example, the usage
` of a protocol with the "Experimental" designation should generally
` be limited to those actively involved with the experiment.
`
` (e) Not Recommended: A TS that is considered to be inappropriate
` for general use is labeled "Not Recommended". This may be because
` of its limited functionality, specialized nature, or historic
` status.
`
` Although TSs and ASs are conceptually separate, in practice a
` standards-track document may combine an AS and one or more related
` TSs. For example, Technical Specifications that are developed
` specifically and exclusively for some particular domain of
` applicability, e.g., for mail server hosts, often contain within a
` single specification all of the relevant AS and TS information. In
` such cases, no useful purpose would be served by deliberately
` distributing the information among several documents just to preserve
` the formal AS/TS distinction. However, a TS that is likely to apply
` to more than one domain of applicability should be developed in a
` modular fashion, to facilitate its incorporation by multiple ASs.
`
` The "Official Protocol Standards" RFC (STD1) lists a general
` requirement level for each TS, using the nomenclature defined in this
` section. This RFC is updated periodically. In many cases, more
` detailed descriptions of the requirement levels of particular
` protocols and of individual features of the protocols will be found
` in appropriate ASs.
`
`4. THE INTERNET STANDARDS TRACK
`
` Specifications that are intended to become Internet Standards evolve
` through a set of maturity levels known as the "standards track".
` These maturity levels -- "Proposed Standard", "Draft Standard", and
` "Standard" -- are defined and discussed in section 4.1. The way in
` which specifications move along the standards track is described in
` section 6.
`
` Even after a specification has been adopted as an Internet Standard,
` further evolution often occurs based on experience and the
` recognition of new requirements. The nomenclature and procedures of
` Internet standardizatio