[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: RESEND-Add "Avoid" in "responseType"
I'm forwarding this from the emergency-comment list. Cheers, Rex >I am resending the letter in its entirely, as the original didn't have the >chart attached. I have also made some some minor edits. >I wanted to be sure the "archive" contained the entire proposal. >(Thanks to Rex Brooks for forwarding the material.) > > > > > >650 Massachusetts Ave, N.W. 6th Floor > >Washington, DC 20001 > > > >November 25, 2008 > > >OASIS Emergency Management Technical Committee (EM TC) >Organization for the Advancement of Structured Information Standards > >Dear Committee Members: > > >This letter is to inform you, as the appropriate >entity of OASIS overseeing the development of >the Common Alerting Protocol standard, of a >proposal adopted by the Commercial Mobile Alert >Advisory Committee to add "Avoid" to the current >code values for the element "ResponseType" for >the purpose of creating text messages under the >Commercial Mobile Alert System. (A copy of the >relevant portion of the meeting transcript is >attached.) >I would encourage you to take action to include >this change to the CAP standard and register it >as part of the standard going forward. >I was privileged to serve as a member of the >Commercial Mobile Alert Advisory Committee >established by the FCC, pursuant to section 603 >of the Warning, Alert and Response Network Act >(WARN Act). >The purpose of the Advisory Committee was to >advise the FCC on technical standards and >protocols to enable commercial mobile service >providers to voluntarily transmit emergency >alerts to their subscribers when an incident >occurs. >The committee, and the "User Needs" subgroup, on >which I served, spent considerable time and >effort analyzing what would constitute an >effective text alert. The Advisory Committee >recommended and the FCC ultimately embraced a >proposed architecture and standards for >delivering alerts to the public using Common >Alerting Protocol (CAP). >Any alert initiator must use CAP as the basic >alerting protocol that would be sent to an alert >gateway/aggregator. The alert gateway would then >create text messages, which, at least initially, >would have a technical limit of 90 characters of >text. >The scenario for nominal text in a CMAS Alert >was in section 4.1.1 of the Advisory Committee's >recommendation: >When an event occurs, the local alert initiator >would use CAP to create an alert, which would >then be sent to an alert gateway/aggregator. >The appropriate government entity performing >that role will be FEMA who would then create and >issue a text based CMA to warn the CMSP >subscribers within the indicated alerting area." >The procedure for generating a CMAM from CAP >fields is in section 5.3.2 of the Committee's >report: >"For initial CMAS system deployment and until >Alert Initiators are trained in the generation >of CMAM, in order to create consistent and >accurate CMAMs, the CMSAAC recommends that the >Alert Gateway 'construct' the CMAM using >selected required and optional fields in the CAP >message." >The Committee recommended that the alert's >recommended action to be taken be constructed >from the optional "ResponseType" CAP field. >The Committee further recommended, "that a >process be developed by which new ResponseType >Codes can be developed and registered." >We recognized that "generating CMAM using CAP >fields may not provide flexibilityŠto tailor the >CMAM content to a specific alert event," and >that the CMAM "may not be very meaningful to the >end user." >The Committee's report points to the "recent >steam pipe explosion in New York City" as an >example where a CMAM automatically generated >CMAM under the current CAP standard would not >have provided enough meaningful information. >The Committee was concerned about not addressing >adequately in the current CAP standard enough >recommended actions that might be proposed to >elicit an appropriate response to potential >hazards. Members of our subgroup, and ultimately >the full advisory group, wanted to assure that >the constructed text stream options could more >fully address incidents like the steam pipe >explosions or the terrorist attacks of 9-11 in >New York City. >To better respond to such situations we proposed >to add, "Avoid" to the current code values for >the element "ResponseType" of the CAP 1.1 >standard. The Commercial Mobile Alert Advisory >Committee supported this change without >opposition. While the Advisory Committee decided >that this new code value should be added, we >recognized, that neither we, nor the FCC had the >authority to change the CAP standard. >During the adoption of this proposal by the >Advisory Group, an amendment was offered to >better clarify the text stream that would be >constructed as a result of "Avoid" filling the >optional "responseType" field. The amendment >proposed was to add the word "hazard" making the >potential text "avoid hazard" which was >consistent with our effort to address all hazard >alerting. As with the other values, there >remained the option to include additional >recommendations in the <instruction> field, for >example, if the alert was warning about >dangerous food products the alert might >recommend to "avoid consuming." >If this recommendation were incorporated into >the CAP standard the 3.2.2 "info" Element and >Sub-elements chart would read as follows, (in >the same fashion as the other existing code >values): > >Element Name - responsetype >Context. Class. Attribute. Representation - cap. alertinfo. responseType. code >Definition and (Optionality) - The code denoting >the type of action recommended for the target >audience. (OPTIONAL) >Notes or Value Domain - >(1) Code Values: >"Shelter" - Take shelter in place or per <instruction> >"Evacuate" - Relocate as instructed in the <instruction> >"Avoid" - Avoid hazard or per <instruction> >"Prepare" - Make preparations per the <instruction> >"Execute" - Execute a pre-planned activity identified in <instruction> >"Monitor" - Attend to information sources as described in <instruction> >"Assess" - Evaluate the information in this >message. (This value SHOULD NOT be used in >public warning applications.) >"None" - No action recommended > >It is our hope that the appropriate standards >entity will adopt this proposal as part of the >CAP standard. > >Sincerely, > > > >Billy Pitts >Senior Vice President, Government Affairs >Blackboard Inc. > > > > > > > > ><ATTACHMENT> > >TRANSCRIPT OF FINAL MEETING (Abridged) > >The Commercial Mobile Service Alert Advisory Committee >October 3, 2007 >Next on my list is, Mr. Pitts, I have an amendment from you. >MR. PITTS: Yes, sir, Mr. Chairman. It should be >fairly straightforward. This one is only >essentially five letters. It's adding the word >avoid in the fields from which we would create >the automatic computer generated messages. As >Art alluded to, we had endless discussions about >concerns about the limitations and character >length of text messages, but we all tried to >live with it and tried to get these messages to >fit within that profile. >There was also concern over some messages being >computer generated where others were free text, >free form text. The Presidential alerts will be >free form text. The amber alerts will be free >form text, although I haven't really seen >examples of either one of them, but initially at >least as a default all other messages would be >computer generated from the existing CAP fields. >I think that there is a deficiency in the >response types to fill in the message from the >fields that are available to us. The current >fields are Shelter, Evacuate, Prepare, Execute >or Monitor. There is another one called Assess, >but we've decided not to include that. >My experience in some of the states with >evacuation, actually in some states the governor >doesn't even have the authority to do that so >there's some question about who would be able to >do evacuate. >The problem though that I think that we found >was if there is an area that you want people to >stay away from, to avoid, that we needed to >include that in the message. Again, this is not >free form text. This is computer generated so >that a message may say radiological hazard >warning in your area. Avoid. Or a nuclear power >plant warning in your area. Avoid. >We had had some discussion earlier about whether >or not the text string should say avoid area, >avoid incidence or avoid hazard. Personally I >like avoid hazard, but I was trying to keep the >number of characters down to a minimum, and I >was concerned about adding area in since in >these computer generated text messages we >already say in this area, and I did not want to >say then avoid area. >So the purpose of the amendment is to highlight >the need to add an additional value, >particularly in light of the all hazard warnings >that I anticipate coming, the word avoid, and to >include that in the computer generated text >string. >MR. MORAN: Thank you. Do we have a second on that? >MALE VOICE: Second. >MR. MORAN: Second? Okay. >Any discussion on Mr. Pitts' proposed amendment? Yes, Dave? >MR. WEBB: Yes, sir, Mr. Chairman. I do believe, >and I will have to defer to Mr. Botterell on >this for the exact thing, but these values are >all fields that are established within the CAP >standard. >FEMALE VOICE: Yes. >MR. WEBB: And by doing this amendment we would >in effect be modifying an OASIS standard that is >published for the whole world to use, and I'm >not sure that this -- while I agree that avoid >is a useful thing to have, I'm not sure we can >modify an international standard in this body. >MR. PITTS: Mr. Chairman, Billy Pitts. If I might >address that? I'd like to hear from Art. >I understand, and this is no way trying to >change the OASIS standard. This is an effort by >us as the committee advising the FCC that >something needs to be done here, that we need to >be a little more explicit in our responses, and >my hope would be that both the OASIS CAP >Standards Setting Group would look at this as >well as the FCC, but I think as a recommendation >we would be deficient in not pointing out the >need here. >MR. MORAN: Thank you. >Any other comments? Discussion? >MR. PREST: Yes. This is Art Prest. I totally agree with what Billy just said. >MR. MORAN: Okay. Any other discussion on the bridge? >MR. RUTKOWSKI: Mr. Chairman, Tony Rutkowski. >MR. MORAN: Yes? >MR. RUTKOWSKI: I was actually the acting >rapporteur for what is actually the >international standard, which is the IQT version >of CAP, and I tend to agree with the amendment, >but I would have one admonition that's generally >applicable to all of these is that in the >continuing international process for exchanging >information on these fields in going forward >that this information be shared with other >administrations. There's a standard mechanism >for doing that. >MR. MORAN: Okay. Thank you. Any other discussion? >MR. BOTTERELL: Mr. Chairman? >MR. MORAN: Yes? >MR. BOTTERELL: Art Botterell. In Section 5.3.2 >of the draft recommendation there is a provision >for the alert gateway adding event codes over >and above those specified either in the CAP or >in the older same event-coding scheme. >I think it was on this principle that the >attempt was being made to go ahead and add what >I think everyone agrees is a needed field. The >small difficulty that arises is that here we are >actually proposing an addition to the response >type enumeration rather than the event code, and >we have not really addressed that prior. >I'd like to offer what I hope will be accepted >as a friendly amendment in two parts. The first >would be that the text string associated with >this new response type value of avoid would be >avoid hazard, and this is really just for >clarity when you construct the whole string. We >don't want to say avoid area because then >everybody who gets the message in this area >thinks it applies to them. That's the best >wording we could come up with. >The second bit is that we add -- I guess there's >actually three bits. The second bit would be >that we add a footnote acknowledging that this >particular value is not currently supported in >the CAP specification, but that it will be added >for CMAS purposes until such time as OASIS can >rule on that as a change since we don't really >have a mechanism in the response field. >And then the third thing would just be to note, >and this is more of a process note. I think >since we already have just adopted an updated >tabulation provided by Brian that this would >really just be a one line change in the table as >most recently amended, the table for response >type, not an amendment of that entire table, so >that's a little complicated, but we can parse >it. MR. MORAN: Yes, Mr. Jones? >MR. JONES: Thank you. Gary Jones. I'd like to >support the change that Art is proposing in the >text string in changing it from avoid to avoid >hazard. >The committee laid out a structure for the >canned message and the order of the elements of >the message. Having the words avoid hazard seems >to fit better in the ordering of the message so >that it would have the event, the recommended >action -- excuse me. The event and then the >words in this area and then the recommended >action. >For instance, it might say a HAZMAT warning in >this area. Avoid hazard. The English seems to >flow a little bit better. Thank you. >MR. BOTTERELL: If I may add just one final aside >for the benefit of Mr. Rutkowski? >Tony, I think we'll have to discuss off-line >whether this would be something that OASIS >should take first and then take to ITU or >exactly how that harmonization would occur. >MR. RUTKOWSKI: I agree, but I think the point is >too this is for global interoperability >purposes. We need to exchange these field values >to allow global interoperability. >MR. BOTTERELL: Exactly. So I guess I would ask >Mr. Pitts if he would accept that as a friendly >amendment. >MR. PITTS: Yes, sir. I think they're very >constructive and worthwhile, and I would accept >it. >FEMALE VOICE: Thank you. >MR. MORAN: Mr. Botterell, your first of your >three suggestions is very clear. The second one >I'm not sure I caught it all and exactly what >you do. >MR. BOTTERELL: Yes. Let me see if I can dictate >it. This would be a footnote or an asterisk or a >note of some sort, whatever editorially works, >that would say: This value is recommended for >CMAS use only pending action by the responsible >standards body. >MR. WILLIAMS: Modification of CAP? >MR. BOTTERELL: Yes. Yes. The pending >modification of CAP. I don't want to posit that >they're going to do it, even though I'm fairly >confident they will. >MR. MORAN: Let me make sure I got your whole sentence there. >MR. BOTTERELL: Yes. >MR. MORAN: This value is recommended for CMAS use only pending action -- >MR. WILLIAMS: Modification of the CAP value. >MR. BOTTERELL: Pending inclusion into the CAP standard. How is that? >MR. MORAN: Pending inclusion into the CAP standard? >MR. BOTTERELL: Yes. Period. >MR. MORAN: Okay. And your third suggestion? >MR. BOTTERELL: Was really just that the scope of >this is really just adding one line to one >section in the table. >It's not a replacement of the entire table >because we just amended the order of the table >before and I don't want to blow that up, so >that's more an editorial note than an amendment >really. >MR. MORAN: Okay. Do we have a second on Mr. Botterell's proposed -- >MALE VOICE: Second. >MR. BOTTERELL: I think it's been accepted as a >friendly amendment, so do we have to -- >MR. MORAN: Okay. So it's been accepted. Okay. >Any more discussion on this proposed amendment? >MR. WEBB: Mr. Chairman, I would like to say >while we have just added this and it's a good >thing, I don't think the alert originator >software industry will build to this immediately >until -- I mean, this is something that would be >likely included in the gateway function, but as >far as an industry building to a standard it's >not yet a standard, so it may not come out in >originator software and be available for their >use. >MR. MORAN: Okay. >MR. BOTTERELL: I think that's right. The good >news is that it's entirely possible that OASIS >could deal with this in the time it's going to >take the FCC to deal with its part of the >rulemaking, but that's not a certainty by any >means. >MR. MORAN: Okay. Any further discussion here in the room on this issue? >(No response.) >MR. MORAN: Any further discussion on the bridge? >(No response.) >MR. MORAN: Okay. Let's vote on this. So we're >voting on the amendment with the friendly >amendment change to the amendment, so it's the >amendment as presented by Mr. Pitts. >On the second page under What Action Should Be >Taken under Text Stream next to avoid it will >say "avoid hazard" on the text stream, and we >would put a footnote somewhere that says: This >value is recommended for CMAS use only pending >inclusion into the CAP standard. >Okay. Let's have a vote here in the room. All >who favor this amendment raise your hand. >(Whereupon, a showing of hands.) >MR. MORAN: We have that. Thank you. >All who are opposed, raise your hand. >(No response.) >MR. MORAN: Any abstentions? >(Whereupon, a showing of hands.) >MR. MORAN: Okay. Sue, what is the count for the bridge? >MS. GILGENBACH: Thirty yes, zero no, one abstain. >MR. MORAN: Thank you. Okay. We'll go to the bridge here. >Mr. Ban? >MR. BAN: Yes. >MR. MORAN: Ms. Brooks? >MS. BROOKS: Yes. >MR. MORAN: Ms. Dunn-Tutor? >MS. DUNN-TUTOR: Yes. >MR. MORAN: Mr. Lyon? >MR. LYON: Yes. >MR. MORAN: Mr. McGinnis? >MR. McGINNIS: Yes. >MR. MORAN: Mr. Prest? >MR. PREST: Yes. >MR. MORAN: Mr. Roberts? >MR. ROBERTS: Yes. >MR. MORAN: Mr. Rutkowski? >MR. RUTKOWSKI: Yes. >MR. MORAN: Mr. Wilcock? >MR. WILCOCK: Yes. >MR. MORAN: Mr. Gehman? >MR. GEHMAN: Yes. >MR. MORAN: Okay. That amendment passes. > >? > >I am resending the letter in its entirely, as the original didn't have the >chart attached. I have also made some some minor edits. >I wanted to be sure the "archive" contained the entire proposal. >(Thanks to Rex Brooks for forwarding the material.) > > >650 Massachusetts Ave, N.W. 6th Floor > >Washington, DC 20001 > >November 25, 2008 > >OASIS Emergency Management Technical Committee (EM TC) > >Organization for the Advancement of Structured Information Standards > >Dear Committee Members: > >This letter is to inform you, as the appropriate >entity of OASIS overseeing the development of >the Common Alerting Protocol standard, of a >proposal adopted by the Commercial Mobile Alert >Advisory Committee to add "Avoid" to the current >code values for the element "ResponseType" for >the purpose of creating text messages under the >Commercial Mobile Alert System. (A copy of the >relevant portion of the meeting transcript is >attached.) >I would encourage you to take action to include >this change to the CAP standard and register it >as part of the standard going forward. >I was privileged to serve as a member of the >Commercial Mobile Alert Advisory Committee >established by the FCC, pursuant to section 603 >of the Warning, Alert and Response Network Act >(WARN Act). >The purpose of the Advisory Committee was to >advise the FCC on technical standards and >protocols to enable commercial mobile service >providers to voluntarily transmit emergency >alerts to their subscribers when an incident >occurs. >The committee, and the "User Needs" subgroup, on >which I served, spent considerable time and >effort analyzing what would constitute an >effective text alert. The Advisory Committee >recommended and the FCC ultimately embraced a >proposed architecture and standards for >delivering alerts to the public using Common >Alerting Protocol (CAP). >Any alert initiator must use CAP as the basic >alerting protocol that would be sent to an alert >gateway/aggregator. The alert gateway would then >create text messages, which, at least initially, >would have a technical limit of 90 characters of >text. >The scenario for nominal text in a CMAS Alert >was in section 4.1.1 of the Advisory Committee's >recommendation: >When an event occurs, the local alert initiator >would use CAP to create an alert, which would >then be sent to an alert gateway/aggregator. The >appropriate government entity performing that >role will be FEMA who would then create and >issue a text based CMA to warn the CMSP >subscribers within the indicated alerting area." >The procedure for generating a CMAM from CAP >fields is in section 5.3.2 of the Committee's >report: >"For initial CMAS system deployment and until >Alert Initiators are trained in the generation >of CMAM, in order to create consistent and >accurate CMAMs, the CMSAAC recommends that the >Alert Gateway 'construct' the CMAM using >selected required and optional fields in the CAP >message." >The Committee recommended that the alert's >recommended action to be taken be constructed >from the optional "ResponseType" CAP field. >The Committee further recommended, "that a >process be developed by which new ResponseType >Codes can be developed and registered." >We recognized that "generating CMAM using CAP >fields may not provide flexibilityŠto tailor the >CMAM content to a specific alert event," and >that the CMAM "may not be very meaningful to the >end user." >The Committee's report points to the "recent >steam pipe explosion in New York City" as an >example where a CMAM automatically generated >CMAM under the current CAP standard would not >have provided enough meaningful information. >The Committee was concerned about not addressing >adequately in the current CAP standard enough >recommended actions that might be proposed to >elicit an appropriate response to potential >hazards. Members of our subgroup, and ultimately >the full advisory group, wanted to assure that >the constructed text stream options could more >fully address incidents like the steam pipe >explosions or the terrorist attacks of 9-11 in >New York City. >To better respond to such situations we proposed >to add, "Avoid" to the current code values for >the element "ResponseType" of the CAP 1.1 >standard. The Commercial Mobile Alert Advisory >Committee supported this change without >opposition. While the Advisory Committee decided >that this new code value should be added, we >recognized, that neither we, nor the FCC had the >authority to change the CAP standard. >During the adoption of this proposal by the >Advisory Group, an amendment was offered to >better clarify the text stream that would be >constructed as a result of "Avoid" filling the >optional "responseType" field. The amendment >proposed was to add the word "hazard" making the >potential text "avoid hazard" which was >consistent with our effort to address all hazard >alerting. As with the other values, there >remained the option to include additional >recommendations in the <instruction> field, for >example, if the alert was warning about >dangerous food products the alert might >recommend to "avoid consuming." > >If this recommendation were incorporated into >the CAP standard the 3.2.2 "info" Element and >Sub-elements chart would read as follows, (in >the same fashion as the other existing code >values): > >Element Name - responsetype >Context. Class. Attribute. Representation - cap. alertinfo. responseType. code >Definition and (Optionality) - The code denoting >the type of action recommended for the target >audience. (OPTIONAL) >Notes or Value Domain - >(1) Code Values: >"Shelter" - Take shelter in place or per <instruction> >"Evacuate" - Relocate as instructed in the <instruction> >"Avoid" - Avoid hazard or per <instruction> >"Prepare" - Make preparations per the <instruction> >"Execute" - Execute a pre-planned activity identified in <instruction> >"Monitor" - Attend to information sources as described in <instruction> >"Assess" - Evaluate the information in this >message. (This value SHOULD NOT be used in >public warning applications.) >"None" - No action recommended >It is our hope that the appropriate standards >entity will adopt this proposal as part of the >CAP standard. > >Sincerely, > >Billy Pitts > >Senior Vice President, Government Affairs > >Blackboard Inc. > ><ATTACHMENT> > >TRANSCRIPT OF FINAL MEETING (Abridged) > >The Commercial Mobile Service Alert Advisory Committee >October 3, 2007 >Next on my list is, Mr. Pitts, I have an amendment from you. >MR. PITTS: Yes, sir, Mr. Chairman. It should be >fairly straightforward. This one is only >essentially five letters. It's adding the word >avoid in the fields from which we would create >the automatic computer generated messages. As >Art alluded to, we had endless discussions about >concerns about the limitations and character >length of text messages, but we all tried to >live with it and tried to get these messages to >fit within that profile. >There was also concern over some messages being >computer generated where others were free text, >free form text. The Presidential alerts will be >free form text. The amber alerts will be free >form text, although I haven't really seen >examples of either one of them, but initially at >least as a default all other messages would be >computer generated from the existing CAP fields. >I think that there is a deficiency in the >response types to fill in the message from the >fields that are available to us. The current >fields are Shelter, Evacuate, Prepare, Execute >or Monitor. There is another one called Assess, >but we've decided not to include that. >My experience in some of the states with >evacuation, actually in some states the governor >doesn't even have the authority to do that so >there's some question about who would be able to >do evacuate. >The problem though that I think that we found >was if there is an area that you want people to >stay away from, to avoid, that we needed to >include that in the message. Again, this is not >free form text. This is computer generated so >that a message may say radiological hazard >warning in your area. Avoid. Or a nuclear power >plant warning in your area. Avoid. >We had had some discussion earlier about whether >or not the text string should say avoid area, >avoid incidence or avoid hazard. Personally I >like avoid hazard, but I was trying to keep the >number of characters down to a minimum, and I >was concerned about adding area in since in >these computer generated text messages we >already say in this area, and I did not want to >say then avoid area. >So the purpose of the amendment is to highlight >the need to add an additional value, >particularly in light of the all hazard warnings >that I anticipate coming, the word avoid, and to >include that in the computer generated text >string. >MR. MORAN: Thank you. Do we have a second on that? >MALE VOICE: Second. >MR. MORAN: Second? Okay. >Any discussion on Mr. Pitts' proposed amendment? Yes, Dave? >MR. WEBB: Yes, sir, Mr. Chairman. I do believe, >and I will have to defer to Mr. Botterell on >this for the exact thing, but these values are >all fields that are established within the CAP >standard. >FEMALE VOICE: Yes. >MR. WEBB: And by doing this amendment we would >in effect be modifying an OASIS standard that is >published for the whole world to use, and I'm >not sure that this -- while I agree that avoid >is a useful thing to have, I'm not sure we can >modify an international standard in this body. >MR. PITTS: Mr. Chairman, Billy Pitts. If I might >address that? I'd like to hear from Art. >I understand, and this is no way trying to >change the OASIS standard. This is an effort by >us as the committee advising the FCC that >something needs to be done here, that we need to >be a little more explicit in our responses, and >my hope would be that both the OASIS CAP >Standards Setting Group would look at this as >well as the FCC, but I think as a recommendation >we would be deficient in not pointing out the >need here. >MR. MORAN: Thank you. >Any other comments? Discussion? >MR. PREST: Yes. This is Art Prest. I totally agree with what Billy just said. >MR. MORAN: Okay. Any other discussion on the bridge? >MR. RUTKOWSKI: Mr. Chairman, Tony Rutkowski. >MR. MORAN: Yes? >MR. RUTKOWSKI: I was actually the acting >rapporteur for what is actually the >international standard, which is the IQT version >of CAP, and I tend to agree with the amendment, >but I would have one admonition that's generally >applicable to all of these is that in the >continuing international process for exchanging >information on these fields in going forward >that this information be shared with other >administrations. There's a standard mechanism >for doing that. >MR. MORAN: Okay. Thank you. Any other discussion? >MR. BOTTERELL: Mr. Chairman? >MR. MORAN: Yes? >MR. BOTTERELL: Art Botterell. In Section 5.3.2 >of the draft recommendation there is a provision >for the alert gateway adding event codes over >and above those specified either in the CAP or >in the older same event-coding scheme. >I think it was on this principle that the >attempt was being made to go ahead and add what >I think everyone agrees is a needed field. The >small difficulty that arises is that here we are >actually proposing an addition to the response >type enumeration rather than the event code, and >we have not really addressed that prior. >I'd like to offer what I hope will be accepted >as a friendly amendment in two parts. The first >would be that the text string associated with >this new response type value of avoid would be >avoid hazard, and this is really just for >clarity when you construct the whole string. We >don't want to say avoid area because then >everybody who gets the message in this area >thinks it applies to them. That's the best >wording we could come up with. >The second bit is that we add -- I guess there's >actually three bits. The second bit would be >that we add a footnote acknowledging that this >particular value is not currently supported in >the CAP specification, but that it will be added >for CMAS purposes until such time as OASIS can >rule on that as a change since we don't really >have a mechanism in the response field. >And then the third thing would just be to note, >and this is more of a process note. I think >since we already have just adopted an updated >tabulation provided by Brian that this would >really just be a one line change in the table as >most recently amended, the table for response >type, not an amendment of that entire table, so >that's a little complicated, but we can parse >it. MR. MORAN: Yes, Mr. Jones? >MR. JONES: Thank you. Gary Jones. I'd like to >support the change that Art is proposing in the >text string in changing it from avoid to avoid >hazard. >The committee laid out a structure for the >canned message and the order of the elements of >the message. Having the words avoid hazard seems >to fit better in the ordering of the message so >that it would have the event, the recommended >action -- excuse me. The event and then the >words in this area and then the recommended >action. >For instance, it might say a HAZMAT warning in >this area. Avoid hazard. The English seems to >flow a little bit better. Thank you. >MR. BOTTERELL: If I may add just one final aside >for the benefit of Mr. Rutkowski? >Tony, I think we'll have to discuss off-line >whether this would be something that OASIS >should take first and then take to ITU or >exactly how that harmonization would occur. >MR. RUTKOWSKI: I agree, but I think the point is >too this is for global interoperability >purposes. We need to exchange these field values >to allow global interoperability. >MR. BOTTERELL: Exactly. So I guess I would ask >Mr. Pitts if he would accept that as a friendly >amendment. >MR. PITTS: Yes, sir. I think they're very >constructive and worthwhile, and I would accept >it. >FEMALE VOICE: Thank you. >MR. MORAN: Mr. Botterell, your first of your >three suggestions is very clear. The second one >I'm not sure I caught it all and exactly what >you do. >MR. BOTTERELL: Yes. Let me see if I can dictate >it. This would be a footnote or an asterisk or a >note of some sort, whatever editorially works, >that would say: This value is recommended for >CMAS use only pending action by the responsible >standards body. >MR. WILLIAMS: Modification of CAP? >MR. BOTTERELL: Yes. Yes. The pending >modification of CAP. I don't want to posit that >they're going to do it, even though I'm fairly >confident they will. >MR. MORAN: Let me make sure I got your whole sentence there. >MR. BOTTERELL: Yes. >MR. MORAN: This value is recommended for CMAS use only pending action -- >MR. WILLIAMS: Modification of the CAP value. >MR. BOTTERELL: Pending inclusion into the CAP standard. How is that? >MR. MORAN: Pending inclusion into the CAP standard? >MR. BOTTERELL: Yes. Period. >MR. MORAN: Okay. And your third suggestion? >MR. BOTTERELL: Was really just that the scope of >this is really just adding one line to one >section in the table. >It's not a replacement of the entire table >because we just amended the order of the table >before and I don't want to blow that up, so >that's more an editorial note than an amendment >really. >MR. MORAN: Okay. Do we have a second on Mr. Botterell's proposed -- >MALE VOICE: Second. >MR. BOTTERELL: I think it's been accepted as a >friendly amendment, so do we have to -- >MR. MORAN: Okay. So it's been accepted. Okay. >Any more discussion on this proposed amendment? >MR. WEBB: Mr. Chairman, I would like to say >while we have just added this and it's a good >thing, I don't think the alert originator >software industry will build to this immediately >until -- I mean, this is something that would be >likely included in the gateway function, but as >far as an industry building to a standard it's >not yet a standard, so it may not come out in >originator software and be available for their >use. >MR. MORAN: Okay. >MR. BOTTERELL: I think that's right. The good >news is that it's entirely possible that OASIS >could deal with this in the time it's going to >take the FCC to deal with its part of the >rulemaking, but that's not a certainty by any >means. >MR. MORAN: Okay. Any further discussion here in the room on this issue? >(No response.) >MR. MORAN: Any further discussion on the bridge? >(No response.) >MR. MORAN: Okay. Let's vote on this. So we're >voting on the amendment with the friendly >amendment change to the amendment, so it's the >amendment as presented by Mr. Pitts. >On the second page under What Action Should Be >Taken under Text Stream next to avoid it will >say "avoid hazard" on the text stream, and we >would put a footnote somewhere that says: This >value is recommended for CMAS use only pending >inclusion into the CAP standard. >Okay. Let's have a vote here in the room. All >who favor this amendment raise your hand. >(Whereupon, a showing of hands.) >MR. MORAN: We have that. Thank you. >All who are opposed, raise your hand. >(No response.) >MR. MORAN: Any abstentions? >(Whereupon, a showing of hands.) >MR. MORAN: Okay. Sue, what is the count for the bridge? >MS. GILGENBACH: Thirty yes, zero no, one abstain. >MR. MORAN: Thank you. Okay. We'll go to the bridge here. >Mr. Ban? >MR. BAN: Yes. >MR. MORAN: Ms. Brooks? >MS. BROOKS: Yes. >MR. MORAN: Ms. Dunn-Tutor? >MS. DUNN-TUTOR: Yes. >MR. MORAN: Mr. Lyon? >MR. LYON: Yes. >MR. MORAN: Mr. McGinnis? >MR. McGINNIS: Yes. >MR. MORAN: Mr. Prest? >MR. PREST: Yes. >MR. MORAN: Mr. Roberts? >MR. ROBERTS: Yes. >MR. MORAN: Mr. Rutkowski? >MR. RUTKOWSKI: Yes. >MR. MORAN: Mr. Wilcock? >MR. WILCOCK: Yes. >MR. MORAN: Mr. Gehman? >MR. GEHMAN: Yes. >MR. MORAN: Okay. That amendment passes. > > >Attachment converted: Macintosh >HD:CAP_Standards_Commit#FC14C6.doc (W8BN/MSWD) >(00FC14C6) > -- Rex Brooks President, CEO Starbourne Communications Design GeoAddress: 1361-A Addison Berkeley, CA 94702 Tel: 510-898-0670
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]