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


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

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

Subject: Re: [emergency] Re: [emergency-comment] PPW letter re CAP

At 9:12 PM -0400 10/8/03, R. Allen Wyke wrote:
>As a reminder, the problem with adding this is that it breaks other
>things - it breaks things from the majority of our members building
>applications. Note that I am not saying apps crash - I am saying
>business processes no longer work, and the mediums across which we
>exchange data may not be able to handle these just by "adding a single
>optional element."

That's a broad claim, but we can't discuss it meaningfully because 
we've yet to hear any specific assertion of what breaks or any 
specific evidence that it actually does.  By this sort of shotgun 
logic, any technology change anywhere could be opposed because it 
might, potentially, somehow, somewhere, disrupt some unspecified 
"business process."

Anyway, we can talk about how to restrict the use of this option to 
appropriate business processes and media.  (Of course, anyone bent on 
a deliberate denial-of-service attack doesn't need CAP to implement 
one... in any medium.)

>For instance, you say it is optional - but what if it is not? What if
>the image itself is the payload carrying the "intent"? What then?

Well, the general answer is that there's really no such thing as 
"intent" without context... and the CAP message is the context for 
any referenced or attached resource.

To take your mugshot example, without additional info there'd be no 
way of knowing whether it was a mugshot or a campaign poster.  In 
that example, as in all alerts, there's a lot of critical information 
that every practitioner would agree is required: name, age, direction 
of travel, whether armed, what to do if located, and so on.  The 
whole point of CAP from the social-science perspective is to enable 
and encourage the creation and transmission of complete and effective 
alerting messages.

(In fact, one of the chief original reasons for CAP was to solve 
exactly the problem you describe as it occurs in our current national 
Emergency Alert System.  In our current EAS all of the information 
has to go into the audio because the SAME format isn't capable of 
representing anything but very imprecise event category and 
geotargeting codes.)

Of course we can't guarantee that nobody will ever find a way to 
screw up and send an incomplete or ill-considered CAP message.  The 
good news is that such screw-ups tend to be self-limiting over time 
because the message won't be as effective as if it were done 
correctly... and because other users will provide negative feedback. 
In the meantime we can do a lot at the application level to help 
reduce the number of ill-formed messages.

But let's be very clear about this: Nobody has the power to guarantee 
that the CAP format (or any other standard we devise) will never be 
used unwisely.  All we can do is make it possible to assert an 
effective message and try to structure things so misuses tend to be 
self-extinguishing.  That's the case here.

>And what if the inline attachment is 1MB in size? Or maybe 1GB or a
>terrabyte? My point isn't of what is extreme or not, but that much like
>legal documents, standards have to think about how to handle, and
>therefore address these kinds of things.

And we've proposed ways to address those issues.  Anyway, these 
concerns aren't new or unique to CAP.  For example, you recently 
suggested the W3C vCard format for use in the ICS-201 project.  I'm 
sure you noticed that that spec provides for inlining audio, photos 
or graphics in exactly the way originally suggested as a 
broadcast-only option for CAP.

So... even leaving aside restrictions on where the inline option in 
CAP would be used... why would CAP inlines bring networks to their 
knees when a few million vCard sources haven't?  Such problems are 
self-limiting for a number of reasons, including that the number of 
bad cases (or even implementations of the capacity for bad uses) are 
only a small fraction of the total use... and that occasions of bad 
behavior brings lots of negative feedback from other users.

Look, we can dream up catastrophic scenarios for anything if we're 
determined to do so... but wouldn't it be more satisfying and 
worthwhile to find ways to solve this than to just toss up reasons 
why we shouldn't try?

>Anyway, I am confused why this is being brought up again, because the TC
>agreed on this back at the mini-f2f. I even mentioned that the need
>could be addressed by including the image in the same envelope, as in
>SOAP, and the URI being relative. When stated I was told "that will
>work". What changed?

What changed was that subsequently we got explicit feedback from 
stakeholders... potential implementers who want  to use CAP... 
telling us that our suggested workaround wouldn't work for them... in 
some cases because they had concerns about SOAP overhead and 
interoperability, and in some just because they needed a specified 
solution that they could count on being applied in the same way by 
all users in their industry segment.

>You know, this entire statement is not only unfair to the work of the
>whole TC, but inappropriate. I am ashamed to even see that in our list.

Allen, we're all counting on you to fill your leadership role in a 
calm and professional way... nothing good will come from taking 
things personally.

And all our good intentions and hard work won't matter if we 
willfully make unwise choices just because we're unwilling to 
reconsider our earlier positions calmly in the face of new evidence.

- Art

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