[IPP] IPP "status-code" *is* a type2 enum in 2911/2911bis

[IPP] IPP "status-code" *is* a type2 enum in 2911/2911bis

Michael Sweet msweet at apple.com
Mon Jan 4 13:56:28 UTC 2016


Ira,

> On Jan 3, 2016, at 3:41 PM, Ira McDonald <blueroofmusic at gmail.com> wrote:
> 
> Hi Mike,
> 
> Reviewing IPP minutes from 12/07, I found:
> 
> ⁃ status-code isn't a type2 enum attribute, it is a parameter; see the
> following for example text (although I think I'll swap the status
> message and natural language paragraphs for the next draft):
>https://tools.ietf.org/html/draft-sweet-rfc2911bis-05#page-38 <https://tools.ietf.org/html/draft-sweet-rfc2911bis-05#page-38>
> 
> 
> But in the 2911 and your latest 2911bis-06 draft, it says:
> 
> 4.1.6.  Operation Response Status Codes and Status Messages
> 
>    Every operation response includes a REQUIRED "status-code" parameter
>    and MAY include the RECOMMENDED "status-message" and OPTIONAL
>    "detailed-status-message" operation attributes.  The Print-URI and
>    Send-URI response MAY include an OPTIONAL "document-access-error"
>    operation attribute.
> 
> 4.1.6.1.  "status-code" (type2 enum)
> 
>    The REQUIRED "status-code" parameter provides information on the
>    processing of a request...
> 
> 
> So despite the "special encoding rules" for "status-code" with in the earlier 
> section 4.1.1 of 2911bis, the spec later describes it as a parameter but also
> specifies its semantics as a type 2 enum in operation responses.

Yes, type2 enum values for purposes of registration (although successful-ok's 0 value isn't strictly allowed for enums) but not an *attribute*.  Status codes are part of a separate registry section.  The point of my comment in the minutes is not about the registration but that "status-code" is not an attribute, but a parameter that is encoded in a fixed location of every IPP message.

I'll re-read the sections and see if there is anything I can do to clarify it.

> 
> I suggest that it's section 4.1.1 of 2911bis that's wrong (and should forward 
> reference section 4.1.6 below) and that the "special encoding rules" text is 
> gratuitous obscurity.
> 
> Cheers,
> - Ira
> 
> Ira McDonald (Musician / Software Architect)
> Co-Chair - TCG Trusted Mobility Solutions WG
> 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/blueroofmusic>
> http://sites.google.com/site/highnorthinc <http://sites.google.com/site/highnorthinc>
> mailto: blueroofmusic at gmail.com <mailto:blueroofmusic at gmail.com>
> Winter  579 Park Place  Saline, MI  48176  734-944-0094
> Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer

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


More information about the ipp mailing list