Forwarded on behalf of Eliot Christian. Please copy him on any reply to this message.

Cheers, Simão

-----Original Message----- From: Eliot Christian [mailto:echristian@usgs.gov] Sent: 28 May 2007 15:56 To: Campos, Simao; paulej@packetizer.com; s.horne@packetizer.com; Christian.Groves@nteczone.com Cc: itu-sg16@lists.packetizer.com; Art Botterell Subject: RE: [itu-sg16] Instant Messaging in H.323 & Common Alerting Protocol (CAP)

Please forgive me diving into the middle of this discussion.

I would like to make a distinction here: a CAP message is a special case of emergency messages generally. We all know that just about any medium can be used to communicate emergency messages: sirens, police with bullhorns, voice over radio or telephone, text over news wire, text crawl over television, fax, e-mail, and so on. I would say that the underlying source of any emergency message may include, but is not limited to, a CAP message.

I'd also note that CAP only standardizes the information content of emergency messages as they are being communicated digitally and electronically. A CAP message must be delivered entirely and without corruption, and in its specific structured format (transformable to the prescribed XML or ASN.1 syntax and encodings).

Human receivers of emergency messages rarely deal directly with underlying CAP messages. A person who hears a siren blaring does not know or care if the siren is a TCP/IP device programmed to process CAP messages. The same is true of a warning given by a policeman based on a CAP message to his squad car, or a warning given by a radio announcer reading a CAP message off of a news wire service.

Yet, the relaying, filtering, and routing of CAP messages is a very important aspect as CAP messages do traverse a wide range of communications paths. From a communications architecture perspective, our key consideration is whether traversal of a given path segment preserves the content and structural integrity of the CAP message and any associated authority, authenticity and security assertions. Where such integrity is not preserved, we should say that delivery of the CAP message is finished although the emergency message itself may continue to be relayed.

For example, let's say the National Weather Service sends out a CAP message for a tornado alert. This CAP message is then picked up by the Weather Channel and inserted into television news. Seeing that message on television, local police trigger the public address system at a shopping mall in the threatened area. Here, a complex relay of the emergency message is occurring. The emergency messages were triggered by the original CAP message but the derivative emergency messages are not preserving the full integrity of the underlying CAP message.

Expanding on the example, it is also possible for a local police system to pick up the CAP message directly from the National Weather Service. The police system can then automatically relay that message to an automated system at the shopping mall, programmed to process the CAP alert directly. In a similar vein, commercial wireless service providers in the U.S. will soon be required to process CAP messages and send such a tornado alert directly to their subscribers. Because these more automated communications paths can be much quicker and less error-prone, we look forward to deeper penetration of CAP-enabled communications over time. But, multiple communications paths for emergency messages will be commonplace for the foreseeable future.

Eliot