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

Randy Turner <rturner@sharplabs.com> Fri, 03 July 1998 00:11 UTC

Delivery-Date: Thu, 02 Jul 1998 20:11:31 -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 UAA11987 for <ietf-archive@ietf.org>; Thu, 2 Jul 1998 20:11:29 -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 UAA23888 for <ietf-archive@cnri.reston.va.us>; Thu, 2 Jul 1998 20:13:50 -0400 (EDT)
Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA13765 for <ietf-archive@cnri.reston.va.us>; Thu, 2 Jul 1998 20:11:26 -0400 (EDT)
Received: by pwg.org (bulk_mailer v1.5); Thu, 2 Jul 1998 20:07:11 -0400
Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA13155 for ipp-outgoing; Thu, 2 Jul 1998 20:04:11 -0400 (EDT)
Message-Id: <199807030005.RAA10539@mail.pacifier.com>
X-Sender: rturner@webmail.sharplabs.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Thu, 02 Jul 1998 17:00:13 -0700
To: Carl-Uno Manros <carl@manros.com>, Keith Moore <moore@cs.utk.edu>
From: Randy Turner <rturner@sharplabs.com>
Subject: Re: IPP> regarding "ipp:" (I spoke too soon...)
Cc: ipp@pwg.org
In-Reply-To: <1.5.4.32.19980702153111.00745da0@pop3.holonet.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipp@pwg.org

There were no operational problems with the proposal, I think what the
group boiled down to was that creating a new "ipp" scheme just for end-user
convenience was not enough justification. I don't remember any specific
examples of how the proposal would break if deployed.

Randy


At 08:31 AM 7/2/98 -0700, Carl-Uno Manros wrote:
>Keith,
>
>Please see this attachment which describes the proposal worked out by Randy
>Turner and Larry Masinter. Case 3 in that proposal caused a number of people
>to object, pointing out that the previous assumption that ipp: would not be
>used over the wire was not true any more. There was also discussion about
>which format the IPP Printer generated Job URIs should have. They are hardly
>ever seen by and end user and could as well be in http: format. The result
>would have been that the client would have had to cover for  URIs coming
>back in either scheme and always have to be able to convert between them.
>The more we discussed this, the more causes we found that the ipp: scheme
>was not such a bright idea after all. As for the suggestion to include a
>security paramter in the ipp: scheme, this was adviced against also by Randy
>and Larry, as it would make the ipp: non-mappable in the http: to ipp:
>direction. We believe that the current solution to identify what security is
>supported by a printer works well without the need for a parameter in the
>scheme.
>
>This is my short answer and explanation right now. I assume that other
>members of the WG can give you further arguments, but many have already
>started their July 4th celebrations.
>
>Carl-Uno
>
>At 12:46 AM 7/2/98 -0400, you wrote:
>>On a careful re-reading the list of resolutions for the IPP 
>>documents, I was surprised to see that the WG had decided not 
>>to adopt an "ipp:" URL prefix.  (I was out of town last
>>week and unable to follow the list as closely as I would
>>have liked.)
>>
>>In my earlier poll of IESG there was strong agreement that both
>>a separate port and a new URL prefix were needed, though the
>>questions were not asked separately  We're having a phone 
>>conference on July 2 (today or tomorrow depending on your
>>current time zone), so I'll ask them again just to be sure.
>>
>>Other than the issue with interoperability with http proxies 
>>(which are easily addressed), I'd like to know what the
>>technical problems were with using an "ipp:" prefix.  I've
>>reviewed most of the list discussion since the teleconference
>>that I participated in, and didn't see any good explanation
>>of why this would cause problems.
>>
>>Keith
>>
>>
>
>
>