doc: Add RFC documents

1 files changed, 507 insertions, 0 deletions

diff --git a/doc/rfc/rfc3975.txt b/doc/rfc/rfc3975.txt
new file mode 100644
index 0000000..f431c95
--- /dev/null
+++ b/doc/rfc/rfc3975.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group                                     G. Huston, Ed.
+Request for Comments: 3975                                           IAB
+Category: Informational                                    I. Leuca, Ed.
+                                                                     OMA
+                                                            January 2005
+
+
+                 OMA-IETF Standardization Collaboration
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document describes the standardization collaboration between the
+   Open Mobile Alliance (OMA) and the Internet Engineering Task Force
+   (IETF).
+
+1.  Introduction
+
+   This document contains a set of principles and guidelines that serves
+   as the basis for establishing a cooperation framework between the
+   Open Mobile Alliance (OMA) and the Internet Engineering Task Force
+   (IETF).  This cooperation is intended to secure timely development of
+   technical specifications that facilitate maximum interoperability
+   with existing (fixed and mobile) Internet systems, devices, and
+   protocols.
+
+   Within the OMA, specific activities are undertaken through OMA
+   working groups, each with an area of responsibility.  These
+   activities are authorized, and their output is approved by, the OMA
+   Technical Plenary.  The list of OMA working groups, OMA
+   Specifications for public comment, the OMA work program, and publicly
+   available working group drafts can be found at the OMA web site,
+   <http://www.openmobilealliance.org>.
+
+   Within the IETF, activities are undertaken within a framework of
+   Areas, with specific activities being undertaken by working groups
+   that are chartered within each Area.  Working group output is
+   reviewed by the Internet Engineering Steering Group (IESG) and
+   published by the RFC-Editor.  IETF activities are based on a
+
+
+
+Huston & Leuca               Informational                      [Page 1]
+
+RFC 3975         OMA-IETF Standardization Collaboration     January 2005
+
+
+   principle of open contribution and participation by any interested
+   party.  Information on IETF working groups, current work item drafts,
+   meeting schedules, and mailing lists are published on the IETF web
+   site, <http://www.ietf.org>.
+
+   The IETF and the OMA, are cooperating with a mutual desire to support
+   the integrity of specifications and standards developed by each body.
+   The preferred approach is that the OMA uses the Internet standards
+   unchanged, if feasible, and communicates requirements for change to
+   the IETF, as needed.  The parties intend to work together in an
+   effort to avoid duplication of work.
+
+   Each organization will operate according to its own rules and
+   procedures, including rules governing Intellectual Property Rights
+   (IPR), specification elaboration, approval, and maintenance.
+
+   This cooperation framework is intended to guide collaborative
+   efforts, and should be put into use in as much as it is applicable to
+   these efforts.  If either party finds this framework inapplicable,
+   then it may notify the other party so that this framework may be
+   modified or withdrawn, as appropriate.
+
+2.  Basis of Collaboration
+
+   In the further development of OMA specifications, the benefit of
+   adopting Internet specifications has been identified.
+
+   Although this document recognizes the importance of interoperability
+   of OMA specifications with the existing Internet and hence the use of
+   IETF standards, the OMA recognizes that additions or modifications
+   might be needed in order to make the IETF Internet specifications
+   meet the needs of the OMA.  In such cases, the OMA will take its
+   concerns directly to the appropriate IETF working groups for
+   resolution.  When no appropriate working group can be found or it is
+   not known where to direct the communication, or in the case of
+   resolution of consequent matters, the issue will be raised through
+   the OMA's designated liaison to the IETF.
+
+   The IETF may also need to ask questions of the OMA in order to refine
+   its understanding of OMA requirements or may wish to offer guidance
+   to OMA on the effective use of Internet specifications.  Where
+   possible, these communications will occur in the context of a
+   discussion between OMA and an IETF working group.  In the event that
+   a working group level discussion is deemed inappropriate for the
+   desired communication, the matter will be raised through the IETF's
+   designated liaison to the OMA.
+
+
+
+
+
+Huston & Leuca               Informational                      [Page 2]
+
+RFC 3975         OMA-IETF Standardization Collaboration     January 2005
+
+
+3.  Document Sharing
+
+   Both the OMA and the IETF encourage the sharing of draft documents
+   that are of mutual interest.
+
+   All IETF documents are publicly available from the IETF web site, and
+   discussion of documents is hosted on open mailing lists.
+
+   OMA documents intended for public consumption, including working
+   drafts, are published for open access on the OMA web site,
+   <http://www.openmobilealliance.org/>.  Technical contributions to OMA
+   by its members are also encouraged to make publicly available.
+
+   The OMA and the IETF will work to update and exchange, on a regular
+   basis, a list of dependencies between each organization's
+   specifications and work in progress.
+
+4.  Participation in the IETF Process
+
+   Participation in the IETF process is completely open.  This allows
+   OMA delegates to participate to whatever extent the OMA considers
+   appropriate in IETF meetings and mailing list discussions to assist
+   the IETF in refining its understanding of OMA requirements and in
+   meeting requirements that the IETF deems appropriate.  This close
+   working relationship also offers an excellent opportunity for OMA
+   delegates to receive informal guidance from IETF on OMA's use of
+   Internet specifications.
+
+   The vast majority of technical discussions and decision making within
+   the IETF is undertaken by using open mailing lists.  It is
+   recommended that interested individuals subscribe to and participate
+   on these lists.
+
+   The OMA is to be notified of new work to be undertaken by the IETF
+   via a nominated IETF liaison notification mechanism.
+
+5.  Designated Liaisons
+
+   When the informal working group level of interaction is insufficient,
+   matters can be raised through a liaison channel.  The OMA and the
+   IETF shall each establish liaison functions for communication with
+   the other organization and shall appoint one or more individuals to
+   those functions.
+
+
+
+
+
+
+
+
+Huston & Leuca               Informational                      [Page 3]
+
+RFC 3975         OMA-IETF Standardization Collaboration     January 2005
+
+
+5.1.  IETF Liaison to OMA
+
+   The preferred way for organizations to work with IETF is through the
+   working groups.  However, IETF has a limited number of individual
+   liaison roles with other organizations when conditions warrant the
+   appointment of a specific person.
+
+   The Internet Architecture Board (IAB) shall appoint a specific person
+   to serve as the OMA Liaison.  The role of the IETF's OMA Liaison is
+   to act as an initial contact point in IETF for administrative aspects
+   of this collaboration that cannot easily be handled in other ways
+   (e.g., at a technical level by interactions with IETF Working Groups
+   or Area Directors).  It is agreed that the role does not carry the
+   expectation of attendance at OMA meetings or participation in OMA
+   administrative processes, and it is anticipated that all liaison
+   efforts assigned to this individual will be carried out by electronic
+   mail.  It is understood that the liaison does not have the ability to
+   make exceptions to, or special provisions for, IETF policies and
+   procedures.
+
+   It is expected that the individual appointed to this role would:
+
+   o  be informed by the OMA of OMA activities on behalf of the IETF,
+      including new work proposals, and be able to report those using
+      appropriate channels within the IETF,
+
+   o  convey liaisons statements from the OMA to the IETF, and be
+      responsible for shepherding the OMA communication to the relevant
+      parts of the IETF,
+
+   o  report to the OMA on progress with IETF consideration of OMA
+      liaison statements, and
+
+   o  have direct access to the OMA technical leadership as well as
+      direct access to the IAB and IETF Area Directors, as required.
+
+   OMA meetings are normally only open to delegates from OMA member
+   organizations.  To assist the information flow between the
+   organizations, the IETF may, by prior written invitation from the OMA
+   on a per-case basis, send a representative to participate in and
+   represent the IETF at an OMA Technical Plenary and working group
+   meeting under conditions set forth by the OMA.  The representative
+   could be the IETF liaison or, in the event that the liaison cannot
+   attend, some other designated individual.
+
+
+
+
+
+
+
+Huston & Leuca               Informational                      [Page 4]
+
+RFC 3975         OMA-IETF Standardization Collaboration     January 2005
+
+
+5.2.  OMA Liaison to IETF
+
+   The OMA Technical Plenary shall establish an IETF liaison to be the
+   initial contact point in the OMA for matters pertaining to the OMA-
+   IETF cooperation.  The OMA-IETF liaison function, therefore, is
+   expected to work with the concerned IETF and OMA working groups and
+   to support the interaction between the OMA and the IETF.
+
+6.  Formal Liaison Statements
+
+   Whenever possible, and as the preferred primary method of
+   communication and coordination of activity, communication at the
+   working group level is strongly encouraged.
+
+   When deemed necessary, formal communication between OMA and IETF is
+   also permitted.  These communications are to be recorded in the form
+   of Liaison Statements, and the IETF will use the OMA liaison role to
+   convey these statements between the IETF and the OMA.  All liaison
+   statements made by the IETF or directed to the IETF shall be
+   published by the IETF as public documents.  All liaison statements
+   made by the IETF will comply with the IETF IPR policy as documented
+   in RFC 3667 [1] and RFC 3668 [2].
+
+7.  Contributions
+
+   OMA members may make contributions to the IETF in their capacity as
+   IETF participants, under the IETF's IPR policy, as documented in RFC
+   3667 [1] and RFC3668 [2].
+
+   IETF participants who are also members of the OMA may make
+   contributions to the OMA only in their capacity as OMA members, under
+   the OMA's membership rules, including its IPR policy.
+
+   OMA mailing lists are not open to the general public.  It is
+   recommended that work of mutual interest be discussed on the relevant
+   IETF mailing lists.
+
+   The OMA may make normative references to the IETF Proposed Standard,
+   Draft Standard, Standard, Best Common Practice and Informational
+   specifications that are published as part of the "Request for
+   Comments" (RFC) document series.
+
+8.  Co-development of Documents
+
+   The IETF and the OMA will not co-develop any documents or material.
+
+
+
+
+
+
+Huston & Leuca               Informational                      [Page 5]
+
+RFC 3975         OMA-IETF Standardization Collaboration     January 2005
+
+
+9.  Terms of Agreement
+
+9.1.  Limitation of Liability
+
+   Neither the IETF or the OMA makes any representations with respect to
+   and does not warrant the accuracy of any information or any document.
+   Without limiting the foregoing, each party agrees to accept the terms
+   of and reproduce any warranty disclaimers or limitations of liability
+   that are included in any reproduction of published material made
+   available to it under this cooperation framework.
+
+9.2.  General
+
+   a. Neither the OMA or the IETF acquires any intellectual or
+      industrial property rights under this cooperation framework or
+      through any disclosure.  No license to any patent, trademark,
+      copyright, or other proprietary right is granted here.
+
+   b. There is no obligation for either the OMA or the IETF to
+      incorporate the materials presented by the other party.
+
+   c. This cooperation framework and the relationship between the IETF
+      and the OMA does not constitute a partnership, joint venture,
+      agency, or contract of employment between the IETF and the OMA.
+
+10.  Acknowledgments
+
+   The editors acknowledge the extensive efforts of Jorge Contreras,
+   Leslie Daigle, Ted Hardie, Allison Mankin, Thomas Narten, Isabelle
+   Valet-Harper, and Dean Willis in contributing to this document.
+
+   This memo took guidance from and borrowed text from RFC 3113 [3] and
+   RFC 3131 [4].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Huston & Leuca               Informational                      [Page 6]
+
+RFC 3975         OMA-IETF Standardization Collaboration     January 2005
+
+
+11.  References
+
+11.1.  Normative References
+
+   [1]  Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667,
+        February 2004.
+
+   [2]  Bradner, S., "Intellectual Property Rights in IETF Technology",
+        BCP 79, RFC 3668, February 2004.
+
+11.2.  Informative References
+
+   [3]  Rosenbrock, K., Sanmugam, R., Bradner, S., and J. Klensin,
+        "3GPP-IETF Standardization Collaboration", RFC 3113, June 2001.
+
+   [4]  Bradner, S., Calhoun, P., Cuschieri, H., Dennett, S., Flynn, G.,
+        Lipford, M., and M. McPheters, "3GPP2-IETF Standardization
+        Collaboration", RFC 3131, June 2001.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Huston & Leuca               Informational                      [Page 7]
+
+RFC 3975         OMA-IETF Standardization Collaboration     January 2005
+
+
+Appendix A.  Work Areas
+
+   The areas of common interest between the IETF and the OMA include the
+   following:
+
+   o  Instant Messaging based on SIP/SIMPLE
+   o  Presence and availability
+   o  Privacy
+   o  SIP Event Notification
+   o  Location services, such as geographic location
+   o  Device management
+   o  Multimedia messaging, including email interconnectivity and
+      mapping
+   o  Group management
+   o  Telephone number mapping (ENUM)
+
+Authors' Addresses
+
+   Geoff Huston (editor)
+   Internet Architecture Board
+
+   EMail: execd@iab.org
+   URI:   http://www.iab.org
+
+
+   Ileana Leuca (editor)
+   Open Mobile Alliance
+
+   EMail: ileana.leuca@Cingular.com
+   URI:   http://www.openmobilealliance.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Huston & Leuca               Informational                      [Page 8]
+
+RFC 3975         OMA-IETF Standardization Collaboration     January 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the IETF's procedures with respect to rights in IETF Documents can
+   be found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+Huston & Leuca               Informational                      [Page 9]
+