---------- Forwarded message ----------
From: Alexey Melnikov <aamelnikov at fastmail.fm>
Date: Tue, Jun 7, 2016 at 9:57 AM
Subject: AD review of draft-sweet-rfc2910bis-07.txt
To: Ira McDonald <blueroofmusic at gmail.com>, Michael R Sweet <
msweet at apple.com>
Cc: art-ads at ietf.org, Barry Leiba <barryleiba at computer.org>
Hi,
Below is my AD review. Most of these are minor and I am happy to start IETF
LC right away, but I need a new version to address the issues I found:
A small note about referencing "Model" (rfc2911bis). This is an issue with
generated HTML, but text like:
The first three fields in the above diagram contain the value of
attributes described in Section 3.1.1 of the Model.
produces a link that points to rfc2910bis and not rfc2911bis. Something
like:
... Model [rfc2911bis].
would be better. This can probably be sorted out by the RFC Editor, but you
might want to fix this yourself.
Issues found by ID-nits:
== Unused Reference: 'IANA-CON' is defined on line 1508, but no explicit
reference was found in the text
-- I suggest removing the reference.
** Obsolete normative reference: RFC 1903 (Obsoleted by RFC 2579)
-- It looks like updating to RFC 2579 is the right thing here.
** Downref: Normative reference to an Informational RFC: RFC 2818.
-- This is Ok, already in the DownRef registry. So just ignore this.
Other issues:
In Section 3:
The first reference to a charset needs a reference to RFC 2978.
In 3.2:
begin-attribute-group-tag = %x00-02 / %x04-0F ; see section 3.5.1
s/%04/%x04
(you are missing "x", without it the ABNF is not syntactically valid).
3.8. Value Length
For any of the types represented by binary signed bytes, the sender
MUST encode the value in exactly one octet.
Can you give me an example? Are you talking about booleans or something
else?
In 8.1.2:
IPP Clients and Printers MAY support Basic
Authentication [RFC7617] for User Authentication if the channel is
secure.
I think you need to expand on what "secure" means here. I think you meant
that TLS was successfully negotiated and the TLS server identity was
verified successfully by the client.
In Section 9:
When you mention IPP/2.0, 2.1 or 2.2, you should have a Normative reference
to relevant specs, because you use them in a SHOULD-level requirement.
In Appendix B:
This section is strictly informative. The MIME media type
listed in
this section should not be re-registered by IANA when this document
is published.
I think this is wrong. The IANA registration template is out of date. It is
missing "Change Controller", etc. See RFC 6838, section 5.6.
So I think this needs to be updated and also mentioned in the
IANA Considerations section.
Best Regards,
Alexey
On Thu, Jun 2, 2016, at 12:17 PM, Ira McDonald wrote:
Hi Alexey,
The document names are:
Internet Printing Protocol/1.1: Model and Semantics
http://www.ietf.org/internet-drafts/draft-sweet-rfc2911bis-09.txt
Internet Printing Protocol/1.1: Encoding and Transport
http://www.ietf.org/internet-drafts/draft-sweet-rfc2910bis-07.txt
Background: In the 1990s, there were a dozen proprietary print protocols
and
several incompatible implementations of LPR. Today, over 98% of all recent
network printers support IPP/1.1. And new network printers will soon be PWG
logo certified for IPP Everywhere (printing via single standard OS driver,
replacing
40 million Windows drivers and 28 million Apple drivers). More than a
dozen IETF
RFCs and 20 PWG standards are based on IPP/1.1. Last year, the PWG profile
spec PWG 5100.12 (2.0, 2.1, 2.2 versions as supersets of 1.1) became the
first full
PWG Standard.
http://www.pwg.org/ipp/everywhere.htmlhttp://ftp.pwg.org/pub/pwg/standards/std-ipp20-20151030-5100.12.pdf
Please let us know if you have questions or suggestions for IETF-based
review.
Cheers,
- Ira (PWG Secretary, PWG IPP WG Co-Chair)
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/blueroofmusichttp://sites.google.com/site/highnorthinc
mailto: blueroofmusic at gmail.com
Winter 579 Park Place Saline, MI 48176 734-944-0094
Summer PO Box 221 Grand Marais, MI 49839 906-494-2434
On Thu, Jun 2, 2016 at 5:31 AM, Alexey Melnikov <aamelnikov at fastmail.fm>
wrote:
Hi,
I am happy to AD-sponsor -bis documents, assuming I don't find anything
seriously objectionable in my AD review (this is not likely, but I
basically reserve the right to change my mind after seeing documents).
What are the document names?
Best Regards,
Alexey
On Tue, May 31, 2016, at 08:03 PM, Barry Leiba wrote:
> Hi, Ian, and I'm sorry I didn't answer this last week. I'm glad to
> hear that you folks have gotten this work done and are ready to put
> out the IETF versions. Unfortunately for my earlier offer, I'm no
> longer an Area Director (my second term ended in April), and Alexey
> Melnikov, whom I've added to this message, is the new AD responsible
> for this area of work.
>> Alexey, the IPP stuff was done in the IETF long ago, producing RFCs
> 2910 and 2911, and some other stuff. After the IETF working group was
> closed, 15 or so years ago, continued work on IPP went to the
> IEEE-ISTO PWG Internet Printing Protocol WG, which Ira and Michael are
> representing. As the original documents are Standards Track, updates
> need to go through the IETF stream as Standards Track documents... but
> no one in the IETF works on this any more, and all the people who do
> are in the PWG IPP WG.
>> So the right thing to do is to run their updates through the process
> as AD-sponsored documents that have full support from the current IPP
> practitioners. Forming a working group would be of little point.
> This seems a bit like people coming to us and asking for a rubber
> stamp of "Standard" on their work, but it's not really the same thing
> in this case. I recommend that you do AD-sponsor this, but, of
> course, have a look and see what you think.
>> Barry
>> On Wed, May 25, 2016 at 4:33 PM, Ira McDonald <blueroofmusic at gmail.com>
> wrote:
> > Hi Barry,
> >
> > After more little nits than we could have imagined, Mike Sweet has
> > completed stable drafts of IPP/1.1 (RFC2910bis and RFC2911bis):
> >
> > http://www.ietf.org/internet-drafts/draft-sweet-rfc2910bis-07.txt> >
> > http://www.ietf.org/internet-drafts/draft-sweet-rfc2911bis-09.txt> >
> > These documents are now ready for IETF review.
> >
> > You offered last year to AD sponsor these updates and we hope that
> > you can advise us and forward these documents to the appropriate
> > IETF WGs/mailing lists for review and comments. The Abstracts have
> > been updated and there are sections for "Changes Since RFC29xx".
> >
> > Cheers,
> > - Ira (PWG Secretary, PWG IPP WG Co-Chair)
> >
> >
> > 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: blueroofmusic at gmail.com> > Winter 579 Park Place Saline, MI 48176 734-944-0094
> > Summer PO Box 221 Grand Marais, MI 49839 906-494-2434
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20160613/f35037a1/attachment.html>