IPP Mail Archive: IPP> COL - Updated 'collection' attribute

IPP Mail Archive: IPP> COL - Updated 'collection' attribute

IPP> COL - Updated 'collection' attribute syntax document down loaded and sent as I-D 02

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Fri Mar 10 2000 - 20:21:51 EST

  • Next message: Manros, Carl-Uno B: "IPP> ADM - Lots of new IPP drafts in the pipeline"

    I've updated the collection specification as discussed at the recent
    telecons and on the mailing list. This is mainly a collaboration between
    Peter Zehler, Bob Herriot, and myself. We've each written parts of it. I
    regret that it has been put together in such haste, so there are obvious
    things that need work. I've sent this version as an Internet-Draft as well
    (Internet-Draft are works in progress, so this one certainly fits that
    description).

    This version includes the three encoding solutions (1a, 1b, and 2) in it
    that Bob sent out as a separate mail message. Please respond to that mail
    message about which encoding technique to use for maximum compatibility with
    IPP/1.1 recipients (clients and Printers) for comments on which encoding
    technique to use.

    Please send any comments about the rest of the document to the mailing list.
    We'd also like to discuss this at the next IPP telecon, Wed, 3/15 as well.

    ftp://ftp.pwg.org/pub/pwg/ipp/new_COL/draft-ietf-ipp-collection-02.txt
    ftp://ftp.pwg.org/pub/pwg/ipp/new_COL/ipp-collection-attr-syntax-000309.doc
    ftp://ftp.pwg.org/pub/pwg/ipp/new_COL/ipp-collection-attr-syntax-000309.pdf
    ftp://ftp.pwg.org/pub/pwg/ipp/new_COL/ipp-collection-attr-syntax-000309.txt
    ftp://ftp.pwg.org/pub/pwg/ipp/new_COL/ipp-collection-attr-syntax-000309-rev.
    doc
    ftp://ftp.pwg.org/pub/pwg/ipp/new_COL/ipp-collection-attr-syntax-000309-rev.
    pdf

    Regrettably, the page numbers stick out beyond column 72. A causality in
    the rush.

    Here is the Abstract:

            This document specifies an OPTIONAL attribute syntax called
    'collection' for use with the Internet Printing Protocol/1.0 (IPP) [RFC2565,
    RFC2566], IPP/1.1 [ipp-mod, ipp-pro], and subsequent versions. A
    'collection' is a container holding one or more named values, which are
    called "member" attributes. A collection allows data to be grouped like a
    PostScript dictionary or a Java Map.

    Here is the Solution section 2:

    The new mechanism is a new IPP attribute syntax called a 'collection'. As
    such each collection value is a value of an attribute whose attribute syntax
    type is defined to be a 'collection'. Such an attribute is called a
    collection attribute. The name of the collection attribute serves to
    identify the collection value in an operation request or response, as with
    any attribute value.
    The 'collection' attribute syntax is a container holding one or more named
    values (i.e., attributes), which are called member attributes. Each
    collection attribute definition document lists the mandatory and optional
    member attributes of each collection value. A collection value is similar to
    an IPP attribute group in a request or a response, such as the operation
    attributes group. They both consist of a set of attributes.
    As with any attribute syntax, the collection attribute definition document
    specifies whether the attribute is single-value (collection) or multi-valued
    (1setOf collection).
    The name of each member attribute MUST be unique, but MAY be the same as the
    name of a member attribute in another collection type and/or MAY be the same
    as the name of an attribute that is not a member of a collection.. The
    rules for naming member attributes are given in section 3.1.
    Each member attribute can have any attribute syntax type, including
    'collection', and can be either single-valued or multi-valued. The length
    of a collection value is not limited. However, the length of each member
    attribute MUST NOT exceed the limit of its attribute syntax.
    The member attributes in a collection MAY be in any order in a request or
    response. When a client sends a collection attribute to the Printer, the
    order that the Printer stores the member attributes of the collection value
    and the order returned in a response MAY be different from the order sent by
    the client.
    A collection value MUST NOT contains two or more member attributes with the
    same attribute name. Such a collection is mal-formed. Clients MUST NOT
    submit such malformed requests and Printers MUST NOT return such malformed
    responses. If such a malformed request is submitted to a Printer, the
    Printer MUST reject the request with the 'client-error-bad-request' status
    code (see section 13.1.4.1)
    ISSUE 01: In attribute groups [ipp-mod] allows a Printer either (1) to
    reject a request with duplicate named attributes OR (2) to choose exactly
    one of the attributes as the one to be used. Should we REQUIRE the Printer
    to reject duplicate named attributes in a collection value as stated above
    or allow the Printer to choose one member attribute as a second alternative
    as we do with attribute groups?

    The other two issues are:

    ISSUE 02: Which encoding do we want to use for collections, 1a, 1b, or 2?

    ISSUE 03 - Since this is intended to be a standards track document, do we
    also register the 'collection' attribute syntax codes (begCollection and
    endCollection) with IANA?

    Answer to the third issue is probably not, since it is intended to be a
    standards track document.

    Tom



    This archive was generated by hypermail 2b29 : Fri Mar 10 2000 - 20:27:59 EST