> Keith, I am trying very hard to follow this discussion to some form =
> of bedrock. I'm not so adamant about the URL scheme... as long as
> I can base my initial implementation on existing, off-the-shelf HTTP
> servers, which I think we have safely agreed upon.
>> What I do need, however, is a timely end to the development process
> for this standards specification. I suspect you would agree - none of
> us have inexhaustible resources.
>> To this end, security appears to be a real "monkey wrench". Your
> statement represents a basic "open loop" in my estimation.
>> It is insufficient, at this point, to be in the position of taking a
> proposal to the IESG which we know will fail to ratify and which is
> completely "Catch22" in context. We can't have security because it's
> not there yet... yet we can't use the security which is there.
> Unless there is some certainty of a very near term resolution of
> the security issue which will satisfy the IESG, I claim we MUST
> focus (and adjust, if appropriate) the IPP effort on utilization
> of a viable interim security method.
Harry,
I share your concern about the need for a timely end to the development
process.
While I do have doubts about the viability of IPP security for some
of the scenarios that IPP has envisioned, I also recognize that my
expertise is limited in this area. I would rather leave it to
the security ADs to evaluate the adequacy of IPP security. If it's
okay with them, it will be okay with me.
Even if the security ADs share my concerns, I will push to get the
Proposed Standard versions of the IPP specifications published quickly
and with as few changes as possible -- perhaps with some sort of
disclaimer about the limitations of the current security setup. The
vast majority of printing applications do not need a fully general
security solution, and IPP should not be kept waiting until such a
solution exists. It may be that IPP needs additional work to
define URL parameters and/or profiles for how TLS should be used
in some of the scenarios, but even if this is necessary I believe
that most of the work can be done in separate documents that aren't
in the critical path for the main IPP set.
I am pushing for the IESG review to be complete by the end of July,
though there is some chance that the review will take two weeks
longer than that. But I am hopeful that IESG can get the feedback to
IPP by end July, and complete IESG approval of any revisions before
the Chicago IETF.
Keith