IPP Mail Archive: RE: IPP> MOD - New attribute metadata prop

IPP Mail Archive: RE: IPP> MOD - New attribute metadata prop

RE: IPP> MOD - New attribute metadata proposal

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Fri Mar 17 2000 - 20:09:01 EST

  • Next message: McDonald, Ira: "IPP> NOT - IPP Notify over SNMP (Job Mon traps) v0.2 - 19 March 2000"

    Ira,

    Interesting start!

    Here are my comments:

    1. It would be nice to produce a complete syntax for IPP/1.1 according to
    this. Any volunteers?

    2. We at least need a bunch of examples. See below to see if I'm getting it
    at all.

    3. The "syntax" facts should have the current values listed (to get the case
    right and clarify that the WithoutLanguage and WithLanguage forms aren't
    included) and indicate that additional values as they are defined by
    standards track documents (I included "collection").

    "text" | "name" | "keyword" | "enum" | "uri" | "uriScheme" | "charset" |
    "naturalLanguage" | "mimeMediaType" | "octetString" | "boolean" | "integer"
    | "rangeOfInteger" | "dateTime" | "resolution" | "collection" | "1setOf X"

    4. Presumably we need to be able to include " ", "(", ")", "*", "-", and "|"
    in the token-char, for example:

       "syntax" = "1setOf (type2 keyword | name)"
       "maxint" = "2 ** 31 -1"

    ISSUE 01 - Or should we use "MAX" that depends on the data type, thereby
    simplifying the syntax of fact values?

    5. ISSUE 02: Should the min and max integer values and the maximum string
    values be indicated using parens as we already do in IPP, or as separate
    metadata facts. In other words, is the following clearer for several facts
    for the "job-metadata-attributes-supported":

    ISSUE 03: I'm not sure whether the " are to be included or not?

    With metadata fact names:

       "name" = "media" "syntax" = "type3 keyword | name"
       "minlen" = "1" "maxlen" = 255;
       "name" = "job-k-octets" "syntax" = "integer" "minint" = 0
       "maxint" = "2**31 - 1"

    Without most metadata fact names:

       "name" = "media" "syntax" = "type3 keyword | name(255)"
       "minlen" = "1";
       "name" = "job-k-octets" "syntax" = "integer(0:2**31-1)"

    ISSUE 04: Do we really need the "minlen" for strings? We've said that 0
    length is always valid for 'text' and 'name'?

    If we get rid of "minlen" factname, then we could use the notation we have
    in the model directly. Then we would only have two facts: "name" and
    "syntax". But if we can simplify to two, why not just have the attribute
    name and the syntax without any fact names. Also we could include the
    syntax value inside parens, like we do in the Model, instead of inside "".
    Finally, why do we need the "=":

    So the above two entries for the "job-metadata-attributes-supported" Printer
    Description attribute would become simply:

       "media" (type3 keyword | name(255));
       "job-k-octets" (integer(0:2**31-1))

    If an implementation didn't support the OPTIONAL name syntax for "media",
    that implementation's value would be:

       "media" (type3 keyword);
       "job-k-octets" (integer(0:2**31-1))

    For the corresponding "printer-metadata-attributes-supported" Printer
    Description attribute would become simply:

       "media-supported" (1setOf (type3 keyword | name(255)));
       "job-k-octets" (integer(0:2**31-1))

    If an implementation didn't support the OPTIONAL name syntax for "media",
    that implementation's value would be:

       "media-supported" (1setOf (type3 keyword));
       "job-k-octets" (integer(0:2**31-1))

    ISSUE 05: Do we even need the " around the attribute names?

    5. ISSUE 06: We also need to decide how to represent the out of band values.

    Are they included as if they were syntaxes: 'unsupported', 'unknown',
    'no-value', 'not-settable', 'delete-attribute', and 'any-value'?

       "media-supported" = (1setOf (type3 keyword | name(255) | unknown |
    no-value | any-value));
       "job-k-octets-supported" = (integer(0:2**31-1) | unknown | no-value)

    6. In writing out these examples, it occurred to me that some of the
    out-of-band values depend on the operation request and/or response. For
    example, the 'unsupported' out-of-band value is only allowed in the
    Unsupported Attributes Group in responses, the 'delete-attribute' value is
    only allowed as the value of an attribute in the Set-Job-Attributes request,
    and the 'any-value' is only allowed in the syntax for "xxx-supported" in a
    Get-Printer-Values-Supported response (so far, but could be extended to
    "xxx-supported" in a Get-Printer-Attributes response).

    ISSUE 07: How do we represent the meta data for out-of-band values used in
    requests and responses, as opposed to being a value of an object attribute
    that is returned in a Get-Xxxx-Attributes response?

    ISSUE 08: What about meta data for operation attributes?

    ISSUE 09: What about meta data for operations? Most important might be
    meta data for Set-Printer-Attributes operations as opposed to
    Get-Printer-Attributes operations. The syntaxes for Set-Job-Attributes is
    the same as the syntaxes for Get-Job-Attributes (I think, with the addition
    of the 'delete-attribute' for Set-Job-Attributes). If setting is always a
    superset of Get, then the Set meta data could be just the additional values
    that can be set.

    Tom

    -----Original Message-----
    From: McDonald, Ira [mailto:imcdonald@sharplabs.com]
    Sent: Thursday, March 16, 2000 18:07
    To: 'ipp@pwg.org'
    Subject: IPP> MOD - New attribute metadata proposal

    Hi folks, Thursday (16 March 2000)

    Per my action item from yesterday's IPP Telecon, I propose the following
    extensible mechanism for IPP clients to 'discover' metadata about the
    attributes supported by IPP server implementations.

    No new IPP operations are required and the mechanism may be used with
    any version of IPP (1.0, 1.1, etc.).

    The proposed mechanism is modelled on the use of metadata 'facts' in
    <draft-ietf-ftpext-mlst-10.txt>, February 2000, which defines the 'MLST'
    (file) and 'MLSD' (directory) machine-readable list command extensions
    to FTP.

    Define three new Printer object attributes which can be queried with
    the existing 'Get-Printer-Attributes' operation.

    ----------------------------------------------------------------------
    * printer-metadata-attributes-supported (1setOf text(MAX))

    This OPTIONAL Printer attribute specifies the set of metadata for all
    supported attributes for this Printer object.

    This attribute is encoded as a set of strings containing keyword/value
    metadata 'facts' about supported Printer object attributes.

    ----------------------------------------------------------------------
    job-metadata-attributes-supported (1setOf text(MAX))

    This OPTIONAL Printer attribute specifies the set of metadata for all
    supported attributes for Job objects which are contained by this Printer
    object.

    This attribute is encoded as a set of strings containing keyword/value
    metadata 'facts' about supported Job object attributes.

    ----------------------------------------------------------------------
    subscription-metadata-attributes-supported (1setOf text(MAX))
    job-metadata-attributes-supported (1setOf text(MAX))

    This OPTIONAL Printer attribute specifies the set of metadata for all
    supported attributes for Subscription objects which are contained by
    this Printer object.

    This attribute is encoded as a set of strings containing keyword/value
    metadata 'facts' about supported Subscription object attributes.

    ----------------------------------------------------------------------

    The metadata 'facts' are encoded according to the following ABNF (hope
    I got this right):

    metadata-entry = 1*( metadata-fact ";" )
    metadata-fact = metadata-factname "=" metadata-value
    metadata-factname = "name" / ; attribute name
                                            ; name defined in IPP
                          "syntax" / ; attribute syntax
                                            ; syntax defined in IPP
                          "minlen" / ; attribute minimum length
                          "maxlen" / ; attribute maximum length
                          "minint" / ; attribute minimum integer
                          "maxint" / ; attribute maximum integer
                          vendor-factname ; vendor unique factname
                          local-factname ; local unique factname
    vendor-factname = <vendor> "." metadata-token
    local-factname = "x" "." metadata-token
    metadata-token = 1*( token-char )
    metadata-value = 1*( token-char )
    token-char = ALPHA / DIGIT / "-"

    Every 'metadata-entry' string MUST begin with a 'name' fact and MAY
    contain zero or more other facts. Each 'syntax' fact MAY be followed by
    zero or more constraint facts 'minlen', 'maxlen', 'minint', or 'maxint'
    (which further constrain that 'syntax'). Multiple 'syntax' facts may be
    present in each 'metadata-entry' string.

    Comments?

    Cheers,
    - Ira McDonald (consulting architect at Sharp Labs America)
      High North Inc



    This archive was generated by hypermail 2b29 : Fri Mar 17 2000 - 23:51:49 EST