MHonArc v2.5.0b2 -->
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 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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]