IPP> NOT - How about using a new HTTP method for the "IPP Notification Delivery Protocol over HTTP"

IPP> NOT - How about using a new HTTP method for the "IPP Notification Delivery Protocol over HTTP"

IPP> NOT - How about using a new HTTP method for the "IPP Notification Delivery Protocol over HTTP"

Ron Bergman rbergma at mailgate.dpc.com
Fri Nov 5 19:09:44 EST 1999


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?




More information about the Ipp mailing list