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 at sharplabs.com]
Sent: Thursday, March 16, 2000 18:07
To: 'ipp at 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