Re: IPP> regarding "ipp:" (I spoke too soon...)

Keith Moore <moore@cs.utk.edu> Thu, 02 July 1998 18:26 UTC

Delivery-Date: Thu, 02 Jul 1998 14:26:21 -0400
Return-Path: ipp-owner@pwg.org
Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA09303 for <ietf-archive@ietf.org>; Thu, 2 Jul 1998 14:26:21 -0400 (EDT)
Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA22659 for <ietf-archive@cnri.reston.va.us>; Thu, 2 Jul 1998 14:28:40 -0400 (EDT)
Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA00886 for <ietf-archive@cnri.reston.va.us>; Thu, 2 Jul 1998 14:26:16 -0400 (EDT)
Received: by pwg.org (bulk_mailer v1.5); Thu, 2 Jul 1998 14:22:10 -0400
Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA00301 for ipp-outgoing; Thu, 2 Jul 1998 14:18:30 -0400 (EDT)
Message-Id: <199807021816.OAA11217@spot.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
From: Keith Moore <moore@cs.utk.edu>
To: Paul Moore <paulmo@microsoft.com>
cc: "'Keith Moore'" <moore@cs.utk.edu>, ipp@pwg.org, moore@cs.utk.edu
Subject: Re: IPP> regarding "ipp:" (I spoke too soon...)
In-reply-to: Your message of "Thu, 02 Jul 1998 10:53:32 PDT." <CB6657D3A5E0D111A97700805FFE6587BF6E27@red-msg-51.dns.microsoft.com>
Date: Thu, 02 Jul 1998 14:16:24 -0400
Sender: owner-ipp@pwg.org

> My fundamental objection is that we are being asked to use a new concept
> 'psuedo-schemes' without this idea being drilled into at all. There should
> at least be an I-Draft discussing the idea.

Actually, it's the other way around.  IPP is designing a new protocol.
It happens to look a lot like HTTP, and there's no problem with that.
But the notion that IPP can insist that their protocol should use 
the same URL type as an existing protocol, is a significant departure 
from well-established practice that requires substantial justification.  
 
> Secondly there were many details that needed to be clarified. Was this
> simply a client convenience or did 'ipp:' ever go over the wire being the
> deepest one. The general idea seems to be that it is a user convenience
> thing. 

No, ipp: needs to go over the wire in all of the IPP protocol elements.

> In this case it is a client implementation issue and has nothing to
> do with the wire protocol (which is what this discussion is about) and so
> should not be accepted. 

It's not just a client implementation issue; it affects servers also.

Nearly every new protocol these days gets a new URL type.  
The issues with use of ipp: are no worse than for any other protocol.

Keith