summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3975.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3975.txt')
-rw-r--r--doc/rfc/rfc3975.txt507
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]
+