Re: [earlywarning] Commentson draft-schulzrinne-atoca-requirements-00

"Carl Reed" <creed@opengeospatial.org> Wed, 21 July 2010 21:24 UTC

Return-Path: <creed@opengeospatial.org>
X-Original-To: earlywarning@core3.amsl.com
Delivered-To: earlywarning@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AB853A6B4A for <earlywarning@core3.amsl.com>; Wed, 21 Jul 2010 14:24:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlHGNxwbdHAs for <earlywarning@core3.amsl.com>; Wed, 21 Jul 2010 14:24:13 -0700 (PDT)
Received: from mail.opengeospatial.org (mail.opengeospatial.org [66.244.86.40]) by core3.amsl.com (Postfix) with ESMTP id E4A693A6BBE for <earlywarning@ietf.org>; Wed, 21 Jul 2010 14:24:12 -0700 (PDT)
Received: from CarlandSusieOf (c-76-25-20-162.hsd1.co.comcast.net [76.25.20.162]) (authenticated bits=0) by mail.opengeospatial.org (8.13.8/8.13.8/Debian-3+etch1) with ESMTP id o6LLOKsU008256; Wed, 21 Jul 2010 17:24:21 -0400
Message-ID: <D532D938AA9C4A128CC1AECB1306656F@CarlandSusieOf>
From: "Carl Reed" <creed@opengeospatial.org>
To: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>, <trutkowski@netmagic.com>
References: <8B0A9FCBB9832F43971E38010638454F03E9DCD3B0@SISPE7MB1.commscope.com><4C403CFE.4020208@netmagic.com><4C45EBEE.9030509@gmx.net> <F9031BD2FE7842C3BECA24AD5BB02B40@CarlandSusieOf> <20100720203818.286440@gmx.net>
In-Reply-To: <20100720203818.286440@gmx.net>
Date: Wed, 21 Jul 2010 15:23:55 -0600
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_03F6_01CB28E8.BBD91180"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6000.16480
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
X-Virus-Scanned: clamav-milter 0.95.3 at mail
X-Virus-Status: Clean
Cc: hannes.tschofenig@nsn.com, earlywarning@ietf.org
Subject: Re: [earlywarning] Commentson draft-schulzrinne-atoca-requirements-00
X-BeenThere: earlywarning@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " <earlywarning.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/earlywarning>, <mailto:earlywarning-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/earlywarning>
List-Post: <mailto:earlywarning@ietf.org>
List-Help: <mailto:earlywarning-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/earlywarning>, <mailto:earlywarning-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Jul 2010 21:24:14 -0000

The requirements document is attached.

Regards

Carl

----- Original Message ----- 
From: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
To: "Carl Reed" <creed@opengeospatial.org>rg>; <trutkowski@netmagic.com>
Cc: <earlywarning@ietf.org>rg>; <hannes.tschofenig@nsn.com>
Sent: Tuesday, July 20, 2010 2:38 PM
Subject: Re: [earlywarning] Commentson 
draft-schulzrinne-atoca-requirements-00


> Good to hear that CAP 2.0 will include a GML profile.
> What location shapes are going to be supported? We ran into this issue in 
> ECRIT.
>
> -------- Original-Nachricht --------
>> Datum: Tue, 20 Jul 2010 14:33:05 -0600
>> Von: "Carl Reed" <creed@opengeospatial.org>
>> An: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>et>, 
>> trutkowski@netmagic.com
>> CC: "Tschofenig, Hannes \\(NSN - FI/Espoo\\)" 
>> <hannes.tschofenig@nsn.com>om>, earlywarning@ietf.org
>> Betreff: Re: [earlywarning] Commentson 
>> draft-schulzrinne-atoca-requirements-00
>
>> Correct -
>>
>> CAP is a payload and is (theoretically) transport agnostic. FYI, CAP 2.0
>> will incorporate a GML profile that will include the same geometry types
>> (plus additional ones) as the LO GML Geoshape Application Schema.  The 
>> only
>> issue is that the OASIS GML "where" profile will use GML 3.2.1 to be
>> consistent with the ISO version of GML and the LO Geoshape schema uses 
>> GML 3.1.1.
>>
>> Cheers
>>
>> Carl
>> an OASIS CAP contributor
>>   ----- Original Message ----- 
>>   From: Hannes Tschofenig
>>   To: trutkowski@netmagic.com
>>   Cc: earlywarning@ietf.org ; Tschofenig,Hannes (NSN - FI/Espoo)
>>   Sent: Tuesday, July 20, 2010 12:33 PM
>>   Subject: Re: [earlywarning] Commentson
>> draft-schulzrinne-atoca-requirements-00
>>
>>
>>   Hi Tony,
>>
>>   thanks for pointing to the CAP Implementer's workshop and in particular
>> the "Draft Implementors Note on Harmonizing Certain Identifiers in CAP
>> Implementations"
>> http://www.wmo.int/pages/prog/www/ISS/Meetings/WIS-CAP_Geneva2009/DraftNote.doc.
>>
>>   My understanding of that document (and my participation at an earlier
>> workshop) is there is room for improvement in the CAP specification from 
>> an
>> interoperability point of view.
>>
>>   Since the work in this group only focuses on the transport of alerts
>> rather than the actual content of the alerts we should not be impacted.
>>
>>   Ciao
>>   Hannes
>>
>>   On 16.07.2010 13:05, Tony Rutkowski wrote:
>>      Hi Martin,
>>
>>     You might also consider the concepts on architecture
>>     and identity constructs that emerged from last year's
>>     global gathering of emergency messaging authorities
>>     convened at the World Meteorological Organization.
>>
>> http://www.wmo.int/pages/prog/www/ISS/Meetings/WIS-CAP_Geneva2009/DocPlan.html
>>
>>     See especially the Draft Implementors Note.
>>
>>     best,
>>     tony
>>
>>
>>       I'm currently unsure about the value of this document.  The
>> different components of the document are somewhat disjointed: problem 
>> statement,
>> architectural model, and requirements don't support each other 
>> particularly
>> well.
>>
>>       General Comments:
>>
>>       This model presented in this document is highly abstract.  Without 
>> a
>> more concrete relationship with the requirements, it's hard to understand
>> the value of the model.  Section 3 looks too much like a copy-and-paste
>> from the email architecture.
>>
>>       A simpler model might be a better starting point:
>>          author [1..*] ->  [1] aggregator [1] ->  [1..*] recipient
>>
>>       Such a model can be evolved to involve relays or mediators by
>> overlapping and chaining roles, just as we do for the GEOPRIV model. 
>> Nothing
>> wrong with giving these entities names and descriptions, but they can 
>> form
>> part of a second architectural layer.
>>
>>
>>
>>     _______________________________________________
>>     earlywarning mailing list
>>     earlywarning@ietf.org
>>     https://www.ietf.org/mailman/listinfo/earlywarning
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
>>   _______________________________________________
>>   earlywarning mailing list
>>   earlywarning@ietf.org
>>   https://www.ietf.org/mailman/listinfo/earlywarning
>