Re: [earlywarning] Review of draft-rosen-atoca-cap

"Thomson, Martin" <> Wed, 21 July 2010 00:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 196A23A6A50 for <>; Tue, 20 Jul 2010 17:53:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.116
X-Spam-Status: No, score=-3.116 tagged_above=-999 required=5 tests=[AWL=-0.517, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eYMg29FdKb-3 for <>; Tue, 20 Jul 2010 17:53:38 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 26E833A6800 for <>; Tue, 20 Jul 2010 17:53:38 -0700 (PDT)
Received: from [] ([]:39117 "EHLO") by with ESMTP id S28245523Ab0GUAxv (ORCPT <rfc822;>); Tue, 20 Jul 2010 19:53:51 -0500
Received: from ( by ( with Microsoft SMTP Server (TLS) id 8.1.436.0; Tue, 20 Jul 2010 19:53:51 -0500
Received: from ([fe80::9d82:a492:85e3:a293]) by ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 21 Jul 2010 08:53:48 +0800
From: "Thomson, Martin" <>
To: Hannes Tschofenig <>
Date: Wed, 21 Jul 2010 08:55:57 +0800
Thread-Topic: [earlywarning] Review of draft-rosen-atoca-cap
Thread-Index: AcsoBiaW5ecTkeWrSbqn6yOjEe8wRwAaDMdQ
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-BCN: Meridius 1000 Version 3.4 on
Cc: "Rosen, Brian" <>, "Tschofenig, Hannes \(NSN - FI/Espoo\)" <>, "" <>
Subject: Re: [earlywarning] Review of draft-rosen-atoca-cap
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 21 Jul 2010 00:53:39 -0000

Thanks for taking the time Hannes,

I really wanted to highlight what I thought needed work.  We're obviously still at a very early stage in this work.

> The first challenge we ran into was the lack of a definition of alerts.
> We tried to put a list of alert types in
> (see
> Section 6.1) but faced a lot of resistance on the mailing list (see
> archive/web/earlywarning/current/msg00130.html).
> Before this aspect is addressed it is a bit difficult to say whether
> filters, service URNs, resource lists, etc. are the right approach.

The alternative is tougher, but potentially more robust.  You have a single service with no associated taxonomy: urn:service:warning

The results of a query on this service returns all applicable services for the area.  Each contains a description.  The user chooses the warning services based on these descriptions.

There are costs, but it avoids the sticky taxonomy problem.

Another approach is to allow for services to be identified with proprietary URI identifiers.  These generic identifiers could be discovered using out-of-band means (side of bus, web search).  Then LoST doesn't come into it at all, SIP routing (possibly location-based) does all the hard work.  It's probably not-cool if we don't use LoST though.