Re: [emergency] CAP Issue #9

[Art Botterell <acb@incident.com>]

Certainly we have a dilemma here, but I'm afraid it's of our own 
making.  It's regrettable that we chose not to deal with this 
fundamental function-point when it was originally raised.  However, 
it's still necessary in order to meet our stated requirements and I 
think we've got consensus on the general approach if not the precise 
wording.

As for testing... I'll point out again that there is no OASIS 
requirement for testing, only for certification of "use" as broadly 
defined.  However, if we want testing then we should be willing 
(regrettably) to delay finalization in order to do it.

- Art


At 10:34 AM -0500 12/30/03, R. Allen Wyke wrote:
>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