Re: [Uri-review] Request for review of draft-mcdonald-ipps-uri-scheme

[Mykyta Yevstifeyev <[e-mail]>]

Hello all,

In December I have already commented this document, but now I'd like to 
raise some other issues and to propose the authors' some other changes.

First of all, this document does not conform to RFC 2223 in the format 
of the text - particularly indents and section titles.

As the global proposal I think IPPS should be replaced with 'ipps'.  
IPPS looks like an abbreviation.

Moreover, I proposed this later, the abstract need be more brief.  I 
propose:

>  This memo defines the Internet Printing Protocol (IPP) over HTTPS
>    transport binding and corresponding 'ipps' URI scheme, that is used
>    to designate the access to the network location of a secure IPP print
>    service, or to a network resource (for example, a print job) managed
>    by such service.
>
>    This memo is a product of the Internet Printing Protocol Working
>    Group in the IEEE-ISTO Printer Working Group, as part of their IPP
>    Everywhere project for mobile, driverless, ubiquitous printing.
>
>    This document updates RFC 2910 and RFC 2911.
Next.  The same concerns the introduction.  I propose:

> This memo defines the Internet Printing Protocol (IPP) over HTTPS
>    transport binding and corresponding 'ipps', that is used to designate
>    the access to the network location of a secure IPP print service, or
>    to a network resource (for example, a print job) managed by such
>    service.  Therefore, this document defines 'ipps' URI scheme
>    applicability, associated port, associated MIME type, character
>    encoding, and syntax.
>
>    This memo updates the Internet Printing Protocol/1.1 Encoding and
>    Transport [RFC2910], by extending section 4 'Encoding of the
>    Transport Layer', section 5 'IPP URL Scheme', and section 8.2 'Using
>    IPP with TLS' and Internet Printing Protocol/1.1 Model and Semantics
>    [RFC2911], by extending section 4.1.6 'uriScheme' and section 4.4.1
>    'printer-uri-supported'.
>
>    This memo is a product of the Internet Printing Protocol Working
>    Group in the IEEE-ISTO Printer Working Group, as part of their IPP
>    Everywhere project for mobile, driverless, ubiquitous printing.
>
>    Overview information about the Internet Printing Protocol (IPP) is
>    available in Section 1 of RFC 2911 [RFC2911] and Section 1 of RFC
>    3196 [RFC3196].
and then separate the structure of the document description to separate 
sub-section of introduction.

Next, the definition of the terms should rather be in the Section 2, 
renamed to 'Conventions Used in this Document'.  Also, I propose to add 
the appendix explaining the abbreviations.

The following thing is Section 4.  I propose to remain the following 
sections:  The 'ipps' URI Scheme Applicability, The 'ipps' URI Scheme 
Syntax, The 'ipps' URI Scheme Character Encoding, The 'ipps' URI Scheme 
Associated MIME Type,The 'ipps' URI Comparisons, The 'ipps' URI Examples 
and the content of others place into these ones.

To add another point, registration template should be directly on 
Section 6, but not in the appendix.  This would improve the readability 
of the doc.

What is more, references are not in the format given at 
ftp://ftp.rfc-editor.org/in-notes/rfc-ref.txt  This should also be changed.

Next, Appendices and Authors' addresses should not be numbered.  I also 
propose to move Acknowledgments to separate Appendix.

Even though these changes are mostly minor editorial proposals, I'd like 
they would be considered while preparing the new version of the draft.

Mykyta Yevstifeyev

10.12.2010 20:26, Ira McDonald wrote:
> Hi,
>
> Please review and send us comments on the IPPS URI Scheme and
> Transport Binding available at:
>
> http://tools.ietf.org/id/draft-mcdonald-ipps-uri-scheme-01.txt
>
>
> Summary:
>
> This memo requests IANA registration of IPPS as a permanent URI
> scheme - see syntax and semantics in section 4 and IANA registration
> in section 12 of this memo.
>
>
> Background:
>
> This memo is a product of the Internet Printing Protocol Working
> Group in the IEEE-ISTO Printer Working Group, as part of their IPP
> Everywhere project for mobile, driverless, ubiquitous printing.
>
> http://pwg-wiki.wikispaces.com/IPP+Everywhere
>
> IPP/1.1 (RFC 2910/2911) uses the IPP URI scheme (RFC 3510) and
> supports secure Printer and Job management and Job submission by
> upgrading to TLS (RFC 5246) using HTTP Upgrade (RFC 2817).  The
> requirement for this TLS upgrade is configured in the IPP Printer object
> for a given service access point URI.
>
> An IPP URI is translated by identity (except for IANA well known port
> 631) into an HTTP URI over the wire (i.e., IPP uses HTTP for its
> transport) - per IESG direction when IPP/1.1 replaced Experimental
> IPP/1.0 (RFC 2565/2566) - see section 3.2 of this memo.
>
> IPP/1.1 is now ubiquitous (i.e., supported by all network printers shipped
> in the last decade).
>
> However, many IPP/1.1 implementations do not support this TLS
> upgrade (OPTIONAL for conformance in RFC 2910/2911).  And some
> IPP/1.1 implementations don't immediately upgrade at connection startup
> (which is non-conforming).
>
> This situation has discouraged the use of IPP/1.1 over public Internet
> connections.
>
> The IPP Everywhere project of the IEEE-ISTO PWG requires the use of
> TLS for *all* connections.  Therefore, an IPPS URI is translated by 
> identity
> (again over port 631) into an HTTPS URI (RFC 2818) - see section 3.3 of
> this memo.  IPPS URI values also must use UTF-8 (RFC 3629).
>
> The IPPS URI scheme has been deployed for years in CUPS - the most
> widely deployed implementation of an IPP print service - CUPS is the
> default print spooler on Mac OSX, Linux, and most UNIX versions and is
> also available on Windows and other operating systems.
>
> Cheers,
> - Ira McDonald (Co-Chair of IPP WG in IEEE-ISTO PWG)
>
>
> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> Co-Chair - IEEE-ISTO PWG IPP WG
> Co-Chair - TCG Hardcopy 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] <mailto:[e-mail]>
> Christmas through April:
>   579 Park Place  Saline, MI  48176
>   734-944-0094
> May to Christmas:
>   PO Box 221  Grand Marais, MI 49839
>   906-494-2434
>
>
> ---------- Forwarded message ----------
>
> From: *IETF I-D Submission Tool* <[e-mail] 
> <mailto:[e-mail]>>
> Date: Wed, Dec 1, 2010 at 8:53 AM
> Subject: New Version Notification for draft-mcdonald-ipps-uri-scheme-01
> To: [e-mail] <mailto:[e-mail]>
> Cc: [e-mail] <mailto:[e-mail]>, 
> [e-mail] <mailto:[e-mail]>
>
> A new version of I-D, draft-mcdonald-ipps-uri-scheme-01.txt has been
> successfully submitted by Ira McDonald and posted to the IETF repository.
>
> Filename:  draft-mcdonald-ipps-uri-scheme
> Revision:   01
> Title:          IPPS URI Scheme and Transport Binding
> Creation_date:   2010-12-01
> WG ID:      Independent Submission
> Number_of_pages: 24
>
> Abstract:
>
> This memo defines the IPPS URI scheme and the corresponding IPP over
> HTTPS transport binding.  This memo updates the Internet Printing
> Protocol/1.1 Model and Semantics (RFC 2911), by extending section
> 4.1.6 'uriScheme' and section 4.4.1 'printer-uri-supported'.  This
> memo updates the Internet Printing Protocol/1.1 Encoding and
> Transport (RFC 2910), by extending section 4 'Encoding of the
> Transport Layer', section 5 'IPP URL Scheme', and section 8.2 'Using
> IPP with TLS'.  This memo complements (but does not update) the
> Internet Printing Protocol/1.1 IPP URL Scheme (RFC 3510).
>
> This memo is a product of the Internet Printing Protocol Working
> Group in the IEEE-ISTO Printer Working Group, as part of their IPP
> Everywhere project for mobile, driverless, ubiquitous printing.
>
> An IPPS URI is used to specify the network location of a secure print
> service that supports the IPP/1.1 Model and Semantics (RFC 2911), or
> of a network resource (for example, a print job) managed by such a
> secure print service.
>
>
> The IETF Secretariat.
>
>
>
>
> _______________________________________________
> Uri-review mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uri-review