RE: CAP Spec Doc

[Art Botterell <acb@incident.com>]

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.

emergency-CAP-1.0.doc