Re: [emergency] RE: CAP Spec Doc

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

I will remind you that Walid has an Action Item to collect the various
comments, including our own, and provide back to the TC for review. 

On Fri, 2003-10-10 at 16:13, Art Botterell wrote:
> Walid -
> 
> I'm happy to do so... the Word document is attached.  I'm sure you 
> agree that it's important to avoid any misperception that any one 
> firm is trying to seize control of the CAP specification at this late 
> date.
> 
> - Art
> 
> 
> >Art:
> >
> >Our developers who are on the TC.  It would be great if you could post
> >it to the document repository or the internal email list.
> >
> >W
> >
> >
> >-----Original Message-----
> >From: Art Botterell [mailto:acb@incident.com]
> >Sent: Friday, October 10, 2003 3:55 PM
> >To: Walid Ramadan
> >Subject: Re: CAP Spec Doc
> >
> >
> >Walid -
> >
> >Who is proposing to do this "editorial review"?  I'll be happy to
> >make the source document available to the Technical Committee, but
> >I'm not sure it would be appropriate for me to encourage third
> >parties to do edits except through the designated comment process.
> >
> >- Art
> >
> >
> >>Art:
> >>
> >>We got some technical folks conducting an editorial review of the CAP
> >>spec document.  The idea is to make it flow better.  However, we only
> >>have a PDF version of it.  Any chance you can provide me with the MS
> >>Word version of it?
> >>
> >>Thanks
> >>
> >>Walid
> >>
> >>
> >>-----Original Message-----
> >>From: Art Botterell [mailto:acb@incident.com]
> >>Sent: Thursday, October 09, 2003 12:57 PM
> >>To: emergency@lists.oasis-open.org
> >>Subject: Re: [emergency] Re: [emergency-comment] PPW letter re CAP
> >>
> >>
> >>At 8:03 AM -0700 10/9/03, Rex Brooks wrote:
> >>>Before Mr. Fulgate's letter on behalf of PPW, I had not heard a
> >>>specific suggestion on how to deal with this issue.
> >>
> >>There was a specific proposal tabled at the "mini-f2f" in Stafford VA
> >>in July.  That you weren't aware of it suggests that we probably should
> >
> >>have opened that discussion to the whole membership... but the
> >>resistance I ran into at the meeting was so immediate and so vehement
> >>that I'll confess I was a bit intimidated.
> >>
> >>The specific proposal, for the record, was that within the <resource>
> >>block we include an optional <data> element which could hold a Base-64
> >>encoding of a binary asset, as an alternative to referencing it in the
> >><uri> element.  (This was actually the chief use-case for adding the
> >><mime> element to the <resource> block.)  It was suggested that this
> >>element could be defined as deprecated except for use over one-way data
> >
> >>links of sufficient capacity, and with a warning that receivers not
> >>designed for use over such links might not support this option.
> >>
> >>>I also feel I should say that we are going to run smack into the
> >>>ROYALTIES quagmire with the TV people,
> >>
> >>Why?  We don't need to specify the use of any proprietary format, any
> >>more than we do now with the <uri> reference approach.  If a particular
> >
> >>implementer chooses to use such a format, then that implementer has a
> >>royalties concern, as with our current <uri> arrangement and as
> >>anywhere else.  But there are royalty-free formats available for images
> >
> >>and audio, so royalties issues would be avoidable unless the
> >>implementer chooses to take them on.
> >>
> >>>Maybe the imminence of having a standard that does not address their
> >>>needs will stimulate them to do something tangible about it.
> >>
> >>Not sure what else you'd like them to do, tangibly... they've written
> >>us letters and PPW has instructed me to pursue this issue.  They've
> >>offered to do implementations if we'll just give them a spec.  What I'm
> >
> >>afraid of is that we'll force them to take the tangible step of
> >>abandoning CAP and setting up their own standard in some other venue.
> >>
> >>>The TV folks, not PPW, have to be responsible for their own bailiwick.
> >>
> >>If I understand you correctly you seem to be saying that you'd rather
> >>see the TV folks create their own standard.
> >>
> >>That's an admissible argument, albeit one I don't personally subscribe
> >>to.  The problems with that include: a) there'd be no guarantee that
> >>their data set would align with ours, in which case we'd have created
> >  >an interoperabiltiy problem instead of solving one; and b) given the
> >>enormous market power of TV in our society, there's a very real
> >>possibility that their standard would overrun ours, in which case all
> >>our hard work here would have been for naught.
> >>
> >>(We already have a small instance of that in Thompson/RCA's adoption of
> >
> >>the elderly SAME coding for their alerting TV sets.  Even the Thompson
> >>folks agree that it's not a very good format, but they like the
> >>liaibility shield of getting all their messages from the National
> >>Weather Service so they took what was on offer.)
> >>
> >>After all, nobody's required to use OASIS standards in preference to
> >>alternatives.  Uptake will depend on timeliness and usability
> >>initially, and network "tipping"  based on market share shortly
> >>thereafter.
> >>
> >>- 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_wo
> >>r
> >>kgroup.php.
> 
> ______________________________________________________________________
> 
> 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, Emergency Management TC
emtc@nc.rr.com
http://www.oasis-open.org/committees/emergency