[IPP] Responses to AppsDir review of draft-mcdonald-ldap-printer-schema-05.txt

[IPP] Responses to AppsDir review of draft-mcdonald-ldap-printer-schema-05.txt

Ira McDonald blueroofmusic at gmail.com
Mon Dec 9 15:28:24 UTC 2013


Hi,

Here is my conversation w/ Alexey Melnikov about his comments on the
LDAP Printer Schema - these resolve all open issues from his Apps Dir
review - I plan to post a new LDAP Printer Schema draft over Christmas
break.

http://ftp.pwg.org/pub/pwg/ipp/wd/alexey-ldap-printer-schema-comments-20131208.pdf
http://ftp.pwg.org/pub/pwg/ipp/wd/alexey-ldap-printer-schema-comments-20131209.pdf

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



On Sun, Dec 8, 2013 at 1:17 PM, Ira McDonald <blueroofmusic at gmail.com>wrote:

> Hi,
>
> FYI - below are the responses that I sent to Alexey Melnikov for
> his very thorough review of the latest draft LDAP Printer Schema.
>
> Barring any objections from Alexey, I'll try to send a corresponding
> updated draft to the IETF and PWG before Christmas.
>
> Cheers,
> - Ira (co-editor of LDAP Printer Schema)
>
>
> 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
>
>
>
> ---------- Forwarded message ----------
> From: Ira McDonald <blueroofmusic at gmail.com>
> Date: Sun, Dec 8, 2013 at 1:08 PM
> Subject: Re: AppsDir review of draft-mcdonald-ldap-printer-schema-05.txt
> To: Alexey Melnikov <alexey.melnikov at isode.com>, Ira McDonald <
> blueroofmusic at gmail.com>
> Cc: "apps-discuss at ietf.org" <apps-discuss at ietf.org>, Pat Fleming <
> patfleminghtc at gmail.com>
>
>
> Hi Alexey,
>
> Thank you very much for your careful review of our revised LDAP Printer
> Schema I-D.  Our responses to your comments are inline below.
>
> We plan to issue a new draft before Christmas.
>
> 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
>
>
>
> On Mon, Nov 18, 2013 at 10:37 AM, Alexey Melnikov <
> alexey.melnikov at isode.com> wrote:
>
>> On 19/09/2013 17:34, Ira McDonald wrote:
>>
>>> Hello,
>>>
>>> The IEEE-ISTO PWG Internet Printing Protocol WG would like to request
>>> IETF Apps Area review of our updated LDAP Printer Schema (updates
>>> RFC 3712).
>>>
>>> http://www.ietf.org/internet-drafts/draft-mcdonald-ldap-
>>> printer-schema-05.txt
>>>
>>> Cheers,
>>> - Ira (co-chair of IEEE-ISTO PWG IPP WG and co-editor of this document)
>>>
>>
>> My apologies for belated review. I hope you find them useful.
>>
>> -----------------------------------------
>>
>> I have been selected as the Applications Area Directorate reviewer for
>> this draft (for background on APPSDIR, please see
>> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).
>>
>> Please resolve these comments along with any other Last Call comments you
>> may receive. Please wait for direction from your document shepherd or AD
>> before posting a new version of the draft.
>>
>> Document: draft-mcdonald-ldap-printer-schema-05.txt
>> Title: Lightweight Directory Access Protocol (LDAP): Schema for Printer
>> Services
>> Reviewer: Alexey Melnikov
>> Review Date: November 18, 2013
>> IETF Last Call Date: N/A
>>
>> Summary: This draft is nearly reading for publication.
>>
>> This document defines a schema, object classes and attributes, for
>> Printers and Print Services, for use with directories that support
>> Lightweight Directory Access Protocol (RFC 4510).  This document is
>> based on the Printer attributes listed in Appendix E of Internet
>> Printing Protocol/1.1 (IPP) (RFC 2911).  Additional Printer
>> attributes are based on definitions in the Printer MIB v2 (RFC 3805),
>> IEEE-ISTO PWG Command Set for IEEE 1284 Device ID (PWG 5107.2),
>> IEEE-ISTO PWG IPP Job and Printer Extensions - Set 3 (PWG 5100.13),
>> and IEEE-ISTO PWG IPP Everywhere (PWG 5100.14).
>>
>> This document is published by the IETF on behalf of the Internet
>> Printing Protocol Working Group of the IEEE-ISTO Printer Working
>> Group.
>>
>>
>> Most of the issues I found are minor. In general the document is quite
>> readable.
>>
>> General comments:
>>
>> I noticed that you redifined various syntaxes to have upper limits on
>> Directory strings. URI and Language Tags have no upper limits.  I suspect
>> that limits that you added are going to be sufficient in most cases, but it
>> would be better for your document to call these out explicitly in text.
>>
>
> <ira>
> We'll remove the upper limits from the ASN.1 and add them to the text of
> each
> relevant attribute.
>
> We'll also add an Implementation Note that explains the rationale for the
> limits
> and compatibility considerations w/ RFC 3712 implementations deployed over
> the past ten years - which is the string length limits in the underlying
> attributes
> in the Job Monitoring MIB (RFC 2707) and IPP/1.1 (RFC 2911).
> <ira>
>
>>
>> In Section 1:
>>
>> This document updates RFC 3712.
>>
>> But the draft header says that it Obsoletes it. I think Obsolete is
>> correct, so the statement in Section 1 should be updated to match.
>>
>
> <ira>
> Good catch.  We'll fix this to "Obsoletes".
> </ira>
>
>
>> In Section 3.3:
>>
>>     Note:  When extending other structural classes with auxiliary
>>>     classes, printerService SHOULD not be used.
>>>
>> You should also capitalize "not" according to RFC 2119. There are
>> multiple occurrences of the same problem in multiple places in the document.
>>
>
> <ira>
> Oops.  This was an artifact of the RFC 3712 text.  We'll fix it globally.
> </ira>
>
>>
>>  3.4.  printerServiceAuxClass
>>>         ( 1.3.18.0.2.6.257
>>>     NAME  'printerServiceAuxClass'
>>>     DESC  'Printer information.'
>>>
>>> Fleming, McDonald            Expires 19 March 2014             [Page 11]
>>>
>>> Internet-Draft    LDAP Schema for Printer Services     19 September 2013
>>>
>>>     AUXILIARY
>>>     SUP   printerAbstract
>>>     MAY   ( printer-uri $
>>>             printer-xri-supported )
>>>     )
>>>         This auxiliary class defines Printer information.  It is derived
>>> from
>>>     class printerAbstract and thus inherits common Printer attributes.
>>>     This class SHOULD be used with a structural class.
>>>
>> Each directory entry requires a structural object class, so I think this
>> SHOULD is misleading. Also, why is this not a MUST?
>> I suggest you just delete this sentence or reword it to make it non
>> normative (and point to the document which makes the authoritative
>> statement on this matter.)
>>
>> Similar text in 3.5 and 3.6.
>>
>
> <ira>
> Oops. We'll fix this by deleting the misleading sentences globally.
> </ira>
>
>>
>>  4.  Definition of Attribute Types
>>>
>>>    The following attribute types reference matching rule names (instead
>>>    of OIDs) for clarity (see Section 6 below).  For optional attributes,
>>>    if the Printer information is not known, the attribute value SHOULD
>>>    not be set.  In the following definitions, referenced matching rules
>>>    are defined in Section 4 of [RFC4517] (see Section 6 'Definition of
>>>    Matching Rules' below).
>>>
>>
>> I think you still meant section 4.
>>
>
> <ira>
> Actually it should be a forward reference to section 6 of this document,
> but we'll clarify the wording in the next draft, e.g., to
> "...Section 4 of [RFC4517] and discussed in Section 6 ' Definition of
> Matching Rules' later in this document."
> OK?
> </ira>
>
>>
>>      Note:  For interoperability and consistent text display, values of
>>>     attributes defined in this document:  (a) SHOULD be normalized as
>>>     recommended in Unicode Format for Network Interchange [RFC5198]; (b)
>>>     SHOULD not contain DEL or any C0 or C1 control characters except for
>>>
>> "SHOULD not" --> "SHOULD NOT"
>>
>
> <ira>
> Oops.  We'll fix in the global check for "SHOULD not" to "SHOULD NOT".
>  </ira>
>
>      HT, CR, and LF; (c) SHOULD only contain CR and LF characters together
>>>     (not as singletons); and SHOULD NOT contain HT, CR, or LF characters
>>>     in names, e.g., printer-name and printer-aliases.
>>>
>>
>>  In 4.1:
>
>>
>>      Note:  LDAP application clients SHOULD not attempt to use malformed
>>>     URI values read from this attribute.  LDAP administrative clients
>>>     SHOULD not write malformed URI values into this attribute.
>>>
>> "SHOULD not" --> "SHOULD NOT" (twice)
>>
>
> <ira>
> Oops.  This was an artifact of the RFC 3712 text.  We'll fix it globally.
> </ira>
>
>>
>> In 4.4:
>>
>>      Values of language tags SHOULD conform to Tags for Identifying
>>>     Languages [BCP47].
>>>
>> Why is this a SHOULD and not a MUST? I.e. what are possible reason to put
>> anything not specified in BCP47 here?
>>
>
> <ira>
> Oops.  We'll change "SHOULD" to "MUST".  The original "SHOULD" (I think)
> was an attempt to allow for the rigorous ABNF in the earlier version of
> BCP47.
> </ira>
>
>>
>>      4.12.  printer-charset-supported
>>>         ( 1.3.18.0.2.4.1131
>>>     NAME 'printer-charset-supported'
>>>     DESC 'One of the charsets supported for the attribute values of
>>>           syntax DirectoryString for this directory entry.'
>>>
>> I don't understand this description. DirectoryString is always in UTF-8.
>>
>
> <ira>
> Oops.  We'll fix the description to refer (as intended) to the underlying
> IPP/1.1 (RFC 2911) corresponding attribute which does allow legacy
> character sets (although they are discouraged) and to restate that the
> values of DirectoryString in this LDAP Schema MUST always be UTF-8.
> </ira>
>
>>
>> How is this LDAP attribute being used?
>>
>>>     EQUALITY caseIgnoreMatch
>>>     SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{255}
>>>     )
>>>
>>
> <ira>
> We have an EQUALITY clause for every string attribute.  The values
> of this attribute are used to inform the LDAP Client of what the supported
> values of the underlying IPP/1.1 (RFC 2911) attribute are, i.e., what are
> the possible charsets that can be sent in string attributes in IPP/1.1
> requests.  We'll rewrite this description to clarify the usage.
> </ira>
>
>>
>>     4.13.  printer-generated-natural-language-supported
>>>         ( 1.3.18.0.2.4.1137
>>>     NAME 'printer-generated-natural-language-supported'
>>>     DESC 'One of the natural languages supported for this directory
>>>           entry.'
>>>
>> Again, I am not entirely sure how this is used. Can you clarify?
>>
>
> <ira>
> Same description problem as the previous attribute (it really refers to
> the supported values of the underlying IPP/1.1 (RFC 2911) attribute).
> We'll rewrite this description to clarify the usage.
> </ira>
>
>>
>>     4.20.  printer-number-up-supported
>>>         ( 1.3.18.0.2.4.1124
>>>     NAME 'printer-number-up-supported'
>>>     DESC 'Maximum number of print-stream pages that can be imposed upon a
>>>           single side of an instance of selected medium by this Printer.'
>>>     EQUALITY integerMatch
>>>     ORDERING integerOrderingMatch
>>>     SYNTAX  1.3.6.1.4.1.1466.115.121.1.27
>>>     )
>>>
>> This is not defined as single-valued. What is the meaning of multiple
>> values?
>>
>
> <ira>
> Oops.  This is an RFC 3712 bug.  The underlying IPP/1.1 (RFC 2911)
> attribute
> has a complex syntax of "1setOf (integer (1:MAX)" or "rangeOfInteger
> (1:MAX)".
> We intended to flatten it in the LDAP Printer Schema to the simple maximum.
> I think we should delete the erroneous ORDERING clause.
> OK?
> </ira>
>
>>
>>      4.35.  printer-device-id
>>>         ( 1.3.18.0.2.24.46.1.101
>>>     NAME 'printer-device-id'
>>>     DESC 'The IEEE 1284 Device ID for this Printer.'
>>>     EQUALITY caseIgnoreMatch
>>>     SUBSTR caseIgnoreSubstringsMatch
>>>     SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{255}
>>>     )
>>>         Values of this attribute SHOULD conform to IEEE-ISTO PWG Command
>>> Set
>>>     Format for IEEE 1284 Device ID [PWG5107.2].
>>>         Note:  For interoperatibility, values of this attribute SHOULD
>>>     include key/value pairs in the following order:  (a) all required
>>>     key/value pairs (i.e., MANUFACTURER/MFG, MODEL/MDL, and COMMAND
>>>     SET/CMD); (b) all optional key/value pairs; and (c) all vendor
>>>     key/value pairs.
>>>
>> How does the advice on ordering interacts with multiple values of the
>> attribute? LDAP multivalued attributes have no ordering of values.
>>
>
> <ira>
> The ordering advice is for the three keywords that are mandatory in the
> source
> IEEE 1284 standard.  I suggest that we simply delete the "Note" clause
> that is
> already covered in much greater detail in PWG 5107.2 with a rationale
> (which
> is the preservation of the three mandatory keywords when string truncation
> may
> occur in various other directory and service location protocols).
> OK?
> </ira>
>
>>
>>    printer-device-id                             1.3.18.0.2.24.46.1.101
>>    printer-device-service-count                  1.3.18.0.2.24.46.1.102
>>    printer-uuid                                  1.3.18.0.2.24.46.1.104
>>    printer-charge-info                           1.3.18.0.2.24.46.1.105
>>    printer-charge-info-uri                       1.3.18.0.2.24.46.1.106
>>    printer-geo-location                          1.3.18.0.2.24.46.1.107
>>    printer-ipp-features-supported                1.3.18.0.2.24.46.1.108
>>
>> This is not necessarily a problem, but I couldn't find a registration for
>> the 1.3.18.0.2.24 OID. The parent OID is owned by IBM.
>>
>
> <ira>
> In October 2011, IBM permanently assigned this base OID to IEEE-ISTO PWG
> for use in the LDAP Printer Schema and any other future PWG standard that
> needed an ASN.1 OID (which wouldn't be covered by the PWG's SMI arc).
> We'll add a labelled section (to show up in Table of Contents) to document
> this
> assignment.
> </ira>
>
>>
>> 13.  Appendix X - Change History
>>
>>    [ [RFC Editor:  This section to be deleted before RFC publication] ]
>>
>> -bis document are required to include "Changes since RFC XXXX" section.
>> So you should replace this Appendix with another one that details changes
>> since RFC 3712.
>>
>
> <ira>
> We'll add a new permanent appendix for "Changes since RFC 3712".
> We prefer to leave the Change History appendix until final publication
> as an RFC, to document the serpentine path to the final text and to
> acknowledge specific contributions that led to draft changes.
> OK?
> </ira>
>
>
>> Best Regards,
>> Alexey
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20131209/559cbf2c/attachment.html>


More information about the ipp mailing list