[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [emergency] Re: [emergency-comment] PPW letter re CAP
Very well stated. While some areas, at the appropriate time, need to be drilled down into even further than you have most graciously done here, I agree on all points. Allen On Thu, 2003-10-09 at 11:03, Rex Brooks wrote: > Carl, Art, Allen, Elliot, et al, > > Let me preface this with a note that I started responding to this > yesterday, got busy, and also felt I should let some time go by and > listen to others before returning to this. So I will leave some of my > initial reply, and address a number of issues that have been raised, > without including all of the the now long list of messages in this > very vital thread. I will leave the specific thread to which I was > responding. The others I will refer to in broad terms, so please > excuse me if I get the attribution of a specific comment wrong. > > First, we are not offering excuses, we are making a point of > including stakeholders that have not been adequately representing > themselves, by informing them of where we are in the process. Before > Mr. Fulgate's letter on behalf of PPW, I had not heard a specific > suggestion on how to deal with this issue. There may be a way to make > this suggestion work by specifying that the optional mechanism use > Mime Type declarations as part of text versions of binaries, which > may also make it possible to skirt other issues. Another mechanism > would be to have the option include SOAP, and SOAP with attachments, > which may also provide one (but not necessarily to only) solution to > the problem of including photos, video clips, audio clips, etc. I > realize that this will not suit some applications, but remember that > it is optional. > > Art, Allen is right, I meant in my first reply, that this > constituency had not been adequately represented by only using PPW > and you, since their concerns are but one of many for you, and you > have had your hands full with getting CAP to this point. You were > right in that I did not express that in a clear way and so it seemed > that I was saying that they were not represented at all. Mea Culpa. > > I think Carl's suggestion is good, but it is also incumbent on us to > get in contact with these folks if we can and let them know where we > stand. I personally think that getting something out there for public > review, and then making sure this audience gets the message is the > best way to get them involved. I am not talking about PPW, but the TV > people. > > However, having said that, I also feel I should say that we are going > to run smack into the ROYALTIES quagmire with the TV people, and we > could spend the next year arguing about accepting or not accepting > MPEG-4, and get no standard to use where we can actually use one now. > We have the exact same problem with Flash. This is the main problem > with the feature they suggest of adding an optional mechanism for > adding binary content. OASIS IPR policy requires that any IPR claims > by any parties contributing to the specification be made public > before a standard can be considered for an OASIS-wide vote. I don't > think we have a problem with going forward with the Committee > Specification as it now stands, but this is an issue that we can put > at the top of the list of public comments with which the TC would > necessarily have to resolve before going forward to whichever of the > next steps in the TC process we decide to follow after the initial > 30-day public comment period. I should also say that we are not, I > believe, required to limit this public comment period to 30 days, nor > that we must immediately move on to a next stage immediately > thereafter. > > I doubt anyone is suggesting that perhaps we should put our work on > indefinite hold until someone comes along to offer a completely > acceptable proposal for handling this constituency? I thought the > point of getting CAP out there was to start getting feedback and get > a v1.0 that addresses the needs we have no proven that we are capable > of addressing now. Maybe the imminence of having a standard that does > not address their needs will stimulate them to do something tangible > about it. However, I have been waiting for reliable RF statement out > of MPEG-4 for five years now, and it still hasn't happened though I > have been assured innumerable times that if I just go along and adopt > their standards, it will all work out. I suspect the the governmental > agencies in general will not accept MPEG-4. I doubt the European > Union will accept it. And the Navy has said in the recent past that > it won't accept MPEG-4. > > One last thought, The TV folks, not PPW, have to be responsible for > their own bailiwick. We can't do that for them, nor can we be held up > indefinitely due to their situation. > > I think we should move forward and combine the suggestions that Carl, > Elliot and I have made for providing a way to include the Broadcast > Media. We will probably have to do some more work on the spec and go > through another 30-day public comment period, but maybe not. > > My last thought is for Allen and the notion of breaking an > application. I ran into this problem in another venue in OASIS and > pointed out that applications have the ability to adapt a lot more > easily than does the spec-writing process. Also, as you say, breaking > does not necessarily mean that the whole app collapses, and when we > get to finally defining a test suite we have the task of clearly > deciding what the differences are between compliance and conformance, > with conformance related ONLY to MUST statements. That's a > particularly tricky distinction. To accommodate this we probably will > need to institute a permanent Conformance SC, but that is a different > matter. In any event, the app builders are represented pretty well, > and you are doing a responsible job of representing their interests > and yours. > > I think I have covered most of the comments that I felt were > potential deal-breakers. We are very close to a good and, more > importantly, A VERY USEABLE SPEC. We can improve, indeed we are > already tasked with improving it, but please, let's move forward. > > Ciao, > Rex > > > At 2:59 PM -0600 10/8/03, Carl Reed wrote: > >Art - > > > >We run into these issues all the time in our specification process at the > >OGC. It is impossible to satisfy every requirement for every application in > >every industry. There is an interesting balance between getting a spec out > >for use and getting one out that is also useful! I think the old 80/20 rule > >applies. > > > >Anyway, perhaps a more positive way to position the CAP spec is to say that > >this is version 1 (one) and that future (new) requirements and change > >proposals will be considered and incorporated. This is the way we deal with > >the enhancement issue at the OGC. We accept change proposals, instantiate a > >spec Revision Working Group, work the suggested changes, and then put the > >modified spec up for member vote and adoption. Some of our specs have > >already gone through 5 or 6 revisions in 2 years. This does raise an issue > >of backwards compatibility and deprecation. But how is this different from > >any vibrant piece of technologies life cycle management? > > > >Cheers > > > >Carl > > > >----- Original Message ----- > >From: "Art Botterell" <acb@incident.com> > >To: "Rex Brooks" <rexb@starbourne.com> > >Cc: <emergency@lists.oasis-open.org> > >Sent: Wednesday, October 08, 2003 2:22 PM > >Subject: [emergency] Re: [emergency-comment] PPW letter re CAP > > > > > >> [I've shifted this thread from the public comment list to the > >> internal TC list.] > >> > >> Rex - > >> > >> Industry won't care what excuses we offer for not addressing their > >> needs... they just need to decide, very shortly, whether to embrace > >> CAP or go their own way. > >> > >> Anyway, I have difficulty with the idea that a lack of representation > >> has somehow made us unable to address this. In fact, there was and > >> is representation: PPW, among others. We've also received input on > >> this issue in public comments. And ultimately we can address > >> whatever we choose to address. > >> > >> And the media standards and technologies involved are no more > >> uncertain than in any other area. In fact, because of the > >> stabilizing force of the gigantic capital investments involved, I'd > >> say that DTV in particular is actually one of the least uncertain > >> environments in all of advanced digital technology. > >> > >> And those colossal investments, which are being programmed right now, > > > are also why we're not likely to get a second chance to be responsive > >> if we blow it this time. > >> > >> - Art > >> > >> > >> >Thanks Art, > >> > > >> >This is very informative and useful. If I might suggest a way of > >> >addressing the specific issue of full-spectrum media specification, > >> >I think we should make it clear, perhaps with a disclaimer in the > > > >spec or an open letter invitation aimed at broadcast television > >> >media representatives to the effect that due to a lack of > >> >representation of these interests combined with uncertainty about > >> >both near-future technological development and existing and/or > >> >planned technical standards directly related to these media, we were > >> >unable to include such media in this initial, admittedly partial CAP > >> >specification. This assumes that we all agree that the goal of > >> >including these media is unanimously supported if we can determine > >> >that it is both appropriate within OASIS and does not conflict with > >> >other efforts. > >> > > >> >Just tryin to be helpful. > >> > > >> >Ciao, > >> >Rex > >> > > >> >At 10:46 AM -0700 10/8/03, Art Botterell wrote: > >> >>The attached is a letter from Craig Fugate, Chairman of the Board > >> >>of Trustees of the Partnership for Public Warning. > >> >> > >> >>Attachment converted: Enterprise:PPW_Letter.PDF (PDF /CARO) (0029B681) > >> >>To unsubscribe from this list, send a post to > >> >>emergency-comment-unsubscribe@lists.oasis-open.org, or visit > >> >>http://www.oasis-open.org/mlmanage/. > >> > > >> > > >> >-- > >> >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 > >> > > >> >To unsubscribe from this list, send a post to > >> >emergency-comment-unsubscribe@lists.oasis-open.org, or visit > >> >http://www.oasis-open.org/mlmanage/. > >> > >> > >> 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]