IPP Mail Archive: Re: IPP> Proposal for new IPP scheme

IPP Mail Archive: Re: IPP> Proposal for new IPP scheme

Re: IPP> Proposal for new IPP scheme

Carl-Uno Manros (carl@manros.com)
Tue, 16 Jun 1998 21:14:59 -0700

Bob,

I do not agree with you on the port number. In every Internet protocol
specification that I have seen there is talk about port numbers.
You could argue that as we are using HTTP, we should use the port number for
that. BTW, we are talking about DEFAULT port numbers, I hope that is still
clear to everybody (you could still support port 80, but your printer
must be able to use the new IPP port out of the box, at least that is my
understanding).

Unfortunately you did not make it to our phone conference with the
Area Directors last week, in which they rather categorically declared that
the IESG expects new protcols, such as IPP, to use new port numbers and if
we want to get the IPP specifications past them, we WILL have a new DEFAULT
port number for IPP. We can keep on arguing this point, but I think we are
just wasting our time right now.

As for the new scheme, I tend to agree that this really falls outside
the protocol and does not neccessarily needs to be resolved as part of
the IPP V1.0. Remains to also convince the Area Directors that this
is the case.

Carl-Uno

At 05:37 PM 6/16/98 -0700, Robert Herriot wrote:
>Actually the default port never hits the wire either. Both the default port
>and the ipp scheme-name are smoke and mirrors on the client which give the
>illusion of an ipp scheme.
>
>On the wire there is nothing but http with default port 80.
>
>If the IPP RFC's should specify wire protocol only, then they should not
>discuss ipp schemes or default ports. If we believe the IPP RFC's should
>give some hints for implementing clients, then the proposal from Randy about
>the ipp scheme and default ports is reasonable except for the last line.
>
>Bob Herriot
>
>At 05:04 PM 6/16/98 , don@lexmark.com wrote:
>>The more I think about this, the more I think it is out of scope for the
>>work we are doing. We are working on the wire protocol and encoding for
>>IPP, so ...
>>
>>- Getting a port number allocated for IPP is OK
>>- Specifying that port as the default port is OK
>>- Creating a new scheme that never hits the wire and is handled inside
>>clients and servers is NOT a wire protocol issue.
>>
>>While I think this material could be a interesting proposal and possibly an
>>informational RFC or maybe even more, I don't think it belongs in the
>>standard track RFCs that define IPP. While I am against a new method, at
>>least it is a wire level issue.
>>
>>... my 2 cents worth ...
>>
>>**********************************************
>>* Don Wright don@lexmark.com *
>>* Product Manager, Strategic Alliances *
>>* Lexmark International *
>>* 740 New Circle Rd *
>>* Lexington, Ky 40550 *
>>* 606-232-4808 (phone) 606-232-6740 (fax) *
>>**********************************************
>>
><html>
><font size=3>Actually the default port never hits the wire either.&nbsp;
>Both the default port <br>
>and the ipp scheme-name are smoke and mirrors on the client which give
>the <br>
>illusion of an ipp scheme.<br>
><br>
>On the wire there is nothing but http with default port 80.<br>
><br>
>If the IPP RFC's should specify wire protocol only, then they should not
><br>
>discuss ipp schemes or default ports. If we believe the IPP RFC's should
><br>
>give some hints for implementing clients, then the proposal from Randy
>about <br>
>the ipp scheme and default ports is reasonable except for the last
>line.<br>
><br>
>Bob Herriot<br>
><br>
>At 05:04 PM 6/16/98 , don@lexmark.com wrote:<br>
>&gt;The more I think about this, the more I think it is out of scope for
>the<br>
>&gt;work we are doing.&nbsp; We are working on the wire protocol and
>encoding for<br>
>&gt;IPP, so ...<br>
>&gt;<br>
>&gt;- Getting a port number allocated for IPP is OK<br>
>&gt;- Specifying that port as the default port is OK<br>
>&gt;- Creating a new scheme that never hits the wire and is handled
>inside<br>
>&gt;clients and servers is NOT a wire protocol issue.<br>
>&gt;<br>
>&gt;While I think this material could be a interesting proposal and
>possibly an<br>
>&gt;informational RFC or maybe even more, I don't think it belongs in
>the<br>
>&gt;standard track RFCs that define IPP.&nbsp; While I am against a new
>method, at<br>
>&gt;least it is a wire level issue.<br>
>&gt;<br>
>&gt;... my 2 cents worth ...<br>
>&gt;<br>
>&gt;**********************************************<br>
>&gt;* Don
>Wright&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;
>don@lexmark.com *<br>
>&gt;* Product Manager, Strategic
>Alliances&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; *<br>
>&gt;* Lexmark
>International&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
>*<br>
>&gt;* 740 New Circle
>Rd&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
>*<br>
>&gt;* Lexington, Ky
>40550&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
>*<br>
>&gt;* 606-232-4808 (phone) 606-232-6740 (fax)&nbsp;&nbsp;&nbsp; *<br>
>&gt;**********************************************<br>
>&gt; </font><br>
></html>
>