If you're only talking in abstract or high-level modeling
terms, then sure, I can see where you don't see the issue.
Exactly what does transport-independent mean, anyway?
One school of thought believes that identifiers (such
as URIs) should be transport-independent as well. They
certainly could be, afterall.
However, an IPP implementation that uses mailto:job at host
as an indentifier will not be very interoperable with one
that uses ftp://host/job.
That is the issue, I believe. Comments from others??
...jay
----------------------------------------------------------------------
-- JK Martin | Email: jkm at underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------
Josh Cohen wrote:
>> I dont see exactly what the issue is.
> Having a job-uri, or using URIs for naming and identification
> doesnt link the IPP protocol to HTTP at all. URIs are
> a fine way to manage a unique namespace, even if your
> not using HTTP.
> Technically, if IPP is deployed over any other protocols,
> you can still use URIs. Lets say, for example, that you
> deployed IPP over FTP or SMTP. If you did this then
> your job-uri would be ftp://host/job or mailto:job at host,
> respectively.
> If you used IPP over another protocol, you could likely
> define a new URI scheme to represent it.
>> > -----Original Message-----
> > From: Paul Moore [mailto:paulmo at microsoft.com]
> > Sent: Thursday, June 04, 1998 11:43 AM
> > To: 'Jay Martin'; ipp at pwg.org> > Subject: RE: IPP> Why must IPP be transport-independent?
> >
> >
> > One point - this is othogonal to much of the 'URI in the
> > protocol' question.
> > As job-id vs job-uri shows there are still areas where this
> > is a problem
> > even if we decide to only do IPP on HTTP.
> >
> >
> > > -----Original Message-----
> > > From: Jay Martin [SMTP:jkm at underscore.com]
> > > Sent: Thursday, June 04, 1998 11:28 AM
> > > To: ipp at pwg.org> > > Subject: IPP> Why must IPP be transport-independent?
> > >
> > > After reading Paul Moore's posting (below), it appears
> > > that we are digger ourselves a deeper and deeper hole
> > > to fall into.
> > >
> > > Must IPP be transport-independent?
> > >
> > > I say "No". IPP stands for "Internet Printing Protocol",
> > > not something like "Generic Printing Protocol", or "Universal
> > > Printing Protocol". It was designed for use on the Internet.
> > >
> > > Sure, there are some in the IPP WG who believe IPP can
> > > and *should* become the single, all-encompassing printing
> > > protocol for use in almost any environment.
> > >
> > > I (and others) say "hogwash". Microsoft and Northlake Software
> > > have done a good job in delineating areas in which the IPP
> > > design falls very short in providing the kind of session-
> > > oriented protocol to achieve the kinds of capabilities that
> > > already exist in TIP/SI, CPAP and others.
> > >
> > > If HTTP is going to be the first and primary reference
> > > implementation of IPP (damn the nay-sayers...), then why
> > > can't we just tie IPP onto HTTP (semantics, syntax et al)
> > > and be done with it?
> > >
> > > Let the SDP project deal with other non-HTTP-oriented
> > > requirements. We'll just strive to make the mapping
> > > from IPP to SDP as easy and painless as possible.
> > >
> > > ...jay
> > >
> > >
> > ----------------------------------------------------------------------
> > > -- JK Martin | Email: jkm at underscore.com> > --
> > > -- Underscore, Inc. | Voice: (603) 889-7000
> > --
> > > -- 41C Sagamore Park Road | Fax: (603) 889-2699
> > --
> > > -- Hudson, NH 03051-4915 | Web:
>http://www.underscore.com --
> > ----------------------------------------------------------------------
> >
> >
> > Paul Moore wrote:
> > >
> > > It seem to me that the fundamental question comes down to -
> > should
> > > the IPP protocol form, transmit and use information that is specific to
> > the
> > > underlying transport.
> > >
> > > We have chosen to use URI as our way of identifying endpoints.
> > The
> > > assumptions we make about these URIs (there actual syntax is irrelevant)
> > > are:-
> > > a) an agent knows how to form them
> > > b) the only thing an agent may do with a URI it receives to it
> > is to
> > > pass it to its underlying transport. This means that the creator of the
> > URI
> > > MUST use the same URI forming convention as that which will be used by
> > the
> > > receivers transport stack (ie. this is not a private issue for a given
> > > implementation). It also means that the receiver may not look at the URI
> > to
> > > infer any deeper meaning (because that is a private issue for the
> > sending
> > > implementation).
> > > This last restriction made us invent job-id. We moved to
> > explicitly
> > > stating in IPP the way of identifying an endpoint.
> > > The real problem is that we end up with leakage from the
> > transport
> > > up into the IPP layer. I cannot blindly forward requests from
> > > IPP-on-protocolX to IPP-on-protocolY. I have to find all the URIs and
> > change
> > > them on the fly.
> > > There is another problem that assumpion b causes. It assumes
> > that a
> > > printer knows how to form an address (URI) that makes sense in the
> > clients
> > > transport stack. This is true for HTTP but not true (or certainly
> > > non-trivial) for other transports.
> > >
> > > I would propose that we use an adressing scheme that corresponds
> > to
> > > the transport endpoint only. We then specifiy in IPP the ways of
> > identifying
> > > the logical object that we wish to talk to (printer-ID, Job-ID,...).