MHonArc v2.5.0b2 -->
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]