DRAFT Meeting Notes from the EM-TC Meeting s2

Draft Meeting Notes from the EM CAP-Profile SC Telecon Meeting

Date: January 13, 2009 11:00 AM EST

A quorum was in attendance.

1 Attendance

Sukumar Dwarkanath Rex Brooks Art Botterell Elysa Jones Jacob Westfall Bill Kalin Gary Ham Chris Springer Tom Ferrentino Fei Yang (Observer) TCS

2 Note taker appointed Rex Brooks will take notes.

3 Meeting Notes Approved: 1/132008, Meeting Notes approved by Art approved seconded by Gary Ham.

4 Tables Discussion – Discussion  Section head CAP IPAWS requirements....wants to change requirements from to IPAWS v1.1 Profile (Normative). Everyone is in agreement.  Expend with the blue higlighting- Remove  Sent –OK  Status – OK  Source – Meant for Public? Any element in the CAP standard may be publicly presentable. Suggesting diffetrent language “Implementors be aware that source may by publicly presented as asigniture line”  Scope – OK  Info element – Multiple sentences in specifications in notes they will be numbered.  ResponseType – Add “All Clear” as second response type”? Have not seen a requirement raised immediately. Something the systems have not required as yet.Sukumar is concerned in making an exception to CAP 1.1. 481 . . It is not a revision of the specification. 482 . . Gary mentions needing a profile note to explain it. Users of this profile will have to be aware that messages may not operate on all CAP networks, may restrict its use on other CAP networks also”. Exception to the standard. Art – Add aprofile note that says “This maay require amdified use of the schema to avoind validation errors”. Gary – “In netwrks that do not use a modified schema this message may not pass” “May not validate unless a modified schema is used”. 483 . . All of this is to make sure CMAS is passed. Art – mentions possible using an errata in changing the spec. Jacob did some research and an errata will not work in this case. We do not want to go to a 1.2 becasue it has to go in before the profile (can take a year to approve). 484 . . Gary – Add aprofile note that “We anticipate adding ‘Avoid’ to Response Type in CAP 1.2”. 485 . . Art – By definition IPAWS is more than EAS 486 . . Jacob –Can we make a custom parameter for CMAS? 487 . . Art –Difficult is an additonal enumerated XML field will cause XML to invalidate against the schema. 488 . . Chris – set aside for the moment and go ahead with appropriate language. Do not think it should it be recognized exception to the standard. 489 . . General acception - “Profile specification column is ‘normative’ – Profile note column is ‘non-normative’.”  Event Code – OK  Effective - OK  OnSet – OK  Expires OK  Parameter – Add “Other eventCode elements may also be present”. To the end of parameter notes. This is a fourth element in Profile Specification. 4131 . . Hazcollect does not use the parameter field. Gary does not know how it is programmed within Hazcollect itself. It may be in a table designed by the weather service. 4132 . . Gary needs to find out from the NWS programmers. 4133 . . Art – What can we do today to not hold up the process – Gary – Leave it the way it is and take a note that we need to check it out. 4134 . . Gary – Should not get rejected because NWS does not use the parameter field. 4135 . . Chris – Station ID is not included in this 4136 . . Jacob –Why the difference in the name CMAM vs CMAS 4.13.6.1 Art – CMAM- Commercial Mobile Alert Message 4.13.6.2 Sukumar – Leave the CMAS text requirement as is.  Resource Description – 4141 . . Art – Changing the labels by combining several labels. Should we add boroadcast content? 4142 . . Rex – Is it possible to be used in CMAS or Hazcollect? 4143 . . Jacob – The format may be specific to EAS so leave as is. 4144 . . EAS Industry group has not have dealt with the possiblity of vido or imagery. Are they using audo-audio or audio streaming values to understand what is in the resource attachment? 4145 . . Rex –You should be able to tell in the mimetype structure. This should tell you the type of file that is being sent. 4146 . . Jacob – Add a note that the specific type of content is added to the mimetype according to the current CAP 1.1 specification. 4147 . . Art - or returned comments and then -Note for our own purposes that we note the mime type values once the specification is finalized.  Mimetype – OK  Area – OK  Geocode 4171 . . Suggest we take the 5 digit comment in the specification and add it tothe note section. 4172 . . Jacob – Include normative and non-normative content into the profile. 4.17.2.1 Rex – Bring it forward and we have yet to hear of any specifics. 4.17.2.2 Chris – There are notes in section five that informs the implementor what to expect in section six. 4.17.2.3 Chris suggests there are other non-normative information that needs to be noted that may limit CAP. 4.17.2.4 Rex – Two process contraaints – What are the specifics? Afraid that OASIS is asked to take responsibility of something that is not OASIS work product. 4.17.2.5 Jacob - Material in question was delivered on December 12th 4.17.2.6 The OASIS profile should include all the reqirements necessary for the system to work for all available profiles 4.17.2.7 Rex – When we send out for public comment we are bound by our rues to address each comment that comes in. We need to keep track of every single one. 4.17.2.8 Chris - Reference FEMA publications in order to reference non-normative information. Suggest the string formating informs the implementor or the information is represented in the fields. 4.17.2.9 Rex – Place in references otherwise it would make the specification way too large. If someone wants to know how to use the profiles then they can look in the refeerences. 4.17.2.10 Art – Not practical to generalize every use case. 4.17.2.11 Gary - Referencable for other people’s use cases. 4.17.2.12 Encourage the IPAWS program to provide us with what we missed. 4.17.2.13 We can include table two explanations 4.17.2.14 We are looking to make sure the availalbe elements avaialble meets the profile. 4.17.2.15 Chris – FEMA needs to publish its own specifications manual. Hoping the OASIS process would help in publishing the non-normative and normative information. 4.17.2.16 Art – We do not want to be getting into non-normative information that is supposed to be normative. Encourage anyone who feels we missed anything that is imporatnt and bring it forward. 4.17.2.17 Rex – to Elysa that when we put it out for public comment that we state there will be motre information to be added. 4.17.2.18 Chris says this is a reasonable approach.  Gary has at least one change to the second table 4181 . . Erase somthing that is not really arestriction. Changed the documentation that you can use multiple geocodes in the same area. Erase the requirement under area for hazcollect.. The geocode requirement remains in place.  Rex motions that we vote on accepting the ammended document for sending out for public comment. 4191 . . Make sure that all updated notes have been added to the table.

5 Rex motioned to accept the current CAP v1.1 IPAWS Public Review Profile (v1.0) for public review…The motion was seconded by Elysa Jones followed by majority vote by the participating quorum.to accept Rex’s motion.

6 Moving Forward  Suggested we not have the profile sent to the TC in a normal specification or standard format. Elysa recommends sending the specification out in a tabular format similar the document we are currently working with.  The SC needs to present the profile to the TC for vote on sending out for public comment.

7 Meeting Adjourned.