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.pdfhttp://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/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 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>