RFC 3975

OMA-IETF Standardization Collaboration

📅 published February 2005, from ietf

okay bestie, RFC 3975 is giving "two organizations walk into a standards room and actually make a plan" 💖

Network Working Group, Informational, January 2005 🎀. The editors are G. Huston, Ed. from the IAB 🧚 and I. Leuca, Ed. from OMA 🌸. It's all about the OMA-IETF Standardization Collaboration ✨. The title block doesn't list anything it obsoletes or updates, so nothing gets replaced or patched here 🫶.

Status of This Memo ✨

ok so this memo is for information only 💅. It is not a standard of any kind, and distribution is unlimited 🦋.

Copyright (C) The Internet Society (2005) 🌈.

Abstract 💜

This doc describes the standardization collaboration between the Open Mobile Alliance (OMA) and the Internet Engineering Task Force (IETF) 🫶.

1. Introduction 🦋

so this section is basically the set of principles and guidelines that becomes the foundation for the cooperation framework between OMA and IETF 💖. The goal is to get technical specs out on time, with maximum interoperability with existing fixed and mobile Internet systems, devices, and protocols 🔥.

On the OMA side, work happens in OMA working groups, each with its own area of responsibility 🌸. The OMA Technical Plenary authorizes those activities and approves their output 👑. You can find the OMA working group list, specs open for public comment, the work program, and public WG drafts at the OMA web site, <http://www.openmobilealliance.org> ✨.

On the IETF side, things are organized into Areas, with working groups chartered inside each Area 🧚. The IESG reviews WG output and the RFC-Editor publishes it 💅. IETF work runs on open contribution, so literally any interested party can join 🙌. Working group info, drafts, meeting schedules, and mailing lists are on the IETF web site, <http://www.ietf.org> 💜.

The IETF and the OMA are both cooperating because they want to protect the integrity of each other's specs and standards 🫶. The preferred approach is that OMA uses Internet standards unchanged, when that's feasible, and sends any change requests to the IETF as needed 🎀. They also want to avoid doing the same work twice 💅.

Each org runs on its own rules and procedures, including its own IPR rules, spec elaboration, approval, and maintenance 🌈.

This framework is meant to guide collaboration, and it SHOULD be used as far as it applies 💖. If either party finds it doesn't apply, it MAY notify the other so the framework can be modified or withdrawn as appropriate 🦋.

2. Basis of Collaboration 🌸

OMA has recognized the benefit of adopting Internet specs when it develops its own specs 🔥.

Even though interoperability with the existing Internet, and so the use of IETF standards, matters a lot here, OMA knows it may need additions or modifications so IETF specs actually meet OMA's needs 👑. In those cases OMA takes its concerns straight to the right IETF working groups for resolution 💅. If no suitable WG can be found, or it isn't clear where to send something, or for resolving related matters, the issue goes through OMA's designated liaison to the IETF 🧚.

The IETF may also need to ask OMA questions to better understand OMA requirements, and it MAY want to give OMA guidance on using Internet specs well 💜. Where possible, this happens in a discussion between OMA and an IETF working group 🫶. If a WG-level discussion isn't the right fit, the matter goes through the IETF's designated liaison to OMA 🎀.

3. Document Sharing 🌈

Both OMA and IETF encourage sharing drafts that they're both interested in 💖.

All IETF documents are publicly available on the IETF web site, and document discussions happen on open mailing lists 🦋.

OMA documents meant for public consumption, including working drafts, are published for open access on the OMA web site, <http://www.openmobilealliance.org/> 🌸. OMA members are also encouraged to make their technical contributions to OMA publicly available 🔥.

OMA and IETF will regularly update and exchange a list of dependencies between each organization's specs and work in progress 👑.

4. Participation in the IETF Process 💅

Participation in the IETF process is completely open 🧚. That means OMA delegates can join IETF meetings and mailing list discussions to whatever extent OMA thinks is right 💜. That helps IETF understand OMA requirements better and meet the requirements IETF considers appropriate 🫶. It's also a great chance for OMA delegates to get informal guidance from IETF on how OMA uses Internet specs 🎀.

Most technical discussion and decision making in the IETF happens on open mailing lists 🌈. It is RECOMMENDED that interested individuals subscribe to and participate on these lists 💖.

OMA gets notified about new IETF work through a nominated IETF liaison notification mechanism 🦋.

5. Designated Liaisons 🌸

When informal WG-level interaction isn't enough, matters can go through a liaison channel 🔥. OMA and IETF SHALL each set up liaison functions for communicating with the other organization, and each SHALL appoint one or more individuals to those functions 👑.

5.1. IETF Liaison to OMA 💅

Working with organizations through working groups is the preferred way for IETF 🧚. IETF does have a limited number of individual liaison roles with other organizations, used when conditions call for a specific person 💜.

The Internet Architecture Board (IAB) SHALL appoint a specific person to serve as the OMA Liaison 🫶. This role is an initial contact point in IETF for administrative aspects of the collaboration that can't easily be handled another way, for example at a technical level through IETF WGs or Area Directors 🎀. The role does NOT come with an expectation of attending OMA meetings or joining OMA administrative processes, and all liaison work for this person is expected to happen over email 🌈. The liaison also can't make exceptions to, or special provisions for, IETF policies and procedures 💖.

The person in this role is expected to:

  • be informed by OMA about OMA activities on behalf of IETF, including new work proposals, and be able to report those through the appropriate IETF channels 🦋,
  • convey liaison statements from OMA to IETF, and be responsible for shepherding OMA communication to the relevant parts of IETF 🌸,
  • report to OMA on progress with IETF consideration of OMA liaison statements, and 🔥
  • have direct access to OMA technical leadership, as well as direct access to the IAB and IETF Area Directors, as needed 👑.

OMA meetings are normally open only to delegates from OMA member organizations 💅. To help information flow between the orgs, IETF may, with prior written invitation from OMA on a per-case basis, send a representative to take part in and represent IETF at an OMA Technical Plenary and working group meeting, under conditions OMA sets 🧚. That representative could be the IETF liaison or, if the liaison can't attend, another designated individual 💜.

5.2. OMA Liaison to IETF 🫶

The OMA Technical Plenary SHALL establish an IETF liaison as the initial contact point in OMA for matters about OMA-IETF cooperation 🎀. So this role is expected to work with the relevant IETF and OMA working groups and support the interaction between OMA and IETF 🌈.

6. Formal Liaison Statements 💖

Whenever possible, communication at the WG level is strongly encouraged, as the preferred primary method for coordinating activity 🦋.

When it's deemed necessary, formal communication between OMA and IETF is also permitted 🌸. These communications are recorded as Liaison Statements, and IETF uses the OMA liaison role to convey them between IETF and OMA 🔥. All liaison statements made by IETF or directed to IETF SHALL be published by IETF as public documents 👑. All liaison statements made by IETF will comply with the IETF IPR policy documented in RFC 3667 [1] and RFC 3668 [2] 💅.

7. Contributions 🧚

OMA members MAY make contributions to IETF in their capacity as IETF participants, under the IETF IPR policy documented in RFC 3667 [1] and RFC3668 [2] 💜.

IETF participants who are also OMA members MAY make contributions to OMA only in their capacity as OMA members, under OMA membership rules, including its IPR policy 🫶.

OMA mailing lists aren't open to the general public 🎀. It is RECOMMENDED that work of mutual interest be discussed on the relevant IETF mailing lists 🌈.

OMA MAY make normative references to IETF Proposed Standard, Draft Standard, Standard, Best Common Practice, and Informational specifications published as part of the "Request for Comments" (RFC) document series 💖.

8. Co-development of Documents 🦋

IETF and OMA will not co-develop any documents or material 🌸. No cap, that's a hard boundary 🔥.

9. Terms of Agreement 👑

9.1. Limitation of Liability 💅

Neither IETF nor OMA makes any representations about, or warrants the accuracy of, any information or any document 🧚. Without limiting the above, each party agrees to accept, and to reproduce, any warranty disclaimers or limitations of liability included in any reproduction of published material made available to it under this cooperation framework 💜.

9.2. General 🫶

a. Neither OMA nor 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 OMA or IETF to incorporate materials presented by the other party 🌈.

c. This cooperation framework, and the relationship between IETF and OMA, does not constitute a partnership, joint venture, agency, or contract of employment between IETF and OMA 💖.

10. Acknowledgments 🎀

okay bestie, big thank-you moment 🫶 the editors shoutout a whole squad for helping make this doc happen: Jorge Contreras, Leslie Daigle, Ted Hardie, Allison Mankin, Thomas Narten, Isabelle Valet-Harper, and Dean Willis. literal legends 👑

also, this memo borrowed some text and guidance from RFC 3113 [3] and RFC 3131 [4]. sharing is caring, and these two were the OG 3GPP and 3GPP2 collab docs 💅

11. References 📚

11.1. Normative References

These are the ones you NEED to read to get the full picture, no skipping 🙈

[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

These ones are more like bonus reading. Super helpful, not strictly required 🌸

[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.

Appendix A. Work Areas 🦋

okay so here's where the IETF and the OMA have overlapping interests, aka the areas where they're both obsessed with the same stuff ✨ the list goes:

  • Instant Messaging based on SIP/SIMPLE 💬
  • Presence and availability 🟢
  • Privacy 🔒
  • SIP Event Notification 🔔
  • Location services, such as geographic location 📍
  • Device management 📱
  • Multimedia messaging, including email interconnectivity and mapping 📨
  • Group management 👯
  • 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

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 on whether any Intellectual Property Rights or other rights that someone might claim over the technology in this document are valid or in scope. It also doesn't say whether licenses for those rights are available, or whether they might not be. And it doesn't claim to have done any independent digging to find such rights 🕵️‍♀️ If you want the IETF's procedures for rights in IETF Documents, check out BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses that will be made available, or the results of an attempt to get a general license or permission for implementers or users to use those proprietary rights, can be found in the IETF online IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology required to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org. 💜

Acknowledgement 🌈

Funding for the RFC Editor function is currently provided by the Internet Society. ✨ bestie, that's the whole story, and I'm obsessed with how it all came together 💖

📦 where this page comes from