Re: [emergency-msg] Minutes from 9-9-03 Notifications SC call

[Art Botterell <acb@incident.com>]

At 12:35 PM -0400 9/20/03, R. Allen Wyke wrote:
>Hmmm, please correct me if I am wrong, but I do not think this is a DMIS
>issue.

Allen, we worked this over at some length in the SC meetings of the 
past two weeks.  The problem was with DMIS applying the optional SOAP 
encoding rules unnecessarily in a messaging-style application.  That 
created a divergent format on the wire.  DMIS took our feedback on 
board and implemented a messaging-style SOAP interface.

>This is exactly why transport needs to be outside of the CAP standard
>itself. So any "fork" does not become that, but rather because "here is
>how you apply this standard to transport situation A, which might be
>slightly different than B, etc." How many types of transports we want to
>consider, think about, decide to avoid all together, etc. is something
>we should discuss.

I don't think we want to say that every transport network can use a 
different schema.  Devices should be able to implement multiple 
transports without having to implement multiple document schemas as 
well.  Especially when there's no necessity to do so.

The real question is "what constitutes compliance with the standard?" 
The current document specifies, as normative, an XML schema that 
defines a message representation.  If the schema isn't the criterion 
then there's no limit to how many different, incompatible "CAP" 
formats might be deployed.

>If we take the stance, which needs to be discussed amongst the whole TC,
>that transport is something we chose not to touch with a 10 foot pole,
>then that is fine - but we will need to be prepared for forking.

Our approach all along has been that the message format should be 
independent of, and standard across, transport options... precisely 
so that different transport choices didn't induce standards forks. 
Whether we address transport as an Infrastructure issue is, and 
should be, an entirely separate question.  Our immediate concern was 
that we not come right out of the box with two different flavors of 
CAP documents being exchanged among users.

>  Take the now famous "broadcast" scenario. One version of that is most likely
>delivered in voice, which means the last mile was not CAP - it was CAP
>transformed into something someone spoke or there was a text-to-speech
>transformation.

That's the easy case, of course.  The version we've been wrestling 
with is the one where the broadcast link isn't the last mile, but may 
be used to pass standard-compliant messages to third-party consumers 
(devices and/or networks) at the far end.

- Art