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

[Claudio Allocchio <[e-mail]>]

On Tue, 26 Nov 2013, Ira McDonald wrote:

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

Ira,

that's because the whole Datatracker was designed to describe "reviews" 
being performed when the IETF Last Call is issued by the IESG, and as such 
"there is a Shepard and AD".

but lately we started the "Early Review" experiment, when WG chairs can 
request reviews even before the LC is out, to make easier and more 
efficient the process.

Alexey (but I made the same slight mistake!) used a template form which is 
for the traditional "in LC period" reviews... also because we do not have 
one (yet) for the Early Review ones...

... yes something to fix into the documentation!


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

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [e-mail]
                         Senior Technical Officer
tel: [phone]      Italian Academic and       G=Claudio; S=Allocchio;
fax: [phone]        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca