Carl | 2 May 22:46 2002

IPP> RE: Mandatory Delivery Method for Notifications - Comments by April 15

Hi all,

Well, April 15 has come and gone a while ago. I wanted to see if we got
views from more people on my strawman proposal for a mandatory delivery
method, but I guess that is not going to happen.

There are two slight modifications that have been discussed on the DL.

1) It seems unreasonable to demand a MUST for TLS in ipp-get considering
that the main IPP specification in RFC2910-2911 has it as a strong SHOULD.
We will try to get the IESG to accept the same level for the basic
notification extensions and the ipp-get notification delivery method.

2) We need to make the same security requirement statements for both the
client and the server (printer) side, otherwise we cannot guarantee
interoperability.

With those modifications I declare that we have rough WG concensus on this
topic and I have already instructed Tom Hastings to go ahead and modify the
following two drafts:

	draft-ietf-ipp-not-spec-08
	draft-ietf-ipp-notify-get-06

When the new drafts are ready, I will send them out for another WG Last
Call, to make sure that we are in sync about the final changes.

As for the other two notification methods, there has also been some
discussions on the DL, which are outside the scope of this particular
concensus. I will address those discussions in a separate message.
(Continue reading)

McDonald, Ira | 6 May 23:25 2002

IPP> I-D Guidelines for XML in IETF Protocols

Hi folks,

RECOMMENDED reading For anyone interested in XML-based protocols
- Bob Herriot, Dave Hall, Kirk Ocke, and other PWG editors.

In the IETF repository 'ftp://ftp.ietf.org/internet-drafts/' see:

"Guidelines for the Use of XML within IETF Protocols",
by Scott Hollenbeck (VeriSign), Marshall Rose (Dover Beach),
Larry Masinter (Adobe).
<draft-hollenbeck-ietf-xml-guidelines-02.txt> (29 April 2002)

As noted below, this document is intended to become an IETF BCP
(Best Current Practice) RFC.

Cheers,
- Ira McDonald
  High North Inc

----------------------------------------

Abstract

   The Extensible Markup Language (XML) is a framework for structuring
   data.  While it evolved from SGML -- a markup language primarily
   focused on structuring documents -- XML has evolved to be a widely-
   used mechanism for representing structured data.
   There are a wide variety of Internet protocols being developed; many
   have need for a representation for structured data relevant to their
   application.  There has been much interest in the use of XML as a
(Continue reading)

c.tiritilli | 14 May 00:35 2002
Picon

PWG-ANNOUNCE> June 24-28, 2002 PWG Meeting Details

Greetings, All,

The arrangements have been finalized for the June 24-28, 2002 PWG Meeting
in Portland, Oregon,  as follows:

When:   Monday - Friday
             June 24-28, 2002

Where:  Hilton Portland
              921 SW Sixth Avenue
              Portland, OR 97204

              Tel: 1-503-226-1611
              Fax: 1-503-220-2565
http://www.hilton.com/en/hi/hotels/index.jhtml;jsessionid=LTMFQ10PUMKL1J31AOQ2JLQ?ctyhocn=PDXPHHH

Hotel Accommodations:
US$112.00/night, single or double occupancy. All attendees are responsible
for making their own hotel reservations. Please ask for the "Printer
Working Group", or "PWG", sleeping room rate. Rooms are being held for the
nights of Sunday, June 23 - Friday, June 28, 2002, and the hotel will
extend the rate to guests 3 days before and after the meetings, pending
availability.   The hotel has confirmed complimentary high speed internet
access in sleeping rooms!! ***Please contact Cindy Tiritilli at
cindy <at> ieee-isto.org if for any reason you are unable to obtain the
negotiated room rate.****

Deadline:  Please call the reservation hotline toll-free at
+1-800-445-8667, or call the hotel directly at +1-503-226-1611  to make
your sleeping room reservation by Friday, May 31, 2002. (Tentatively to be
(Continue reading)

Robert Herriot | 19 May 09:57 2002

IPP> The "bind" value of the "finishings" attribute

An issue has come up in another standards effort which is trying to map IPP attributes. 
 
The question is about the "bind" value of the IPP "finishings" attribute. It is the least specific value of "finishings".
 
Does anyone remember why the "bind" value of the "finishings" attribute was put into IPP?
 
Does anyone implement it?
 
Bob Herriot
Vadiraj | 20 May 07:40 2002

IPP> using SIP and IPP

Hello,

Can we use SIP on top of IPP for network printing. SIP already has support for controlling network
appliances.So, considering the printer also is a Network Device, can we not use SIP for network printing ?

Regards,
Raj

McDonald, Ira | 20 May 16:44 2002

RE: IPP> using SIP and IPP

Hi Raj,

By 'SIP' do you mean the IETF Session Initiation Protocol (RFC 2543)?

I'm confused.  Why would you want to try to run SIP over IPP (which
itself only runs over HTTP over TCP)?

Cheers,
- Ira McDonald
  High North Inc

-----Original Message-----
From: Vadiraj [mailto:vadiraj <at> cosystems.com]
Sent: Monday, May 20, 2002 1:41 AM
To: 'ipp <at> pwg.org'
Subject: IPP> using SIP and IPP

Hello,

Can we use SIP on top of IPP for network printing. SIP already has support
for controlling network appliances.So, considering the printer also is a
Network Device, can we not use SIP for network printing ?

Regards,
Raj

Zehler, Peter | 20 May 17:49 2002
Picon

RE: IPP> The "bind" value of the "finishings" attribute

Bob,
 
Was it added as a generic term for any type of binding (e.g. tape, coil binding, plastic comb) without identifying the bound edge ?  I am not aware of the value 'bind' being used for "finishings" in any implementation.  Any Printer that offers finishing normally describes the type of finishing with a specific value instead of the generic 'bind'. (see ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.1.pdf)  This spec resolves the bind location but still does not qualify the type of binding.  Do we need to add some new values/qualifiers to the PWG model?
 
Pete
 

          Peter Zehler
          XEROX
          Xerox Architecture Center
          Email: PZehler <at> crt.xerox.com
          Voice:    (716) 265-8755
          FAX:      (716) 265-8871
          US Mail: Peter Zehler

                    Xerox Corp.
                    800 Phillips Rd.
                    M/S 128-30E
                    Webster NY, 14580-9701

-----Original Message-----
From: Robert Herriot [mailto:bob <at> herriot.com]
Sent: Sunday, May 19, 2002 3:58 AM
To: ipp <at> pwg.org
Subject: IPP> The "bind" value of the "finishings" attribute

An issue has come up in another standards effort which is trying to map IPP attributes. 
 
The question is about the "bind" value of the IPP "finishings" attribute. It is the least specific value of "finishings".
 
Does anyone remember why the "bind" value of the "finishings" attribute was put into IPP?
 
Does anyone implement it?
 
Bob Herriot
McDonald, Ira | 20 May 22:03 2002

IPP> New I-D for IPP URL Scheme (20 May 2002)


Copies: Carl-Uno Manros <carl <at> manros.com>
        IPP WG <ipp <at> pwg.org>

Hi folks,                                           Monday (20 May 2002)

I've just sent a new version of 'IPP: IPP URL Scheme' to the
Internet-Drafts editor and posted a copy on the PWG server in the
directory 'ftp://ftp.pwg.org/pub/pwg/ipp/new_URL/' in the file:

    draft-ietf-ipp-url-scheme-05.txt (20 May 2002)

All of the changes in this version are clarifications and expansions
requested by our IETF Applications Area Director, Ned Freed, during the
IESG 'last call' on the previous version (draft-04).  Carl-Uno Manros
(IETF IPP WG chair) plans to send this final version to the IESG for
publication as a Proposed Standard RFC.

Cheers,
- Ira McDonald (IPP WG member, co-editor of IPP URL scheme)
  High North Inc
  imcdonald <at> sharplabs.com

------------------------------------------------------------------------

Appendix X - Change History

   [To be deleted before RFC publication] 

   20 May 2002 - draft-ietf-ipp-url-scheme-05.txt 
   - expanded IPP in title of document, per RFC Editor; 
   - revised 'References' section, separating into 'Normative
     References' and 'Informative References' sections, per RFC Editor; 
   - revised 'Abstract' section, to emphasize that this document updates
     RFC 2910, per Ned Freed; 
   - revised several sections, deleting repeated paragraphs and
     references to RFC 2373 "IPv6 Addressing Architecture", per Ned
     Freed; 
   - revised 'IPP URL Examples' section, adding examples of IPP URLs
     used to uniquely identify IPP Jobs, per Ned Freed; 
   - revised 'IPP URL Examples' section, deleting both IPv4 and IPv6
     literal address examples, per Ned Freed; 
   - revised 'Conformance Requirements' section, to specify requirements
     both for IPP URLs used for the network location of IPP print
     services and for IPP URLs used as protocol elements in IPP protocol
     requests and responses, per Ned Freed; 
   - revised 'Security Considerations' section, to discuss security
     threats associated with the use of IPP URLs (see section 2.4 of
     [RFC2718]), per Ned Freed; 
   - added 'Appendix A - Registration of "ipp" URL Scheme' with
     completed form (see section 6.0 'Registration Template' of
     [RFC2717]).  

------------------------------------------------------------------------

Copies: "Internet Drafts Editor" <internet-drafts <at> ietf.org>
        "Carl-Uno Manros" <carl <at> manros.com>
        "Tom Hastings" <hastings <at> cp10.es.xerox.com>
        "Bob Herriot" <bob <at> herriot.com>
        "Ira McDonald" <imcdonald <at> sharplabs.com>

I-D Editor,                                         Monday (20 May 2002)

IETF IPP WG:

Please place this document in the Internet-Drafts repository named:

    <draft-ietf-ipp-url-scheme-05.txt> (20 May 2002)

It replaces the previous:

    <draft-ietf-ipp-url-scheme-04.txt> (10 January 2002)

Thanks very much,
- Ira McDonald (IPP WG member, co-editor of IPP URL scheme)
  High North Inc
  imcdonald <at> sharplabs.com

--------------------

Abstract 

   This memo defines the "ipp" URL (Uniform Resource Locator) scheme.
   This memo updates IPP/1.1: Encoding and Transport (RFC 2910), by
   expanding and clarifying Section 5 'IPP URL Scheme' of RFC 2910.  An
   "ipp" URL is used to specify the network location of a print service
   that supports the IPP Protocol (RFC 2910), or of a network resource
   (for example, a print job) managed by such a print service.  

Robert Herriot | 20 May 23:04 2002

Re: IPP> The "bind" value of the "finishings" attribute

Thanks for the reply.  I am not suggesting that we add another value for the "finishings" attribute.
 
Instead I'm trying to find out whether "bind" was put into the IPP spec to satisfy product requirements or whether it accidentally slipped in with the reasoning that "no one needs it now, but its support is optional and someone may find such a generalization useful in the future."
 
The "bind" value expresses an intent for binding without giving the specifics. Generally, the IPP finishings attribute is specific about a particular binding process, e.g. "staple", "saddle-stitch", "fold". In the JDF world, the latter is a process, and the former is intent. The "bind" value creates a mapping problem (for JDF to support IPP) because the "bind" value must be converted to "staple" or something else by the time the job is actually being processed in JDF.
 
In the JDF model, the IPP "bind" value is a problem. From the IPP point of view, the JDF model may be too black and white when it separates the world into intent and process. In the real world, intent may be very close to process or very far.
 
Bob Herriot
----- Original Message -----
Sent: Monday, May 20, 2002 8:49 AM
Subject: RE: IPP> The "bind" value of the "finishings" attribute

Bob,
 
Was it added as a generic term for any type of binding (e.g. tape, coil binding, plastic comb) without identifying the bound edge ?  I am not aware of the value 'bind' being used for "finishings" in any implementation.  Any Printer that offers finishing normally describes the type of finishing with a specific value instead of the generic 'bind'. (see ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.1.pdf)  This spec resolves the bind location but still does not qualify the type of binding.  Do we need to add some new values/qualifiers to the PWG model?
 
Pete
 

          Peter Zehler
          XEROX
          Xerox Architecture Center
          Email: PZehler <at> crt.xerox.com
          Voice:    (716) 265-8755
          FAX:      (716) 265-8871
          US Mail: Peter Zehler

                    Xerox Corp.
                    800 Phillips Rd.
                    M/S 128-30E
                    Webster NY, 14580-9701

-----Original Message-----
From: Robert Herriot [mailto:bob <at> herriot.com]
Sent: Sunday, May 19, 2002 3:58 AM
To: ipp <at> pwg.org
Subject: IPP> The "bind" value of the "finishings" attribute

An issue has come up in another standards effort which is trying to map IPP attributes. 
 
The question is about the "bind" value of the IPP "finishings" attribute. It is the least specific value of "finishings".
 
Does anyone remember why the "bind" value of the "finishings" attribute was put into IPP?
 
Does anyone implement it?
 
Bob Herriot
Carl | 22 May 18:03 2002

IPP> FW: BOUNCE ipp <at> pwg.org: Non-member submission from [Internet-Drafts <at> ietf.org]

All,

Forwarded message from Internet-Drafts below.

This new draft is in response to earlier AD comments. It contains some
clarifications and examples, but no new/revised technical content. Hence I
do NOT intend to Last Call this in the WG again.

Carl-Uno

----

From: Internet-Drafts <at> ietf.org
Reply-to: Internet-Drafts <at> ietf.org
Subject: I-D ACTION:draft-ietf-ipp-url-scheme-05.txt
Date: Wed, 22 May 2002 07:20:55 -0400
Sender: nsyracus <at> cnri.reston.va.us

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Internet Printing Protocol Working Group of
the IETF.

	Title		: Internet Printing Protocol/1.1: IPP URL Scheme
	Author(s)	: R. Herriot, I. McDonald
	Filename	: draft-ietf-ipp-url-scheme-05.txt
	Pages		: 22
	Date		: 21-May-02

This memo defines the 'ipp' URL (Uniform Resource Locator) scheme.
This memo updates IPP/1.1: Encoding and Transport (RFC 2910), by
expanding and clarifying Section 5 'IPP URL Scheme' of RFC 2910.  An
'ipp' URL is used to specify the network location of a print service
that supports the IPP Protocol (RFC 2910), or of a network resource
(for example, a print job) managed by such a print service.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipp-url-scheme-05.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ipp-url-scheme-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ipp-url-scheme-05.txt".

NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv <at> ietf.org"

Content-Type: text/plain
Content-ID:	<20020521141744.I-D <at> ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipp-url-scheme-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ipp-url-scheme-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020521141744.I-D <at> ietf.org>

--OtherAccess--

--NextPart--


Gmane