At 16:18 07/03/98 PDT, Keith Moore wrote:
snip...
>> Isn't there some IESG expert that can bless this proposal now, so that
we can
>> discuss it and put it in our documents?
snip...
>*I'm* the expert. The rest of IESG would prefer to avoid reading the
>IPP documents; they'd far rather trust my judgement and vote "No Objection"
>But a strong objection from any IESG member can cause the process to
>take a lot longer. But my opinion is irrelevant, as is the opinion of
>other experts, if there's strong objection from other IESG members
>who have read the documents.
Good! Then its very important that you review the detailed proposal
that the IPP has been considering to satify your requirements for a
new IPP scheme (but has so far rejected). It sounds like you like parts
of it, but have some concerns too. I would think that the proper steps
BEFORE taking IPP to the IESG would be:
1) you finish giving us your feed back on our detailed proposal to
use an IPP scheme (that Randy Turner and Larry Masinter wrote up),
including conformance wording, etc.
2) we update that proposal and make sure you agree with it.
3) then the IPP WG reviews whether they support the proposal or not
and writes down the problems that they have for your review.
We have an IPP meeting this Wednesday/Thursday, July 8/9, in Monterey.
It would be nice if we could finish steps 1-3 by the end of that meeting.
Can you participate with us if we setup a phone conference?
Question: should this usage of the IPP scheme be a separate document
or part of the "Encoding and Transport" (was called Protocol) document?
Thanks,
Tom
>>I personally think the overall proposal to use ipp: is sound and
>reasonably detailed, but the solution to allow both ipp: and http:
>in IPP protocol elements is marginal. I'd like the proposal better
>if it said "clients and servers SHOULD use ipp: URLs in IPP protocol
>elements".
>>The proposal would be stronger if it provided some justification for
>using http: in IPP protocol elements at all. It should also
>explain why using http: when talking to proxies isn't an attempt
>to subvert a site's firewall security policy. It probably needs
>to describe a common case where talking directly to the server's
>IPP port doesn't work, and the reason it doesn't work is something
>other than "access to the IPP port is turned off at the firewall".
snip...
>But at this point I think it's to the point that I can should it to
>IESG, let them comment on it and recommend changes, and have the
>IPP editors do at most one more pass. Assuming, of course, that
>IPP is willing to make the changes that IESG requests.
snip...
>Keith
>>