Subject: [IPP] Re: [MFD] Comments on IPP Faxout Spec w/r SM FaxOut Service

From: Michael Sweet <[email-masked]>
Date: Thu, 07 Mar 2013 12:33:58 -0500

Bill,

Sorry, finally getting a chance to read through this and respond...

On Feb 24, 2013, at 4:50 PM, William A Wagner <[email-masked]> wrote:
> In pursuing the question about  the SM correlation to Get-Printer-Suppported-Values in table 1, Operations for IPP FaxOut, there appear to be several inconsistencies.
> 1.    ValidateFaxOutJob  does not exist. ValidateFaxOutJobTicket is probably intended.

Correct.

> 2.    I find no RestartFaxOutJob in either the SM FaxOut Service or general SM Model. Does the make sense? There is a ResubmitFaxOutJob.

I believe IPP's Restart-Job was never brought into the Semantic Model because of the accounting issues is causes.  I can ban its use in FaxOut, much like we've banned Print-Job and Print-URI, if people prefer...

> 3.     The SM FaxOut Service does not appear to differentiate GetFaxOutJobElements from the general Get<service>JobElements, which has an important difference from IPP Get-Job-Attributes.  Unlike the IPP Get-Job-Attributes, the GetFaxOutJobElements request does not specify individual Elements. Rather, the Client requests specific groups of Elements contained within the Job. The allowed values for RequestedElements are Job Receipt, Job Status, or Job Ticket. It is not clearly stated whether the FaxOut follows the Common Semantics (presumably it must) or the IPP printer approach.

I believe this is an artifact of the web services binding; IPP has attribute groups that can be requested (job-template, job-description, etc.) as well as individual named attributes, so I don't think this is an issue.

> 4.    The SM FaxOut Service does not appear to differentiate GetFaxOutServiceElements from the general Get<service>ServiceElements, which has an important difference from IPP Get-Printer-Attributes. Unlike the IPP Get-Printer-Attributes, the GetFaxOutServiceElements request does not specify individual Elements. Rather, the Client requests specific groups of Elements contained within the Job. The allowed values for Requested Elements are Service Capabilities, Service Configuration, Service Description, Service Status or DefaultJob Ticket. This distinction is not clearly stated.

Same comment as for #3.

> 5.    As follows from item 4, the correlation to  SM Get-Printer-Supported-Values is GetFaxOutServiceElements with values of Service Configuration, Service Description and Service Status (??)

No, there is a semantic difference.  Get-Printer-Supported-Values returns the original manufacturer xxx-supported values while Get-Printer-Attributes returns the values as configured by the administrator of the printer - a configuration utility would use Get-Printer-Supported-Values to get the full set of values that can be configured and Get-Printer-Attributes to get the currently configured values.

What we'd need is (effectively) a <service>DefaultConfiguration group in the Semantic Model to provide the same information.

> 6.    Comment: - should the SM address subscriptions?

I think we need to for Cloud, at least.

> 7.    ReleaseHeldNewFaxOutJobs does not exist. ReleaseHeldFaxOutJobs ( no 'new') is probably intended.

Correct.

> 8.    Deactivate and Activate were dropped from the SM model. Do we really need these?

They are part of IPP already.  

> 9.    It might be noted that Startup-Printer correlates to StartupService (FaxOut) of the System Control Service.

Done.

> 10. Neither the SM FaxOut nor Common Semantics include an operation correlating to Reprocess-Job. It is not clear how this would act for FaxOut.

Same as for print I'd think - creates a new job as a copy of an existing one.  But ResubmitJob works that way and also accepts a new job ticket, avoiding the race condition for supplying new values before the job starts processing.

Perhaps we should deprecate Reprocess-Job for IPP FaxOut and just have Resubmit-Job?

> 11. Schedule-Job-After correlates to PromoteFaxOutJob. If the predecessor Job is specified, PromoteFaxOutJob acts the same way as the IPP Schedule-Job-After operation.

Done.

> 12. There is no CancelFaxOutDocument in the FaxOut Service just a CancelFaxOutDocuments (note the 's') although the general semantics operations is Cancel<service>Document . Is this an error in the FaxOut Service spec?

Probably.

> 13. I find no IdentifyFaxOutService under FaxOut, Common Semantics or System Control Service. Should this be added to the SM FaxOut Service (and all other services) or perhaps to System Control Service?

It should be part of Common Semantics, with each service getting its own Identify<service>Service operation.

> 14. The FaxOut Service identifies the following operations that do not appear in the IPP FaxOut spec:
> a.    ResubmitFaxOutJob
> b.    ValidateFaxOutDocumentTicket

Yes, for some reason I missed adding those two operations to the table. Now added (for the next draft...)

....

I'll hold off on publishing a new draft until we've had a chance to review the current one, but perhaps we can discuss whether Restart-Job and Reprocess-Job belong in IPP FaxOut, then the next draft will be that much cleaner...

Thanks!

_________________________________________________________
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, 7 Mar 2013 12:55:52 -0500

Hi,

Pete and I have both argued that RestartJob (terrible) and
ReprocessJob (a subset of ResubmitJob) shouldn't be in the
Semantic Model v2.0 (except for legacy Print Service).

I don't want to put them in any IPP Multifunction services.

ResubmitJob is necessary and is accounting-friendly.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
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]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

On Thu, Mar 7, 2013 at 12:33 PM, Michael Sweet <[email-masked]> wrote:

> In pursuing the question about  the SM correlation to
> Get-Printer-Suppported-Values in table 1, Operations for IPP FaxOut, there
> appear to be several inconsistencies.****
> ****
> 2.    I find no RestartFaxOutJob in either the SM FaxOut Service or
> general SM Model. Does the make sense? There is a ResubmitFaxOutJob.
>
>
> I believe IPP's Restart-Job was never brought into the Semantic Model
> because of the accounting issues is causes.  I can ban its use in FaxOut,
> much like we've banned Print-Job and Print-URI, if people prefer...
>
> ****
> 3.     The SM FaxOut Service does not appear to differentiate
> GetFaxOutJobElements from the general Get<service>JobElements, which has an
> important difference from IPP Get-Job-Attributes.  Unlike the IPP
> Get-Job-Attributes, the GetFaxOutJobElements request does not specify
> individual Elements. Rather, the Client requests specific groups of
> Elements contained within the Job. The allowed values for RequestedElements
> are Job Receipt, Job Status, or Job Ticket. It is not clearly stated
> whether the FaxOut follows the Common Semantics (presumably it must) or the
> IPP printer approach.
>
>
> I believe this is an artifact of the web services binding; IPP has
> attribute groups that can be requested (job-template, job-description,
> etc.) as well as individual named attributes, so I don't think this is an
> issue.
>
> ****
> 4.    The SM FaxOut Service does not appear to differentiate
> GetFaxOutServiceElements from the general Get<service>ServiceElements,
> which has an important difference from IPP Get-Printer-Attributes. Unlike
> the IPP Get-Printer-Attributes, the GetFaxOutServiceElements request does
> not specify individual Elements. Rather, the Client requests specific
> groups of Elements contained within the Job. The allowed values for
> Requested Elements are Service Capabilities, Service Configuration, Service
> Description, Service Status or DefaultJob Ticket. This distinction is not
> clearly stated.
>
>
> Same comment as for #3.
>
> ****
> 5.    As follows from item 4, the correlation to  SM
> Get-Printer-Supported-Values is GetFaxOutServiceElements with values of
> Service Configuration, Service Description and Service Status (??)
>
>
> No, there is a semantic difference.  Get-Printer-Supported-Values returns
> the original manufacturer xxx-supported values while Get-Printer-Attributes
> returns the values as configured by the administrator of the printer - a
> configuration utility would use Get-Printer-Supported-Values to get the
> full set of values that can be configured and Get-Printer-Attributes to get
> the currently configured values.
>
> What we'd need is (effectively) a <service>DefaultConfiguration group in
> the Semantic Model to provide the same information.
>
> ****
> ****
> ****
> ****
> ****
> 10. Neither the SM FaxOut nor Common Semantics include an operation
> correlating to Reprocess-Job. It is not clear how this would act for FaxOut.
>
>
> Same as for print I'd think - creates a new job as a copy of an existing
> one.  But ResubmitJob works that way and also accepts a new job ticket,
> avoiding the race condition for supplying new values before the job starts
> processing.
>
> ****
> 11. Schedule-Job-After correlates to PromoteFaxOutJob. If the predecessor
> Job is specified, PromoteFaxOutJob acts the same way as the IPP
> Schedule-Job-After operation.
>
>
> Done.
>
> ****
> 12. There is no CancelFaxOutDocument in the FaxOut Service just a
> CancelFaxOutDocuments (note the 's') although the general semantics
> operations is Cancel<service>Document . Is this an error in the FaxOut
> Service spec?
>
>
> Probably.
>
> ****
> 13. I find no IdentifyFaxOutService under FaxOut, Common Semantics or
> System Control Service. Should this be added to the SM FaxOut Service (and
> all other services) or perhaps to System Control Service?
>
>
> ****
> 14. The FaxOut Service identifies the following operations that do not
> appear in the IPP FaxOut spec:****
> a.    ResubmitFaxOutJob****
> I'll hold off on publishing a new draft until we've had a chance to review
> the current one, but perhaps we can discuss whether Restart-Job and
> Reprocess-Job belong in IPP FaxOut, then the next draft will be that much
> cleaner...
>
> Thanks!
>
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>
> mfd mailing list
> [email-masked]
> https://www.pwg.org/mailman/listinfo/mfd
>
>

---

From: Michael Sweet <[email-masked]>
Date: Thu, 07 Mar 2013 17:39:35 -0500

Nancy,

On Mar 7, 2013, at 5:08 PM, Ying Chen <[email-masked]> wrote:
> ...
> 2.  In Mike's response to #5, regarding Get-Printer-Supported-Values -
> From rfc3380 page 1,  "The Get-Printer-Supported-Values administrative operation returns values that the IPP Printer will accept for setting its "xxx-supported".  Notice that this operation does not return any "xxx-supported" values that cannot be set by an administrator.  Hence Mike is correct that "use Get-Printer-Supported-Values to get the full set of values that can be configured", but I did not see any semantic in rfc3380 that defines "Get-Printer-Supported-Values returns the original manufacturer xxx-supported values while Get-Printer-Attributes returns the values as configured by the administrator of the printer" as Mike said.

RFC 3380 also defines Set-Printer-Attributes; from section 4.1:

   5. The Printer MUST support the value, according to the rules defined
      in Appendix A, i.e., each value of each supplied "xxx" attribute
      MUST be validated against the value of a corresponding "xxx-
      supported" Printer attribute.  One of those rules permits an
      administrator to set arbitrary 'name' values to those "xxx-
      supported" Printer attributes that include the 'name' attribute
      syntax if the implementation supports the 'admin-define' out-of-
      band value for that "xxx-supported" attribute (see section 8.3 and
      Appendix A).

Section 4.3 talks about the differences between Get-Printer-Attributes and Get-Printer-Supported-Values, including:

   3. The Get-Printer-Attributes operation returns the current values of
      requested attributes, while the Get-Printer-Supported-Values
      operation returns the values that are inherently supported by the
      implementation code, i.e., the values that an administrative
      client can set in a Set-Printer-Attributes request.

   4. The Get-Printer-Attributes operation returns the current values of
      requested "xxx-supported" attributes that the Printer is
      configured to accept in Job Creation operations, including
      additional values defined by the administrator, while the Get-
      Printer-Supported-Values operation returns only the values of
      "xxx-supported" attributes that are inherently supported by the
      implementation and does not return any additional values defined
      by the administrator, where the implementation supports the
      'admin-define' out-of-band value.

> ...
> Therefore, Mike is correct that there is no element in MFD SM that defines "the original manufacturer xxx-supported values".  I think this set of values are very useful when there is a need to restore <service> attributes to the manufacturer's defaults.  But I don't see the IPP spec (rfc3380) has this set of attributes defined either.

I'm interpreting "values inherently supported by the implementation" as the "manufacturer default values", but you are right technically the defaults might not include all values. Consider my wording changed accordingly to align with 3380's Get-Printer-Supported-Values terminology.  We still don't have a way to get the full set of supported values for read/write elements in the Semantic Model... :/

---

From: "William A Wagner" <[email-masked]>
Date: Sat, 9 Mar 2013 17:47:04 -0500

Hello All,

This discussion is exposing several issues  and questions. I suggest that
there should be some consideration of these in the SM meeting as well.

1.      Since the PWG has an approved candidate standard that Nancy suggests
does not agree with the current schema, which takes precedence? I suggest
that any  SM change must be reflected in an errata in the Common Model or
specific Service candidate standard, as appropriate.

2.       Has the Get<service>ServiceElements  operation requested elements
actually been changed? The Common Model indicates that "Some Services may
accept an additional argument in a Get<service>ServiceElements request to
further filter the response. The individual Service specifications identify
such arguments if any, their effect and whether support is mandatory."  My
interpretation of this is that the Common Model allows the distinction
between the SM and IPP operations to be eliminated for a specific Service if
the Service Specification so mandates. I do not see this mandate in the
FaxOut Service Specification. Should it be there? 

3.      In regard to GetFaxOutServiceElements and GetFaxJobElements as well
as other operations (e.g., Activate and Deactivate), the proposed IPP FaxOut
binding  appears to follow IPP Printing rather than the SM FaxOut
specification. (i.e., although  the IPP binding may allow specifying groups,
it is mandated in the SM) Is this divergence valid? Or, if the differences
are necessary, should the SM FaxOut specification be updated? And if this
update violates the Common Model, should that be updated? Essentially,
should we be consistent among our standards?

4.      Returning to the issue of  desired capability, I may have gotten
lost, but it appears that three levels of Service capabilities are desired.
Is this correct?

a.      Currently configured,  provided by Get-Printer-Attributes and
(perhaps) by GetFaxOutServiceElements

b.      Values that the implementation allows an administrator to configure,
provided by Get-Printer-Supported-Values ( I find RFC 3380, 4.3, para 4
totally confusing and suggest that clarification is in order)

c.       The "original manufacturer xxx-supported values", which depending
upon ones interpretation, may not be provided by IPP. The term "default" in
the discussion is  unclear. Is the interest in manufacturer default
configuration (why?)  or the 'out-of-box' capabilities that an administrator
could configure?

5.      So, whether or not IPP provides  it in Get-Printer-Supported-Values
(which seems to depend upon the implementer's interpretation), it is desired
to include in the FaxOut SM a capability to get the full set of supported
values for read/write elements.  Although some clarification is necessary, I
think that Get<service>ServiceElements/Capabilities may  provide this, as
distinguished from Get<service>ServiceElements/Configuration which would
correlate with Get-Printer-Attributes.

6.      Finally, in addition to the potentially new
Get<service>ServiceSupportedElements operation (or whatever to call it) to
be added to the FaxOut (and probably other Service SM) specifications,  the
discussion  suggested that the SM group add the following:

a.      Handling of subscriptions

b.      Identify<service>Service

From: Ying Chen [mailto:[email-masked]] 
Sent: Thursday, March 07, 2013 5:09 PM
To: Michael Sweet
Cc: William A Wagner; [email-masked]; [email-masked]
Subject: Re: [IPP] Re: [MFD] Comments on IPP Faxout Spec w/r SM FaxOut
Service

Mike and Bill,

I'd like to point out two things:

1.  In Bill's #4 regarding SM GetFaxOutServiceElements request, it stated
that "the allowed values for Requested Elements are Service Capabilities,
Service Configuration, Service Description, Service Status or DefaultJob
Ticket."  These are what specified in the current MFD Common SM 2.0 spec.
However the MFD Schema has evolved since.  The Requested Elements can be any
element in the service.  But for operational efficiency, it is recommended
to get a larger group element.

      I think the MFD Common Semantic Model should be updated accordingly.

>From rfc3380 page 1,  "The Get-Printer-Supported-Values administrative
operation returns values that the IPP Printer will accept for setting its
"xxx-supported".  Notice that this operation does not return any
"xxx-supported" values that cannot be set by an administrator.  Hence Mike
is correct that "use Get-Printer-Supported-Values to get the full set of
values that can be configured", but I did not see any semantic in rfc3380
that defines "Get-Printer-Supported-Values returns the original manufacturer
xxx-supported values while Get-Printer-Attributes returns the values as
configured by the administrator of the printer" as Mike said.

In MFD SM, "xxx-supported" attributes are defined in the
"<service>ServiceCapabilities" group element, each elements in this group
most of times is either a list of keywords or a range of values between a
Lowerbound and Upperbound elements representing the allowed values for the
xxx-supported attribute, or a boolean representing whether an attributed is
supported or not.  There is a xxx-supported value for every
<service>JobTicket element and every <service>JobDocument element.  For
example, the JobHoldUntil element in JobTicketCapabilities is a list of
keywords: "DayTime" "Evening" "Indefinite" "Night" ...etc, the Priority
element has a Lowerbound and Upperbound sub-elements of integer type.  All
Capabilities elements in MFD SM are settable by Admin.

Therefore, Mike is correct that there is no element in MFD SM that defines
"the original manufacturer xxx-supported values".  I think this set of
values are very useful when there is a need to restore <service> attributes
to the manufacturer's defaults.  But I don't see the IPP spec (rfc3380) has
this set of attributes defined either.

-Nancy

-------------------------------------------

Nancy Chen

Independent contributor, PWG Vice-Chair

Bill,

In pursuing the question about  the SM correlation to
Get-Printer-Suppported-Values in table 1, Operations for IPP FaxOut, there
appear to be several inconsistencies.

1.    ValidateFaxOutJob  does not exist. ValidateFaxOutJobTicket is probably
intended.

Correct.

2.    I find no RestartFaxOutJob in either the SM FaxOut Service or general
SM Model. Does the make sense? There is a ResubmitFaxOutJob.

3.     The SM FaxOut Service does not appear to differentiate
GetFaxOutJobElements from the general Get<service>JobElements, which has an
important difference from IPP Get-Job-Attributes.  Unlike the IPP
Get-Job-Attributes, the GetFaxOutJobElements request does not specify
individual Elements. Rather, the Client requests specific groups of Elements
contained within the Job. The allowed values for RequestedElements are Job
Receipt, Job Status, or Job Ticket. It is not clearly stated whether the
FaxOut follows the Common Semantics (presumably it must) or the IPP printer
approach.

I believe this is an artifact of the web services binding; IPP has attribute
groups that can be requested (job-template, job-description, etc.) as well
as individual named attributes, so I don't think this is an issue.

4.    The SM FaxOut Service does not appear to differentiate
GetFaxOutServiceElements from the general Get<service>ServiceElements, which
has an important difference from IPP Get-Printer-Attributes. Unlike the IPP
Get-Printer-Attributes, the GetFaxOutServiceElements request does not
specify individual Elements. Rather, the Client requests specific groups of
Elements contained within the Job. The allowed values for Requested Elements
are Service Capabilities, Service Configuration, Service Description,
Service Status or DefaultJob Ticket. This distinction is not clearly stated.

Same comment as for #3.

No, there is a semantic difference.  Get-Printer-Supported-Values returns
the original manufacturer xxx-supported values while Get-Printer-Attributes
returns the values as configured by the administrator of the printer - a
configuration utility would use Get-Printer-Supported-Values to get the full
set of values that can be configured and Get-Printer-Attributes to get the
currently configured values.

What we'd need is (effectively) a <service>DefaultConfiguration group in the
Semantic Model to provide the same information.

7.    ReleaseHeldNewFaxOutJobs does not exist. ReleaseHeldFaxOutJobs ( no
'new') is probably intended.

Correct.

8.    Deactivate and Activate were dropped from the SM model. Do we really
need these?

9.    It might be noted that Startup-Printer correlates to StartupService
(FaxOut) of the System Control Service.

Done.

Perhaps we should deprecate Reprocess-Job for IPP FaxOut and just have
Resubmit-Job?

Done.

Probably.

13. I find no IdentifyFaxOutService under FaxOut, Common Semantics or System
Control Service. Should this be added to the SM FaxOut Service (and all
other services) or perhaps to System Control Service?

It should be part of Common Semantics, with each service getting its own
Identify<service>Service operation.

14. The FaxOut Service identifies the following operations that do not
appear in the IPP FaxOut spec:

a.    ResubmitFaxOutJob

Yes, for some reason I missed adding those two operations to the table. Now
added (for the next draft...)

....

Thanks!

-- 
This message has been scanned for viruses and 
dangerous content by  <http://www.mailscanner.info/> MailScanner, and is 
believed to be clean. 

 

-- 
Nancy Chen

---

From: Michael Sweet <[email-masked]>
Date: Mon, 11 Mar 2013 09:29:51 -0400

Bill,

On 2013-03-09, at 5:47 PM, William A Wagner <[email-masked]> wrote:
> Hello All,
> This discussion is exposing several issues  and questions. I suggest that there should be some consideration of these in the SM meeting as well.
> 1.      Since the PWG has an approved candidate standard that Nancy suggests does not agree with the current schema, which takes precedence? I suggest that any  SM change must be reflected in an errata in the Common Model or specific Service candidate standard, as appropriate.

>From a purely pragmatic perspective, I would say precedence for typographical/omission errors goes to whichever is right! :)

If we find genuine technical issues then we need to proceed carefully.

Regardless, we will need to do errata for the corresponding specs - at the very least to point to the current version of the schema that has the fix.

> 2.       Has the Get<service>ServiceElements  operation requested elements actually been changed? The Common Model indicates that “Some Services may accept an additional argument in a Get<service>ServiceElements request to further filter the response… The individual Service specifications identify such arguments if any, their effect and whether support is mandatory.”  My interpretation of this is that the Common Model allows the distinction between the SM and IPP operations to be eliminated for a specific Service if the Service Specification so mandates. I do not see this mandate in the FaxOut Service Specification. Should it be there?

Personally I am not so concerned about this aspect, although it would be nice for all services to support selection of elements as well as groups for efficiency, just like IPP already provides.

> 3.      In regard to GetFaxOutServiceElements and GetFaxJobElements as well as other operations (e.g., Activate and Deactivate), the proposed IPP FaxOut  binding  appears to follow IPP Printing rather than the SM FaxOut specification. (i.e., although  the IPP binding may allow specifying groups, it is mandated in the SM) Is this divergence valid? Or, if the differences are necessary, should the SM FaxOut specification be updated? And if this update violates the Common Model, should that be updated? Essentially, should we be consistent among our standards?

IPP requires both groups and attributes (elements), and always has.  There is some wiggle room for IPP implementations (a conforming implementation can just return everything with successful-ok-ignored-or-substituted-attributes, with requested-attributes in the unsupported attributes group), but functionally requested-attributes is just a performance optimization (with the exception of media-col-database)

> 4.      Returning to the issue of  desired capability, I may have gotten lost, but it appears that three levels of Service capabilities are desired. Is this correct?
> a.      Currently configured,  provided by Get-Printer-Attributes and (perhaps) byGetFaxOutServiceElements
> b.      Values that the implementation allows an administrator to configure, provided by Get-Printer-Supported-Values ( I find RFC 3380, 4.3, para 4 totally confusing and suggest that clarification is in order)
> c.       The “original manufacturer xxx-supported values", which depending upon ones interpretation, may not be provided by IPP. The term “default” in the discussion is  unclear. Is the interest in manufacturer default configuration (why?)  or the ‘out-of-box’ capabilities that an administrator could configure?

IPP provides A and B.  We don't have a way to get C directly, but honestly I would expect B and C to be the same out-of-the-box most of the time.

> 5.      So, whether or not IPP provides  it in Get-Printer-Supported-Values (which seems to depend upon the implementer’s interpretation), it is desired to include in the FaxOut SM a capability to get the full set of supported values for read/write elements.

I don't think the question of Get-Printer-Supported-Values returning set B above is at issue - that is precisely what it is defined to return.

>  Although some clarification is necessary, I think that Get<service>ServiceElements/Capabilities may  provide this, as distinguished from Get<service>ServiceElements/Configuration which would correlate with Get-Printer-Attributes.

See section 4.3 of MFD Model for the discussion of capabilities.

<service>ServiceCapabilities provides the currently configured/available job and document ticket elements and values.  This is equivalent to what IPP's Get-Printer-Attributes provides in its xxx-supported attributes.

<service>ServiceCapabilitiesReady provides the ready job and document ticket elements and values. This is equivalent to what IPP's Get-Printer-Attributes provides in its xxx-ready attributes.

What we need is a new group, <service>ServiceCapabilitiesSupported, which provides the equivalent of IPP's Get-Printer-Supported-Values.  This should also include a discussion of its use in conjunction with Set<service>ServiceElements.

....

FWIW, <service>ServiceDefaults provides the default job and document ticket elements and values. This is equivalent to what IPP's Get-Printer-Attributes provides in its xxx-default attributes.

<service>ServiceConfiguration provides a view of the components (essentially the Printer MIB properties) associated with the service.  We have some very limited exposure of this in IPP attributes - printer-alert, printer-input-tray, printer-output-tray, and printer-supply.