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


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

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

Subject: Re: [emergency] RE: CAP Spec Doc

At 9:22 AM -0400 10/11/03, R. Allen Wyke wrote:
>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.

That's right, and I've provided my collected notes and I trust others 
are doing the same.  I didn't presume to present a rewrite of the 
existing spec document... it struck me as more appropriate to let 
Walid aggregate a list and let the TC discuss it item-by-item and 
decide what it wanted to do first.  I imagine that's your plan, too.

I only meant to highlight... as others have done from time to time... 
the importance of protecting the "optics" of the process.

- Art

>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 
>R. Allen Wyke
>Chair, Emergency Management TC

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