Re: Comments on draft-mcdonald-ipps-uri-scheme-00.txt

HiBjoern,

Mike Sweet (co-editor) is the author of the open source CUPS that is the
most widely deployed implementation of IPP (RFC 2910/2911) - all Mac,
Linux, and UNIX systems ship with it default or as an option.

Background to the UTF-8 encoding issue:

"ipp:" URIs (RFC 3510 and 2910) are converted VERBATIM to "http:" URIs
(only inserting port 631, if needed, to avoid port 80 defaulting).

"ipps:" URIs (this spec) are converted VERBATIM to "https:" URIs (doing
the same port 631 fixup).

"https:" URI are defined in RFC 2817 and we can't constrain them further,
because CUPS has supported "ipps:" for years and users expect to be
able to use ANY valid "https:" URI for a target Printer object.

Mike - can we constrain "ipps:" to use UTF-8?

Cheers,
- Ira

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:blueroofmusic@gmail.com
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



On Tue, Oct 12, 2010 at 6:41 PM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:

> * Ira McDonald wrote:
> >>  http://www.ietf.org/id/draft-mcdonald-ipps-uri-scheme-00.txt in
> >> section 7 notes:
> >>
> >>  IPPS URIs MUST use [RFC3986] encoding, as do their equivalent HTTPS
> >>  URIs [RFC2818].  Characters other than those in the "reserved" set
> >>  [RFC3986] are equivalent to their ""%" HEX HEX" encoding.
> >>
> >> This does not work as a definition as the %xx encoding encodes octets,
> >> not characters. You would have to specify the character encoding to
> >> encode characters.
> >
> ><ira>
> >I propose to delete the second sentence above (verbatim from RFC 3510).
> ></ira>
>
> For new schemes textual data should be encoded using the UTF-8 character
> encoding, this is already mandatory for the `host` part per RFC 3986 and
> recommended for path and query if they represent textual data. If those
> components carry textual data, there would need to be a discussion of
> that in the document. I am not sufficiently familiar with the scheme and
> how it is used in practise to make a recommendation beyond that.
>
> > In section 6 it would be useful to clearly identify the registry, e.g.
> >> by referencing the BCP number for RFC 4395.
> >>
> >> <ira>
> >Right - of course - I'll fix section 6 and the Normative References too.
> >I believe it's preferable to say just '[BPCxxx]' inline and leave the RFC
> >number for Normative References - is that right?
> ></ira>
>
> That is what I would do, yes.
>
> >In section 4.5 the ABNF lacks two closing "]".
> >>
> >> <ira>
> >Oh please, line numbers and/or quotes?  Thanks for looking at the ABNF.
> ></ira>
>
> The text is
>
>  ipps-uri = "ipps:" "//" host [ ":" port ] [ path-absolute [ "?" query
>
> so it needs to end in "] ]". Also note that RFC 3986 changes the host
> production to permit the empty string. You would either need to disallow
> that or specify what it means if the host is the empty string. A common
> interpretation is that the empty string refers to "localhost" e.g. the
> "file" scheme does that. (You could define that the semantics are unde-
> fined).
> --
> Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
> Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
> 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
>