Re: [emergency] CAP Issue #9

["R. Allen Wyke" <emtc@nc.rr.com>]

While I understand the objective of what this is trying to accomplish,
and I certainly think we, as a TC, need to address this scenario/use
case, my personal belief is that we do not know enough about the
ramifications of this addition, at this time, to include this in CAP
1.0. Therefore, I would propose we label it as a Future Version item,
and we give it the attention, thought, and testing it deserves.

Some supporting specifics on each of the Notes/Value domain, just as
examples of why I propose this:

1. What is its relation to the URI? Are they are the same? Can they be
coupled together to equal the "total" attachment? For instance, using
what we have here, I could put a photo, like of a missing child, in the
message, and a continually updated audio of the most recent status
locate at the URI reference. From an implementor's perspective on being
at the receiving end, how would I know these go together? What if I get
one, but not the other (URI is down)? Etc...

2. Saying one-way MUST support this is definitely a great attempt to
ensure compatibility, but realize what it also says  - in practice, this
also says that if you can't support it, then the alert has no value,
which may not be the case. Again, this has to do with the relativity of
the resource to the alert itself and is a topic we need to discuss. We
somewhat tabled it by not including binary items, but doing so certainly
implies that it is to "go with" the alert, versus just referencing
("supplements"). Also, whether or not it is supported should be
determined by the capabilities of the receiving party, not whether or
not it is one-way or two-way.

3. Certainty of clients being able to support - this, in my opinion, is
a big black hole. Why? Because as a sender of an alert, it now requires
me to keep a database of all recipients that can support my alerts,
which is an infrastructure nightmare. Think of the web - imagine a web
site having to keep track of every IP address that requests a resource
(HTTP, FTP, etc.) before sending it something. In the Web world this is
handled by the user-agent sending some info about itself to help the
site determine what it can and can not support - browser type, language,
supported "Accept" mimetypes, etc. In the one-way world, we need to
think through this more.

4. Striping the content out and providing it via a URI would also be an
issue. It may be ok to do this - again, its not a one-way or two-way
issue. It is a capability issue, such as bandwidth. Same problem here if
the two items are not the same - photo + audio for example.

5. Enforcing additional restrictions...again, this should not be a
one-way vs. two-way issue - its a capabilities issue.

Personally, I think this is a GREAT first step at trying to conquer this
issue, and it think it is something we can build upon. But adding this
in, in my professional opinion, forks the standard. It breaks it into
one-way vs. two-way, which I think is a bad thing. To ensure
compatibility and interoperability, I think this issue needs to be
thought out in more detail - so that we can come up with a mechanism to
facilitate either of these scenarios, with some consistency on how that
is accomplished.

Allen

On Mon, 2003-12-29 at 23:18, Art Botterell wrote:
> Attached is an updated version of the proposed language with a 
> technical correction in the class name.
> 
> - Art
> 
> ______________________________________________________________________
> 
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/emergency/members/leave_workgroup.php.
-- 
R. Allen Wyke
Chair, OASIS Emergency Management Technical Committee
http://www.oasis-open.org/committees/emergency