* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

2017 Applications and Real Time (ART) Desired Expertise

Applications and Real Time (ART)

The ART Area has recently been created by merging the former Applications Area with the RAI Area, and encompasses several areas of work:

  1. "Infrastructure" protocols. These are underpinnings for other application-layer protocols. They sit above transport protocols, and should not themselves be considered "transport", but they are often or usually used by other application-layer protocols as a layer between applications and transport. Current work in this category includes evolution, maintenance, and extensions to HTTP, SIP, Audio/Video Transport, and RTSP, and codec development.
  1. Real-time applications. These have previously been developed in the RAI Area, and are protocols that enable interactive human-to-human communication (see RFC 3550). Groups in this category are working on things such as real-time web communications, teleconferencing, emergency services communication, internet telephony, and instant messaging.
  1. Traditional applications. These have previously been developed in the Applications Area, and are the protocols we've generally thought of in relation to the application layer. They include such things as email, calendaring, directory services, non-real-time web services, and support for constrained environments.
  1. Application building blocks. These are designed to be used with a variety of more specific applications. They include internationalization, JSON and XML, media types, URNs, and URI schemes.

The ART Area often discusses whether something is properly the realm of the IETF or "belongs" to other SDOs. The ART Area often re-uses technology developed elsewhere. As a result, the set of ART ADs needs to include the ability and experience to relate to a wide range of non-IETF organizations, such as the W3C, 3GPP and Unicode Consortium.

ART ADs are expected to take a lead role, guiding the community in the making of critical decisions about the scope of the IETF's applications-layer protocol work. Because of the breadth of the ART Area, the ART ADs need to deal with a large set of application-layer protocols, including many with which a particular AD may not have direct experience. ART ADs need to be good at evaluating new approaches to new problems and assessing the expertise of the people who bring them to the IETF. They need to connect well with the community, and know whom to go to for technical advice.

The set of people active in the ART Area changes with the protocols under development at the time. Therefore it is important that the ART ADs be able to clearly explain how the IETF works and to help new participants and working groups operate well, within the IETF standards process. The ability to reach out to new technology communities is important, so that the ART Area stays relevant to the ongoing evolution of Internet applications.

Cross-area expertise with the Security and Transport Areas is also useful, as there are often dependencies between ART work and those areas, particularly with respect to authentication, confidentiality, privacy, network congestion issues, and newly evolving work in the Transport Area.

ART ADs should be prepared to spend 50-75% of their time on IESG-related activities.

This description has been careful to talk about the set of ART ADs as a collective, with a collective set of skills. No one AD will have all of them, and it would be best to look at a balanced skill set across the ART ADs. A generalist with good management skills and good working relationships within the community will be more successful than a narrow specialist. That said, the particular challenges of certain aspects of ART Area work mean that it's important that for each of the following there be at least one AD with a good understanding of it: internationalization; URI schemes; SIP, SDP and related services; RTP; real-time web communications; web services; and media types.