OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Comments on IPAWS Profile spreadsheet


Comments on the IPAWS Profile spreadsheet dated 20 January 2009.

 

I'm glad to see the EM-TC is considering all the current Profiles in constructing the IPAWS Profile.  Hopefully a way can be found for one single CAP message to satisfy all of these CAP Profiles.  That has been a vision of mine since day one.

I didn't identify any major issues, so my comments are somewhat esoteric, but I thought I'd forward my obervations for your review anyway, trivial though they may be.

I'm not really sure if this spreadsheet is a pivotal document and thus should include all the minutias I identify below, or if the spreadsheet is just a minor intermediate point on the way to an integrated Profile and thus does not need to be as complete as I am alluding to.

So please take my comments for whatever value they carry.

Gary Timm

 

Spreadsheet 1:

 

Scope element: (not in your spreadsheet), is there a restriction to “Public”, or are all these nuances not needed in this spreadsheet?

 

Info Block: You refer to multiple Info Blocks for different languages or area-specific details.

I am also on the FEMA IPAWS Practitioner Working Group (PWG), where FEMA circulated their version of the IPAWS Profile where it shows multiple Info Blocks, one for each Exchange Partner.  These two uses seem to conflict, but I presume this is being worked out.

 

ResponseType element: You refer to a value of “Avoid”.  This is not a CAP Standard recognized value, as you point out.  I just listened to a presentation by the NIMS Support Center, which will be testing IPAWS EAS boxes for CAP conformance, and they stated that all messages “must be valid against a CAPv1.1 applied schema”.  It would seem a message with “Avoid” as a value should be rejected by all systems honoring the CAP Standard.

 

U/S/C elements: (not in your spreadsheet) Are you making no references to these elements in regard to EAS test codes, as ECIG did?

 

Parameter element EAS-ORG: You state it is required for HazCollect.  Is this something new?  This requirement is not listed for HazCollect on your next spreadsheet which is supposed to list all HazCollect restrictions.  Last I knew, the NWS CRS system assumed ORG = CIV on all NWEM messages.

 

Parameter element EAS-STN-ID: (not in your spreadsheet) I presume you intended to drop this ECIG-recommended element?

 

MimeType element: The audio file formats you list are not Mime Types, so appear to not belong listed under this element.  The CAP Standard refers to the webpage: www.iana.org/assignments/media-types/, which does not list MP3 or WAV as valid values.

 

 

Spreadsheet 2:

 

I’m not sure why the proposed IPAWS Profile itself is not listed in a column here, in addition to, or instead of, the ECIG Profile.  The ECIG Profile is really an interim document.  The proposed IPAWS Profile is what matters.

 

Note that I did not have access to the latest HazCollect document, so some of my HazCollect comments may no longer be germane, but I included them for your reference so you can check on them.

 

Sender element: (not in your spreadsheet) HazCollect should say this element must be the COG Name.

 

Status element: HazCollect should say “Draft” not allowed, if not “Actual”, adds text “Do not take action”.

 

Scope element: ECIG should say must be “Public” or system will Ignore.

 

Note element: ECIG should be reworded to say: If msgType is “Ack”, should include “Accepted:” or “Aired on:” plus station call sign.  If msgType is Error”, should include “Error:” or “Ignored:”.  [That is, Ignored goes with Error, not Ack.]

Actually, the Note element is part of the optional use of Ack and Error messages.  I wonder if this reference should be here at all, since these are optional uses.  For if Note is here, then Reference should be as well.  There are other ECIG required-if-used elements which are not listed as well, so it seems this isolated optional Note element is maybe out of place.

 

Response Type element: Same comment as above regarding the use of value “Avoid”.  Its use would mean non-conformance to the NIMS SC.

 

SenderName element: (not in your spreadsheet) HazCollect should say must be COG Name, city, and state.

 

Headline element: (not in your spreadsheet) HazCollect should say 160 characters maximum.

 

Description and Instruction elements: (not in your spreadsheet) HazCollect should say Description + Instruction must be 160 characters maximum.

 

MimeType element: Same comment as above.  The audio file formats listed are not Mime Types.

 

AreaDesc element: (not in your spreadsheet) HazCollect should say is administrative name corresponding to Geocode.

 

God Speed in your work,

 

Gary Timm, Broadcast Chair

Wisconsin EAS Committee (SECC)

 

Member of ECIG, as Group Facilitator

 

Member of FEMA IPAWS Practitioner Working Group (PWG)

 

Member of SBE (Society of Broadcast Engineers) EAS Committee

 

The comments above are my own, and do not represent the views of any of the above groups to which I belong.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]