Subject: [IPP] Question concerning the "presentonoff" key for "printer-finisher"

From: "Kennedy, Smith \(Wireless & IPP Standards\) via ipp" <[email-masked]>
Date: Fri, 18 Dec 2020 21:16:31 +0000

Greetings,

In PWG 5100.1-2017, one of the keys defined for the "printer-finisher" Printer Status attribute is "presentonoff". Yesterday in the IPP WG <https://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-concall-minutes-20201217.pdf> we discussed how that key should become RECOMMENDED in our Finishings 2.2 update. The definition of this key in the ABNF on page 48 of Finishings 2.1 <http://ftp.pwg.org/pub/pwg/candidates/cs-ippfinishings21-20170217-5100.1.pdf#page=48> is:
finisher-presentonoff = "presentonoff" "=" 1*ALPHA
    ; string value as an alpha string mapped directly from ; PresentOnOff in [RFC3805]

RFC 3805 defines PresentOnOff thus:

PresentOnOff ::= TEXTUAL-CONVENTION
    STATUS    current
    DESCRIPTION
        "Presence and configuration of a device or feature."
    SYNTAX    INTEGER {
                  other(1),
                  on(3),
                  off(4),
                  notPresent(5)
                  }

I think this ABNF definition should be fixed to be more like this to limit the set of values:
finisher-presentonoff = "presentonoff" "=" "other" / "on" / "off" / "notPresent"
    ; string value as an alpha string mapped directly from ; PresentOnOff in [RFC3805]

Perhaps we need to do it with two rules:

finisher-presentonoff = "presentonoff" "=" 1*presentonoffvalue
finisher-presentonoff-value = "other" / "on" / "off" / "notPresent"
    ; string value as an alpha string mapped directly from ; PresentOnOff in [RFC3805]

Thoughts?

Smith

/**
    Smith Kennedy
    HP Inc.
*/

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

---

From: Michael Sweet via ipp <[email-masked]>
Date: Fri, 18 Dec 2020 16:26:42 -0500

Smith,

> On Dec 18, 2020, at 4:16 PM, Kennedy, Smith (Wireless & IPP Standards) via ipp <[email-masked]> wrote:
> ...

That would be fine with me - these mappings often get pretty obtuse and including the list of values in the ABNF would be a welcome improvement for me...

>     ; string value as an alpha string mapped directly from ; PresentOnOff in [RFC3805]

Doesn't 1*SOMETHING allow one or more values?  If you really want to split the values out (not necessary IMHO) you just need "finisher-presentonoff-value".

________________________
Michael Sweet

---

From: "Kennedy, Smith \(Wireless & IPP Standards\) via ipp" <[email-masked]>
Date: Fri, 18 Dec 2020 21:35:54 +0000

> On Dec 18, 2020, at 2:26 PM, Michael Sweet <[email-masked]> wrote:
> 
> Smith,
> 

You are right about the "1*" part. I'll use the first proposal with some added hard wraps and a clarified origin:

finisher-presentonoff = "presentonoff" "=" "other" / "on" /
                           "off" / "notPresent"
   ; string value as an alpha string mapped directly from
   ; finDevicePresentOnOff in [RFC3806] which imports the
   ; definition of PresentOnOff from [RFC3805]

---

From: Ira McDonald via ipp <[email-masked]>
Date: Fri, 18 Dec 2020 20:03:13 -0500

Hi Smith and Mike,

+1

Cheers,
- Ira

*Ira McDonald (Musician / Software Architect)*

*Chair - SAE Trust Anchors and Authentication TF*
*Co-Chair - TCG Trusted Mobility Solutions WG*

*Co-Chair - TCG Metadata Access Protocol SG*

*Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer
Working GroupCo-Chair - IEEE-ISTO PWG Internet Printing Protocol WGIETF
Designated Expert - IPP & Printer MIBBlue Roof Music / High North
Inchttp://sites.google.com/site/blueroofmusic
<http://sites.google.com/site/blueroofmusic>http://sites.google.com/site/highnorthinc
<http://sites.google.com/site/highnorthinc>mailto: [email-masked]
<[email-masked]>(permanent) PO Box 221  Grand Marais, MI 49839
906-494-2434*

On Fri, Dec 18, 2020 at 4:36 PM Kennedy, Smith (Wireless & IPP Standards)
via ipp <[email-masked]> wrote:

> That would be fine with me - these mappings often get pretty obtuse and
> including the list of values in the ABNF would be a welcome improvement for
> me...
>
> Doesn't 1*SOMETHING allow one or more values?  If you really want to split
> the values out (not necessary IMHO) you just need
> "finisher-presentonoff-value".
>
>