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