[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 >>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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]