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/blueroofmusichttp://sites.google.com/site/highnorthinc
mailto: blueroofmusic at gmail.com
PO Box 221 Grand Marais, MI 49839 906-494-2434
On Thu, Aug 1, 2019 at 5:08 PM Michael Sweet via ipp <ipp at pwg.org> 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:
>> 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
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20190806/73991f71/attachment.html>