attachment

<div dir="ltr"><div><div><div><div><div><div>Hi,<br><br></div>Here is my conversation w/ Alexey Melnikov about his comments on the <br>LDAP Printer Schema - these resolve all open issues from his Apps Dir <br>review - I plan to post a new LDAP Printer Schema draft over Christmas <br>

break.<br><br></div><div><a href="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-20131208.pdf</a><br></div></div>
<a href="http://ftp.pwg.org/pub/pwg/ipp/wd/alexey-ldap-printer-schema-comments-20131209.pdf">http://ftp.pwg.org/pub/pwg/ipp/wd/alexey-ldap-printer-schema-comments-20131209.pdf</a><br>
<br></div>Cheers,<br></div>- Ira<br><br></div></div><div class="gmail_extra"><br clear="all"><div><div dir="ltr">Ira McDonald (Musician / Software Architect)<br>Co-Chair - TCG Trusted Mobility Solutions WG<br>Chair - Linux Foundation Open Printing WG<br>

Secretary - IEEE-ISTO Printer Working Group<br>Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG<br>IETF Designated Expert - IPP &amp; Printer MIB<br>Blue Roof Music / High North Inc<br><a style="color:rgb(51,51,255)" href="http://sites.google.com/site/blueroofmusic" target="_blank">http://sites.google.com/site/blueroofmusic</a><br>

<a style="color:rgb(102,0,204)" href="http://sites.google.com/site/highnorthinc" target="_blank">http://sites.google.com/site/highnorthinc</a><br>mailto: <a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a><br>

Winter  579 Park Place  Saline, MI  48176  734-944-0094<br>Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434<br><br><div style="display:inline"></div><div style="display:inline"></div><div style="display:inline"></div>

<div></div><div></div><div></div><div></div></div></div>
<br><br><div class="gmail_quote">On Sun, Dec 8, 2013 at 1:17 PM, Ira McDonald <span dir="ltr">&lt;<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr"><div><div><div><div><div><div>Hi,<br><br></div>FYI - below are the responses that I sent to Alexey Melnikov for<br></div>his very thorough review of the latest draft LDAP Printer Schema.<br><br></div>Barring any objections from Alexey, I&#39;ll try to send a corresponding<br>


</div>updated draft to the IETF and PWG before Christmas.<br><br></div>Cheers,<br></div>- Ira (co-editor of LDAP Printer Schema)<br><br><br clear="all"><div><div><div><div><div><div><div><div><div dir="ltr">Ira McDonald (Musician / Software Architect)<br>


Co-Chair - TCG Trusted Mobility Solutions WG<br>Chair - Linux Foundation Open Printing WG<br>Secretary - IEEE-ISTO Printer Working Group<br>Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG<br>IETF Designated Expert - IPP &amp; Printer MIB<br>


Blue Roof Music / High North Inc<br><a style="color:rgb(51,51,255)" href="http://sites.google.com/site/blueroofmusic" target="_blank">http://sites.google.com/site/blueroofmusic</a><br><a style="color:rgb(102,0,204)" href="http://sites.google.com/site/highnorthinc" target="_blank">http://sites.google.com/site/highnorthinc</a><br>


mailto: <a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a><br>Winter  579 Park Place  Saline, MI  48176  <a href="tel:734-944-0094" value="+17349440094" target="_blank">734-944-0094</a><br>

Summer  PO Box 221  Grand Marais, MI 49839  <a href="tel:906-494-2434" value="+19064942434" target="_blank">906-494-2434</a><br><br><div style="display:inline">
</div><div style="display:inline"></div><div style="display:inline"></div><div></div><div></div><div></div><div></div></div></div>
<br><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Ira McDonald</b> <span dir="ltr">&lt;<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>&gt;</span><br>


Date: Sun, Dec 8, 2013 at 1:08 PM<br>Subject: Re: AppsDir review of draft-mcdonald-ldap-printer-schema-05.txt<br>To: Alexey Melnikov &lt;<a href="mailto:alexey.melnikov@isode.com" target="_blank">alexey.melnikov@isode.com</a>&gt;, Ira McDonald &lt;<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>&gt;<br>


Cc: &quot;<a href="mailto:apps-discuss@ietf.org" target="_blank">apps-discuss@ietf.org</a>&quot; &lt;<a href="mailto:apps-discuss@ietf.org" target="_blank">apps-discuss@ietf.org</a>&gt;, Pat Fleming &lt;<a href="mailto:patfleminghtc@gmail.com" target="_blank">patfleminghtc@gmail.com</a>&gt;<br>


<br><br><div dir="ltr"><div>Hi Alexey,<br><br></div><div>Thank you very much for your careful review of our revised LDAP Printer<br></div><div>Schema I-D.  Our responses to your comments are inline below.<br><br></div><div>


We plan to issue a new draft before Christmas.<br>
<br></div><div>Cheers,<br></div><div>- Ira<br></div><div><br></div><div class="gmail_extra"><br clear="all"><div><div dir="ltr"><div>Ira McDonald (Musician / Software Architect)<br>Co-Chair - TCG Trusted Mobility Solutions WG<br>



Chair - Linux Foundation Open Printing WG<br>Secretary - IEEE-ISTO Printer Working Group<br></div><div>Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG<br>IETF Designated Expert - IPP &amp; Printer MIB<br>
Blue Roof Music / High North Inc<br>
<a style="color:rgb(51,51,255)" href="http://sites.google.com/site/blueroofmusic" target="_blank">http://sites.google.com/site/blueroofmusic</a><br><a style="color:rgb(102,0,204)" href="http://sites.google.com/site/highnorthinc" target="_blank">http://sites.google.com/site/highnorthinc</a><br>



mailto: <a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a><br>Winter  579 Park Place  Saline, MI  48176  <a href="tel:734-944-0094" value="+17349440094" target="_blank">734-944-0094</a><br>


Summer  PO Box 221  Grand Marais, MI 49839  <a href="tel:906-494-2434" value="+19064942434" target="_blank">906-494-2434</a><br><br><div style="display:inline">
</div><div style="display:inline"></div><div style="display:inline"></div><div></div><div></div><div></div><div></div></div></div></div>
<br><br><div class="gmail_quote"><div>On Mon, Nov 18, 2013 at 10:37 AM, Alexey Melnikov <span dir="ltr">&lt;<a href="mailto:alexey.melnikov@isode.com" target="_blank">alexey.melnikov@isode.com</a>&gt;</span> wrote:<br>
</div><div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On 19/09/2013 17:34, Ira McDonald wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Hello,<br>
<br>
The IEEE-ISTO PWG Internet Printing Protocol WG would like to request<br>
IETF Apps Area review of our updated LDAP Printer Schema (updates<br>
RFC 3712).<br>
<br>
<a href="http://www.ietf.org/internet-drafts/draft-mcdonald-ldap-printer-schema-05.txt" target="_blank">http://www.ietf.org/internet-<u></u>drafts/draft-mcdonald-ldap-<u></u>printer-schema-05.txt</a><br>
<br>
Cheers,<br>
- Ira (co-chair of IEEE-ISTO PWG IPP WG and co-editor of this document)<br>
</blockquote>
<br>
My apologies for belated review. I hope you find them useful.<br>
<br>
------------------------------<u></u>-----------<br>
<br>
I have been selected as the Applications Area Directorate reviewer for this draft (for background on APPSDIR, please see <a href="http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate" target="_blank">http://trac.tools.ietf.org/<u></u>area/app/trac/wiki/<u></u>ApplicationsAreaDirectorate</a> ). <br>




<br>
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.<br>
<br>
Document: draft-mcdonald-ldap-printer-<u></u>schema-05.txt<br>
Title: Lightweight Directory Access Protocol (LDAP): Schema for Printer Services<br>
Reviewer: Alexey Melnikov<br>
Review Date: November 18, 2013<br>
IETF Last Call Date: N/A<br>
<br>
Summary: This draft is nearly reading for publication.<br>
<br>
This document defines a schema, object classes and attributes, for<br>
Printers and Print Services, for use with directories that support<br>
Lightweight Directory Access Protocol (RFC 4510).  This document is<br>
based on the Printer attributes listed in Appendix E of Internet<br>
Printing Protocol/1.1 (IPP) (RFC 2911).  Additional Printer<br>
attributes are based on definitions in the Printer MIB v2 (RFC 3805),<br>
IEEE-ISTO PWG Command Set for IEEE 1284 Device ID (PWG 5107.2),<br>
IEEE-ISTO PWG IPP Job and Printer Extensions - Set 3 (PWG 5100.13),<br>
and IEEE-ISTO PWG IPP Everywhere (PWG 5100.14).<br>
<br>
This document is published by the IETF on behalf of the Internet<br>
Printing Protocol Working Group of the IEEE-ISTO Printer Working<br>
Group.<br>
<br>
<br>
Most of the issues I found are minor. In general the document is quite readable.<br>
<br>
General comments:<br>
<br>
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.<br>



</blockquote><div><br></div></div></div><div>&lt;ira&gt;<br></div><div>We&#39;ll remove the upper limits from the ASN.1 and add them to the text of each<br></div><div>relevant attribute.  <br><br>We&#39;ll also add an Implementation Note that explains the rationale for the limits<br>



and compatibility considerations w/ RFC 3712 implementations deployed over<br>the past ten years - which is the string length limits in the underlying attributes <br>in the Job Monitoring MIB (RFC 2707) and IPP/1.1 (RFC 2911).<br>



</div><div>&lt;ira&gt;<br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>

In Section 1:<br>
<br>
This document updates RFC 3712.<br>
<br>
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.<br></blockquote><div><br></div></div><div>&lt;ira&gt;<br></div><div>Good catch.  We&#39;ll fix this to &quot;Obsoletes&quot;.<br>



</div><div>&lt;/ira&gt; <br></div><div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
In Section 3.3:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
   Note:  When extending other structural classes with auxiliary<br>
    classes, printerService SHOULD not be used.<br>
</blockquote>
You should also capitalize &quot;not&quot; according to RFC 2119. There are multiple occurrences of the same problem in multiple places in the document.<br></blockquote><div><br></div></div><div>&lt;ira&gt;<br></div><div>


Oops.  This was an artifact of the RFC 3712 text.  We&#39;ll fix it globally.<br>
</div><div>&lt;/ira&gt; <br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
3.4.  printerServiceAuxClass<br>
        ( 1.3.18.0.2.6.257<br>
    NAME  &#39;printerServiceAuxClass&#39;<br>
    DESC  &#39;Printer information.&#39;<br>
<br>
Fleming, McDonald            Expires 19 March 2014             [Page 11]<br>
<br>
Internet-Draft    LDAP Schema for Printer Services     19 September 2013<br>
<br>
    AUXILIARY<br>
    SUP   printerAbstract<br>
    MAY   ( printer-uri $<br>
            printer-xri-supported )<br>
    )<br>
        This auxiliary class defines Printer information.  It is derived from<br>
    class printerAbstract and thus inherits common Printer attributes.<br>
    This class SHOULD be used with a structural class.<br>
</blockquote>
Each directory entry requires a structural object class, so I think this SHOULD is misleading. Also, why is this not a MUST?<br>
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.)<br>
<br>

Similar text in 3.5 and 3.6.<br></blockquote><div><br></div></div><div>&lt;ira&gt;<br></div><div>Oops. We&#39;ll fix this by deleting the misleading sentences globally.<br></div><div>&lt;/ira&gt; <br></div><div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
4.  Definition of Attribute Types<br>
<br>
   The following attribute types reference matching rule names (instead<br>
   of OIDs) for clarity (see Section 6 below).  For optional attributes,<br>
   if the Printer information is not known, the attribute value SHOULD<br>
   not be set.  In the following definitions, referenced matching rules<br>
   are defined in Section 4 of [RFC4517] (see Section 6 &#39;Definition of<br>
   Matching Rules&#39; below).<br>
</blockquote>
<br>
I think you still meant section 4.<br></blockquote><div><br></div></div><div>&lt;ira&gt;<br></div><div>Actually it should be a forward reference to section 6 of this document,<br></div><div>but we&#39;ll clarify the wording in the next draft, e.g., to<br>



</div><div>&quot;...Section 4 of [RFC4517] and discussed in Section 6 &#39; Definition of<br></div><div>Matching Rules&#39; later in this document.&quot;<br></div><div>OK?<br></div><div>&lt;/ira&gt;<br></div><div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
    Note:  For interoperability and consistent text display, values of<br>
    attributes defined in this document:  (a) SHOULD be normalized as<br>
    recommended in Unicode Format for Network Interchange [RFC5198]; (b)<br>
    SHOULD not contain DEL or any C0 or C1 control characters except for<br>
</blockquote>
&quot;SHOULD not&quot; --&gt; &quot;SHOULD NOT&quot;<br></blockquote><div><br></div></div><div>&lt;ira&gt;<br></div><div>Oops.  We&#39;ll fix in the global check for &quot;SHOULD not&quot; to &quot;SHOULD NOT&quot;.<br></div>


<div>
&lt;/ira&gt; <br><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
    HT, CR, and LF; (c) SHOULD only contain CR and LF characters together<br>
    (not as singletons); and SHOULD NOT contain HT, CR, or LF characters<br>
    in names, e.g., printer-name and printer-aliases.<br>
</blockquote>
<br></blockquote><div> In 4.1:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
    Note:  LDAP application clients SHOULD not attempt to use malformed<br>
    URI values read from this attribute.  LDAP administrative clients<br>
    SHOULD not write malformed URI values into this attribute.<br>
</blockquote>
&quot;SHOULD not&quot; --&gt; &quot;SHOULD NOT&quot; (twice)<br></blockquote><div><br></div></div><div>&lt;ira&gt;<br><div>Oops.  This was an artifact of the RFC 3712 text.  We&#39;ll fix it globally.<br></div>&lt;/ira&gt; <br>



</div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
In 4.4:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
    Values of language tags SHOULD conform to Tags for Identifying<br>
    Languages [BCP47].<br>
</blockquote>
Why is this a SHOULD and not a MUST? I.e. what are possible reason to put anything not specified in BCP47 here?<br></blockquote><div><br></div></div><div>&lt;ira&gt;<br></div><div>Oops.  We&#39;ll change &quot;SHOULD&quot; to &quot;MUST&quot;.  The original &quot;SHOULD&quot; (I think)<br>



</div><div>was an attempt to allow for the rigorous ABNF in the earlier version of BCP47.<br></div><div>&lt;/ira&gt;<br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
    4.12.  printer-charset-supported<br>
        ( 1.3.18.0.2.4.1131<br>
    NAME &#39;printer-charset-supported&#39;<br>
    DESC &#39;One of the charsets supported for the attribute values of<br>
          syntax DirectoryString for this directory entry.&#39;<br>
</blockquote>
I don&#39;t understand this description. DirectoryString is always in UTF-8.<br></blockquote><div><br></div></div><div>&lt;ira&gt;<br></div><div>Oops.  We&#39;ll fix the description to refer (as intended) to the underlying<br>



</div><div>IPP/1.1 (RFC 2911) corresponding attribute which does allow legacy<br></div><div>character sets (although they are discouraged) and to restate that the<br></div><div>values of DirectoryString in this LDAP Schema MUST always be UTF-8.<br>



</div><div>&lt;/ira&gt; <br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
How is this LDAP attribute being used?<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
    EQUALITY caseIgnoreMatch<br>
    SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{<u></u>255}<br>
    )<br></blockquote></blockquote><div><br></div></div><div>&lt;ira&gt;<br></div><div>We have an EQUALITY clause for every string attribute.  The values<br></div><div>of this attribute are used to inform the LDAP Client of what the supported<br>



</div><div>values of the underlying IPP/1.1 (RFC 2911) attribute are, i.e., what are<br></div><div>the possible charsets that can be sent in string attributes in IPP/1.1<br>requests.  We&#39;ll rewrite this description to clarify the usage.<br>



</div><div>&lt;/ira&gt; <br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">




</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
   4.13.  printer-generated-natural-<u></u>language-supported<br>
        ( 1.3.18.0.2.4.1137<br>
    NAME &#39;printer-generated-natural-<u></u>language-supported&#39;<br>
    DESC &#39;One of the natural languages supported for this directory<br>
          entry.&#39;<br>
</blockquote>
Again, I am not entirely sure how this is used. Can you clarify?<br></blockquote><div><br></div></div><div>&lt;ira&gt;<br></div><div>Same description problem as the previous attribute (it really refers to<br>the supported values of the underlying IPP/1.1 (RFC 2911) attribute).<br>



We&#39;ll rewrite this description to clarify the usage.<br></div><div>&lt;/ira&gt;<br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
   4.20.  printer-number-up-supported<br>
        ( 1.3.18.0.2.4.1124<br>
    NAME &#39;printer-number-up-supported&#39;<br>
    DESC &#39;Maximum number of print-stream pages that can be imposed upon a<br>
          single side of an instance of selected medium by this Printer.&#39;<br>
    EQUALITY integerMatch<br>
    ORDERING integerOrderingMatch<br>
    SYNTAX  1.3.6.1.4.1.1466.115.121.1.27<br>
    )<br>
</blockquote>
This is not defined as single-valued. What is the meaning of multiple values?<br></blockquote><div><br></div></div><div>&lt;ira&gt;<br></div><div>Oops.  This is an RFC 3712 bug.  The underlying IPP/1.1 (RFC 2911) attribute<br>



</div><div>has a complex syntax of &quot;1setOf (integer (1:MAX)&quot; or &quot;rangeOfInteger (1:MAX)&quot;.<br></div><div>We intended to flatten it in the LDAP Printer Schema to the simple maximum.<br></div><div>I think we should delete the erroneous ORDERING clause.<br>



</div><div>OK?<br></div><div>&lt;/ira&gt;<br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
    4.35.  printer-device-id<br>
        ( 1.3.18.0.2.24.46.1.101<br>
    NAME &#39;printer-device-id&#39;<br>
    DESC &#39;The IEEE 1284 Device ID for this Printer.&#39;<br>
    EQUALITY caseIgnoreMatch<br>
    SUBSTR caseIgnoreSubstringsMatch<br>
    SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{<u></u>255}<br>
    )<br>
        Values of this attribute SHOULD conform to IEEE-ISTO PWG Command Set<br>
    Format for IEEE 1284 Device ID [PWG5107.2].<br>
        Note:  For interoperatibility, values of this attribute SHOULD<br>
    include key/value pairs in the following order:  (a) all required<br>
    key/value pairs (i.e., MANUFACTURER/MFG, MODEL/MDL, and COMMAND<br>
    SET/CMD); (b) all optional key/value pairs; and (c) all vendor<br>
    key/value pairs.<br>
</blockquote>
How does the advice on ordering interacts with multiple values of the attribute? LDAP multivalued attributes have no ordering of values.<br></blockquote><div><br></div></div><div>&lt;ira&gt;<br></div><div>The ordering advice is for the three keywords that are mandatory in the source<br>



</div><div>IEEE 1284 standard.  I suggest that we simply delete the &quot;Note&quot; clause that is<br></div><div>already covered in much greater detail in PWG 5107.2 with a rationale (which<br></div><div>is the preservation of the three mandatory keywords when string truncation may<br>



</div><div>occur in various other directory and service location protocols).<br></div><div>OK?<br></div><div>&lt;/ira&gt;<br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">




<br>
   printer-device-id                             1.3.18.0.2.24.46.1.101<br>
   printer-device-service-count                  1.3.18.0.2.24.46.1.102<br>
   printer-uuid                                  1.3.18.0.2.24.46.1.104<br>
   printer-charge-info                           1.3.18.0.2.24.46.1.105<br>
   printer-charge-info-uri                       1.3.18.0.2.24.46.1.106<br>
   printer-geo-location                          1.3.18.0.2.24.46.1.107<br>
   printer-ipp-features-supported                1.3.18.0.2.24.46.1.108<br>
<br>
This is not necessarily a problem, but I couldn&#39;t find a registration for the 1.3.18.0.2.24 OID. The parent OID is owned by IBM.<br></blockquote><div><br></div></div><div>&lt;ira&gt;<br></div><div>In October 2011, IBM permanently assigned this base OID to IEEE-ISTO PWG<br>



</div><div>for use in the LDAP Printer Schema and any other future PWG standard that<br></div><div>needed an ASN.1 OID (which wouldn&#39;t be covered by the PWG&#39;s SMI arc). <br></div><div>We&#39;ll add a labelled section (to show up in Table of Contents) to document this<br>



assignment.<br></div><div>&lt;/ira&gt;<br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
13.  Appendix X - Change History<br>
<br>
   [ [RFC Editor:  This section to be deleted before RFC publication] ]<br>
<br>
-bis document are required to include &quot;Changes since RFC XXXX&quot; section. So you should replace this Appendix with another one that details changes since RFC 3712.<br></blockquote><div><br></div></div><div>&lt;ira&gt;<br>



</div><div>We&#39;ll add a new permanent appendix for &quot;Changes since RFC 3712&quot;.<br></div><div>We prefer to leave the Change History appendix until final publication<br>as an RFC, to document the serpentine path to the final text and to<br>



acknowledge specific contributions that led to draft changes.<br></div><div>OK?<br></div><div>&lt;/ira&gt;<br> <br></div><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">




Best Regards,<br>
Alexey<br>
<br>
</blockquote></div><br></div></div>
</div><br></div></div></div></div></div></div></div></div>
</blockquote></div><br></div>