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/blueroofmusichttp://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/blueroofmusichttp://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/20131208/95d8cb56/attachment.html>