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

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-msg message

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


Subject: Fw: [emergency] Fwd: Re: [emergency-comment] RE: Content ( was RE: [emergency-comment] RE: [CAP] RE: CAP-list digest...)


As usual, you're missing the point. Let me be clear, therefore. In my view
your list traffic on this issue is professionally divisive, irritating and
de-motivating, and your repeated personal attacks have been, and continue to
be, offensive and out of line.
>
This dialogue is NOT about you. It's about the production of a professional
standard that is globally viable and understandable to all users, in all
formats, and across all networks. If you can't accept fairly delivered
criticism offered responsibly by the committee's leadership, then please
find a group of professional nebbishes you CAN bully.
>
 Further, please feel free to "stack" anything you want. The production of
good solid work is fine by me, and I couldn't give a rat's tutu who's name
is on it - you can call it Gwendolyn, or attribute its genesis to a
passionate merger between Baba Ram Das and Elvis' Love Child for all I care.
But, at the end of the day, only the quality of the work counts, and if
there are concerns within the committee then they should be heard and
considered not denigrated. I have read no traffic from anyone on this list
to suggest anything other than a series of attempts to insure that the user
community is being properly heard and served by CAP, and attention to the
professional consensus of this committee is being appropriately sustained.
>
As for personal loyalty, I have house rabbits and they are quite loyal
thank you. This on the other hand is business.

 Rick

>
>
> ----- Original Message ----- 
> From: "Art Botterell" <acb@incident.com>
> To: "CONSULTRAC" <rcarlton@consultrac.com>;
<emergency@lists.oasis-open.org>
> Cc: "Karl F. Best" <karl.best@oasis-open.org>; "Scott McGrath"
> <scott.mcgrath@oasis-open.org>
> Sent: Tuesday, March 23, 2004 8:46 PM
> Subject: Re: [emergency] Fwd: Re: [emergency-comment] RE: Content ( was
RE:
> [emergency-comment] RE: [CAP] RE: CAP-list digest...)
>
>
> > Welcome back, Rick!  We hardly had time to miss you.
> >
> > Of course we all appreciate your personal loyalty, but as I've been
> > reminded many times, OASIS has a process.  I understand that a few of
> > us... although not the majority... might prefer to continue arguing
> > over 1.0 until they got their way.  But that's not what the TC voted
> > to do.  The TC voted to advance 1.0 to an OASIS ballot.
> >
> > Now if our Chair can't bring himself to serve as a positive spokesman
> > for the TC's work, even if it clashes with his personal opinions,
> > then I believe he has an ethical and professional obligation to step
> > aside.
> >
> > And for our Chair to use his position to make public statements that
> > undermine the credibility of CAP, the EM TC and OASIS is, I believe,
> > more than adequate grounds for his replacement by the TC membership.
> > But I think Allen has had a lot on his mind lately and so I sincerely
> > hope it doesn't come to that.
> >
> > Patronize us with corn-pone all you like, Rick, but I'll stack up my
> > contributions and my results in this TC with anyone's.  And I don't
> > know anyone who's demonstrated more concern about the success or the
> > effectiveness of CAP than I have.
> >
> > But you're mistaken:  The process isn't about satisfying everybody.
> > If it were then anybody with an axe to grind or a grudge to carry or
> > just a craving for attention could hold it hostage forever.  The
> > process is about finding those things we can agree on and formalizing
> > them and then refining them in orderly stages.  That's what the TC
> > has done and that's what we're all obliged to work with, at least
> > until the appropriate time comes for the next round of improvement.
> >
> > At least, that's the OASIS process my organization paid its dues to
join.
> >
> > - Art
> >
> >
> >
> >
> > At 7:08 PM -0800 3/23/04, CONSULTRAC wrote:
> > >Wow, am I glad I decided to come back to work with this group!
> > >
> > >Lets see; we've got a spec in float that the public comment list and
some
> on
> > >the committee are suggesting needs work before it can be effective,
we've
> > >got a committee member suggesting that the TC's Chairman is incompetent
> and
> > >sending email as such to the heads of all known government and
> sanctioning
> > >organizations while regaling us with  pre-Christian history lessons on
> Roman
> > >General's, and everyone appears to be "low, slow and out of ideas." Man
> this
> > >is great. Someone get me a Prozac!
> > >
> > >Now that everyone has had their end-of-quarter "hissy," can we either
> look
> > >at the work that's been done professionally, and in context of the
> resources
> > >available or can't we? While I don't claim to be either as smart, or as
> > >clever, as certain of my TC brethren, I do know the difference between
a
> > >sharp stick and a poke in the eye. In order for this thing to work we
> NEED
> > >to settle down, stay engaged and get the freaking spec completed to
> > >EVERYONE's satisfaction, or we're just blowing smoke up each other's
> skirts.
> > >As my pig farmer relatives used to say, (sorry Art, no Roman Generals
in
> the
> > >family), "Life is not about how fast you run, or how high you climb,
but
> how
> > >well you bounce."
> > >
> > >Rick
> > >
> > >
> > >
> > >
> > >
> > >  ----- Original Message -----
> > >From: "Art Botterell" <acb@incident.com>
> > >To: <emergency@lists.oasis-open.org>
> > >Cc: "Karl F. Best" <karl.best@oasis-open.org>; "Scott McGrath"
> > ><scott.mcgrath@oasis-open.org>
> > >Sent: Tuesday, March 23, 2004 6:01 PM
> > >Subject: [emergency] Fwd: Re: [emergency-comment] RE: Content ( was RE:
> > >[emergency-comment] RE: [CAP] RE: CAP-list digest...)
> > >
> > >
> > >>  Here our Chair tells a public list that "For anyone trying to
support
> > >>  CAP messages from various sources, it is impossible, in the current
> > >>  state of CAP, to do so in any kind of standard method"  and
> > >>  "Differently != Standard. Basically, CAP is not a protocol."
> > >>
> > >>  Aside from the fact that this statement is demonstrably incorrect,
> > >  > for that sort of negative publicity about the TCs work product to
> > >>  issue from our own Chair, right in the middle of balloting, is
> > >>  nothing short of astonishing to me.
> > >>
> > >>  - Art
> > >>
> > >>
> > >>  >From: "R. Allen Wyke" <emergency-tc@earthlink.net>
> > >>  >Subject: Re: [emergency-comment] RE: Content ( was RE:
> > >>  >   [emergency-comment] RE: [CAP] RE:   CAP-list digest...)
> > >>  >To: cap-list@incident.com
> > >>  >Date: Tue, 23 Mar 2004 11:20:06 -0500
> > >>  >
> > >>  >
> > >>  >Hate to say it, but Bob is right. For anyone trying to support CAP
> > >>  >messages from various sources, it is impossible, in the current
> > >>  >state of CAP, to do so in any kind of standard method. You have to
> > >>  >build a bunch of one-off connectors to handle the different
> > >>  >implementations. We "stood silent" on so much, that people are all
> > >>  >using it differently. While that may seem like a good thing to some
> > >>  >people, it is not. Differently != Standard. Basically, CAP is not a
> > >>  >protocol. It is a grouping of elements of like purpose to reflect a
> > >>  >format.
> > >>  >
> > >>  >Allen
> > >>  >
> > >>  >On Mar 5, 2004, at 8:30 PM, Bob Wyman wrote:
> > >>  >
> > >>  >>Art Botterell wrote:
> > >>  >>>>At 5:29 PM -0500 3/5/04, Bob Wyman wrote:
> > >>  >>>>  ... the CAP specification *DOES NOT* tell me where to put them
> if
> > >>  >>I
> > >>  >>>>am trying to pass a CAP message without SOAP.
> > >>  >>>That's right, it doesn't.... And after discussing this very
> > >>  >>>question at some length a number of months ago, the members
> > >>  >>>of the TC decided that it lay outside the scope of the CAP
> > >>  >>>spec and more properly in the scope of specifications for
> > >>  >>>a particular transport context.
> > >>  >> So, what you're saying is that CAP *does not* provide any
> > >>  >>mechanism or facility for doing authentication of messages in a
> manner
> > >>  >>which is independent of the transport mechanism. If you want
signed
> > >>  >>messages, you must use a transport, like SOAP, that supports
signed
> > >>  >>messages. Thus, the odd mention of WSSE in the specification is
> really
> > >>  >>just a non-normative hint to users of SOAP which reminds them that
> > >>  >>they can use SOAP to transport and sign CAP bodies. CAP itself,
> > >>  >>doesn't deal with the issue of signing CAP messages nor does it
deal
> > >>  >>with encryption.
> > >>  >> This sounds a bit odd since in Section 1.1 of the CAP
> > >>  >>specification it is explicitly stated that CAP capabilities
include:
> > >>  >>"Facility for digital encryption and signature capability". In
fact,
> > >>  >>it appears that encryption and signatures can only be had by using
> > >>  >>facilities that are *not* provided by CAP. If anything, the most
CAP
> > >>  >>does is avoid interference with these non-CAP facilities. Given
> this,
> > >>  >>it would seem to make sense to remove the statements in Section
1.1
> > >>  >>that promise encryption and signatures... CAP doesn't deliver on
> these
> > >>  >>promises.
> > >>  >> Am I reading this correctly?
> > >>  >>
> > >>  >>>But in the meantime I've yet to hear of any actual
> > >>  >>>attempt at implementation that's failed for lack of
> > >>  >>>this feature, and there have been a number of implementations,
> > >>  >>>  so I think it might be premature to cast the discussion
> > >>  >>>in catastrophic tones.
> > >>  >> As I've mentioned in earlier messages, I am prepared to
> > >>  >>provide an Internet-Scale facility for the collection of and
> > >>  >>distribution of CAP messages. However, given that the content of
CAP
> > >>  >>messages is very sensitive (i.e. it involves folk's lives), I'm
> > >>  >>finding it hard to understand how such a facility can be provided
> > >>  >>*without* a mechanism for authenticating messages and providing
for
> > >>  >>non-repudiation. The issue is not one of technology -- it relates
to
> > >>  >>ethics, law, risk management, and the methods of hackers and
> > >>  >>terrorists...
> > >>  >> If the "actual" author of a message can't be reliably
> > >>  >>established (i.e. via signatures), then whoever was "last in the
> > >>  >>chain" for handling the message ends up being responsible for its
> > >>  >>content... Given that we're an intermediary, we would end up
> "owning"
> > >>  >>every message that passes through us. We would also become an
> obvious
> > >>  >>target for anyone wanting to insert forged data into the system.
> That
> > >>  >>is not a good thing.
> > >>  >> Authentication is not only useful to the end users of the
> > >  > >>system. It is also useful to the intermediaries since
> authentication
> > >>  >>allows them to wave off responsibility for the content of messages
> > >>  >>passed and it makes them a less useful focal point for malicious
> > >>  >>attacks. (Note: Pay attention to this last point... The network,
the
> > >>  >>channel, is *less likely to be attacked* if signatures are
> > >>  >>supported...)
> > >>  >> In Section 1.2 of the CAP spec it is indicated that CAP was at
> > >>  >>least partially motivated by a desire to deliver on the
> recommendation
> > >>  >>of the National Science and Technology Council which urged that "a
> > >>  >>standard method should be developed to collect and *relay*
> > >>  >>instantaneously and automatically all types of hazard warnings ...
> > >>  >>into a wide variety of dissemination systems". The key to my issue
> is
> > >>  >>the word "relay." For a relay to be deployable with this sort of
> data,
> > >>  >>there *must* be mechanisms for establishing the true source of CAP
> > >>  >>messages in a manner which cannot be repudiated.
> > >>  >>
> > >>  >>>Nonetheless, it sounds like what you're saying boils down
> > >>  >>>to a suggestion that CAP would be stronger if it provided
> > >>  >>>an explicit internal mechanism for digital signatures.
> > >>  >>>That's certainly a question the TC could revisit.
> > >>  >> If CAP is to provide a transport-mechanism-independent format
> > >>  >>for Alerts and also provide for "encryption and signatures" then
it
> > >>  >>*MUST* explicitly deal with the question of authentication,
> > >>  >>encryption, etc. in a channel independent manner. Thus, I'm not
> > >>  >>suggesting this as a way to make CAP "stronger" (even though that
> > >>  >>would be the case) rather, I'm suggesting that the professed goals
> of
> > >>  >>CAP can only be achieved by taking this step.
> > >>  >>
> > >>  >> bob wyman
> > >>  >>
> > >>  >>(Note: This message is cc'd to emergency-comment not as a
> solicitation
> > >>  >>for input but rather as a comment. I understand that comments will
> > >>  >>travel over other channels...)
> > >>  >>
> > >>  >>-----Original Message-----
> > >>  >>From: cap-list-admin@incident.com
> [mailto:cap-list-admin@incident.com]
> > >>  >>On Behalf Of Art Botterell
> > >>  >>Sent: Friday, March 05, 2004 6:26 PM
> > >>  >>To: cap-list@incident.com
> > >>  >>Subject: RE: Content ( was RE: [emergency-comment] RE: [CAP] RE:
> > >>  >>CAP-list digest...)
> > >>  >>
> > >>  >>
> > >>  >>At 5:29 PM -0500 3/5/04, Bob Wyman wrote:
> > >>  >>>  ... the CAP specification *DOES NOT* tell me where to put them
if
> I
> > >>  >>>am trying to
> > >>  >>>pass a CAP message without SOAP.
> > >>  >>
> > >>  >>That's right, it doesn't.  Again I'll point out that CAP does not
> > >>  >>specify any particular transport arrangement.  And after
discussing
> > >>  >>this very question at some length a number of months ago, the
> members
> > >>  >>of the TC decided that it lay outside the scope of the CAP spec
and
> > >>  >>more properly in the scope of specifications for a particular
> > >>  >>transport context.
> > >>  >>
> > >>  >>In the SOAP case, for example, the security design was the output
of
> > >>  >>a standards process.   In the DMIS case it was a "designer's
choice"
> > >>  >>(albeit still standards-based and open) by that network's
> > >>  >>implementer... as was also the case for the MyStateUSA and Hormann
> > >>  >>America implementations and the earlier ComCARE/Orillion
> deployments.
> > >>  >>
> > >>  >>Nonetheless, it sounds like what you're saying boils down to a
> > >>  >>suggestion that CAP would be stronger if it provided an explicit
> > >>  >>internal mechanism for digital signatures.  That's certainly a
> > >>  >>question the TC could revisit.
> > >>  >>
> > >>  >>But in the meantime I've yet to hear of any actual attempt at
> > >>  >>implementation that's failed for lack of this feature, and there
> have
> > >>  >>been a number of implementations, so I think it might be premature
> to
> > >>  >>cast the discussion in catastrophic tones.
> > >>  >>
> > >>  >>- Art
> > >>  >--
> > >>  >R. Allen Wyke
> > >>  >Chair, OASIS Emergency Management TC
> > >>  >emergency-tc@earthlink.net
> > >>  >_______________________________________________
> > >>  >CAP-list mailing list
> > >>  >CAP-list@incident.com
> > >>  >http://www.incident.com/mailman/listinfo/cap-list
> > >>  >
> > >>  >This list is not for announcements, advertising or advocacy of any
> > >>  >particular program or product other than the CAP itself.
> > >>
> > >>
> > >>  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_workgr
> oup.php.
> > >>
> > >>
> > >>
> >
> >
> >
>



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