IPP Mail Archive: RE: IPP> I-D ACTION:draft-ietf-ipp-url-sch

IPP Mail Archive: RE: IPP> I-D ACTION:draft-ietf-ipp-url-sch

RE: IPP> I-D ACTION:draft-ietf-ipp-url-scheme-00.txt

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Mon Jan 22 2001 - 18:49:35 EST

  • Next message: Carl Kugler: "RE: IPP> I-D ACTION:draft-ietf-ipp-url-scheme-00.txt"

    Hi Carl,

    I was directed to REMOVE discussion of backward
    compatibility with IPP/1.0, because the IETF docs
    (RFC 2565/2566) for IPP/1.0 do not specify the
    use of the 'ipp:' URL scheme (although many
    implementations of IPP/1.0 correctly accept and
    process 'ipp:' URL schemes in clients and servers).

    Cheers,
    - Ira McDonald, co-editor of 'ipp:' URL scheme I-D
      High North Inc

    -----Original Message-----
    From: Carl Kugler [mailto:kugler@us.ibm.com]
    Sent: Wednesday, January 17, 2001 10:11 AM
    To: ipp@pwg.org
    Subject: RE: IPP> I-D ACTION:draft-ietf-ipp-url-scheme-00.txt

    What ever happened to the section about backward compatibility with
    IPP/1.0? It used to be in

         ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-scheme-981116.doc

         -Carl

    1 Compatibility with IPP/1.0
    For compatibility with IPP/1.0, clients and IPP objects (i.e. a server)
    MUST support additional schemes as described in this section:

    If a server receives an IPP/1.0 request, it MUST return an IPP/1.0
    response. That is, it MUST support an http-URL in the target "printer-uri"
    and "job-uri" operation attributes in a request. If the server returns any
    of the 3 attributes, "job-uri", "job-printer-uri" or
    "printer-uri-supported" in the response, the value of these attributes MUST
    be http-URLs. For security, a server MAY also support https-URLs.
    When a server returns the printer attribute "printer-uri-supported",
    it MUST return all supported values for an IPP/NV request. For an IPP/1.0
    request, a server MUST NOT return values that are ipp-URLs, i.e. it MUST
    return only the http-URLs and https-URLs.
    The table below shows the type of URL that a server returns for the
    "job-uri" and "job-printer-uri" job attributes for all operations based on
    how the job was created. The "or" in the table below indicates an
    implementation option.
           |-----------+------------------------------------|
           | Operation | Job created via |
           | attributes| |
           | for a | |
           | request | |
           |-----------+------------------------------------|
           | | ipphttphttps |
           |-----------+------------------------------------|
           | ipp | ippippNo URL returned |
           |-----------+------------------------------------|
           |http | httphttpNo URL returned |
           |-----------+------------------------------------|
           |https | https or httphttps or httphttps |
           |-----------+------------------------------------|

             If a server registers an ipp-URL with a name service, then it
            MUST also register an http-URL. If a printer supports a secure
            connection using SSL3, then it MUST register an https-URL.
             An IPP/NV client MUST use an ipp-URL for non-secure printers
            unless it receives a "version not supported" error message. Then it
            MUST try to send a request in version 1.0, using the http-URL in
            place of the ipp-URL for the target "job-uri" and "printer-uri"
            operation attributes in the request. For secure printers, an IPP/NV
            client must operate as an IPP/1.0 client and use an https-URL. An
            IPP/1.0 client MUST use an http-URL for non-secure printers and an
            https-URL for secure printers.

    --- In ipp@egroups.com, "Hastings, Tom N" <hastings@c...> wrote:
    I've made a .pdf file with line numbers from the .txt I-D and posted
    both of
    them at:

    ftp://ftp.pwg.org/pub/pwg/ipp/new_URL/draft-ietf-ipp-url-scheme-00.pdf
    ftp://ftp.pwg.org/pub/pwg/ipp/new_URL/draft-ietf-ipp-url-scheme-00.txt

    As usual, send any comments to the DL. This will also be on the
    agenda for
    next week's IPP WG meeting and maybe today's telecon, if callers want
    to
    discuss.

    Tom

    -----Original Message-----
    From: Internet-Drafts@i... [mailto:Internet-Drafts@i...]
    Sent: Monday, January 15, 2001 03:45
    Cc: ipp@p...
    Subject: IPP> I-D ACTION:draft-ietf-ipp-url-scheme-00.txt

    A New Internet-Draft is available from the on-line Internet-Drafts
    directories.
    This draft is a work item of the Internet Printing Protocol Working
    Group of
    the IETF.

         Title : Internet Printing Protocol (IPP): IPP URL
    Scheme
         Author(s) : R. Herriot, I. McDonald
         Filename : draft-ietf-ipp-url-scheme-00.txt
         Pages : 15
         Date : 12-Jan-01

    This document is a product of the Internet Printing Protocol Working
    Group of the Internet Engineering Task Force (IETF). Comments should
    be submitted to the ipp@p... mailing list.

    A URL for this Internet-Draft is:
    http://www.ietf.org/internet-drafts/draft-ietf-ipp-url-scheme-00.txt

    Internet-Drafts are also available by anonymous FTP. Login with the
    username
    "anonymous" and a password of your e-mail address. After logging in,
    type "cd internet-drafts" and then
         "get draft-ietf-ipp-url-scheme-00.txt".

    A list of Internet-Drafts directories can be found in
    http://www.ietf.org/shadow.html
    or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

    Internet-Drafts can also be obtained by e-mail.

    Send a message to:
         mailserv@i...
    In the body type:
         "FILE /internet-drafts/draft-ietf-ipp-url-scheme-00.txt".

    NOTE: The mail server at ietf.org can return the document in
         MIME-encoded form by using the "mpack" utility. To use this
         feature, insert the command "ENCODING mime" before the "FILE"
         command. To decode the response(s), you will need "munpack"
    or
         a MIME-compliant mail reader. Different MIME-compliant mail
    readers
         exhibit different behavior, especially when dealing with
         "multipart" MIME messages (i.e. documents which have been
    split
         up into multiple messages), so check your local documentation
    on
         how to manipulate these messages.

    Below is the data which will enable a MIME compliant mail reader
    implementation to automatically retrieve the ASCII version of the
    Internet-Draft.
    --- End forwarded message ---



    This archive was generated by hypermail 2b29 : Mon Jan 22 2001 - 18:51:00 EST