Hi Mike,
Thanks for the clarifications.
I'll make a note to move the *parameter* definitions into a separate
explicit
section in the next System Service update and to clarify that they should
not be termed attributes.
I still think the operation request parameters section would benefit from a
forward reference to the operation response parameters section where the
registration definitions actually occur, rather than just the obscure
reference
to the 2910 "special encoding rules" (which of course we still need to
keep).
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/blueroofmusichttp://sites.google.com/site/highnorthinc
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
On Mon, Jan 4, 2016 at 8:56 AM, Michael Sweet <msweet at apple.com> wrote:
> 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>>> 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/highnorthinc> 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/3cbd43bf/attachment.html>