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
- IPP> IPP and the IESG don
- RE: IPP> IPP and the IESG Rich Gray
- IPP> Re: IPP and the IESG Keith Moore