Subject: [IPP] RFC: IDS Attributes additions to IPP System Service v1.0

From: Michael Sweet via ipp <[email-masked]>
Date: Thu, 1 Aug 2019 17:08:22 -0400

All,

At today's IPP workgroup conference call we discussed adding the printer-firmware-xxx attributes that are being registered separately to the IPP System Service specification, as well as additional top-level System Status attributes that expose both the firmware and other attributes from PWG 5110.1-2013: PWG Hardcopy Device Health Assessment Attributes.  Ira and I have an action item to review that specification and make recommendations about which attributes should be added, so here is my list:

    5110.1 Attribute                             IPP System Status Attribute
    -------------------------------------------  ---------------------------
    FirmwareName (String*)                       system-firmware-name (1setOf name(MAX))
    FirmwarePatches (String*)                    system-firmware-patches (1setOf text(MAX))
    FirmwareStringVersion (String*)              system-firmware-string-version (1setOf text(MAX))
    FirmwareVersion (OctetArray*)                system-firmware-version (1setOf octetString(64))
    ResidentApplicationName (String*)            system-resident-application-name (1setOf name(MAX))
    ResidentApplicationPatches (String*)         system-resident-application-patches (1setOf text(MAX))
    ResidentApplicationStringVersion (String*)   system-resident-application-string-version (1setOf text(MAX))
    ResidentApplicationVersion (OctetArray*)     system-resident-application-version (1setOf octetString(MAX))
    TimeSource (String)                          system-time-source-configured (type2 keyword | name(MAX))
    UserApplicationName (String*)                system-user-application-name (1setOf name(MAX))
    UserApplicationPatches (String*)             system-user-application-patches (1setOf text(MAX))
    UserApplicationStringVersion (String*)       system-user-application-string-version (1setOf text(MAX))
    UserApplicationVersion (OctetArray*)         system-user-application-version (1setOf octetString(64))

    * = multiple values allowed

Some additional notes:

- I've limited the xxx-version attributes to 64 octets since that is what the System service limits things (because that's what the TNC binding limits things to...)
- Currently the xxx-patches string is not exposed as a Resource Status attribute, but we could easily add that and the corresponding operation attribute as the source of that information.
- Currently we do not differentiate between User applications/software and Resident applications/software in the system service spec.  Presumably the resident applications are baked into the firmware and won't show up as separate resources, while user applications are separate, "uploadable" executable-software resources?
- I have omitted all of the network configuration/state attributes since I figure those would be limited by the network security infrastructure and can be separately queried at that level.  My focus is on things an administrator might need to manage the HCD's operating configuration and maintenance.

________________________
Michael Sweet

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

---

From: Ira McDonald via ipp <[email-masked]>
Date: Tue, 6 Aug 2019 07:37:47 -0400

Hi Mike,

I agree with all of your suggestions.

It seems like a good idea to add the patches support to Resources,
which would reflect (for example) firmware plus patches.

To clarify, "Resident Applications" are *distinct* from base firmware
and intended to represent manufacturer-supplied value-add, while
"User Applications" are intended to represent customer-supplied
value-add (such as functions built w/ manufacturer SDKs).  For
some manufacturers, "Resident Applications" may be extra cost.

Although the name is ambiguous, "User Applications" would
typically be created by and installed by Enterprise network admins,
rather than end users (although anyone w/ an SDK could possibly
create one).

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Co-Chair - TCG Metadata Access Protocol SG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
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]
PO Box 221  Grand Marais, MI 49839  906-494-2434

On Thu, Aug 1, 2019 at 5:08 PM Michael Sweet via ipp <[email-masked]> wrote:

> All,
>
> At today's IPP workgroup conference call we discussed adding the
> printer-firmware-xxx attributes that are being registered separately to the
> IPP System Service specification, as well as additional top-level System
> Status attributes that expose both the firmware and other attributes from
> PWG 5110.1-2013: PWG Hardcopy Device Health Assessment Attributes.  Ira and
> I have an action item to review that specification and make recommendations
> about which attributes should be added, so here is my list:
>
>     FirmwareStringVersion (String*)
> system-firmware-string-version (1setOf text(MAX))
>     ResidentApplicationName (String*)
> system-resident-application-name (1setOf name(MAX))
>     ResidentApplicationPatches (String*)
>  system-resident-application-patches (1setOf text(MAX))
>     ResidentApplicationStringVersion (String*)
>  system-resident-application-string-version (1setOf text(MAX))
>     ResidentApplicationVersion (OctetArray*)
>  system-resident-application-version (1setOf octetString(MAX))
>     TimeSource (String)
> system-time-source-configured (type2 keyword | name(MAX))
>     UserApplicationName (String*)
> system-user-application-name (1setOf name(MAX))
>     UserApplicationPatches (String*)
>  system-user-application-patches (1setOf text(MAX))
>     UserApplicationStringVersion (String*)
>  system-user-application-string-version (1setOf text(MAX))
>     UserApplicationVersion (OctetArray*)
>  system-user-application-version (1setOf octetString(64))
>
> - I've limited the xxx-version attributes to 64 octets since that is what
> the System service limits things (because that's what the TNC binding
> limits things to...)
> - Currently the xxx-patches string is not exposed as a Resource Status
> attribute, but we could easily add that and the corresponding operation
> attribute as the source of that information.
> - Currently we do not differentiate between User applications/software and
> Resident applications/software in the system service spec.  Presumably the
> resident applications are baked into the firmware and won't show up as
> separate resources, while user applications are separate, "uploadable"
> executable-software resources?
> - I have omitted all of the network configuration/state attributes since I
> figure those would be limited by the network security infrastructure and
> can be separately queried at that level.  My focus is on things an
> administrator might need to manage the HCD's operating configuration and
> maintenance.
>
> ________________________
> Michael Sweet
>
>
>

---

From: "Kennedy, Smith \(Wireless & Standards Architect\) via ipp" <[email-masked]>
Date: Tue, 6 Aug 2019 12:44:56 +0000

Hi Mike,

> TimeSource (String) system-time-source-configured (type2 keyword | name(MAX))

How is this attribute supposed to work? Is this supposed to pertain to NTP / SNTP?

Smith

/**
    Smith Kennedy
    HP Inc.
*/

> On Aug 1, 2019, at 3:08 PM, Michael Sweet via ipp <[email-masked]> wrote:
> 
> All,
> 
> https://www.pwg.org/mailman/listinfo/ipp <https://protect-us.mimecast.com/s/prFQC73z5zuApQY0lCWRhEG?domain=pwg.org>

---

From: Michael Sweet via ipp <[email-masked]>
Date: Tue, 6 Aug 2019 09:43:37 -0400

Smith,

We'll need to work out the details.  The IDS Attribute is defined simply as:

“onboard” for a resident RTC or a Hostname or URI string for a network time source

However, there is no URI scheme defined for NTP/SNTP yet... Anyways, my thought was something along the lines of:

This attribute identifies the source for time values on the System. Name values specify a Network Time Protocol (NTP) or Simple Network Time Protocol (SNTP) [RFC5905] server host name. The following keyword values are defined:

'dhcp': The System obtains the NTP or SNTP server address via DHCP option 42 [RFC2132].

'onboard': The System uses an internal real time clock.

> On Aug 6, 2019, at 8:44 AM, Kennedy, Smith (Wireless & Standards Architect) <[email-masked]> wrote:
> 
> Hi Mike,
> 

________________________
Michael Sweet