Ron,
I think Keith is suggesting that we use a different port and that we won't
have much of a problem making the case:
> if you don't want to
> use the same port as for IPP (and I can imagine instances where this
> would cause problems) then you should allocate another port.
and:
Personally, I don't think you have to make a big case for allocating
another port. Indeed, I would be surprised if you wanted to reuse
the IPP port for notifications.
A server that receives notifications is different than a printer server.
If you were to operate both on the same host, you might want them to
be different processes (perhaps even supplied by different vendors),
which implies that they need to be different ports.
We need to remember that there are always two firewall administrators
involved with any interaction:
1. The outbound administrator
2. The inbound administrator
We have to have both allowing traffic, or the traffic doesn't get through.
Tom
-----Original Message-----
From: Ron Bergman [mailto:rbergma at mailgate.dpc.com]
Sent: Friday, November 05, 1999 16:10
To: Hastings, Tom N
Cc: Keith Moore; Ron Bergman; ipp; Parra, Hugo
Subject: Re: IPP> NOT - How about using a new HTTP method for the "IPP
Notification Delivery Protocol over HTTP"
Tom,
I did not interpret Keith's response the same as you did. I do not see a
new
port and scheme mandated, but I do see a need to justify our position
regardless of which path we take. To quote Keith:
"If you use the IPP port I think ipp: would be okay."
My only concern is that we have not made a sufficient case for a new port
and
scheme. Just saying it is a different protocol is not sufficient.
Certainly
Paul Moore believed that it is not a new protocol. This issue needs more
discussion.
Ron Bergman
Hitachi Koki Imaging Solutions
'
"Hastings, Tom N" wrote:
> Keith,
>> Thanks for answering all our questions about the "IPP Notification
Delivery
> Protocol over HTTP".
>> So we'll use a new URL scheme: 'ipp-ntfy' with a new default port to be
> assigned by IANA.
>> And we'll use the same post HTTP method, rather than a new HTTP method.
>> We'll update the INTERNET-DRAFT accordingly.
>> Thanks,
> Tom
>> -----Original Message-----
> From: Keith Moore [mailto:moore at cs.utk.edu]
> Sent: Thursday, November 04, 1999 18:56
> To: Hastings, Tom N
> Cc: Ron Bergman; moore at cs.utk.edu; ipp
> Subject: Re: IPP> NOT - How about using a new HTTP method for the "IPP
> No tification Delivery Protocol over HTTP"
>> I glanced over the draft -won't have time to read it in detail
> until mid-November at the earliest.
>> some notes, mostly typed in before I read the draft:
>> - IPP notifications should not default to port 80. if you don't want to
> use the same port as for IPP (and I can imagine instances where this
> would cause problems) then you should allocate another port.
>> if you let the port be setable on notificaiton servers, and if you let
> the requestor of the notification specify the URL to
> which the notification should be sent, then the port assignment is
> less of an issue - it can be specified in the URL using whatever
> port will get through the various firewalls that might be in
> the way (if there is such a port at all!) still, it would be better
> to have a port number allocated for this purpose, even if the requestor
> can specify a different port number, as this minimizes conflict.
>> - similarly, IPP notifications should not use http:. If you
> use the IPP port I think ipp: would be okay. If you define a
> completely new port a new prefix would be appropriate.
> I'd like to avoid the situation where the default port
> for URL type xyz: is different depending on what you're
> using it for - let's keep a one-to-one correspondence between
> URLs and default ports.
>> - Defining a new HTTP method is okay, and the HTTP crowd will be
> happier about it than if you use POST again. But you're already
> using POST for IPP, so I don't see any reason to insist that you define
> a new method for IPP notifications.
>> does this answer the questions?