Re: [Ecrit] draft-tschofenig-ecrit-xmpp-es-00.txt comments

Bernard Aboba <bernard_aboba@hotmail.com> Sat, 17 March 2012 18:54 UTC

Return-Path: <bernard_aboba@hotmail.com>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FAB421F853D for <ecrit@ietfa.amsl.com>; Sat, 17 Mar 2012 11:54:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.66
X-Spam-Level:
X-Spam-Status: No, score=-101.66 tagged_above=-999 required=5 tests=[AWL=0.938, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YsPSwitDVrJJ for <ecrit@ietfa.amsl.com>; Sat, 17 Mar 2012 11:54:01 -0700 (PDT)
Received: from blu0-omc3-s21.blu0.hotmail.com (blu0-omc3-s21.blu0.hotmail.com [65.55.116.96]) by ietfa.amsl.com (Postfix) with ESMTP id 26C3921F8513 for <ecrit@ietf.org>; Sat, 17 Mar 2012 11:54:01 -0700 (PDT)
Received: from BLU169-W20 ([65.55.116.72]) by blu0-omc3-s21.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 17 Mar 2012 11:54:00 -0700
Message-ID: <BLU169-W2042D8EBDB71E5A15AFE90935C0@phx.gbl>
Content-Type: multipart/alternative; boundary="_4085dbb0-dc47-4929-81ac-8c6474f19363_"
X-Originating-IP: [99.32.177.175]
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: gunnar.hellstrom@omnitor.se, ecrit@ietf.org
Date: Sat, 17 Mar 2012 11:54:00 -0700
Importance: Normal
In-Reply-To: <4F603743.7030002@omnitor.se>
References: <20120305201639.24006.81528.idtracker@ietfa.amsl.com>, <4F603743.7030002@omnitor.se>
MIME-Version: 1.0
X-OriginalArrivalTime: 17 Mar 2012 18:54:00.0794 (UTC) FILETIME=[50D9BBA0:01CD046F]
Subject: Re: [Ecrit] draft-tschofenig-ecrit-xmpp-es-00.txt comments
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ecrit>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 17 Mar 2012 18:54:02 -0000




One question I have is whether we are talking about XMPP Instant Messaging, or MUC (XEP-045) or some mixture of both. The draft currently doesn't mention MUC, but one can imagine a per-incident chat room.  

There are several ways that MUC could be used.  For example, contact between the user and PSAP might be via IM,;  however, caller and dispatcher messages could also be forwarded to an MUC within the PSAP where police, fire and medical could provide information to the dispatcher.  Alternatively, the caller might actually be placed into a per-incident MUC. 

Date: Wed, 14 Mar 2012 07:14:27 +0100
From: gunnar.hellstrom@omnitor.se
To: ecrit@ietf.org; Hannes.Tschofenig@gmx.net
Subject: [Ecrit] draft-tschofenig-ecrit-xmpp-es-00.txt   comments


  


    
  
  
    Hannes and all,

    It is good that this draft is published.

    

    Whatever architecture is decided for handling of XMPP in emergency
    services, conversion outside or bring it in, it is important to
    collect information on what factors shall be considered and what
    problems to solve. 

    

    I have made some mainly editorial comments that I send in a
    changemarked copy to you, Hannes.

    

    Here, I just want to comment that I suggest to include a section
    about session handling as well.

    

    A starting proposal:

---------------------------------------------------------------------------------------------------------------

    
    
    4.9  Sessions versus Messaging in Emergency Communication
     
    Emergency case handling is currently handled in sessions by the call takers.
In most cases it is most efficient if the same call taker can handle the call 
and any subsequent calls back, so that the detailed knowledge of the case is maintained. 
    XMPP messaging sessions are often not ended by any specific signaling indicating 
the end of a session. This causes a need to artificially create an end of a session,
 so that human and technical resources can be released.
    It also creates a need to keep messages together in the session even when the user
 is travelling and moves between PSAP areas during the session.
     
    There is thus a need to create a method for a pseudo-session management of XMPP messages,
 influencing the routing and linking to emergency case.     

    
    
    
    
    
    
    __________________________________________________________________________

    

    /Gunnar

    

    internet-drafts@ietf.org skrev 2012-03-05 21:16:
    
      A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Emergency Services Functionality with the Extensible Messaging and Presence Protocol (XMPP)
	Author(s)       : Hannes Tschofenig
	Filename        : draft-tschofenig-ecrit-xmpp-es-00.txt
	Pages           : 17
	Date            : 2012-03-05

   The Extensible Messaging and Presence Protocol (XMPP) is a technology
   that enjoys widespread deployment in the instant messaging
   application domain.  While many features for XMPP had been
   standardized in the IETF as well as in the XMPP Standards Foundation
   emergency services functionality was not part of it.

   This document aims to initiate a discussion about the necessary
   emergency services functionality for XMPP.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-tschofenig-ecrit-xmpp-es-00.txt

    
  


_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit