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
- [Ecrit] draft-tschofenig-ecrit-xmpp-es-00.txt com… Gunnar Hellström
- Re: [Ecrit] draft-tschofenig-ecrit-xmpp-es-00.txt… Bernard Aboba