Re: [IPP] Responses to AppsDir review of draft-mcdonald-ldap-printer-schema-05.txt
Ira McDonald <blueroofmusic@gmail.com> Mon, 09 December 2013 15:28 UTC
Return-Path: <ipp-bounces@pwg.org>
X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E24391AE34C for <ietfarch-ipp-archive@ietfa.amsl.com>; Mon, 9 Dec 2013 07:28:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.361
X-Spam-Level:
X-Spam-Status: No, score=-1.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.428, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9mn62QqvePK for <ietfarch-ipp-archive@ietfa.amsl.com>; Mon, 9 Dec 2013 07:28:51 -0800 (PST)
Received: from www.pwg.org (www.pwg.org [IPv6:2600:3c01::f03c:91ff:fe70:b03f]) by ietfa.amsl.com (Postfix) with ESMTP id 416F91ADF9F for <ipp-archive@lists.ietf.org>; Mon, 9 Dec 2013 07:28:51 -0800 (PST)
Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 2FCC48521; Mon, 9 Dec 2013 15:42:44 +0000 (UTC)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by www.pwg.org (Postfix) with ESMTPS id 10D7B84D9 for <ipp@pwg.org>; Mon, 9 Dec 2013 15:42:42 +0000 (UTC)
Received: by mail-ie0-f170.google.com with SMTP id qd12so6341591ieb.1 for <ipp@pwg.org>; Mon, 09 Dec 2013 07:28:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=f4tl8hxYV6gfN2TdYbGJv8YaZSbd5Ax54qDmmutIaeY=; b=tpFxZ0PGGJ3pkgydI62btbMP5Q8XhQdxGDwImtjcyGbEt54LRy/85XYcBDHgWhSfoT 1yU3YPFBEFqXvIdx4XXHCy5f1WgaFaG1CdNb8xwKcnQV98Z/YgcUNRvl4pEY4noksSxn IGEyV50+fc2XYewfOAAAPr1Ea/aqWBJV+AuN0PlY+Cbbl3qfRtjFsad/8KZ2w7LFxkL8 eduDjFjTpw1LlrSliZEShPO7FULHZM3LxGbfknBSMv3VnIQvrXIwoEW68gX9KIPCf2go cyAodiE8tFiEbDQRlAC2NLZies9+AcaHHicGvivy1NhfPShmiv61DJ4sc8TMaV8r+Pjy a50g==
X-Received: by 10.50.39.45 with SMTP id m13mr16059825igk.14.1386602924214; Mon, 09 Dec 2013 07:28:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.50.203.38 with HTTP; Mon, 9 Dec 2013 07:28:24 -0800 (PST)
In-Reply-To: <CAN40gSvXKwTxrrY4TFsDDuhczTGqkDSOKieFbO1SACoq3yLU-A@mail.gmail.com>
References: <CAN40gSvXKwTxrrY4TFsDDuhczTGqkDSOKieFbO1SACoq3yLU-A@mail.gmail.com>
From: Ira McDonald <blueroofmusic@gmail.com>
Date: Mon, 09 Dec 2013 10:28:24 -0500
Message-ID: <CAN40gSvsFs4WxewCS8aNuPjjY1HgqeNO+r-3HNZHBJgwhwZO1Q@mail.gmail.com>
To: "ipp@pwg.org" <ipp@pwg.org>, Ira McDonald <blueroofmusic@gmail.com>
Subject: Re: [IPP] Responses to AppsDir review of draft-mcdonald-ldap-printer-schema-05.txt
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Internet Printing Protocol Workgroup discussion list <ipp.pwg.org>
List-Unsubscribe: <https://www.pwg.org/mailman/options/ipp>, <mailto:ipp-request@pwg.org?subject=unsubscribe>
List-Archive: <http://www.pwg.org/pipermail/ipp/>
List-Post: <mailto:ipp@pwg.org>
List-Help: <mailto:ipp-request@pwg.org?subject=help>
List-Subscribe: <https://www.pwg.org/mailman/listinfo/ipp>, <mailto:ipp-request@pwg.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0217473184=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
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.pdf http://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/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@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@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@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@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@isode.com>, Ira McDonald < > blueroofmusic@gmail.com> > Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>, Pat Fleming < > patfleminghtc@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@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@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 >> >> > >
_______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp
- [IPP] Responses to AppsDir review of draft-mcdona… Ira McDonald
- Re: [IPP] Responses to AppsDir review of draft-mc… Ira McDonald