Subject: [apps-discuss] AppsDir review of draft-mcdonald-ldap-printer-schema-05.txt

From: Alexey Melnikov <[email-masked]>
Date: Mon, 18 Nov 2013 15:37:20 +0000

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.

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.

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.

> 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.

> 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.

>     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"
>     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)

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?

>     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.

How is this LDAP attribute being used?
>     EQUALITY caseIgnoreMatch
>     SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{255}
>     )

>    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?

>    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?

>     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.

    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.

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.

Best Regards,
Alexey

---

From: Ira McDonald <[email-masked]>
Date: Fri, 22 Nov 2013 13:14:46 -0500

Hi Alexey,

Thanks for you excellent comments!  My apologies for not acknowledging them
sooner.

I need to think about resolutions and discuss w/ the IEEE-ISTO PWG Internet
Printing
Protocol WG, so I'll be a week or so responding yet (our next meeting is 2
December).

Cheers,
- Ira (co-editor of LDAP Printer Schema, co-chair of PWG IPP WG)

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: [email-masked]
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 <[email-masked]
> wrote:

> 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.
>
> 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.
>
>
> In Section 1:
>
> You should also capitalize "not" according to RFC 2119. There are multiple
> occurrences of the same problem in multiple places in the document.
>
>
> Why is this a SHOULD and not a MUST? I.e. what are possible reason to put
> anything not specified in BCP47 here?
>
>
> 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.
>
>
> -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.
>
> Best Regards,
> Alexey
>
>