Re: [art] Revising BCP56: On the use of HTTP as a Substrate

Hi,

Speaking as the co-editor of both the "ipp" and "ipps" URI schemes and the
successor (RFC 8010) to RFC 2910, using HTTP as a substrate for IPP was
a serious design mistake that has added numerous implementation errors and
no functional value.

One prominent (non-conforming) implementation of IPP does use port 443,
but that's just plain wrong and fails the IEEE-ISTO PWG IPP Everywhere
conformance certification tests.

Please don't use IPP as justification in this discussion.  The use of HTTP
as
a substrate was based on bad advice from IETF regulars who should have
known better.

[ok - back into my cave...]

Cheers,
- Ira

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@gmail.com
Jan-April: 579 Park Place  Saline, MI  48176  734-944-0094
May-Dec: PO Box 221  Grand Marais, MI 49839  906-494-2434

On Sat, Jul 15, 2017 at 10:55 AM, Adam Roach <adam@nostrum.com> wrote:

> On 7/15/17 16:25, Ted Hardie wrote:
>
> On Sat, Jul 15, 2017 at 4:09 PM, Mark Nottingham <mnot@mnot.net> wrote:
>
>>
>> > On 15 Jul 2017, at 11:20 am, Adam Roach <adam@nostrum.com> wrote:
>> >
>> > I found 4.3.2 particularly interesting, as there doesn't seem to have
>> been consensus in this space in the past. For example, the ws(s) and ipp(s)
>> schemes made a different decision. I presume your assertion is that, were
>> we defining these protocols today, they would be using http(s) instead?
>>
>> AFAICT IPP doesn't use the HTTP port, scheme nor HTTP's registries, so as
>> per section 2, it's not "using" HTTP.
>>
>>
> RFC 7472 describes the  HTTPS tranport binding and its relationship to the
> ipps scheme (it's a successor to some previous work doing similar things
> for HTTP).  It notes:
>
> The IPP Client converts the 'ipps' URI to an 'https' URI [RFC7230 <https://tools.ietf.org/html/rfc7230>]
>       (replacing 'ipps' with 'https' and inserting the port number from
>       the URI or port 631 if the URI doesn't include an explicit port
>       number);
>
> While the default isn't the existing HTTPS port, it's my understanding
> that in some deployments the ipps scheme uses the HTTPS port and so ends up
> with an HTTPS scheme message over the standard HTTPS port.
>
>
> You don't have to rely on the ipps spec for this -- the original design of
> IPP has a similar transformation for ipp URLs; RFC2910 stipulates:
>
>    Because the HTTP layer does not support the 'ipp' scheme, a client
>    MUST map 'ipp' URLs to 'http' URLs, and then follows the HTTP
>    [RFC2616][RFC2617] rules for constructing a Request-Line and HTTP
>    headers.  The mapping is simple because the 'ipp' scheme implies all
>    of the same protocol semantics as that of the 'http' scheme
>    [RFC2616], except that it represents a print service and the implicit
>    (default) port number that clients use to connect to a server is port
>    631.
>
> Mark -- if you think the guidance in your document wouldn't apply in these
> cases, you'll have to be clearer by what you mean when you say 'The URL
> scheme "http" or "https" is used': I would have thought this qualifies.
>
>
> /a
>
> _______________________________________________
> art mailing list
> art@ietf.org
> https://www.ietf.org/mailman/listinfo/art
>
>