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

[Ira McDonald <[e-mail]>]

Hi Alexey,

I'm confused about current IETF procedures.

You requested that I should NOT post a new draft until directed to do so
by my document shepherd or AD.

But, according to the IETF datatracker there is NO assigned document
shepherd or AD for this document:

  http://datatracker.ietf.org/doc/draft-mcdonald-ldap-printer-schema/

And the same holds true for the closely related IPPS URI Scheme draft:

  http://datatracker.ietf.org/doc/draft-mcdonald-ipps-uri-scheme/

How do I get a responsible AD or document shepherd assigned to these
documents?

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: [e-mail]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434



On Fri, Nov 22, 2013 at 1:14 PM, Ira McDonald <[e-mail]>wrote:

> 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
>>
>>
>