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: [emergency-comment] PPW letter re CAP

At 9:56 AM -0700 10/9/03, Art Botterell wrote:
>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.

If the TV people don't insist on making mandatory any particular 
codec or set of codecs which include MPEG-4. and streaming (for which 
there are other constituencies) I sure wouldn't bring it up to them. 
But if they don't, it will be the first time I've seen it. (Doesn't 
mean it hasn't happened, just that I stopped listening after a number 
of years of getting runarounds and endless arguments that always 
boiled down to "Take our word on it."

>>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.

Not necessarily, but if they were to basically make their standards 
interoperable, I would not mind one bit. However, I do not want to 
give them the ability to jerk our chains when they are not willing to 
represent themselves here in this forum, and I don't mean through 
you, though you are a good representative in the sense that you are 
not letting it drop. I commend you for that because this is very 
important. But this is the same old tactic of which I have seen too 
much. You are unfortunately serving as their stalking horse because 
it suits them to work through proxies that allow them to delay and 
confuse issues and blame other folks for freezing them out while they 
stay ensconced in their patent groups and engage in endless 
infighting. This is not a new situation.

>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 

I don't buy that. The TV market has already fragmented into niches. 
Their problem is that they know they can't get agreement among 
themselves. However, I think Carl's approach works best and we just 
give PPW what they suggest with "blessed" status for any formats, 
which also seems fine to me since it is optional.

>(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 

Len Bullard's argument that we need to get our standard adopted into 
RFPs will take care of that, but it requires that we get the work out 
the door. If DHS specifies compliance with CAP, it will be 

We do need to make it clear that we are moving forward and publicize 
the public review as widely as possible, beyond what OASIS provides, 
but not in contradictory or conflicting terms. By that I mean we must 
avoid allowing any part of the public to believe that they can have 
their interests as public commenters proxied by any process other 
than submitting comments to the public comments list.

>- Art
>To unsubscribe from this mailing list (and be removed from the 
>roster of the OASIS TC), go to 

Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email: rexb@starbourne.com
Tel: 510-849-2309
Fax: By Request

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