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: McDonald, Ira (imcdonald@sharplabs.com)
Date: Mon Mar 20 2000 - 22:15:15 EST

  • Next message: Michael Sweet: "Re: IPP> New CUPS 1.1 beta and set-job-attributes extension [why not use "job-sheets"?]"

    Hi Tom,

    My comments are in your note below, preceded by 'ira> '.

    Cheers,
    - Ira

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Friday, March 17, 2000 5:09 PM
    To: McDonald, Ira; 'ipp@pwg.org'
    Subject: RE: IPP> MOD - New attribute metadata proposal

    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?

    ira> As I told Carl-Uno at last week's IPP WG Telecon,
    ira> I volunteer to collaborate with you, Tom, and others.

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

    ira> For all your examples, the double quote (") is NOT supposed
    ira> to be imbedded in the actual string values - it's an artifact
    ira> of ABNF.

    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").

    ira> Note that ABNF is case insensitive by specification (which is
    ira> a bug), so we can only indicate case sensitivity by comments
    ira> in ABNF for describing 'literals'.

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

    ira> No, we want this to be extensible for FUTURE syntaxes, so
    ira> the ABNF needs to incorporate current syntaxes only by
    ira> comments and not directly. We need metadata discovery
    ira> because things change.

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

       "syntax" = "1setOf (type2 keyword | name)"

    ira> I agree that it would be interesting (and terse) to describe
    ira> the attribute name and syntax facts by simply stating them
    ira> in the IPP Model manner, for example:
    ira>
    ira> job-more-info(uri); other-fact=other-info

       "maxint" = "2 ** 31 -1"

    ira> I dislike introducing the '**' exponent operator. So what
    ira> if it's terse? End users (who will be presented with metadata
    ira> by their local UIs in many cases) often don't understand that
    ira> '**' exponentiation operator.

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

    ira> No - the metadata MUST disambiguate the meaning of the kludge
    ira> MAX into an integer number for real users to understand. The
    ira> use of 'MAX' in metadata destroys much of the utility of the
    ira> metadata.

    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":

    ira> I agree, as I stated in my example and comment above.

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

    ira> No, they are ABNF specification artifacts, as I said above.

    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'?

    ira> Zero (0) may be a legal length for some 'text' strings but it is
    ira> always gibberish for 'name' strings.

    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 "=":

    ira> For the attribute name and syntax we don't need the '='
    ira> as I agreed above. But if we delete the ability for
    ira> a semicolon ';' to introduce another 'keyword=value'
    ira> style metadata 'fact' then we lose the ability for
    ira> vendors to do extensions (and future IPP versions to
    ira> do extensions. For example, I believe simple 'constraints'
    ira> can be expressed as an attribute metadata 'fact' set.

    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))

    ira> Your semicolon ';' was not needed in the above example.
    ira> I proposed that 'printer-metadata-attributes-supported'
    ira> is '(1setOf (text)' so 'media' and 'job-k-octets' are
    ira> separate VALUES in the '1setOf'.

    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?

    ira> No, as I said above.

    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)

    ira> Now that's an attractive idea that adds utility to metadata.

    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?

    ira> I think we probably need 'printer-metadata-operations-supported'
    ira> or (fixing my names for comprehension a little bit)
    ira> 'printer-attributes-metadata' (let 'supported' be implied) and
    ira> 'printer-operations-metadata' and (perhaps)
    ira> 'printer-syntaxes-metadata' (for general extensibility)

    ISSUE 08: What about meta data for operation attributes?

    ira> Yes - see above.

    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.

    ira> Yes - see above.

    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 : Mon Mar 20 2000 - 22:22:07 EST