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

[Ira McDonald <[e-mail]>]

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: [e-mail]
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 <[e-mail]
> 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.
>
>
> 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
>
>