At 12:36 PM 9/9/97 PDT, you wrote:
>We also discussed what is required to move from an Internet Draft to a
>Proposed Standard. It is my understanding that we need 2 interoperable
>implementations. This would mean 2 clients and 2 IPP Printers that
>interoperate with each other. The implementations should be on a
>product tract. This is the part that is not very clear. Hopefully the
>area director will make the requirements explicit for moving from
>Internet Draft to Proposed Standard. I expect the area director to
>specify what proof of interoperability must be supplied.
This is a misunderstanding. It is not until we want to move the documents
from Proposed to Draft standards that we actually have to give proof of
interworking implementations. Our ambition was to have this already before
the Proposed Standard was published, but that is not a requirement to get
it out. So we can relax a little on that point, which however should not
be a reason to get on with the prototyping..
>It was suggested that a TCP port be allocated for IPP(516 was
>suggested). Some of us use 3rd party embedded HTTP servers. We need to
>find out from these companies is supporting IPP on a port other than
>port 80 is a problem. Ira will check with SpyGlass and I will see if I
>can get input from other vendors. This issue will be brought to the
>full IPP group.
We have discussed this earlier and came to the conclusion that there was
no obvious advantage in having a separate port as part of the standard.
Do we have any new compelling arguments now?
>We discussed pairwise and blanket IPP interop testing. An IPP Bakeoff
>would have to be arranged to handle the blanket test. We are not ready
>for this at this time. (How much lead time will we need to prepare?)
>Pairwise testing seem to be a sticky point.
> 1) Can an implementer place his IPP Printer on the public side of
>their firewall?
We are prepared to do this.
> 2) Are we worried about security issues for initial tests?
Suggest that we can start without worrying too much about security,
as long as we only gove our Printer URIs to other vselected testers.
> 3) Would a proxy server using SSL or TLS help security?
It probably would, but this seems to be more work than putting a printer
outside the firewall initially.
> 4) Can we work with a firewall vendor to prototype modifications
>necessary for IPP support?
Let us see if we can find one.
> 5) Would a publicly available IPP client make the across the
>Internet pairwise testing unnecessary?
>The way it stands right now is that any two individuals are encouraged
>to arrange a pairwise test. Groupwide IPP pairwise testing is not ruled
>out. We still have obstacles in the way.
>>There are two main roadblocks to the IPP TES group. One is the IPP
>JobId/JobURI issue. The next is the security issue. These issues will
>be passed on to the IPP chair.
You are right, that we definately need to settle on the JOB URI decision
quickly. The same goes for security, but I think we can do quite a lot of
testing also without security at this stage.
Carl-Uno