New area description/name

Ted Hardie <hardie@qualcomm.com> Thu, 22 September 2005 19:32 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIWnr-0006AT-ER; Thu, 22 Sep 2005 15:32:19 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIWnq-00069i-E8 for ietf@megatron.ietf.org; Thu, 22 Sep 2005 15:32:18 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21703 for <ietf@ietf.org>; Thu, 22 Sep 2005 15:32:16 -0400 (EDT)
Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIWu5-0002Wz-S1 for ietf@ietf.org; Thu, 22 Sep 2005 15:38:48 -0400
Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8MJVwtC015470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf@ietf.org>; Thu, 22 Sep 2005 12:31:59 -0700 (PDT)
Received: from [192.168.1.4] (vpn-10-50-16-137.qualcomm.com [10.50.16.137]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8MJVtS3009007 for <ietf@ietf.org>; Thu, 22 Sep 2005 12:31:56 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p06230905bf58aaf41052@[192.168.1.4]>
Date: Thu, 22 Sep 2005 12:31:54 -0700
To: ietf@ietf.org
From: Ted Hardie <hardie@qualcomm.com>
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 31247fb3be228bb596db9127becad0bc
Subject: New area description/name
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

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@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf