Subject: IPP> MOD - Outside the box resolution for the two URIs issue

From: Carl-Uno Manros <[email-masked]>
Date: Mon, 5 Jan 1998 15:59:39 PST

I got some private feedback from Larry Mainter on this issue, which
triggered some further thoughts that I wanted to share with you.

I like Bob's approach because it provides the functionality within IPP,
while Randy's approach might be easier to implement, but makes us dependent
on HTTP functionality for redirects, which may not be available in other
transfer protocols.

Maybe we should think outside the box instead. Larry asked why do we limit
ourselves to TWO URIs?  Thinking about extensibility, I think Larry has a
point.

If we want to add a new mapping for IPP on top of HTTP NG or whatever and
the IPP server can support both that and the current HTTP and HTTPS
mappings, where do we put the additional URI in the IPP protocol? If
instead, we made the Printer URI a MULTI-VALUED attribute, we could add any
number of future transfer protocols for the same IPP Printer without having
to revise our model. The IPP client would probably need to understand the
scheme part of the URI, but could then choose any of the offered URI
alternatives, with more or less security etc. We would probably need to add
some rules about whether the same transfer protocol has to be used for a
particular IPP Job, or if the client can use different ones, provided that
the same level of security is maintained. Another question is whether the
IPP Server would always return Job URIs with the same scheme as the one
with which the job request was submitted. A consequence of this propoal is
that directory entries might have multiple URIs for the same IPP Printer.

Is this approach worth further discussion?

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: Tom Hastings <[email-masked]>
Date: Tue, 6 Jan 1998 12:40:48 PST

Refining this proposal a bit (after discussions with Scott and Carl-Uno):

The changes to the current Model document would be:

1. Remove the "printer-tls-uri" attribute from the Printer object and
the directory.
2. Rename the "printer-uri" Printer and Directory attribute to 
"printer-uri-supported" and make it multi-valued, i.e., 1setOf uri.
3. Keep the "printer-uri" Operation attribute as a single-valued
attribute that is the uri being used on this operation.  Thus its single
value is just like the single value of the "document-format" operation
attribute, i.e., one of the values of the curresponding "xxx-suported"
attribute ("printer-uri-supuported" in this case).