come join us...
...walker
--------------A11D1A834D64888B7775ED0B
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Return-Path: <ipp-owner@pwg.org>
Received: from support.dazel.com by dazel.com (4.1/SMI-4.1)
id AA21570; Mon, 15 Jun 98 17:22:24 CDT
Received: from lists.underscore.com by support.dazel.com (8.8.7/dazel)
id RAA04417 for <ipp@dazel.com>; Mon, 15 Jun 1998 17:22:22 -0500 (CDT)
Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA01855 for <ipp@dazel.com>; Mon, 15 Jun 1998 18:22:20 -0400 (EDT)
Received: by pwg.org (bulk_mailer v1.5); Mon, 15 Jun 1998 18:21:07 -0400
Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA01683 for ipp-outgoing; Mon, 15 Jun 1998 18:17:18 -0400 (EDT)
Message-Id: <3.0.5.32.19980615150424.009d2a10@garfield>
X-Sender: cmanros@garfield
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Mon, 15 Jun 1998 15:04:24 PDT
To: ipp@pwg.org
From: Carl-Uno Manros <manros@cp10.es.xerox.com>
Subject: IPP> ADM - Agenda for PWG IPP Phone Conference 980617
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipp@pwg.org
Agenda for PWG IPP Phone Conference 980617
==========================================
We will hold our normal weekly conference in Wednesday.
I want to get to closure on the remaining show stoppers,
so the editors can finish up the next set of drafts to
be sent to the IESG for their final review.
Based on the discussion with the Application Area
Directors last weeek, I consider the discussion about
a separate default port for IPP closed. This was the
preferred method from the IESG to distinguish IPP
from other HTTP traffic and seemed to get overall
approval from the members of the WG. I have sent in
the application for an IPP port to the IANA registry.
Subjects from Keith Moore's review that might need
some further discussion are:
1) Do we really need a new ipp: scheme, when we introduce
the new port? Are we clear on all the consequences of
introducing a new scheme? Can we fit in a security parameter,
when we define the new scheme?
(Larry Masinter and Randy Turner are working on a draft -
hopefully ready for the Wednesday phone call).
2) Considering that we have the new default port number for
IPP, do we need to also distinguish IPP by using a PRINT
method rather than POST?
Another subject which has been discussed on the DL is:
3) Do we want to keep the redundant (and potentially
conflicting) operation attributes for Print-URI and Job-URI
in the MIME structure, or take them out?
I would like to focus the discussion around these three
subjects. I do not think that there are any further
issues to discuss at this point, apart from reviewing
the minor editorials that we have already agreed on
in principle.
Here is the dial-in information:
Time: June 17, 10:00 - 12:00 PDT (1:00 - 3:00 EDT)
Phone: 1-800-857 5607
Passcode: cmanros
Carl-Uno
Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: manros@cp10.es.xerox.com
--------------A11D1A834D64888B7775ED0B--