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 & 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"><<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>></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'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 & 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"><<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>></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 <<a href="mailto:alexey.melnikov@isode.com" target="_blank">alexey.melnikov@isode.com</a>>, Ira McDonald <<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>><br>
Cc: "<a href="mailto:apps-discuss@ietf.org" target="_blank">apps-discuss@ietf.org</a>" <<a href="mailto:apps-discuss@ietf.org" target="_blank">apps-discuss@ietf.org</a>>, Pat Fleming <<a href="mailto:patfleminghtc@gmail.com" target="_blank">patfleminghtc@gmail.com</a>><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 & 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"><<a href="mailto:alexey.melnikov@isode.com" target="_blank">alexey.melnikov@isode.com</a>></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><ira><br></div><div>We'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'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><ira><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><ira><br></div><div>Good catch. We'll fix this to "Obsoletes".<br>
</div><div></ira> <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 "not" 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><ira><br></div><div>
Oops. This was an artifact of the RFC 3712 text. We'll fix it globally.<br>
</div><div></ira> <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 'printerServiceAuxClass'<br>
DESC 'Printer information.'<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><ira><br></div><div>Oops. We'll fix this by deleting the misleading sentences globally.<br></div><div></ira> <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 'Definition of<br>
Matching Rules' below).<br>
</blockquote>
<br>
I think you still meant section 4.<br></blockquote><div><br></div></div><div><ira><br></div><div>Actually it should be a forward reference to section 6 of this document,<br></div><div>but we'll clarify the wording in the next draft, e.g., to<br>
</div><div>"...Section 4 of [RFC4517] and discussed in Section 6 ' Definition of<br></div><div>Matching Rules' later in this document."<br></div><div>OK?<br></div><div></ira><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>
"SHOULD not" --> "SHOULD NOT"<br></blockquote><div><br></div></div><div><ira><br></div><div>Oops. We'll fix in the global check for "SHOULD not" to "SHOULD NOT".<br></div>
<div>
</ira> <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>
"SHOULD not" --> "SHOULD NOT" (twice)<br></blockquote><div><br></div></div><div><ira><br><div>Oops. This was an artifact of the RFC 3712 text. We'll fix it globally.<br></div></ira> <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><ira><br></div><div>Oops. We'll change "SHOULD" to "MUST". The original "SHOULD" (I think)<br>
</div><div>was an attempt to allow for the rigorous ABNF in the earlier version of BCP47.<br></div><div></ira><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 'printer-charset-supported'<br>
DESC 'One of the charsets supported for the attribute values of<br>
syntax DirectoryString for this directory entry.'<br>
</blockquote>
I don't understand this description. DirectoryString is always in UTF-8.<br></blockquote><div><br></div></div><div><ira><br></div><div>Oops. We'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></ira> <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><ira><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'll rewrite this description to clarify the usage.<br>
</div><div></ira> <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 'printer-generated-natural-<u></u>language-supported'<br>
DESC 'One of the natural languages supported for this directory<br>
entry.'<br>
</blockquote>
Again, I am not entirely sure how this is used. Can you clarify?<br></blockquote><div><br></div></div><div><ira><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'll rewrite this description to clarify the usage.<br></div><div></ira><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 'printer-number-up-supported'<br>
DESC 'Maximum number of print-stream pages that can be imposed upon a<br>
single side of an instance of selected medium by this Printer.'<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><ira><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 "1setOf (integer (1:MAX)" or "rangeOfInteger (1:MAX)".<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></ira><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 'printer-device-id'<br>
DESC 'The IEEE 1284 Device ID for this Printer.'<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><ira><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 "Note" 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></ira><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'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><ira><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't be covered by the PWG's SMI arc). <br></div><div>We'll add a labelled section (to show up in Table of Contents) to document this<br>
assignment.<br></div><div></ira><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 "Changes since RFC XXXX" section. So you should replace this Appendix with another one that details changes since RFC 3712.<br></blockquote><div><br></div></div><div><ira><br>
</div><div>We'll add a new permanent appendix for "Changes since RFC 3712".<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></ira><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>