Hi,
I'll consider all of these good comments from Alexey and review briefly
at IPP WG extra call (25 November) or regular call (2 December).
Cheers,
- Ira
---------- Forwarded message ----------
From: Alexey Melnikov <alexey.melnikov at isode.com>
Date: Mon, Nov 18, 2013 at 10:37 AM
Subject: AppsDir review of draft-mcdonald-ldap-printer-schema-05.txt
To: Ira McDonald <blueroofmusic at gmail.com>
Cc: "apps-discuss at ietf.org" <apps-discuss at ietf.org>, Pat Fleming <
patfleminghtc at gmail.com>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20131118/a8b1e970/attachment.html>