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