IPP> Re: IPP and the IESG

Keith Moore <moore@cs.utk.edu> Mon, 06 July 1998 23:47 UTC

Delivery-Date: Mon, 06 Jul 1998 19:47:33 -0400
Return-Path: ipp-owner@pwg.org
Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA02452 for <ietf-archive@ietf.org>; Mon, 6 Jul 1998 19:47:32 -0400 (EDT)
Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA06000 for <ietf-archive@cnri.reston.va.us>; Mon, 6 Jul 1998 19:49:50 -0400 (EDT)
Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA05660 for <ietf-archive@cnri.reston.va.us>; Mon, 6 Jul 1998 19:47:30 -0400 (EDT)
Received: by pwg.org (bulk_mailer v1.5); Mon, 6 Jul 1998 19:43:11 -0400
Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA05059 for ipp-outgoing; Mon, 6 Jul 1998 19:41:31 -0400 (EDT)
Message-Id: <199807062341.TAA10143@spot.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
From: Keith Moore <moore@cs.utk.edu>
To: don@lexmark.com
cc: ipp@pwg.org, moore@cs.utk.edu
Subject: IPP> Re: IPP and the IESG
In-reply-to: Your message of "Mon, 06 Jul 1998 14:24:39 EDT." <199807061901.AA04631@interlock2.lexmark.com>
Date: Mon, 06 Jul 1998 19:41:18 -0400
Sender: owner-ipp@pwg.org

Don,

It's really very simple.

Most of the time HTTP is used to fetch web pages or to upload form data.  
Printing is viewed by IESG to be sufficiently different than either
of these two that it needs to be distinguished from ordinary HTTP, both by
having a different port # and a different URL type. 

Making such judgements is part of IESG's job.    

I refer you to RFC 2026, section 6, first paragraph:

6.  THE INTERNET STANDARDS PROCESS

   The mechanics of the Internet Standards Process involve decisions of
   the IESG concerning the elevation of a specification onto the
   standards track or the movement of a standards-track specification
   from one maturity level to another.  Although a number of reasonably
   objective criteria (described below and in section 4) are available
   to guide the IESG in making a decision to move a specification onto,
   along, or off the standards track, there is no algorithmic guarantee
   of elevation to or progression along the standards track for any
   specification.  The experienced collective judgment of the IESG
                   ***********************************************
   concerning the technical quality of a specification proposed for
   *****************************************************************
   elevation to or advancement in the standards track is an essential
   ******************************************************************
   component of the decision-making process.
   ****************************************

Keith