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

[t.petch <[e-mail]>]

----- Original Message -----
From: "Claudio Allocchio" <[e-mail]>
To: "Ira McDonald" <[e-mail]>
Cc: "Pat Fleming" <[e-mail]>; <[e-mail]>
Sent: Tuesday, November 26, 2013 5:05 PM
>
> 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!

Indeed, and being engineers, we can cope with things like that.

Meanwhile, I hope that there will be an AD for these two I-Ds.  I would
like them to progress, bringing RFC2910, RFC2911 up-to-date, and presume
that that would be as an individual submission, which then needs an AD.
I am willing to review them (although my expertise in printing is more
user than
implementor).

Tom Petch

 > 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/ApplicationsAreaDirectorat
e).
> >>>
> >>> 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
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>