Re: [emergency] Re: [emergency-comment] PPW letter re CAP

[Art Botterell <acb@incident.com>]

At 8:55 AM -0400 10/9/03, R. Allen Wyke wrote:
>So, you are saying the TC has not been democratic in our process?

If you're talking about our offline phone conversation in which we 
agreed to propose the SwA option as a workaround but not include it 
in the spec, then yes, I'd have to say that fell short of being 
"democratic."  However, I thought it was an appropriate way to 
address a need we didn't seem prepared to engage headon.  So we tried 
it.  Regrettably, it didn't work.

>Are you saying that people have previously voted
>irresponsibly, because that is what you are implying. That everyone here
>has voted on "our organizational self-interest."

Allen, this isn't about you and this isn't about me.  What I'm saying 
is what I've said... it's all in the archive.  And I didn't say 
anything about how folks voted in the past.

For the record, I believe that most of us have worked very hard to 
integrate our organization's agendas with our own professional 
judgement.  Which is, of course, the eternal challenge in any 
representative democracy.

>I was making the statement, as
>it applies to CAP, that if you are implying that non-media standards and
>technologies are not ready to handle XML-based alerts as the spec is
>written today that I disagreed.

XML isn't the issue here... never said it was.  The problem has to do 
with a workflow option (push of binary resources over one-way 
networks) that our current document design doesn't support.  It 
could, using established XML practices... it just doesn't.

>We have shown that they are in our demos
>and relative ease to support the format. True, the transport is a
>different issue - which is why we have a group now focused on that.

But if we don't provide the necessary capabilities (optional ones, in 
this case) in the message design, implementers will be unable to 
fully utilize some transport options without going beyond the spec 
and thus risking incompatibility with other users.  Pulling this out 
as merely a "transport" issue misses the point.

>As a member organization, I would love to see PPW have a person with
>that kind of expertise join the TC. FCC schedules, leadtimes for
>consumer devices, inability to do two-way communication, etc. all need
>substantive details.

Allen, I'm PPW's designated representative to the TC.  If the TC 
wants to take the time to articulate a specific question I'll be 
happy to carry it back to the Board and the membership and ask the 
various companies and agencies involved for their specific inputs. 
We're a representative organization of many different members, and 
the Board's letter represents the intersection of a number of 
different members' specific concerns.  It wouldn't be appropriate for 
me to try to answer questions that may have different answers for 
different members.

>No good reason, or no good reason that impacts you?

So far I've heard no good reason we CAN'T address this in a timely 
fashion that impacts anybody.  All I've heard is one member saying he 
doesn't want to do it, and a couple asking (understandably) if we 
can't put off this discussion until later.  Which we can, of course, 
but I believe the cost of doing so could be very high.

>Help me understand how we did not do this on 7/15?

As I recall it, we didn't resolve this issue on 7/15, mainly because 
a couple of folks immediately (and to my mind, prematurely) assumed 
adamant positions in opposition to any support for binary "push" in 
any context.  We agreed to other proposed changes in the draft but 
omitted any provision for this particular application.

In a phone call a few days later, you and I agreed that SOAP with 
Attachments might offer a workaround, but you still didn't want it to 
be part of the spec.  Bending to your wishes, the committee draft 
adopted a month later didn't address this issue at all.

Subsequently we got feedback from NDSAmerica, and then from PPW on 
behalf of a number of its members, that this non-standard workaround 
wasn't a viable solution for them.  Their comments are in the record 
so I won't rehash them here.

The point is that things change, and we learn from experience and 
hopefully move forward.  So whatever we did or didn't do on 7/15 is 
history but it's not a pair of handcuffs.

>It seems to be your
>inflexibility as to accomplishing the very same thing, but another way
>that is the root of this issue.

How are we accomplishing the very same thing?  Please tell me where 
in our current specification there's anything that addresses how to 
do this in any way.  Seriously, if I've missed some existing 
provision that solves this, I'd be the happiest guy I know.

All PPW, in particular, is asking is that we make some explicit 
provision for moving binaries over one-way links, so folks who need 
to do that know the One Standard Way to do it.

(Although I do think we'd be wise, in the interests of the success of 
the standard, to check with known, interested stakeholders before 
assuming that whatever specific proposal we like automatically meets 
their needs.  They've offered to answer if we only ask.)

- Art