IPP Mail Archive: IPP> Notification Spec Errors

IPP> Notification Spec Errors

From: mjoel@netreon.com
Date: Fri Jun 22 2001 - 10:02:17 EDT

  • Next message: vonletztekrieger: "IPP> Puppies"

    Hello IPP Group,

    In my study of the IPP Event Notification Specification
    (draft-ietf-ipp-not-spec-06.txt), I found a few problems that probably should be
    fixed before the official RFC is created.

    1) 5.3 Table 1 lists "notify-natural-languages", which, according to the rest of
    the spec, should be in the singular.

    2) In 11.2.3.2, where it describes the Unsupported Attributes group of the
    Get-Subscription-Attributes reply, it states:

       Group 2: Unsupported Attributes

             See [RFC2911] section 3.1.7 for details on returning
             Unsupported Attributes.

             The response NEED NOT contain the "requested-attributes"
             operation attribute with any supplied values (attribute
             keywords) that were requested by the client but are not
             supported by the Printer. If the Printer does return
             unsupported attributes referenced in the "requested-attributes"
             operation attribute and that attribute included group names,
             such as 'all', the unsupported attributes MUST NOT include
             attributes described in the standard but not supported by the
             implementation.

    My guess is that the last sentence should read:

             If the Printer does return unsupported attributes referenced in the
             "requested-attributes" operation attribute, it MUST include only
             unsupported attributes that are in the "requested-attributes"
             operation attribute, and not any that are implied by any attribute
             group name in the "requested-attributes" operation attribute.

    What I think the spec currently says is that if the printer does return
    unsupported attributes referenced in the "requested-attributes" operation
    attribute, then unsupported attributes that appear in that attribute are treated
    differently depending on if there are any attribute group names also in that
    attribute or not. I'm sure that's not what is wanted.

    Please note that RFC 2911 section 3.2.5.2 contains the same ambiguous wording.

    3) 5.2, line 3, says: "These rules for are similar...". Looks like a typo, and
    either "for" should be removed, or what it is for should follow "for".

    4) 11.1.3, last paragraph, says "must EITHER" but only lists one option, so that
    should probably be changed to just "MUST".

    I would appreciate it if anyone who knows the correct meaning of the paragraph
    regarding unsupported attributes in 11.2.3.2 (my point 2 above) would please let
    me know.

    Regards,

    Marty Joel



    This archive was generated by hypermail 2b29 : Fri Jun 22 2001 - 10:06:19 EDT