In reading through discussions of RAI/TAWNNY/BOB I've been struck
by how the original descriptions of human interaction got interpreted.
Clearly, something in the verbal shorthand that made sense to Allison,
Jon, Scott and me doesn't quite expand the same way for others. Looking
at the text we sent out, I think the word "interpersonal" was actually a
marker of something else. (Clearly email can be interpersonal. It's
not "instant", but that's probably not the real point either). I think we
used "real-time" and "interpersonal" because the applications we had
in mind are person-to-person interactive ones like telephony, but now
I'm wondering if the actual unifying aspect isn't the step before
the real-time and interpersonal phase of these applications.
The salient bit might, in fact, be that voice over IP and friends have a
set-up phase that is invoked prior to the "real" application traffic starting.
For voice over IP, the sip interactions set up the media flows that will carry
the voice traffic. From a human-interaction point of view, the voice traffic
is the real application, telephony. But from an engineering perspective,
the protocols required to set up the environment for telephony and similar
applications are building blocks that need development and coordination.
The whole presence architecture, for example, may be invisible during
a call or IM session, but it is darn useful for it to be well developed
and deployed before the session starts.
As a thought experiment, I've re-cast the area description in those terms.
Feedback on that formulation would be welcome.
Here's the original:
The Real-Time Applications and Infrastructure Area develops protocols
and architectures for delay-sensitive interpersonal communications. Work
in this area serves an emerging industry whose applications and services
include voice and video over IP, instant messaging and presence. These
applications and services are "real-time" in the sense that delay
impedes human participation in the associated systems.
The RAI Area is seeded with existing working groups from the Transport
and Applications Area: SIP, SIPPING, XCON, SIMPLE, GEOPRIV, ECRIT, ENUM,
IPTEL, MEGACO, MMUSIC, IEPREP, SPEECHSC, and SIGTRAN. A good rule of
thumb for the incorporation of new work into RAI, as opposed to
Transport or Applications, is that the work in question has major goals
supporting instant interpersonal communication or its infrastructure.
For example, they can range from applications to help users make
decisions about how best to communicate using presence services, to
session signaling protocols and emergency call routing solutions, to
work on the "layer five" issues for Internet telephony.
Like all areas of the IETF, the RAI Area draws on the work of numerous
other areas, and as such there can be no neat mathematical boundaries
delineating RAI's work from the rest of the IETF. The new area will
allow an existing community within the IETF to solidify its vision and
to benefit from increased institutional support.
Here's the reformulation. I ended up choosing "Signalled" despite
the fact "signal" is heavily overloaded because nothing better struck
me. Alternatives would be welcome:
The Signalled Applications and Infrastructure Area develops protocols
and architectures for delay-sensitive interactive communications. Work
in this area serves an emerging industry whose applications and services
include voice and video over IP, instant messaging and presence.
The SAI Area is seeded with existing working groups from the Transport
and Applications Area: SIP, SIPPING, XCON, SIMPLE, GEOPRIV, ECRIT, ENUM,
IPTEL, MEGACO, MMUSIC, IEPREP, SPEECHSC, and SIGTRAN. A good rule of
thumb for the incorporation of new work into SAI, as opposed to
Transport or Applications, is that it relates to applications which require
a set-up phase prior to the start of interactive communications.
For example, work might relate to presence services, to
session signaling protocols and emergency call routing solutions, or to
work on the "layer five" issues for Internet telephony.
Like all areas of the IETF, the SAI Area draws on the work of numerous
other areas, and as such there can be no neat mathematical boundaries
delineating SAI's work from the rest of the IETF. The new area will
allow an existing community within the IETF to solidify its vision and
to benefit from increased institutional support.
This is just my personal reformulation, by the way, with no hats on.
regards,
Ted Hardie
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf