ETS applicability, was Re: proposed charter

In the long term, ETS as an umbrella term (and stressing the term  
Service) can be applied to applications other than voice.  in  
rfc-3689 (General Requirements for ETS), we state the following under  
the Problem section (The key item being the first sentence)

    A subsequent problem is to ensure that requirements associated with
    potential support is not focused just on IP telephony applications.
    The I-Am-Alive (IAA) database system is an example of an ETS type
    application used in Japan that supports both signaled and non-
    signaled access by users [10].  It is a distributed database system
    that provides registration, querying, and reply primitives to
    participants during times of an emergency (e.g., an earthquake) so
    that others can make an after-the-event determination about the
    status of a person.  In this case, a separate signaling protocol  
like
    SIP is not always required to establish or maintain a connection.

    Given the case where signaling is optional, requirements and
    subsequent solutions that address these problems must not assume the
    existence of signaling and must be able to support applications that
    only have labels in data packets.  These label(s) may be in various
    places, such as the application or IP header.

the low hanging fruit and the immediate attention for some users/ 
clients of ETS is voice in the context of IP, given that that there  
are deployed systems like GETS in the PSTN world which need to be  
bridged and eventually migrated to the IP world.  But this immediate  
attention shouldn't confuse others into thinking that ETS exclusively  
= voice.

-ken