Subject: [IPP] Use of unknown and no-value attribute value tags

From: Michael Sweet <[email-masked]>
Date: Thu, 15 Sep 2011 14:56:57 -0700

All,

I've received a few queries about how the "unknown" and "no-value" attribute value tags are used in IPP recently.  What I've been telling people is basically the following, but I'd like to document this somewhere, perhaps as an errata for one of the IPP RFCs (probably RFC 2911 and 3380) along with some updates to the IPP registry for the affected attributes.

Comments?

The "no-value" Attribute Value Tag

This value may be set or returned for any settable Job, Subscription, or Printer attribute. The typical usage is to specify an xxx-default Job Template attribute that has no default value, such as "orientation-requested-default" - in that case the Printer may apply a default based on the document such as automatically applying "orientation-requested" with a value of 4 (landscape) for a landscape document.

The "no-value" value may also be returned for read-only description attributes that are a mandatory part of an object.  For example, the Job object's "time-at-completion" attribute can be returned as "no-value" when the Job has not yet entered a terminating state.

The "unknown" Attribute Value Tag

This value may only be set or returned for specific Printer attributes. Currently only the proposed "printer-geo-location" attribute has been defined to potentially have an "unknown" value.

__________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Ira McDonald <[email-masked]>
Date: Thu, 15 Sep 2011 18:05:00 -0400

Hi Mike,

I like all of it, except that in printer-geo-location we should
get rid of that MIB-centric "unknown" and instead use the
semantically equivalent "no-value".

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - IEEE-ISTO PWG IPP WG
Chair - TCG Embedded Systems Hardcopy SWG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:[email-masked]
Christmas through April:
  579 Park Place  Saline, MI  48176
  734-944-0094
May to Christmas:
  PO Box 221  Grand Marais, MI 49839
  906-494-2434

On Thu, Sep 15, 2011 at 5:56 PM, Michael Sweet <[email-masked]> wrote:

> All,
>
> I've received a few queries about how the "unknown" and "no-value"
> attribute value tags are used in IPP recently.  What I've been telling
> people is basically the following, but I'd like to document this somewhere,
> perhaps as an errata for one of the IPP RFCs (probably RFC 2911 and 3380)
> along with some updates to the IPP registry for the affected attributes.
>
> Comments?
>
>
> This value may be set or returned for any settable Job, Subscription, or
> Printer attribute. The typical usage is to specify an xxx-default Job
> Template attribute that has no default value, such as
> "orientation-requested-default" - in that case the Printer may apply a
> default based on the document such as automatically applying
> "orientation-requested" with a value of 4 (landscape) for a landscape
> document.
>
> The "no-value" value may also be returned for read-only description
> attributes that are a mandatory part of an object.  For example, the Job
> object's "time-at-completion" attribute can be returned as "no-value" when
> the Job has not yet entered a terminating state.
>
>
> This value may only be set or returned for specific Printer attributes.
> Currently only the proposed "printer-geo-location" attribute has been
> defined to potentially have an "unknown" value.
>
>
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>

---

From: Michael Sweet <[email-masked]>
Date: Thu, 15 Sep 2011 15:16:27 -0700

Ira,

Semantically-speaking "unknown" and "no-value" do mean different things:

    unknown: There is a value but we don't know what it is.
    no-value: We know there is no value.

Clearly every printer has a geographic location (and thus a value exists), however the value of that location may not be known because nobody has entered one and/or the printer has no way to get its location automatically.  While we certainly could use "no-value" for printer-geo-location and treat it as "no value set", I like using a more specific tag if one exists.

That said, I wonder - how does the Semantic Model map "unknown" to the XML schema?
(or does it?)  If there isn't a mapping of unknown then I would suggest we formally deprecate the "unknown" value tag and use "no-value" for printer-geo-location as you suggest - it hasn't been used widely (or at all as far as I can see) and I don't want to depend on something that can't be mapped to another protocol binding.

---

From: Ira McDonald <[email-masked]>
Date: Thu, 15 Sep 2011 18:44:31 -0400

Hi Mike,

"unknown" is used 39 places in PwgWellKnownValues.xsd
in three spellings - unknown, Unknown, and UNKNOWN
- oof! - needs work here...

In PWG SM, SystemGeoLocation is of datatype "xs:anyURI"
with a reference to RFC 5870 ('geo' URI Scheme).  "unknown"
is an obviously illegal value, while the empty string can be and
is construed as "unknown" in MFD Model [PWG5108.01].

Cheers,
- Ira

On Thu, Sep 15, 2011 at 6:16 PM, Michael Sweet <[email-masked]> wrote:

> Clearly every printer has a geographic location (and thus a value exists),
> however the value of that location may not be known because nobody has
> entered one and/or the printer has no way to get its location automatically.
>  While we certainly could use "no-value" for printer-geo-location and treat
> it as "no value set", I like using a more specific tag if one exists.
>
> (or does it?)  If there isn't a mapping of unknown then I would suggest we
> formally deprecate the "unknown" value tag and use "no-value" for
> printer-geo-location as you suggest - it hasn't been used widely (or at all
> as far as I can see) and I don't want to depend on something that can't be
> mapped to another protocol binding.
>
>

---

From: "Zehler, Peter" <[email-masked]>
Date: Fri, 16 Sep 2011 11:15:18 -0700

Ira,

There are are a few places where "Unknown" was purposely set to either all uppercase or lowercase.  It was so the values matched the associated external definitions (i.e., charset, MIME type, OS name).  Here are the affected WKVs:
lowercase: CharsetWKV(unknown-8bit), DocumentFormatWKV
Uppercase: OperatingSystemNameWKV
Fixed to titlecase: ConnectionFailReasonWKV, PowerRequestStatusWKV

I have no issue with the way the SM handles SystemGeoLocation.  An empty SystemGeoLocation maps to no-value.  I agree that every printer has geographic location.  I do not agree it has a GeoLocation until a geolocation component has instrumented the data or it has been administratively set. (probably set with data from a geolocation component)  If the printer has a geolocation component and was unable to triangulate its position, i'd say the SystemGeoLocation was unknown.

I would prefer to interpret an empty SystemGeoLocation as no-value.  I would prefer to use the IPP 'no-value' tag with printer-geo-location regardless of the reason.  I could live with using the IPP 'unknown' tag for instrumentation failure. 

Pete  

-----Original Message-----
From: [email-masked] on behalf of Ira McDonald
Sent: Thu 9/15/2011 3:44 PM
To: Michael Sweet; Ira McDonald
Cc: [email-masked]
Subject: Re: [IPP] Use of unknown and no-value attribute value tags
 
Hi Mike,

Cheers,
- Ira

---

From: Michael Sweet <[email-masked]>
Date: Tue, 27 Sep 2011 21:22:06 -0700

FWIW, I just noticed that "unknown" is used in RFC 3381 for the job progress attributes (at least).

I plan on going through all of the RFCs to find any other mention of "unknown" and then provide another update for the registry...