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

From: Paul Moore <[email-masked]>
Date: Thu, 2 Jul 1998 10:53:32 -0700

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.

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. 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. If its meant to appear on the wire then this raises
a whole bunch of issues that we havent even thought about - and the only
benefit is to make the url slightly more user friendly.

-----Original Message-----
From: Keith Moore [mailto:[email-masked]]
Sent: Wednesday, July 01, 1998 9:46 PM
To: [email-masked]
Cc: [email-masked]
Subject: IPP> regarding "ipp:" (I spoke too soon...)

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

---

From: Keith Moore <[email-masked]>
Date: Thu, 02 Jul 1998 14:16:24 -0400

> 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.  
 
> 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
> 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

---

From: Carl-Uno Manros <[email-masked]>
Date: Thu, 2 Jul 1998 11:51:23 PDT

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

Keith,

I think that this is where the disconnect is. 

I know that most of the people who participated in the phone conference
with you on this subject, heard you stating that ipp: was NOT going over
the wire, which is why you thought that the WG had accepted your proposal.

When it became clear that ipp: is INDEED going over the wire, people
disagreed with your proposal.

Are going to insist on ipp: in order to pass on the IPP specs?

Carl-Uno
Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: [email-masked]

---

From: Keith Moore <[email-masked]>
Date: Thu, 02 Jul 1998 16:18:24 -0400

> Are going to insist on ipp: in order to pass on the IPP specs?

IESG is.  Nobody could make a case for it being any other way.

Keith