IPP Mail Archive: RE: IPP> Supported URIs for print-by-reference

RE: IPP> Supported URIs for print-by-reference

Turner, Randy (rturner@sharplabs.com)
Wed, 24 Sep 1997 15:24:23 -0700

The FILE URL would be used if the server itself somehow advertised the
availability of
a local file that could be transferred. I don't think I was implying
that the user would
have to formulate the absolute FILE: pathname, since I myself have had
problems
with interoperability in certain client browsers with incorrect FILE:
URL evaulations.
But if the IPP server (or parent HTTP site) advertised the file then I
think the syntax
should be acceptable to that particular site's server.

Randy

> -----Original Message-----
> From: Larry Masinter [SMTP:masinter@parc.xerox.com]
> Sent: Tuesday, September 23, 1997 11:15 PM
> To: Randy Turner
> Cc: ipp@pwg.org
> Subject: Re: IPP> Supported URIs for print-by-reference
>
> > At the meeting in Atlanta, it was agreed that we would mandate that
> both
> > FTP and HTTP would be supported schemes for PrintURI and SendURI.
> >
> > I would like to propose that we also include the FILE: scheme to
> this
> > list. The FILE: scheme allows the server to print files that are
> > available
> > on locally mounted file system volumes that are available to the
> server
> > itself.
> >
> > We can talk about this at the teleconference or on the list.
>
>
> a) without a standard way of loading a print server's disks with
> any data, mandating support for the "file:" scheme would hardly
> lead to interoperability.
>
> b) While one can imagine "if you support remote printing at all,
> you should be able to retrieve files from an HTTP server", since
> it just requires a network connection, it doesn't make as much
> sense to mandate a "file:" scheme because it presumes that the
> print server has a file system with a naming system that is URL
> accessible.
>
> c) the "file:" URL scheme is in serious need of attention: the
> implementations (even on the same platform) are widely divergent,
> and not conformant with the recommended practice in the RFCs.
>
> It's not that this is really a terrible idea, it's just not clear
> that it's useful to "mandate" something that by most measures
> has to be optional.
>
> Larry
> --
> http://www.parc.xerox.com/masinter