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

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

Michael Sweet msweet at msweet.org
Tue Aug 6 13:43:37 UTC 2019


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:

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

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) <smith.kennedy at hp.com> wrote:
> 
> 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 <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
> 

________________________
Michael Sweet



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20190806/68d598f8/attachment.html>


More information about the ipp mailing list