From ipp-archive Wed Oct 1 00:06:34 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA12162 for ipp-outgoing; Wed, 1 Oct 1997 00:06:06 -0400 (EDT) Message-Id: <1.5.4.32.19971001040229.006e2d2c@pop3.holonet.net> X-Sender: cumanros@pop3.holonet.net X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 30 Sep 1997 21:02:29 -0700 To: ipp@pwg.org From: Internet-Drafts@ietf.org (by way of Carl-Uno Manros ) Subject: IPP> I-D ACTION:draft-ietf-drums-abnf-04.txt Sender: ipp-owner@pwg.org Precedence: bulk Status: RO FYI, the is the lastest and bestest on ABNF now going out for last call. Carl-Uno --- A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Detailed Revision/Update of Message Standards Working Group of the IETF. Title : Augmented BNF for Syntax Specifications: ABNF Author(s) : D. Crocker, P. Overell Filename : draft-ietf-drums-abnf-04.txt Pages : 9 Date : 29-Sep-97 Internet technical specifications often need to define a format syntax and are free to employ whatever notation their authors deem useful. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. It balances compactness and simplicity, with reasonable representational power. In the early days of the Arpanet, each specification contained its own definition of ABNF. This included the email specifications, RFC733 and then RFC822 which have come to be the common citations for defining ABNF. The current document separates out that definition, to permit selective reference. Predictably, it also provides some modifications and enhancements. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-drums-abnf-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-drums-abnf-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-drums-abnf-04.txt". NOTE: The mail server at ds.internic.net 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. Content-Type: text/plain Content-ID: <19970929101824.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-drums-abnf-04.txt Content-Type: text/plain Content-ID: <19970929101824.I-D@ietf.org> From ipp-archive Wed Oct 1 10:41:44 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA13794 for ipp-outgoing; Wed, 1 Oct 1997 10:37:45 -0400 (EDT) Date: Wed, 1 Oct 1997 07:41:24 PDT From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9710011441.AA14847@snorkel.eso.mc.xerox.com> To: Ned.Freed@INNOSOFT.COM, imcdonal@eso.mc.xerox.com Subject: Re: IPP> MOD - Separate 'document-format' and 'document-language' Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Hi Ned, Thanks for clearing up all my muddledness. And for pointing out the fact that MIME is written intentionally from an open-ended perspective. I'm sorry that my background is almost wholly in ISO and ITU-T specs, and I'll failed to suspect that MIME was written from a different slant. And I didn't realize that the IANA character set registry didn't exist as recently as RFC 204x series. So as a co-editor, you have told us that any IANA registered character set may be used in the 'charset' parameter of 'text/*' MIME types. Could the character set policy that Harald is hard at work on possibly just SAY that, in the interim until the MIME RFCs are updated (perhaps quite a bit later), so us chickens would get the message clearly? Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc 906-494-2434 From ipp-archive Wed Oct 1 11:26:44 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA14690 for ipp-outgoing; Wed, 1 Oct 1997 11:17:31 -0400 (EDT) Date: Wed, 01 Oct 1997 08:06:16 -0700 (PDT) From: Ned Freed Subject: Re: IPP> MOD - Separate 'document-format' and 'document-language' In-reply-to: "Your message dated Wed, 01 Oct 1997 07:41:24 -0700 (PDT)" <9710011441.AA14847@snorkel.eso.mc.xerox.com> To: imcdonal@eso.mc.xerox.com Cc: Ned.Freed@innosoft.com, imcdonal@eso.mc.xerox.com, ipp@pwg.org Message-id: <01IOAAPBS6FO94GL1L@INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO > Thanks for clearing up all my muddledness. And for pointing out the > fact that MIME is written intentionally from an open-ended perspective. > I'm sorry that my background is almost wholly in ISO and ITU-T specs, > and I'll failed to suspect that MIME was written from a different > slant. And I didn't realize that the IANA character set registry > didn't exist as recently as RFC 204x series. Actually it is worse than this. The registry exists, but there are no rules governing it at present. We're working as hard as we can to get the necessary rules in place to fix this. (I've posted two revised drafts this week alone, and I'll probably be posting a third.) > So as a co-editor, you have told us that any IANA registered character > set may be used in the 'charset' parameter of 'text/*' MIME types. That's what RFC2045-2049 say. However, it turns out that this can be somewhat problematic, in that MIME imposes some restrictions on the use of certain characters in MIME text, e.g. CR, LF, and NUL. Some of the charsets registered currently aren't compatible with these restrictions (e.g. various forms of EBCDIC.) There are also problems with the names of some charsets and the restrictions MIME imposes on the use of names (in particular MIME part III and the new parameter value in RFC2184). Quite a few registered charsets have primary names that don't meet these requirements. I recently added ABNF to the registry document that spells out the restrictions quite explicitly for any charset intended to be compatible with MIME. All of this is being dealt with in the new charset registry work. Since we cannot unregister a charset (nor would we want to -- there are more uses than just in MIME for this stuff), we've added a "eligible for use in MIME" criteria instead. Old registrations can then be evaluated as to their appropriateness and can be flagged accordingly. We'll also be rearranging the names of registrations to make as many of them as possible be usable within MIME. > Could the character set policy that Harald is hard at work on > possibly just SAY that, in the interim until the MIME RFCs are > updated (perhaps quite a bit later), so us chickens would get the > message clearly? Well, the hope is to publish Harald's new document alongside the new registration procedures document. So this really should not be necessary. However, if for some reason we cannot get the registration document out I agree this would be a good thing to do. Ned From ipp-archive Wed Oct 1 12:31:45 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA16163 for ipp-outgoing; Wed, 1 Oct 1997 12:28:05 -0400 (EDT) From: don@lexmark.com Message-Id: <199710011627.MAA16158@lists.underscore.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org Date: Wed, 1 Oct 1997 12:01:25 -0400 Subject: IPP> New Requirements document Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Precedence: bulk Status: RO I have placed a new draft of the requirements document on the FTP server. The following versions have been uploaded: ftp://ftp.pwg.org/pub/ipp/new_REQ/ draft-ietf-ipp-req-970930-rev.pdf ftp://ftp.pwg.org/pub/ipp/new_REQ/ draft-ietf-ipp-req-970930.pdf ftp://ftp.pwg.org/pub/ipp/new_REQ/ draft-ietf-ipp-req-970930.txt I hope the file naming is obvious; the "-rev" version has revision marks in it. I really hate revision editing so don't expect this as a new trend from me. I will not be on the conference call today as I have a personal commitment. I don't really expect anyone will have time to read this by then, anyway. Please send me your feedback via e-mail. Don ********************************************** * Don Wright don@lexmark.com * * Manager, Strategic Alliances and Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-archive Wed Oct 1 14:46:46 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA17483 for ipp-outgoing; Wed, 1 Oct 1997 14:46:01 -0400 (EDT) Message-ID: <34329A65.631F374D@underscore.com> Date: Wed, 01 Oct 1997 14:45:57 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.02 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org CC: don@lexmark.com Subject: Re: IPP> New Requirements document References: <199710011627.MAA16158@lists.underscore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Corrected URLs for the previous message: ftp://ftp.pwg.org/pub/pwg/ipp/new_REQ/draft-ietf-ipp-req-970930-rev.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_REQ/draft-ietf-ipp-req-970930.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_REQ/draft-ietf-ipp-req-970930.txt ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- don@lexmark.com wrote: > > I have placed a new draft of the requirements document on the FTP server. > The following versions have been uploaded: > > ftp://ftp.pwg.org/pub/ipp/new_REQ/ draft-ietf-ipp-req-970930-rev.pdf > ftp://ftp.pwg.org/pub/ipp/new_REQ/ draft-ietf-ipp-req-970930.pdf > ftp://ftp.pwg.org/pub/ipp/new_REQ/ draft-ietf-ipp-req-970930.txt > > I hope the file naming is obvious; the "-rev" version has revision marks > in it. I really hate revision editing so don't expect this as a new trend > from > me. > > I will not be on the conference call today as I have a personal commitment. > I don't really expect anyone will have time to read this by then, anyway. > Please send me your feedback via e-mail. > > Don > > ********************************************** > * Don Wright don@lexmark.com * > * Manager, Strategic Alliances and Standards * > * Lexmark International * > * 740 New Circle Rd * > * Lexington, Ky 40550 * > * 606-232-4808 (phone) 606-232-6740 (fax) * > ********************************************** From ipp-archive Wed Oct 1 16:11:47 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA18640 for ipp-outgoing; Wed, 1 Oct 1997 16:10:07 -0400 (EDT) Date: Wed, 1 Oct 1997 13:09:51 -0700 (Pacific Daylight Time) From: Ron Bergman To: Carl-Uno Manros cc: ipp@pwg.org Subject: Re: IPP> ADM - Agenda for PWG IPP Phone Conference on 971001 In-Reply-To: <3.0.1.32.19970929164256.00a207e0@garfield> Message-ID: X-X-Sender: rbergma@it.dpc.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Carl-Uno, I tried to dial in today and I get the message: "Your Access Code is not recognized." What is the correct code? Ron Bergman On Mon, 29 Sep 1997, Carl-Uno Manros wrote: > Agenda for PWG IPP Phone Conference on 971001, 1-3 pm PST, 4-6 pm EST > > Hi, > > My latest estimate is that we will not be able to circulate the latest > drafts for last call quite yet, considering that several of you did not > finish your home work assignments until today, and that it all has to be > integrated in the drafts. > > Bob Herriot will circulate an intermediate draft of the Protocol document > shortly, and considering the many minor changes to the Model document, I > have asked Scott to also circulate one more intermediate version before we > send the documents to the IETF and issue the last call for the WG. > > So on Wednesday, I expect to get final estimates from the editors about > their schedules and to learn about any issues that are not yet fully > resolved before we produce the next set of official I-Ds. > > The numbers as reminder: > > The phone number is 1-423-523-7162. The access code is 190148. > > Regards, > > 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 > From ipp-archive Wed Oct 1 16:21:47 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA18671 for ipp-outgoing; Wed, 1 Oct 1997 16:19:51 -0400 (EDT) Message-Id: <3.0.1.32.19971001130609.00b0e100@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 1 Oct 1997 13:06:09 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> URGENT - New Time and Number for Today's Phone Conference Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Something went wrong with setting up the phone conference for today. As Don is not in, I have set up a new conference time and number as follows: Starting time at 2 pm PST (on hour later than usual) this afternoon Number to dial in: 1-800-857 5607 Password: cmanros As a bonus you get an 800 number today!! Hope that this message reaches you in time. 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 From ipp-archive Thu Oct 2 11:56:58 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA21345 for ipp-outgoing; Thu, 2 Oct 1997 11:56:40 -0400 (EDT) From: don@lexmark.com Message-Id: <199710021556.AA13320@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org Date: Thu, 2 Oct 1997 11:56:29 -0400 Subject: IPP> Conference Calls Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Sorry for the confusion yesterday. I saw Carl-Uno's notes earlier in the week listing the time and number for the call and assumed I had set up the call and distributed the info. I was wrong. I have set up calls for the next three weeks. The dial-in number is different. Here are the details: Dates: 10/8, 10/15, 10/22 Time: 4PM Eastern, 1PM Pacific Number: 608-250-1828 Access: 190148 Don ********************************************** * Don Wright don@lexmark.com * * Manager, Strategic Alliances and Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-archive Thu Oct 2 12:42:02 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA22018 for ipp-outgoing; Thu, 2 Oct 1997 12:41:10 -0400 (EDT) Priority: Urgent From: Harry Lewis To: , , , , Subject: IPP> Final chance for October reservations Message-ID: <5030300011550270000002L002*@MHS> Date: Thu, 2 Oct 1997 12:45:50 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk Status: RO Reminder... tomorrow (Friday 10/3) is the last day the Hotel Boulderado= will accept reservations for the PWG meeting at the preferred IBM rate. Plea= se make your reservations now, if you haven't yet, and please Ping me also, if = you haven't yet done so. Harry Lewis - IBM Printing Systems = From ipp-archive Fri Oct 3 16:32:18 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA25413 for ipp-outgoing; Fri, 3 Oct 1997 16:28:02 -0400 (EDT) Date: Fri, 03 Oct 1997 13:25:11 PST From: David_Kellerman@nls.com To: ipp@pwg.org Message-ID: <009BB388.3D5A9AF0.1@nls.com> Subject: IPP> steering by the rear-view mirror Sender: ipp-owner@pwg.org Precedence: bulk Status: RO [excuse me, but I'm getting up on the soap box for a minute] The ongoing exchange over the per-job attributes concerns me. Not so much because of the specifics, but because it fits a pattern that seems to dominate much of the discussion on IPP -- something I'd call steering by looking in the rear-view mirror. I was hoping IPP offered an opportunity to do a better job of printing than the currently prevalent printing systems, which, IMHO, are a pretty idiosyncratic lot and have evident shortcomings as far as meeting the needs of Internet printing. What I see instead is a standard being crafted around those historical idiosyncracies and limitations -- arguments of the form "feature-x will be hard to implement in a gateway to my-favorite-printing-system, so we should remove it from the standard (or make it optional, much the same thing)" or "my-favorite-printing- system doesn't provide feature-x, so it isn't important." Accomodating the past and present seems much more compelling than trying to design for the future. Witness the discussion of Job-URL vs Job-Number. We ended up with an extended discussion centered around backward-compatibility, and precious little concerning whether the IPP model (with or without Job-URLs) incorporated the flexibility desirable for Internet printing. Now we have a discussion of "can System V UNIX handle print jobs with multiple data types." In contrast, look at all the tweaks and twists added to existing lpr/lpd implementations. Take a step back and look at what printer vendors have been doing with document data types -- automatic type sensing, multiple virtual printers, and so forth. These are all, in large part, market-driven, ad-hoc attempts to deal with inadequacies of printing protocols in place today. If there's a conclusion to be drawn from existing protocols, it's not "gotta have multiple document data types," or "don't need 'em" -- it's "who can tell from this mess." It seems to me that, for Internet printing, if you want to look at existing protocols for guidance, some of the less "popular" ones have more to contribute, because they share characteristics of Internet printing that are missing from the prevalent ones. The much-maligned ISO 10175 still has the clearest model for the printing process, if you can crack the impenetrable prose of the standards document. Many "legacy" and production printing systems address issues with shared and remote printing that are relevant to Internet printing. To get back to the rear-view mirror analogy -- check out the road ahead. How are these decisions going to look five years from now, when you're trying to use software based on IPP for your printing? I realize we're at a very late stage for IPP 1.0, but for remaining discussion, and for follow-on work, I really think we'd benefit from placing more emphasis on looking out the windshield. [thanks; end tirade] :: David Kellerman Northlake Software 503-228-3383 :: david_kellerman@nls.com Portland, Oregon fax 503-228-5662 From ipp-archive Mon Oct 6 20:53:06 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA29410 for ipp-outgoing; Mon, 6 Oct 1997 20:52:49 -0400 (EDT) Message-Id: <3.0.1.32.19971006173822.00ce2670@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 6 Oct 1997 17:38:22 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - PWG IPP Phone Conference on 971008 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk PWG IPP Phone Conference on 971008 As Seybold is now over, I hope that we will have the normal participation again this coming Wednesday. I have spoken to Scott Isaacson today. His estimate is that he will need another week to get all the recent contributions integrated in the Model & Semantics document. Several people are also still working on little home work assignments from last week. It looks like we are about a month late compared to latest schedule. We will try to capture what has been done and identify any remaining tasks or input for the Model & Semantics and the Protocol Specification documents. I would also like to find out if we have any comments on the intermediate draft of the Requirements document that was circulated by Don last week. HINT: We still seem to have a few features in the Requirements document for which there is no corresponding functionality in the other documents. Below is the information about the call (this time for real): Date: 10/8 Time: 4PM Eastern, 1PM Pacific Number: 608-250-1828 Access: 190148 PS. Do not bother to search for the minutes from last week's call. I am still trying to catch up and get them out by tomorrow. DS. 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 From ipp-archive Mon Oct 6 22:48:07 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA00521 for ipp-outgoing; Mon, 6 Oct 1997 22:44:07 -0400 (EDT) Message-Id: <3.0.1.32.19971006194807.01089860@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 6 Oct 1997 19:48:07 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Proposal for natural language and charset Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk This mail note contains a proposal that Ira and I took on at the 10/01/97 telecon to propose clarifications and additions to the 9/26/97 Model document that are required in order to enter on the standard track with respect to the Language and CharSet policies of the IETF that are currently on standards track themselves. See RFC 1766 and 2184 and . RFC 2130 (IAB Character Set Workshop, Feb 1997) provides background material. I've posted the files in: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ -rw-r--r-- 1 pwg pwg 20480 Oct 7 02:35 langchar.doc -rw-r--r-- 1 pwg pwg 10447 Oct 7 02:35 langchar.pdf -rw-r--r-- 1 pwg pwg 9187 Oct 7 02:35 langchar.txt and have attached the .txt here. I'd like to discuss this at the telecon, this Wednesday 10/8. If there is agreement on the points, we'll draft the spec for the attributes. The text herein is the specific points for the Internationalization Considerations section of the IPP Model document. Send comments before the telecon if possible. Thanks, Tom Subj: Proposal for IPP to meet IESG Language and CharSet requirements From: Tom Hastings and Ira McDonald Date: 10/6/97 File: langchar.doc This document contains a proposal that Ira and I took on at the 10/01/97 telecon to propose clarifications and additions to the 9/26/97 Model document that are required in order to enter on the standard track with respect to the Language and CharSet policies of the IETF that are currently on standards track themselves. See RFC 1766 and 2184 and . RFC 2130 (IAB Character Set Workshop, Feb 1997) provides background material. NOTE - For clarity of the Model and Semantics document and the mapping in the protocol document, we have included as operational attributes in the Model specification any attribute that is mapped to HTTP/1.1 Protocol as headers. Any such mapping to HTTP/1.1 is indicated as a parenthetical remark in the Model specification. We think that URIs should also be brought back into the Model document as operational attributes that are mapped to the appropriate place in the HTTP/1.1 protocol as well. 1. Summary of Changes This proposal adds/clarifies attributes so that the client supplies the language and charset of the request and the Printer object responds in the requested language and charset, if supported, or in the Printer's default language and charset which can be queried. This functionality is provided by two Job Template attributes: (1) "content-natural-language" and (2) "content-charset" which are also operational attributes in query operations. As with any Job Template attribute, there are also the corresponding Printer "content-natural-language-default", "content-charset-default", "content-natural-language-supported", and "content-charset-supported" attributes. There are also two "document-natural-language" and "document-charset" operational attributes for independently specifying the content of documents for those media types that need such. This proposal is intended to replace existing natural language and charset attributes in the Model and Semantics document. 2. Specific Internationalization Provisions The following provisions are listed for inclusion in the Internationalization Considerations section of the IPP Model specification. They also serve as a detailed summary of the capabilities. The IPP Model and Semantics specification provides the following internationalization capabilities: 1. Clients SHALL supply the HTTP/1.1 Content-Type header with the value: application/ipp; charset=xxx where xxx specifies the charset used by the body of the IPP request (independent of the document content) and SHALL be a charset registered with IANA [REG] The Printer object SHALL support charset=utf-8 [28]. Support of other charsets is OPTIONAL, but all supported charsets SHALL be ones in which the code points from decimal 20 to 127 are US-ASCII [US-ASCII]. For conforming IPP Printer objects, the utf-8 charset SHALL be restricted to mean conformance level 2 of ISO 10646 [ISO-10646], so that accented letters SHALL not represented with non-spacing accents. 2. The term "natural language" is used to avoid confusion with "printer language", since "printer language" is the name given by IANA to the registration of print document formats as used in the Printer MIB, RFC 1759 [1]. 3. The client SHALL supply and the Printer object SHALL support the single-valued "content-natural-language" and "content-charset Job Template attributes in order to meet the IETF Policy on Character Sets and Languages [IETF-Pol]. (The protocol SHALL convey these attributes as the HTTP/1.1 "content-language" and "content-charset" headers [23]). Each value of an attribute in a request or a response with attribute syntax 'text' or 'name' MAY be in any language and/or charset and SHALL be tagged using the syntax and mechanism in RFC 2184 [RFC-2184], to indicate the language and charset of the value. If the natural language or charset is the same as that supplied by the client in the request, then the empty tag may be used consisting of only a single ' character for the language or charset. Examples: If the client supplies "content-natural-language" as 'en' and the "content-charset" as 'us-ascii', the following are valid representations of the "job-name" attribute in the request and in the response: us-ascii'en-us'Monthly Report us-ascii''Monthly Report 'en-us'Monthly Report ''Monthly Report iso-8859-1'fr'Rapport Mensuel 4. As with any supported Job Template attribute, the Printer object SHALL support the corresponding "content-natural-language-default", "content-natural-language-supported", "content-charset-default", and "content-charset-supported" Printer attributes. However, these Job Template attributes are MANDATORY for the Printer to support. 5. IPP Printer objects NEED NOT support HTTP/1.1 Accept headers and IPP/1.0 does not address the processing semantics for HTTP/1.1 Accept headers. 6. For the create operations the Printer object shall store in the Job Object any 'text' and 'name' Job Template attributes in the language and charset as supplied by the client, along with the values of the "content-natural-language" and "content-charset" attributes. In a subsequent query request, the Printer object NEED not convert any 'text' or 'name' attributes that had been supplied in the create request to the natural language or charset of the requester. However, any 'text' or 'name' attributes generated by the Printer SHALL be returned in the natural language and charset specified by the requester in the "content-natural-language" and "content-charset" operational attributes of the query. However, if the specified natural language or charset is not supported by the Printer, the Printer SHALL respond in its default natural language or charset, rather than returning an error. 7. Notifications SHALL always include non-empty language and charset tags according to RFC 2184, since the recipient might not know what empty tags mean. 8. Type 4 keywords are often names defined by a system administrator and so may be in any language or charset. Therefore, attributes with attribute syntax 'type4 keyword' are allowed to have a mixture of 'keyword' tokens defined by the standard and/or registered as keywords (in U.S. English and US-ASCII) and 'name' tokens defined by the system administrator. Such names SHALL follow the syntax for names and SHALL be tagged using the syntax and mechanism of RFC 2184, while the keywords SHALL not be tagged (since keywords SHALL always be in US-English and US-ASCII). 9. No IPP Printer implementation NEED perform actual translation of natural language text and name values. A Printer object that supports multiple languages, often has separate catalogs of messages, one for each natural language. 10. The natural language and charset used in certain document formats may be specified separately and independently from that used by attributes that are part of the IPP protocol. Therefor, in order to indicate the natural language and charset of these document-formats, the "document-natural-language" and "document-charset" operation attributes are defined for use in the create, Send-Document, and Send-URI operations. For those media types that are not defined to include a charset parameter, such as application/octet-stream, the "document-charset" attribute MAY be used to convey the charset. For those media types that allow the charset to be specified as a parameter, such as 'text/plain', the client SHALL also supply the "document-charset" attribute with the same value. Then the Printer object NEED not parse the "document-format" media type attribute value. The Printer object SHALL support the "document-natural-language" and "document-charset" operational attributes, if the Printer object supports document formats which require them in order to be unambiguous and to follow the IETF Character Set and Language policy which forbids an implementation to assume a default language or charset. 3. Additions to the References section [ISO-10646] ISO/IEC 10646-1:1993, "Information technology -- Universal Multiple-Octet Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane, JTC1/SC2." [REG] N. Freed, J. Postel: IANA CharSet Registration Procedures, Work in Progress (draft-freed-charset-reg-02.txt). [US-ASCII] Coded Character Set - 7-bit American Standard Code for Information Interchange, ANSI X3.4-1986. [IETF-Pol] H. Alvestrand, "IETF Policy on Character Sets and Languages, work in progress , June 1997. [RFC-2184] N. Fried, K. Moore, MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations, RFC 2184, August 1997. From ipp-archive Tue Oct 7 07:38:12 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id HAA01929 for ipp-outgoing; Tue, 7 Oct 1997 07:33:41 -0400 (EDT) From: don@lexmark.com Message-Id: <199710071133.AA02598@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: cmanros@cp10.es.xerox.com Cc: Ipp@Pwg.Org Date: Tue, 7 Oct 1997 07:33:23 -0400 Subject: IPP> REQ - Requirements Document Issues Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@Pwg.Org Precedence: bulk Carl-Uno Manros said: >I would also like to find out if we have any comments on the intermediate >draft of the Requirements document that was circulated by Don last week. >HINT: We still seem to have a few features in the Requirements document for >which there is no corresponding functionality in the other documents. Are we playing twenty questions or are there real issues to be resolved here? Don From ipp-archive Tue Oct 7 09:43:13 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA02609 for ipp-outgoing; Tue, 7 Oct 1997 09:42:43 -0400 (EDT) From: "Zehler,Peter" To: "Scott Isaacson (E-mail)" Cc: "Redirector IPP (E-mail)" Subject: IPP> MOD pdl-override inconsistency Date: Tue, 7 Oct 1997 06:45:36 PDT X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Message-Id: <97Oct7.064224pdt."52766(3)"@alpha.xerox.com> Sender: ipp-owner@pwg.org Precedence: bulk Scott, The September 26th version of the model document has an inconsistency. The printer attribute table, line 1909, shows 'pdl-override' as optional. Section 4.4.17, line 2100, states the attribute is mandatory. Pete __________________________________ Email: pzehler@channels.mc.xerox.com US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. Webster NY, 14580-9701 Voice: (716) 265-8755 FAX: (716)265-8792 __________________________________ "I always wanted to be somebody, but I should have been more specific." Lily Tomlin __________________________________ From ipp-archive Tue Oct 7 19:03:19 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA03669 for ipp-outgoing; Tue, 7 Oct 1997 18:59:06 -0400 (EDT) Message-Id: <3.0.1.32.19971007154459.009fbe40@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 7 Oct 1997 15:44:59 PDT To: Ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Minutes from PWG IPP Phone Conference on 971001 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Here are the minutes of what was discussed in the PWG IPP Phone Conference on 971001: Participants: Carl-Uno Manros Tom Hastings Ira Mcdonald Dave Kellerman Randy Turner Ron Bergman Most of the discussion centered on a few remaining issues and omissions in the latest draft on Model & Semantics: - Relationship between Job-name and Document-name Suggested to add back "document-name" as an operation attribute, mainly to make it easier to map from older implementations that often generate "job-name" from "document-name". Tom Hastings to write up suggested text. - It was pointed out that URIs that go into the HTTP protocol heading in the Protocol document do not get mentioned at all in the Model document. Suggested that they be described as operation attributes in the Model document and that the Protocol document then explains that they are mapped to HTTP headers rather than operation attributes. Tom Hastings to write up suggested text. - It was previously possible to find out the number of documents in a multiple document job by checking for multiple values in the "document-name" attribute. As this was removed, this is not possible any more, so we have lost that functionality. It was suggested to remedy this by introducing a "number-of-documents" attribute on the Job object. Tom Hastings to write up suggested text. - New discussion about what scheme to support if print-by-reference is implemented. A counter proposal to Carl-Uno's proposal earlier on the DL, which was to make all optional, was to mandate FTP to be implemented with option to support others. The Carl-Uno suggested attribute "reference-uri-schemes-supported" as a Printer object attribute would be kept. Carl-Uno to write up suggested text. - We need to write up the text for the IANA registry for application/ipp, and probably include it as an annex in the Model document. Ira to draft the text. - Discussion on the DL between Ira, Larry Masinter, and Ned Freed has made it obvious that we need to do further work related to internationalization of text strings in MIME. Tom and Ira to come back with proposal (has been posted to the DL). - We need to state somewhere in the conformance statement text that all IPP Printers (servers) MUST support UTF-8 encoding (but can support others as well). Ask Scott to include. - Patrick Powell has again suggested that we specify an additional port to be used by IPP. After discussion it was suggested to accept Patrick's proposal with the following conditions: 1) The alternative port should be used if not the default port (80) for HTTP is used. AND 2) unless the security protocol used, SSL3 or TLS, requires a special port THEN 3) it is recommended to use the alternative port number (516), which must be present in the published Printer URI. Carl-Uno to write up text. - Suggrested to change the name of "time-of-pending" attribute to "time-of-creation" and fix up some of the semantics. The background is that the DPA defines "time-of-pending" differently than IPP; the name change would make it clear that they are not the same. Tom to write up text. - The decision from Atlanta about language tags does not yet seem to be implemented in the Protocol document. Synchronize with Model document. Bob to check. - The fact that you can use either Job-URI or Printer-URI + Job-id does not seem to be reflected in the Protocol document yet. Bob to check. Carl-Uno suggested that we still need to check about consistency between the latest version of the Requirements document to see if all requirements (except the ones that we have declared out of scope) are now covered by solutions in Model and Protocol documents. -- 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 From ipp-archive Tue Oct 7 19:28:19 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA04309 for ipp-outgoing; Tue, 7 Oct 1997 19:25:57 -0400 (EDT) Message-Id: <3.0.1.32.19971007161209.00c234b0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 7 Oct 1997 16:12:09 PDT To: David_Kellerman@nls.com, ipp@pwg.org From: Carl-Uno Manros Subject: Re: IPP> steering by the rear-view mirror In-Reply-To: <009BB388.3D5A9AF0.1@nls.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk David, Generally speaking I tend to agree with you that we should attempt to design for the future rather than for the past. However, these kind of things do not happen in a vacuum. Are we trying to be revolutionaries or evolutionaries? I guess the right approach is somewhere in between. My take on this is that we should design for the future, but we should not make future solutions different from current ones just for the heck of it. If we can make things backwards compatible in areas where it it does not compromise our design, I think it as a good approach to stay with what people are already familiar with (be they implementors or end users). I admit that some of the discussions that you refer to have taken more time than I would have liked, but this is fully in line with one of the Parkinson's Laws (remember Parkingson, or am I the only one old enough?), which states that the time spent on discussing a subject is in revers proportion to its importance :-) All in all, I do not think we have been doing too badly (compared to many other DL discussions I have seen in other IETF WGs). Compromise is the name of the game in all standardization groups. Carl-Uno At 02:25 PM 10/3/97 PDT, David_Kellerman@nls.com wrote: >[excuse me, but I'm getting up on the soap box for a minute] > >The ongoing exchange over the per-job attributes concerns me. Not so >much because of the specifics, but because it fits a pattern that seems >to dominate much of the discussion on IPP -- something I'd call >steering by looking in the rear-view mirror. > >I was hoping IPP offered an opportunity to do a better job of printing >than the currently prevalent printing systems, which, IMHO, are a pretty >idiosyncratic lot and have evident shortcomings as far as meeting the >needs of Internet printing. What I see instead is a standard being >crafted around those historical idiosyncracies and limitations -- >arguments of the form "feature-x will be hard to implement in a gateway >to my-favorite-printing-system, so we should remove it from the standard >(or make it optional, much the same thing)" or "my-favorite-printing- >system doesn't provide feature-x, so it isn't important." Accomodating >the past and present seems much more compelling than trying to design >for the future. > >Witness the discussion of Job-URL vs Job-Number. We ended up with an >extended discussion centered around backward-compatibility, and precious >little concerning whether the IPP model (with or without Job-URLs) >incorporated the flexibility desirable for Internet printing. > >Now we have a discussion of "can System V UNIX handle print jobs with >multiple data types." In contrast, look at all the tweaks and twists >added to existing lpr/lpd implementations. Take a step back and look at >what printer vendors have been doing with document data types -- >automatic type sensing, multiple virtual printers, and so forth. These >are all, in large part, market-driven, ad-hoc attempts to deal with >inadequacies of printing protocols in place today. If there's a >conclusion to be drawn from existing protocols, it's not "gotta have >multiple document data types," or "don't need 'em" -- it's "who can tell >from this mess." > >It seems to me that, for Internet printing, if you want to look at >existing protocols for guidance, some of the less "popular" ones have >more to contribute, because they share characteristics of Internet >printing that are missing from the prevalent ones. The much-maligned >ISO 10175 still has the clearest model for the printing process, if you >can crack the impenetrable prose of the standards document. Many >"legacy" and production printing systems address issues with shared and >remote printing that are relevant to Internet printing. > >To get back to the rear-view mirror analogy -- check out the road ahead. >How are these decisions going to look five years from now, when you're >trying to use software based on IPP for your printing? I realize we're >at a very late stage for IPP 1.0, but for remaining discussion, and for >follow-on work, I really think we'd benefit from placing more emphasis >on looking out the windshield. > >[thanks; end tirade] > >:: David Kellerman Northlake Software 503-228-3383 >:: david_kellerman@nls.com Portland, Oregon fax 503-228-5662 > > 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 From ipp-archive Tue Oct 7 21:58:21 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA05019 for ipp-outgoing; Tue, 7 Oct 1997 21:55:03 -0400 (EDT) Date: Tue, 7 Oct 1997 19:02:26 -0700 (PDT) From: papowell@astart.com Message-Id: <199710080202.TAA29114@astart4.astart.com> To: cmanros@cp10.es.xerox.com, Ipp@pwg.org Subject: Re: IPP> ADM - Minutes from PWG IPP Phone Conference on 971001 Sender: ipp-owner@pwg.org Precedence: bulk # # - Patrick Powell has again suggested that we specify an additional port to # be used by IPP. After discussion it was suggested to accept Patrick's # proposal with the following conditions: # 1) The alternative port should be used if not the default port (80) for # HTTP is used. # AND # 2) unless the security protocol used, SSL3 or TLS, requires a special port # THEN # 3) it is recommended to use the alternative port number (516), which must # be present in the published Printer URI. # # Carl-Uno to write up text. Thank you. I think this will make life simpler. Patrick Powell From ipp-archive Tue Oct 7 22:58:21 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA05691 for ipp-outgoing; Tue, 7 Oct 1997 22:54:11 -0400 (EDT) Message-Id: <3.0.1.32.19971007174541.00c78e60@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 7 Oct 1997 17:45:41 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> REQ - Requirements Match? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk At 04:33 AM 10/7/97 PDT, you wrote: > >Carl-Uno Manros said: > >>I would also like to find out if we have any comments on the intermediate >>draft of the Requirements document that was circulated by Don last week. >>HINT: We still seem to have a few features in the Requirements document >for which there is no corresponding functionality in the other documents. > >Are we playing twenty questions or are there real issues to be resolved >here? > >Don > Don, Not to keep you in suspense any longer, here are a number of things that I found, while scanning through the latest version of the requirements document: Page 6: Users want to limit the scope of their search when locating a printer: - inside a functional sub-domain - include only a particular domain - exclude specified domains We have no Directory or Printer attributes defined to support this. Page 13: Printer discovery: - cost per page to print [also in several other places] - maximum job size (spool size) - payment required for printing - printer supports compression We have no Directory or Printer attributes to support this. Page 15: We talk about "marking technology" here [and in various other places]. We have "printer description" which might include this in text form, but no explicit Printer attribute, which tells whether a printer is ink-jet, laser, etc. Page 22: Select printer based on: - usable by department J15 We do not have an explicit Directory or Printer attribute for this. You could use some authorization mechanism to achieve this, but it seems a bit farfetched. Page 24: Select a printer based on: - is a public printer (accessible from outside a firewall) We have no explicit Directory or Printer attribute to support this. The presence of a "printer-tls-uri" attribute might give a hint about this, but does not have this semantic. Page 26: Printer discovery: - Is in Downtown Boulder - Give me the Printer's public key Although we have an unstructured Printer location attribute, is it likely that we can do this kind of match? We do not have a Directory attribute for the Printer's public key. Page 51: Searching for printers: - takes my VISA card - gives me a rough cost per page We have a generic text Printer attribute for printer description, but can you request and search on it? We have no Directory or Printer attribute to support this. --- Admittedly, most of the "missing" features I spotted have to do with the location of printers, which we have said are outside the scope of the IPP protocol. On the other hand, we are supposed to define a Directory Schema, which ought to provide these things as attributes, if we want to claim that we have met the requirements in the scenarios. Seems we still have some work to do on the Directory attributes (and indirectly on the Printer attributes). Comments? 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 From ipp-archive Tue Oct 7 22:58:22 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA05702 for ipp-outgoing; Tue, 7 Oct 1997 22:55:29 -0400 (EDT) Message-Id: <3.0.1.32.19971007180400.010e76b0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 7 Oct 1997 18:04:00 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - RESEND: Proposal for IPP to meet IESG Language and CharSet requirements Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk We've corrected the proposal to map the IPP "content-charset" attribute to the HTTP/1.1 'charset' parameter of the 'application/ipp' media type "Content-Type header. I also added line numbers to the .pdf file (three pages) and (red) revision marks show the minor changes. The updated files are now in: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ -rw-r--r-- 1 pwg pwg 31744 Oct 8 00:47 langchar.doc -rw-r--r-- 1 pwg pwg 14874 Oct 8 00:47 langchar.pdf -rw-r--r-- 1 pwg pwg 9439 Oct 8 00:47 langchar.txt This mail note and these files contain a proposal that Ira and I took on as an action item at the 10/01/97 IPP telecon to propose clarifications and additions to the 9/26/97 Model document that are required in order to enter on the standard track with respect to the Language and CharSet policies of the IETF that are currently on standards track themselves. See RFC 1766 and 2184 and . RFC 2130 (IAB Character Set Workshop, Feb 1997) provides background material. We'd like to discuss this proposal at the telecon, this Wednesday 10/8. If there is agreement on the points, we'll draft the spec for the attributes. The text herein is the specific points for the Internationalization Considerations section of the IPP Model document. Send comments before the telecon if possible. Thanks, Tom Subj: Proposal for IPP to meet IESG Language and CharSet requirements From: Tom Hastings and Ira McDonald Date: 10/7/97 File: langchar.doc This document contains a proposal that Ira and I took on at the 10/01/97 telecon to propose clarifications and additions to the 9/26/97 Model document that are required in order to enter on the standard track with respect to the Language and CharSet policies of the IETF that are currently on standards track themselves. See RFC 1766 and 2184 and . RFC 2130 (IAB Character Set Workshop, Feb 1997) provides background material. NOTE - For clarity of the Model and Semantics document and the mapping in the protocol document, we have included as operational attributes in the Model specification any attribute that is mapped to HTTP/1.1 Protocol as headers. Any such mapping to HTTP/1.1 is indicated as a parenthetical remark in the Model specification. We think that URIs should also be brought back into the Model document as operational attributes that are mapped to the appropriate place in the HTTP/1.1 protocol as well. 1. Summary of Changes This proposal adds/clarifies attributes so that the client supplies the language and charset of the request and the Printer object responds in the requested language and charset, if supported, or in the Printer's default language and charset which can be queried. This functionality is provided by two Job Template attributes: (1) "content- natural-language" and (2) "content-charset" which are also operational attributes in query operations. As with any Job Template attribute, there are also the corresponding Printer "content-natural-language-default", "content-charset- default", "content-natural-language-supported", and "content- charset-supported" attributes. There are also two "document- natural-language" and "document-charset" operational attributes for independently specifying the content of documents for those media types that need such. This proposal is intended to replace existing natural language and charset attributes in the Model and Semantics document. 2. Specific Internationalization Provisions The following provisions are listed for inclusion in the Internationalization Considerations section of the IPP Model specification. They also serve as a detailed summary of the capabilities. The IPP Model and Semantics specification meets the IETF Policy on Character Sets and Languages [IETF-Pol] by providing the following internationalization capabilities: 1. Clients SHALL supply the HTTP/1.1 Content-Type header with the value: application/ipp; charset=xxx where xxx specifies the charset used by the attributes with attribute syntax 'text' and 'name' in the IPP request body (independent of the document content) and SHALL be a charset registered with IANA [REG] The Printer object SHALL support charset=utf-8 [28]. Support of other charsets is OPTIONAL, but all supported charsets SHALL be ones in which the code points from decimal 20 to 127 are US-ASCII [US-ASCII]. For conforming IPP Printer objects, the utf-8 charset SHALL be restricted to mean conformance level 2 of ISO 10646 [ISO- 10646], so that accented letters SHALL NOT be represented with non-spacing accents. 2. The term "natural language" is used to avoid confusion with "printer language", since "printer language" is the name given by IANA to the registration of print document formats as used in the Printer MIB, RFC 1759 [1]. 3. The client SHALL supply and the Printer object SHALL support the single-valued "content-natural-language" and "content-charset" Job Template attributes for correct interpretation of empty language and charset tags in IPP attributes with attribute syntax 'text' and 'name'. (The protocol SHALL convey these attributes via the HTTP/1.1 "Content-Language" and the 'charset' parameter of the 'application/ipp' media type "Content-Type" headers (see 1. above) [23]). Each value of an attribute in a request or a response with attribute syntax 'text' or 'name' MAY be in any language and/or charset and SHALL be tagged using the syntax and mechanism in RFC 2184 [RFC-2184], to indicate the language and charset of the value. If the natural language or charset is the same as that supplied by the client in the request, then the empty tag may be used consisting of only a single ' character for the language or charset. Examples: If the client supplies "content-natural-language" as 'en' and the "content-charset" as 'us-ascii', the following are valid representations of the "job-name" attribute in the request and in the response: us-ascii'en-us'Monthly Report us-ascii''Monthly Report 'en-us'Monthly Report ''Monthly Report -- the two ' characters SHALL be present iso-8859-1'fr'Rapport Mensuel 4. As with any supported Job Template attribute, the Printer object SHALL support the corresponding "content- natural-language-default", "content-natural-language- supported", "content-charset-default", and "content-charset- supported" Printer attributes. However, these Job Template attributes are MANDATORY for the Printer to support. 5. IPP Printer objects NEED NOT support HTTP/1.1 Accept headers and IPP/1.0 does not address the processing semantics for HTTP/1.1 Accept headers. 6. For the create operations the Printer object shall store in the Job Object any 'text' and 'name' Job Template attributes in the language and charset as supplied by the client, along with the values of the "content-natural- language" and "content-charset" attributes. In a subsequent query request, the Printer object NEED not convert any 'text' or 'name' attributes that had been supplied in the create request to the natural language or charset of the requester. However, any 'text' or 'name' attributes generated by the Printer object SHALL be returned in the natural language and charset specified by the requester in the "content-natural-language" and "content-charset" operational attributes of the query. However, if the specified natural language or charset is not supported by the Printer, the Printer SHALL respond in its default natural language or charset, rather than returning an error. 7. Notifications SHALL always include non-empty language and charset tags according to RFC 2184, since the recipient might not know what empty tags mean. 8. Type 4 keywords are often names defined by a system administrator and so may be in any language or charset. Therefore, attributes with attribute syntax 'type4 keyword' are allowed to have a mixture of 'keyword' tokens defined by the standard and/or registered as keywords (in U.S. English and US-ASCII) and 'name' tokens defined by the system administrator. Such names SHALL follow the syntax for names and SHALL be tagged using the syntax and mechanism of RFC 2184, while the keywords SHALL not be tagged (since keywords SHALL always be in US-English and US-ASCII). 9. No IPP Printer implementation NEED perform actual translation of natural language text and name values. A Printer object that supports multiple languages, often has separate catalogs of messages, one for each natural language. 10. The natural language and charset used in certain document formats may be specified separately and independently from that used by attributes that are part of the IPP protocol. Therefore, in order to indicate the natural language and charset of these document-formats, the "document-natural-language" and "document-charset" operation attributes are defined for use in the create, Send-Document, and Send-URI operations. For those media types that are not defined to include a charset parameter, such as application/octet-stream, the "document-charset" attribute MAY be used to convey the charset. For those media types that allow the charset to be specified as a parameter, such as 'text/plain', the client SHALL also supply the "document- charset" attribute with the same value. Then the Printer object NEED not parse the "document-format" media type attribute value. The Printer object SHALL support the "document-natural- language" and "document-charset" operational attributes, if the Printer object supports document formats which require them in order to be unambiguous. 3. Additions to the References section [ISO-10646] ISO/IEC 10646-1:1993, "Information technology -- Universal Multiple-Octet Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane, JTC1/SC2." [REG] N. Freed, J. Postel: IANA CharSet Registration Procedures, Work in Progress (draft-freed-charset-reg- 02.txt). [US-ASCII] Coded Character Set - 7-bit American Standard Code for Information Interchange, ANSI X3.4-1986. [IETF-Pol] H. Alvestrand, "IETF Policy on Character Sets and Languages, work in progress , August 29, 1997. [RFC-2184] N. Fried, K. Moore, MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations, RFC 2184, August 1997. From ipp-archive Wed Oct 8 16:03:29 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA07706 for ipp-outgoing; Wed, 8 Oct 1997 16:01:46 -0400 (EDT) Message-Id: <3.0.1.32.19971008124747.009ba3e0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 8 Oct 1997 12:47:47 PDT To: ipp@pwg.org From: Keith Moore (by way of Carl-Uno Manros ) Subject: IPP> Re: Timing for delivery of drafts for IESG review Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Friends, Please see the following suggestion for time table from Keith Moore. The bottom line is that we need to have the I-Ds to the IESG by the first week of November, if we want to have them through this year. Can we do that, considering that we still need to have our own WG last call, which takes 2 weeks and a bit? Carl-Uno --- > My question to you is about timing to get our documents in your and the > IESG's hands in time to get the project closed up this year. What is the > meeting schedule for the next IESG meeting? How long do you expect the IESG > review process to take? Hence, by which date do you need to get our final > I-D texts in order to get this done in 1997? It takes a month at a minimum to get standards-track documents through the IESG. Before IESG votes on the documents there will be a two week IETF-wide Last Call, after which the documents will be placed on the IESG agenda. Any Last Calls that are issued within two weeks prior to an IETF meeting will be extended to last until two weeks *after* that meeting. IESG normally meets every two weeks, but the documents have to be on the agenda for at least a week before we vote on them. However, the IESG meeting schedule, and therefore processing of standards-track documents, will be disrupted by the IETF meeting in December, and possibly by the US Thanksgiving holiday. Bottom line: I'd try to get them in by the first week in November, or the second week at the latest. That should give ample time to get the Last Call completed two weeks before the IETF meeting, which would allow the IESG to ballot the document in December. And if it turns out that minor revisions are needed after Last Call, there's at least some possibility of getting them turned around before the end of the year. There's no hard and fast rule, but the later we creep into November the more likely we are to push the Last Call into late December, which will then push the IESG ballot into January. Keith From ipp-archive Wed Oct 8 17:53:30 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA08904 for ipp-outgoing; Wed, 8 Oct 1997 17:53:08 -0400 (EDT) Message-Id: <3.0.1.32.19971008143917.009d2b30@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 8 Oct 1997 14:39:17 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Minutes from PWG IPP Phone Conference 971008 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Minutes from PWG IPP Phone Conference 971008 Participants: Carl-Uno Manros Tom Hastings Ira Mcdonald Scott Isaacson (part time) Bob Herriot Randy Turner (part time) Jay Martin Stan McConnell Carl-Uno started up by informing about a correspondance with Keith Moore about the deadline to get our documents to the IESG for processing this year. The dealine would be the first week of November. The discussion came up with the following tough schedule to achieve this: - All text contributions to Scott and Bob by tomorrow October 9th - Scott and Bob to send out new intermediate drafts by Monday October 13th - Review these drafts in next week's phone conference Wednesday October 15th - Send the documents to the IETF on October 15th or 16th - Start the WG last call on October 20th - Finish WG last call on November 3rd - Do final editing (if needed) and send to IETF and IESG by November 7th Tom, Ira, Scott, Bob and Carl-Uno all took on various home work assignments to deliver on the agreements out of last week's call. It was agreed that the easiest fix to the Requirements docxument would be to simply flag things which are not yet covered in the Model document as (Version 2) deliverables. Don to do this edit in time for the Requirements document to go out together with the other documents on the WG last call. Carl-Uno to contact Steve Zilles to get the new version of the Rationale document ready in time to go out for last call with the other documents. It was decided that the registration for the MIME type application/ipp will be prepared by Ira in consultation with Larry Masinter and progressed in parallel with the WG last call. Bob to synchronize variuos parts with Scott to make sure that Model and Protocol documents are aligned. --- 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 From ipp-archive Wed Oct 8 19:08:31 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA09579 for ipp-outgoing; Wed, 8 Oct 1997 19:05:05 -0400 (EDT) Message-Id: <3.0.1.32.19971008160920.00c696e0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 8 Oct 1997 16:09:20 PDT To: Larry Masinter From: Tom Hastings Subject: IPP> Re: MOD - RESEND: Proposal for IPP to meet IESG Language and CharSet requirements Cc: ipp@pwg.org In-Reply-To: <343BFA34.17091AA@parc.xerox.com> References: <3.0.1.32.19971007180400.010e76b0@garfield> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk At 02:25 PM 10/8/97 PDT, Larry Masinter wrote: >Tom, I didn't understand the rationale for having a 'document-charset' >rather than using the 'charset=..' parameter of the document format. We would have preferred to use the 'charset=..' parameter of the document format, but there are a number of media types that are registered that do NOT specify that the 'charset=..' paramater may be used with them. For example, 'application/octet-stream' and 'application/vnd.hp-PCL'. While PCL has an optional instruction inside the document data that specifies the codeset, it is optional, even when the codeset is different from US-ASCII (or HP Roman-8). Therefore, we had to introduce the IPP "document-charset" (operational) attribute. Rather than making it optional, we decided it would simplify the recipient, if it was required for the sender to always included and had to agree with the media type charset parameter, if present. > >You said something like: >> Then the Printer >> object NEED not parse the "document-format" media type >> attribute value. > >(which doesn't seem to be a good use of "NEED", did you mean >just "MAY" instead of "NEED NOT"?), but I don't get it. The >Printer (object?) has to look at the document-format if it >needs to know the document format, doesn't it? Yes, the Printer does have to look at the value to make sure that it is supported, but it doesn't have to parse any further once it reaches the ';' character. We'll just delete the sentence. > >> 5. IPP Printer objects NEED NOT support HTTP/1.1 Accept >> headers and IPP/1.0 does not address the processing >> semantics for HTTP/1.1 Accept headers. > >HTTP/1.1 support for ACCEPT headers is optional, but >Accept-language and Accept-charset is useful, e.g., when >determining the language & charsets useful for HTTP >warnings & error messages. I don't know if "does not >address the processing semantics for HTTP/1.1 Accept headers" >is useful advice. Is there an ambiguity? We thought it was simpler to avoid the complexity of accept headers. What we have is complicated enough. Also in IPP, the client can query the server to see what languages and char sets the server supports before creating a job or making a query. Finally, IPP, unlike HTTP, the client is supplying language and charset attributes as input and these attributes are stored on the job object. Later queries of the job object and notifications use the value stored with the job (or the Printer default for messages generated by the Printer, if the stored language or charset is not supported). Sound ok not to specify the semantics of accept headers? Should we say that IPP implementations SHALL ignore the accept headers, if present? > >Larry >-- >http://www.parc.xerox.com/masinter > > From ipp-archive Wed Oct 8 19:38:31 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA10214 for ipp-outgoing; Wed, 8 Oct 1997 19:34:17 -0400 (EDT) Message-ID: <343C1856.491455B9@parc.xerox.com> Date: Wed, 8 Oct 1997 16:33:42 PDT From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: Tom Hastings CC: ipp@pwg.org Subject: IPP> Re: MOD - RESEND: Proposal for IPP to meet IESG Language and CharSet requirements References: <3.0.1.32.19971007180400.010e76b0@garfield> <3.0.1.32.19971008160920.00c696e0@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk > For example, 'application/octet-stream' > and 'application/vnd.hp-PCL'. While PCL has an optional instruction > inside the document data that specifies the codeset, it is optional, > even when the codeset is different from US-ASCII (or HP Roman-8). For 'application/vnd.hp-PCL': if it is necessary to know the codeset in order to properly interpret application/vnd.hp-pcl, then the definition of application/vnd.hp-pcl is deficient. If you can't convince HP to fix their registration, you could register an alternative value. It may well be that the range of available 'codeset' for some printer types is different than the range of registered Internet 'charset' values; after all, 'charset' combines both the coded character set and the encoding scheme, while some printer languages may employ a different mechanism for mapping between embedded integers and visual representations. For 'application/octet-stream': either this is for auto-detection or it is not. If the sender knows enough about the sender's environment to determine what 'charset' is used, shouldn't the sender also know what document format is actually used? Under what circumstances would one be known and not the other? As for the discussion on Accept headers: it seems riskier to layer on top of HTTP but then to declare that you're ignoring some of the features. Presumably you're going to go through proxy gateways and other HTTP-munging intermediaries, and if so, it's very risky to claim that you're changing the semantics. I'm not sure why you're focusing on the 'accept headers' here, but not also supplying advice for any other HTTP header. Do you support etags? COntent-ID? etc. etc. Accept headers are merely advisory as it stands, and you're not adding any additional requirements nor are you removing them. So why say anything at all? > We thought it was simpler to avoid the complexity of accept headers. > What we have is complicated enough. People are hoping to avoid complexity by reusing existing HTTP implementations, and so any *change* from HTTP adds complexity. If you want to point out that Accept headers have no special significance in IPP, and will likely be ignored by IPP printers, well, that's fine. Accept headers are ONLY for client to server, and the content negotiation you need for IPP is for server to client, so they don't apply, anyway. It would be great to extend HTTP to allow for reverse content negotiation (e.g., for POST or PUT) but that's some other work that will likely be ongoing. We're trying to put together a separate working group on 'content negotiation' more generally; perhaps there will be something done in time for IPP version 2, future versions of HTTP, fax, etc. Larry -- http://www.parc.xerox.com/masinter From ipp-archive Wed Oct 8 20:53:32 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA10897 for ipp-outgoing; Wed, 8 Oct 1997 20:50:35 -0400 (EDT) Date: Wed, 8 Oct 1997 17:54:16 PDT From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9710090054.AA17254@snorkel.eso.mc.xerox.com> To: imcdonal@eso.mc.xerox.com, ipp@pwg.org, masinter@parc.xerox.com Subject: IPP> MOD - Proposed application/ipp registration text Sender: ipp-owner@pwg.org Precedence: bulk Copies To: masinter@parc.xerox.com imcdonal@eso.mc.xerox.com ipp@pwg.org Hi Larry Masinter, Wednesday (8 October 1997) At our IPP Telecon this afternoon, I got the action item to write up a MIME registration for the MIME media type "application/ipp". I'm hoping you'll take a minute to look my attempt below and tell me where I've gone wrong. Based on a note from Keith Moore (one of our two IETF Area Directors), we are trying to finish up the IPP specs for submission to the IESG by the beginning of November, so our schedule is very tight. I got the template from RFC 2048. Thanks for your help in advance, - Ira McDonald (outside consultant at Xerox) High North Inc PO Box 221 Grand Marais, MI 49839 906-494-2434 ------------------------------------------------------------------------ To: ietf-types@iana.org Subject: Registration of MIME media type "application/ipp" MIME type name: application MIME subtype name: ipp A Content-Type of "application/ipp" indicates an Internet Printing Protocol request or response. Currently there is one version: IPP/1.0, described in [IPP-MOD] and [IPP-PRO], transported via the HTTP/1.1 (RFC 2068) POST method, using single-valued Content-Type and Content-Language headers (both headers MUST be specified). Required parameters: charset IPP/1.0 keywords (eg, attribute names) are encoded in US-ASCII and US-English. IPP/1.0 string attributes of syntax "text" or "name" MAY have values in ANY character set and language, and MUST use "charset/language" prefixes, via the method specified in RFC 2184. The required "charset" parameter of the "application/ipp" MIME media type MUST be used to specify the default to use when the "charset" of a "charset/language" prefix is empty (ie, a single quote character). IPP/1.0 protocol requests and responses MUST use a Content-Language header to specify a default to use when the "language" of a "charset/language" prefix is empty (ie, a single quote character). Optional parameters: None Encoding considerations: IPP/1.0 protocol requests and responses MAY contain long lines and MUST always contain binary data and therefore MUST be encoded using Content-Transfer-Encoding: binary. Security considerations: IPP/1.0 requests and responses MAY be secured via the use of a transport layer security protocol (below HTTP/1.1). Interoperability considerations: IPP/1.0 Printer objects (ie, servers) MUST support the attributes "printer-charset-supported" (MAY be multi-valued) and "printer-natural-language-supported" (MAY be multi-valued), to facilitate interoperability with IPP/1.0 clients. Published specification: [IPP-MOD] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, "Internet Printing Protocol/1.0: Model and Semantics", work in progress , September 1997. [IPP-PRO] S. Butler, R. Herriot, P. Moore, R. Turner, "Internet Printing Protocol/1.0: Protocol Specification", work in progress , September 1997. Applications which use this media type: Internet Printing Protocol (IPP) Person & email address to contact for further information: Scott A. Isaacson Novell, Inc. 122 E 1700 S Provo, UT 84606 Phone: 801-861-7366 Fax: 801-861-4025 Email: scott_isaacson@novell.com or Robert Herriot Sun Microsystems Inc. 901 San Antonio Road, MPK-17 Palo Alto, CA 94303 Phone: 650-786-8995 Fax: 650-786-7077 Email: robert.herriot@eng.sun.com Intended usage: COMMON ------------------------------------------------------------------------ From ipp-archive Thu Oct 9 03:28:37 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id DAA11926 for ipp-outgoing; Thu, 9 Oct 1997 03:24:49 -0400 (EDT) Date: Thu, 09 Oct 1997 00:05:30 -0700 (PDT) From: Ned Freed Subject: Re: IPP> Re: MOD - RESEND: Proposal for IPP to meet IESG Language and CharSet requirements In-reply-to: "Your message dated Wed, 08 Oct 1997 16:33:42 -0700 (PDT)" <343C1856.491455B9@parc.xerox.com> To: Larry Masinter Cc: Tom Hastings , ipp@pwg.org Message-id: <01IOL0HKRCLI9JD7O7@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii References: <3.0.1.32.19971007180400.010e76b0@garfield> <3.0.1.32.19971008160920.00c696e0@garfield> Sender: ipp-owner@pwg.org Precedence: bulk > > For example, 'application/octet-stream' > > and 'application/vnd.hp-PCL'. While PCL has an optional instruction > > inside the document data that specifies the codeset, it is optional, > > even when the codeset is different from US-ASCII (or HP Roman-8). > For 'application/vnd.hp-PCL': if it is necessary to know the codeset > in order to properly interpret application/vnd.hp-pcl, then the > definition of application/vnd.hp-pcl is deficient. I agree. > If you can't > convince HP to fix their registration, you could register an > alternative value. It may well be that the range of available > 'codeset' for some printer types is different than the range > of registered Internet 'charset' values; after all, 'charset' > combines both the coded character set and the encoding scheme, > while some printer languages may employ a different mechanism > for mapping between embedded integers and visual representations. A codeset parameter would also be a possibility. > For 'application/octet-stream': either this is for auto-detection > or it is not. If the sender knows enough about the sender's environment > to determine what 'charset' is used, shouldn't the sender also > know what document format is actually used? Under what circumstances > would one be known and not the other? I agree with the logic here as well. But as far as application/octet-stream goes, I suggest that before any attempt is made to standardize the processing of this type that some consideration be given to IETF interoperability rules for standards-track protocols. The IETF doesn't let standards advance with demonstrable interoperability problems or without multiple interoperable implementations. And any idea that the addition of a charset parameter is sufficient to make complete arbitrary binary data renderable, even with the best auto-detection logic in the world in place, just isn't going to fly. As such, I strongly recommend that any attempt to standardize handling of application/octet-stream, either with supplemental information or without, and either with auto-detection or without, be abandoned. This would be OK as an informational document or as an experimental one, but not in a standard. Ned From ipp-archive Thu Oct 9 08:08:41 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA12774 for ipp-outgoing; Thu, 9 Oct 1997 08:06:39 -0400 (EDT) X-Mailer: exmh version 1.6.9 8/22/96 From: Harald.T.Alvestrand@uninett.no To: find@bunyip.com, ietf-calendar@imc.org, ipp@pwg.org cc: directorate@apps.ietf.org Subject: IPP> Content-disposition: A better place for command verbs? Date: Thu, 09 Oct 1997 14:06:10 +0200 Message-ID: <5918.876398770@dale.uninett.no> MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk Hi, as some of you know, I've been somewhat worried about the recent trend to try to define MIME types that have more or less the same content (or even no content), but different names, because they indicate different things that the sender wants the recipient to do. Recently, an I-D crossed my desk: draft-rfced-exp-whalen-00.txt Now the actual draft is quite dangerous, because it confuses "program name" with "desired function", effectively making it just too easy to create an "execute anything" facility without intending to. But the basic idea might have a point: *> Architecturally, I think the "command verb" part fits better as a <* *> content-disposition modifier than as a MIME type. <* So - it SHOULD be possible to define a content-disposition modifier that is adequately narrow, for instance: Content-type: application/job-id Content-disposition: process; proto=3Dipp; request=3Dreturn-status Content-type: appication/event Content-disposition: process; proto=3Dimip; request=3Dcounteroffer Content-type: index/cip-tokenized-index-delta Content-disposition: process; proto=3Dcip; request=3Dmerge I know that several of you are quite far along the track already, and may= not want to rethink the usage you make of MIME types, but I think it's wo= rth spending at least 3 minutes thinking about where you put the "command ver= b". Have fun! Harald A From ipp-archive Thu Oct 9 09:38:42 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA13461 for ipp-outgoing; Thu, 9 Oct 1997 09:36:29 -0400 (EDT) Message-ID: <70973C3481791200@mail.lan-aces.com> In-Reply-To: <5918%.876398770@mail.lan-aces.com> Date: Thu, 9 Oct 1997 08:36:00 -0500 From: Ralph Patterson Organization: LAN-ACES, Inc. To: Harald.T.Alvestrand@uninett.no Cc: directorate@apps.ietf.org, find@bunyip.com, ietf-calendar@imc.org, ipp@pwg.org Subject: IPP> cc: re: Content-disposition: A better place for command verbs? X-SMF-Hop-Count: 1 MIME-Version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Mailer: Connect2-SMTP 4.31.05 MHS/SMF to SMTP Gateway Sender: ipp-owner@pwg.org Precedence: bulk On Thursday, October 09, 1997 7:06 AM, Harald.T.Alvestrand@uninett.no wrote: > >Date: 9-Oct-97 7:06:10 -0500 >From: Harald.T.Alvestrand@uninett.no >To: find@bunyip.com, >Subject: Content-disposition: A better place for command verbs? > >Hi, >as some of you know, I've been somewhat worried about the recent trend >to try to define MIME types that have more or less the same content >(or even no content), but different names, because they indicate >different things that the sender wants the recipient to do. > >Recently, an I-D crossed my desk: draft-rfced-exp-whalen-00.txt >Now the actual draft is quite dangerous, because it confuses >"program name" with "desired function", effectively making it just too >easy to create an "execute anything" facility without intending to. >But the basic idea might have a point: > >*> Architecturally, I think the "command verb" part fits better as a <* >*> content-disposition modifier than as a MIME type. <* > >So - it SHOULD be possible to define a content-disposition modifier >that is adequately narrow, for instance: > >Content-type: application/job-id >Content-disposition: process; proto=ipp; request=return-status > >Content-type: appication/event >Content-disposition: process; proto=imip; request=counteroffer > >Content-type: index/cip-tokenized-index-delta >Content-disposition: process; proto=cip; request=merge > >I know that several of you are quite far along the track already, and may >not want to rethink the usage you make of MIME types, but I think it's worth >spending at least 3 minutes thinking about where you put the "command verb". > >Have fun! > > Harald A **** Comment from Ralph Patterson on 10/09/97 at 8:14 AM CST **** Harald, If I understand what you are suggesting correctly, this was addressed early on in the iCalendar discussion. I believe the consensus was that putting disposition information *only* in the MIME header caused the iCalendar object to fail at being a self contained "object". Again, if I recall correctly, the concern was that even though the specification is for MIME encapsulated information, the iCalendar object itself may not stay MIME encoded for the duration of the process (e.g., gateways to other messaging systems, certain e-mail packages (e.g., Eudora) that split the attachment from the message, etc.). Now, if that is not what you were suggesting, I'm sorry for the interruption and everyone can resume their normally scheduled broadcast day. Ralph Patterson From ipp-archive Thu Oct 9 11:03:42 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA14144 for ipp-outgoing; Thu, 9 Oct 1997 11:03:14 -0400 (EDT) Message-ID: <343CF123.E6DCC6A5@sharplabs.com> Date: Thu, 09 Oct 1997 07:58:44 -0700 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Labs of America X-Mailer: Mozilla 4.02 [en] (Win95; I) MIME-Version: 1.0 To: Ned Freed CC: Larry Masinter , ipp@pwg.org Subject: Re: IPP> Proposal for IPP to meet IESG Language/CharSet requirements References: <3.0.1.32.19971007180400.010e76b0@garfield> <3.0.1.32.19971008160920.00c696e0@garfield> <01IOL0HKRCLI9JD7O7@INNOSOFT.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Ned Freed wrote: > > For 'application/octet-stream': either this is for auto-detection > > or it is not. If the sender knows enough about the sender's environment > > to determine what 'charset' is used, shouldn't the sender also > > know what document format is actually used? Under what circumstances > > would one be known and not the other? I agree that in the "application/octet-stream" case, 99.9% of the clients willnot know the charset, or anything else about the document(s) to be printed. > > > I agree with the logic here as well. But as far as application/octet-stream > goes, I suggest that before any attempt is made to standardize the processing > of this type that some consideration be given to IETF interoperability rules > for standards-track protocols. The IETF doesn't let standards advance with > demonstrable interoperability problems or without multiple interoperable > implementations. And any idea that the addition of a charset parameter is > sufficient to make complete arbitrary binary data renderable, even with the > best auto-detection logic in the world in place, just isn't going to fly. > > As such, I strongly recommend that any attempt to standardize handling of > application/octet-stream, either with supplemental information or without, and > either with auto-detection or without, be abandoned. This would be OK as > an informational document or as an experimental one, but not in a standard. > > Ned While I understand the spirit of the comments related to standardization of "application/octet-stream", it is not our responsibiltiy to enforce absolute interoperability onto an existing printing environment that inherently has an interoperability problem. There are a million non-pathological scenarios wherein a user has an existing file that is to be printed and may or may not know the format of the file. In my experience with MIME, this has been how mail clients tag attachments when they're not sure the format of a particular attachment. This is exactly how we would use the "application/octet-stream" in the IPP case. In order to make our use of "application/octet-stream" more palatable to the IESG, we could use proper wordsmithing to come up with something I think would work. IPP could not dictate what "application/octet" stream means to a server that receives such a document, but only say that it is implementaiton dependent what happens when a server receives such a document, and maybe provide examples (such as auto-sense). In this case we're not officially standardizing how "application/octet-stream" is to be handled by a server, only suggesting. And while this may indeed present interoperability problems, I think it is worth keeping the use of "application/octet-stream" at least mentioned in the documents. With proper wordsmithing, I don't think IPP implementations will use "application/octet-stream" any different than it is being used today in the SMTP/MIME world. Randy From ipp-archive Thu Oct 9 11:28:43 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA14786 for ipp-outgoing; Thu, 9 Oct 1997 11:28:35 -0400 (EDT) Message-ID: <343CF817.C82BEB2D@underscore.com> Date: Thu, 09 Oct 1997 11:28:23 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.02 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org CC: rturner@sharplabs.com, Ned Freed , Larry Masinter Subject: Re: IPP> Proposal for IPP to meet IESG Language/CharSet requirements References: <3.0.1.32.19971007180400.010e76b0@garfield> <3.0.1.32.19971008160920.00c696e0@garfield> <01IOL0HKRCLI9JD7O7@INNOSOFT.COM> <343CF123.E6DCC6A5@sharplabs.com> Content-Type: multipart/mixed; boundary="------------578C7E2551A60BAD272EADE4" Sender: ipp-owner@pwg.org Precedence: bulk This is a multi-part message in MIME format. --------------578C7E2551A60BAD272EADE4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Randy's comments are right on the mark, IMHO. The printer industry has been successfully dealing with auto-sensed data for quite sometime now. It should make no difference what the official MIME type is, whether it be "application/octet-string" or "something/go-fish". A rose by any other color, etc... Perhaps I'm missing something here, but it seems painfully obvious to me that we have put a big stake in the ground to support legacy printing systems as part of the philosophy/strategy of wide-scale IPP deployment. As such, auto-sensing is absolutely mandatory to for the interoperable implementations to succeed. The less baggage we attach to the auto-sense situation, the better. It just seems that the rest of the world has long embraced the MIME type "application/octet-stream" to be "unknown type, go fish", and I don't understand why we can't follow that lead. (Sorry if I'm not up on the latest, greatest IETF trends in this area.) ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- --------------578C7E2551A60BAD272EADE4 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by uscore.underscore.com (8.8.4/8.7.2) with ESMTP id LAA26449; Thu, 9 Oct 1997 11:14:09 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA14278; Thu, 9 Oct 1997 11:14:08 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 9 Oct 1997 11:13:10 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA14144 for ipp-outgoing; Thu, 9 Oct 1997 11:03:14 -0400 (EDT) Message-ID: <343CF123.E6DCC6A5@sharplabs.com> Date: Thu, 09 Oct 1997 07:58:44 -0700 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Labs of America X-Mailer: Mozilla 4.02 [en] (Win95; I) MIME-Version: 1.0 To: Ned Freed CC: Larry Masinter , ipp@pwg.org Subject: Re: IPP> Proposal for IPP to meet IESG Language/CharSet requirements References: <3.0.1.32.19971007180400.010e76b0@garfield> <3.0.1.32.19971008160920.00c696e0@garfield> <01IOL0HKRCLI9JD7O7@INNOSOFT.COM> Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Content-Type: text/plain; charset=us-ascii Ned Freed wrote: > > For 'application/octet-stream': either this is for auto-detection > > or it is not. If the sender knows enough about the sender's environment > > to determine what 'charset' is used, shouldn't the sender also > > know what document format is actually used? Under what circumstances > > would one be known and not the other? I agree that in the "application/octet-stream" case, 99.9% of the clients willnot know the charset, or anything else about the document(s) to be printed. > > > I agree with the logic here as well. But as far as application/octet-stream > goes, I suggest that before any attempt is made to standardize the processing > of this type that some consideration be given to IETF interoperability rules > for standards-track protocols. The IETF doesn't let standards advance with > demonstrable interoperability problems or without multiple interoperable > implementations. And any idea that the addition of a charset parameter is > sufficient to make complete arbitrary binary data renderable, even with the > best auto-detection logic in the world in place, just isn't going to fly. > > As such, I strongly recommend that any attempt to standardize handling of > application/octet-stream, either with supplemental information or without, and > either with auto-detection or without, be abandoned. This would be OK as > an informational document or as an experimental one, but not in a standard. > > Ned While I understand the spirit of the comments related to standardization of "application/octet-stream", it is not our responsibiltiy to enforce absolute interoperability onto an existing printing environment that inherently has an interoperability problem. There are a million non-pathological scenarios wherein a user has an existing file that is to be printed and may or may not know the format of the file. In my experience with MIME, this has been how mail clients tag attachments when they're not sure the format of a particular attachment. This is exactly how we would use the "application/octet-stream" in the IPP case. In order to make our use of "application/octet-stream" more palatable to the IESG, we could use proper wordsmithing to come up with something I think would work. IPP could not dictate what "application/octet" stream means to a server that receives such a document, but only say that it is implementaiton dependent what happens when a server receives such a document, and maybe provide examples (such as auto-sense). In this case we're not officially standardizing how "application/octet-stream" is to be handled by a server, only suggesting. And while this may indeed present interoperability problems, I think it is worth keeping the use of "application/octet-stream" at least mentioned in the documents. With proper wordsmithing, I don't think IPP implementations will use "application/octet-stream" any different than it is being used today in the SMTP/MIME world. Randy --------------578C7E2551A60BAD272EADE4-- From ipp-archive Thu Oct 9 12:28:44 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA15481 for ipp-outgoing; Thu, 9 Oct 1997 12:26:59 -0400 (EDT) From: Roger K Debry To: , Cc: Subject: IPP> Comments on Requirements document Message-ID: <5030100010589501000002L012*@MHS> Date: Thu, 9 Oct 1997 12:27:15 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk I apologize for not being able to participate much recently in the conf= erence calls. I've just been terriibly busy with my day job and have been trav= eling a lot. I did sit down and review the requirements document while on the p= lane this week. Here are my comments: o I think it would be good to have something in the introductory text explaining our rationale for determining what were version 1.0 IPP req'ts. In particular, I think some words of the tone that our goal was= to hit the 80% mark quickly and that rapid deployment was a major objective, would be important things to say. Otherwise it is hard to understand why some things aren't considered valid req'ts for version 1.0. o In the terminology section, the discussion is cast in terms of an overall internet printing solution. I think this is fine, and as it sho= uld be. However, a sentence or two simply explicitly saying that IPP is but one key component of an internet printing solution would seem important. Then going on to say how things like locating printers and creating printer instances is enabled by IPP seems to work better. o The latter part of the first paragraph in section I and the second paragraph seem to be too Browser-centric. I think these could be deleted altogether, or based on the previous comment simply say that HTTP, and Web Browsers are **other** components of a complete internet printing solution. As it stands, one could easily come away believing that IPP running on a browser is a major requirement of IPP. o I think the third paragraph of section I is slightly misleading. While it says that "No assumption is made about multi-tiered printing solutions", it does not make clear that such solutions are in fact supported by the protocol. I think as written, it might leave the reader believing server congurations are not supported. Just a few word changes would fix this. o Section 2 introduces the three user roles, end-user, operator, and adminsitrator. Although we say it elsewhere, I think it important to say right here that only end-user functions are considered as version 1.0 requirements. o In the second paragraph of section 1.2, I'd spell out the six categories more carefully. For example, finding/locating should be finding/locating a printer, local instance should be creating a local isntance of a printer, etc. o Add the phrase "by their IPP attributes" to the last sentence of section 2.1.1. o In the last set of bullets in section 2.1.3, I'd suggest taking out t= he sentence that begins "When checking the status on jobs ...". Also take out the last bullet, how are job priorities assigned. I don't thin= k there is anything in IPP that describes **HOW** priorities are assigned. I think this would read better with these changes and better reflect actual usage. o I think section 2.1.4 needs some work. I believe we defined three distinct usages: Printing from an application, which places a req't on the protocol to support streaming, pushing a previously created file, and print by reference (pull). The simple push case doesn't get covered as this section is written. Also, the second paragraph seems confusing and I am not sure it adds much to the document. In any case, the three bullets listed here are all outside the scope of IPP. I believe that everything that needs = to be said in terms of requirements here is said in the following paragrap= hs. o In the second paragraph of section 2.1.6, the second sentence begins "New notification means ...". I don't think the word New is required he= re. o In section 2.1.6, I would prefer that we say changing job properties = or changing job attributes, instead of Altering the print job. o Section 4 would seem to better fit before section 3. Thus all of the= general discussion of requiremetns comes first, then the high level scenarios, then the datailed scemarios comes last. o In section 3.0, there is quite some discussion of the three physical environments supported in the scenarios. In fact, the physical environments are quite transparent and aren't discussed in any way in any of the scenarios. If it is appropriate to keep these three models in the requirements document, then I'd suggest that this discussion be moved to section 1.o and replace or supplement the third paragraph in section 1 which says that "No assumption is made about multi-tiered environments." Also, we long ago decided to get rid of the notion of inside and outside of firewalls in the security document. I'd suggest taking this discussion out of section 3 and supplementing the security discussion in paragraph 4.1. o Replace section 4.1 with the following (from the security ID): It is required that the Internet Printing Protocol be able to operate within a secure environment. Wherever possible, IPP ought to make use of existing security protocols and services. IPP will not invent ne= w security features when the requirements described in this document can be met by existing protocols and services. Examples of such services inlcude Transport Layer Security (TLS) and HTTP Digest Authentication. Since we cannot anticipate the security levels or the specific threats that any given IPP print administrator may be concerned with, IPP must be capable of operating with different secuity mechanisms and policies as required by the individual installation. The initial securi= ty needs of IPP are derived from two primary considerations. First, the printing environments describes in this document take into account that the client, the Printer, and the document to be printed may all ex= ist in different security domains. When objects are in different security domains the requirements for authentication and message protection are much stronger than when they are all in the same domain. Secondly, the sensitivity and value of the content being printed will vary from one instance of a print job to another. For example, a publicly available document does not need the same level of protection as a payroll document does. Message protection requirements include data origin authentication, privacy, integrity, and non-repudiation. o In section 8, the appendix, you should preface this entire section with the caveat that these scenarios describe internet printing applications, which are **enabled** with IPP, and that many of the flows shown are not actually within the scope of IPP. Also, you should mention that many of the IPP flows are beyond the scope of version 1.0. Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 = From ipp-archive Thu Oct 9 13:03:44 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA16119 for ipp-outgoing; Thu, 9 Oct 1997 12:59:15 -0400 (EDT) Message-Id: <3.0.1.32.19971008215215.00f613b0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 8 Oct 1997 21:52:15 PDT To: fyergeau@alis.com From: Tom Hastings Subject: IPP> MOD - Comment on RFC 2044: need to specify the ISO 10646 conformance level Cc: Harald.T.Alvestrand@uninett.no, Keith Moore , ipp@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk ISO 10646 has three conformance levels: 1. No composed characters 2. Several code points respresenting a single character in certain Asian languages where such composition is part of the language. 3. Composed characters using non-spacing accents. Thus accented letters have at least two different encodings: (1) as a single code point, and (2) a sequence of two code points where one is a non-spacing accent. Characters with more than one accent are represented by a sequence of three code points. For level 3, a recipient has to fold the alternate forms into a single cannonical form for purposes of comparing. One of the advantages of level 3 is that new accented letters can be invented without having to add new code points to the standard. Another disadvantage is that characters are not fixed length. For the purposed of Internet Protocols, we suspect that level 2 is sufficient. But the UTF-8 definition in RFC 2144 is silent on this matter. We suggest that a refision to RFC 2144 be issues that indicates that utf-8 means just level 2. Alternatively, register a new value, say, 'utf-8-level-2'. Tom From ipp-archive Thu Oct 9 13:13:50 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA16619 for ipp-outgoing; Thu, 9 Oct 1997 13:12:50 -0400 (EDT) Message-Id: <3.0.1.32.19971009095814.00bac100@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 9 Oct 1997 09:58:14 PDT To: Ned Freed , Larry Masinter From: Carl-Uno Manros Subject: Re: IPP> Re: MOD - RESEND: Proposal for IPP to meet IESG Language and CharSet requirements Cc: Tom Hastings , ipp@pwg.org In-Reply-To: <01IOL0HKRCLI9JD7O7@INNOSOFT.COM> Illegal-Object: Syntax error in References: value found on alpha.xerox.com: References: <"Your message dated Wed, 08 Oct 1997 16:33:42 -0700 (PDT)"<343C1856.491455B9@parc.xerox.com><3.0.1.32.19971007180400.010e76b0@garfield> <3.0.1.32.19971008160920.00c696e0@garfield> ^-illegal end of message identification Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk At 12:05 AM 10/9/97 PDT, Ned Freed wrote: >I agree with the logic here as well. But as far as application/octet-stream >goes, I suggest that before any attempt is made to standardize the processing >of this type that some consideration be given to IETF interoperability rules >for standards-track protocols. The IETF doesn't let standards advance with >demonstrable interoperability problems or without multiple interoperable >implementations. And any idea that the addition of a charset parameter is >sufficient to make complete arbitrary binary data renderable, even with the >best auto-detection logic in the world in place, just isn't going to fly. > >As such, I strongly recommend that any attempt to standardize handling of >application/octet-stream, either with supplemental information or without, and >either with auto-detection or without, be abandoned. This would be OK as >an informational document or as an experimental one, but not in a standard. > > Ned > Ned, FYI, many existing proprietary products successfully supports the auto-detection feature. It may obviously not always work, but works most of the time. A scenario where this is very helpful, is if the user gets a file of some unknown file type e.g. as attachment in a message or found on a web page and wants to attempt printing it. In another scenario, a user might know that a file is Postscript, but not whether it is Postscript 1, 2 or 3. The auto-sensing can often help sort that out once the file arrives at the printer. We obviously do not want to make IPP less powerful than existing products in this respect. It seems to me though, that we should define our own MIME type for a document file that we want to have auto-sensed. 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 From ipp-archive Thu Oct 9 13:38:44 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA17384 for ipp-outgoing; Thu, 9 Oct 1997 13:35:12 -0400 (EDT) Message-Id: <3.0.1.32.19971009101939.009c1100@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 9 Oct 1997 10:19:39 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> REMINDER: Copyright notice requirement for standards track RFCs Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk FYI, Editors, please include this new boiler plate. Carl-Uno >Return-Path: >From: Harald.T.Alvestrand@uninett.no >To: wg-chairs@apps.ietf.org >Cc: directorate@apps.ietf.org >Subject: REMINDER: Copyright notice requirement for standards track RFCs >Date: Thu, 9 Oct 1997 05:19:29 PDT >Sender: hta@dale.uninett.no > >Note that RFC 2026, the standards process document that we all follow, >has the following text in it: > > (C) The following copyright notice and disclaimer shall be included > in all ISOC standards-related documentation: > > "Copyright (C) The Internet Society (date). All Rights > Reserved. > > This document and translations of it may be copied and > furnished to others, and derivative works that comment on or > otherwise explain it or assist in its implmentation may be > prepared, copied, published and distributed, in whole or in > part, without restriction of any kind, provided that the above > copyright notice and this paragraph are included on all such > copies and derivative works. However, this document itself may > not be modified in any way, such as by removing the copyright > notice or references to the Internet Society or other Internet > organizations, except as needed for the purpose of developing > Internet standards in which case the procedures for copyrights > defined in the Internet Standards process must be followed, or > as required to translate it into languages other than English. > > The limited permissions granted above are perpetual and will > not be revoked by the Internet Society or its successors or > assigns. > > This document and the information contained herein is provided > on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET > ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR > IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE > OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY > IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A > PARTICULAR PURPOSE." > > >The IESG has threatened to start enforcing this rule "sometime soon"; >it is probably just good planning to start including this notice in >your internet-drafts destined for the standards track now. > >If your local legal eagles require paperwork in order for you to write >this, you'd better start working on it, too. >We haven't yet gotten around to sending out little pieces of dead tree >for you to scratch using colored implements, but it's not inconcievable >that it will happen. > >I suggest placing it in a separate section, just after the >"security considerations" section, but before the "Authors' address" >section, entitled "Copyright". It's enough boilerplate that you >don't want to put this on the "front page". > >Comments? > > Harald A > > > > 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 From ipp-archive Thu Oct 9 14:13:45 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA18040 for ipp-outgoing; Thu, 9 Oct 1997 14:08:47 -0400 (EDT) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: IPP> Client usage of TCP port number selection Date: Thu, 9 Oct 1997 11:06:21 -0700 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk I think we could include these rules into the model document, and echoed to the protocol document, if need be, for emphasis. The following steps would be taken, in order, to determine what port number should be used to contact an IPP server 1. If the protocol scheme for the URI allows the port number to be explicity included in the URI string, and an explicit port number is specified, then that port number MUST be used by the client to contact the IPP server. 2. If the protocol scheme for the URI does not allow an explicit port number specification, then the default port number for the protocol should be used. 3. Consult the appropriate IPP protocol mapping document to determine alternamte port numbers for the protocol specified in the server URI. Comments? Randy From ipp-archive Thu Oct 9 15:18:45 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA18701 for ipp-outgoing; Thu, 9 Oct 1997 15:14:15 -0400 (EDT) Message-Id: <199710091913.PAA05755@spot.cs.utk.edu> X-Mailer: exmh version 2.0gamma 1/27/96 X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Harald.T.Alvestrand@uninett.no cc: find@bunyip.com, ietf-calendar@imc.org, ipp@pwg.org, directorate@apps.ietf.org, moore@cs.utk.edu Subject: IPP> Re: Content-disposition: A better place for command verbs? In-reply-to: Your message of "Thu, 09 Oct 1997 14:06:10 +0200." <5918.876398770@dale.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 09 Oct 1997 15:13:44 -0400 Sender: ipp-owner@pwg.org Precedence: bulk > I know that several of you are quite far along the track already, and may > not want to rethink the usage you make of MIME types, but I think it's worth > spending at least 3 minutes thinking about where you put the "command verb". Let's see...how many possible ways of dispatching email things do we have: 1. content-type 2. parameters of content-types 3. content-disposition keyword (as proposed here) 4. the portion of the filename after the '.' 5. using different email addresses for different purposes 6. using different subaddresses of a single email address 7. using a directory entry to indicate which email address is used for which purpose 8. SRV records (just for completeness...please, let's not go there) Any more? This seems like plenty... It would be nice to have some shared idea of which of these should never be used, and when to use those that remain. Given that we have so many ways to dispatch things already, I'm inclined to think that this new proposal is of marginal value. Keith From ipp-archive Thu Oct 9 15:23:46 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA18718 for ipp-outgoing; Thu, 9 Oct 1997 15:20:55 -0400 (EDT) Message-Id: <3.0.1.32.19971009120648.00ca0100@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 9 Oct 1997 12:06:48 PDT To: "Turner, Randy" , "'ipp@pwg.org'" From: Carl-Uno Manros Subject: Re: IPP> Client usage of TCP port number selection In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Randy, I do not have any problem in formulating the requirements like you have stated, but I have a couple of questions: 1) Are there any URI schemes that do NOT allow you to specify a port number as part of the URI (just a wording question)? 2) I hope that we are not in conflict with the HTTP 1.1 spec if we allow an HTTP server, providing IPP service, NOT to support the HTTP default port 80. A couple of quotes from RFC 2068: "The default port is 80, but other ports can be used." "If the port (in the URI) is empty or not given, port 80 is assumed." This seems to indicate that an HTTP 1.1 server MAY be allowed to ONLY listen to another port number, which I believe was the new part of Randy's proposal. Carl-Uno At 11:06 AM 10/9/97 PDT, Turner, Randy wrote: > >I think we could include these rules into the model document, and echoed >to the protocol document, if need be, for emphasis. The following steps >would be taken, in order, to determine what port number should be used >to contact an IPP server > >1. If the protocol scheme for the URI allows the port number to >be explicity included in the URI string, and an explicit port number >is specified, then that port number MUST >be used by the client to contact the IPP server. > >2. If the protocol scheme for the URI does not allow an >explicit port number specification, then the default port >number for the protocol should be used. > >3. Consult the appropriate IPP protocol mapping document to > determine alternamte port numbers for the protocol specified > in the server URI. > >Comments? > >Randy > > > > > > > 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 From ipp-archive Thu Oct 9 15:48:50 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA19974 for ipp-outgoing; Thu, 9 Oct 1997 15:48:20 -0400 (EDT) Date: Thu, 9 Oct 1997 12:51:49 PDT From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9710091951.AA17622@snorkel.eso.mc.xerox.com> To: ipp@pwg.org, jmp@pwg.org, pmp@pwg.org Subject: IPP> FW: Harald's note on Internationalization Policy Sender: ipp-owner@pwg.org Precedence: bulk Hi folks, Thursday (9 October 1997) With Harald Alvestrand's kind permission, I am forwarding to the IPP, JMP, and PMP lists his reply to my recent question about the timeframe for adoption of the IETF Policy on Character Sets and Languages (which Harald presented at the IETF Plenary in Munich in August). I have also forwarded my original note to Harald last week (for context). As Harald makes clear, expect to have to give adequate answers for all IETF-chartered projects to the requirements stated in Harald's policy, which may be found at "ftp://ds.internic.net/Internet-Drafts" as "draft-alvestrand-charset-policy-01.txt" Please note that the Printer MIB v2 is NOT exempt from compliance with this policy on internationalization of text strings. Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc PO Box 221 Grand Marais, MI 49839 906-494-2434 >----------------------------------------------------------------------< >From: Harald.T.Alvestrand@uninett.no >To: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) >Cc: hastings@cp10.es.xerox.com >Subject: Re: Timeframe of adoption for IETF Charset/Language Policy? >In-Reply-To: Your message of "Tue, 30 Sep 1997 08:45:55 PDT." >Date: Thu, 9 Oct 1997 08:10:59 PDT > >Ira, >I hope to have the rules in force some time in November. >It'll be safe to assume that I'll be asking the questions of >protocols before that time, too. > >I've got the printing MIBs and things on my list of things to check >(which unfortunately is long). I won't forget, but may be late.... > > Harald A >----------------------------------------------------------------------< >>Date: Tue, 30 Sep 97 11:45:55 EDT >>From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) >>To: Harald.T.Alvestrand@uninett.no, >> hastings@cp10.es.xerox.com, imcdonal >>Subject: Timeframe of adoption for IETF Charset/Language Policy? >> >>Hi Harald, Tuesday (30 September 1997) >> >>I just read your second draft ('...policy-01.txt') of the IETF >>Charset/Language policy. It is EXCELLENT work. >> >>I'm wondering if you could characterize the timeframe when you >>expect (or hope) for adoption of this policy (and presumably >>publication as an RFC). >> >>The PWG (Printer Working Group) members are working on three >>projects which would be affected by this policy (and the need >>for waivers for non-conformance for protocols entering OR >>advancing upon the IETF 'standards track'): >> >>Printer MIB v2.0 (updates RFC 1759) >>- clearly deficient, as numerous read-only and read-write >> descriptive text strings are entirely without labels for >> charset OR language >>- would NOT be permitted to advance to Draft Standard, if >> subject to the IETF's policy >> >>Job MIB v0.86 (latest of six I-Ds) >>- since it intends to cohere with IPP and Tom Hastings edits >> this MIB, it can safely be assumed to meet the IETF policy >> before completion >>- I'm aware that you and Keith Moore have stated that this >> is NOT a chartered IETF project, nonetheless, the PWG's >> Job Mon MIB working group are following IETF SMIv2 and >> other applicable rules >> >>Internet Print Protocol v1.0 (still in late I-D stage) >>- I'm delighted to point out to you that two weeks ago >> the IPP working group decided to add 'charset/language' >> prefixes (in the style of RFC 2184) to EACH operation >> and/or object attribute of datatype 'text' or 'name' >>- We are also working to make sure that documents sent >> directly (ie, PrintJob) or by reference (ie, SendURI) >> are labelled (EXTERNALLY) with 'document-format' (a >> MIME 'media-type') and 'document-language' (RFC 1766 tag). >> >>Cheers, >>- Ira McDonald (outside consultant at Xerox) >> High North Inc >> PO Box 221 >> Grand Marais, MI 49839 >> 906-494-2434 From ipp-archive Thu Oct 9 15:48:52 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA19955 for ipp-outgoing; Thu, 9 Oct 1997 15:47:25 -0400 (EDT) Message-Id: <3.0.1.32.19971009123321.00c6bd60@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 9 Oct 1997 12:33:21 PDT To: Roger K Debry , From: Carl-Uno Manros Subject: IPP> Re: Comments on Requirements document Cc: In-Reply-To: <5030100010589501000002L012*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Roger, Thanks for actually taking the time to go over the Requirements document in the light of later events. I think that the proposals you have made for improvements are all contructive and useful. We need to find out from Don if he has any chance to actually work them into the document before our next I-D delivery deadline, which is next Wednesday October 15. Comments from anybody else on this? Carl-Uno At 09:27 AM 10/9/97 PDT, Roger K Debry wrote: >I apologize for not being able to participate much recently in the conference >calls. I've just been terriibly busy with my day job and have been traveling a >lot. I did sit down and review the requirements document while on the plane >this week. Here are my comments: > >o I think it would be good to have something in the introductory text >explaining our rationale for determining what were version 1.0 IPP >req'ts. In particular, I think some words of the tone that our goal was >to hit the 80% mark quickly and that rapid deployment was a >major objective, would be important things to say. Otherwise it is >hard to understand why some things aren't considered valid req'ts >for version 1.0. > >o In the terminology section, the discussion is cast in terms of an >overall internet printing solution. I think this is fine, and as it should >be. However, a sentence or two simply explicitly saying that IPP is >but one key component of an internet printing solution would seem >important. Then going on to say how things like locating printers and >creating printer instances is enabled by IPP seems to work better. > >o The latter part of the first paragraph in section I and the second >paragraph seem to be too Browser-centric. I think these could be >deleted altogether, or based on the previous comment simply say >that HTTP, and Web Browsers are **other** components of a >complete internet printing solution. As it stands, one could easily >come away believing that IPP running on a browser is a major >requirement of IPP. > >o I think the third paragraph of section I is slightly misleading. >While it says that "No assumption is made about multi-tiered >printing solutions", it does not make clear that such solutions >are in fact supported by the protocol. I think as written, it might >leave the reader believing server congurations are not >supported. Just a few word changes would fix this. > >o Section 2 introduces the three user roles, end-user, operator, >and adminsitrator. Although we say it elsewhere, I think it important >to say right here that only end-user functions are considered as >version 1.0 requirements. > >o In the second paragraph of section 1.2, I'd spell out the six >categories more carefully. For example, finding/locating should >be finding/locating a printer, local instance should be creating >a local isntance of a printer, etc. > >o Add the phrase "by their IPP attributes" to the last sentence >of section 2.1.1. > >o In the last set of bullets in section 2.1.3, I'd suggest taking out the >sentence that begins "When checking the status on jobs ...". Also >take out the last bullet, how are job priorities assigned. I don't think >there is anything in IPP that describes **HOW** priorities are >assigned. I think this would read better with these changes and >better reflect actual usage. > >o I think section 2.1.4 needs some work. I believe we defined three >distinct usages: Printing from an application, which places a req't on >the protocol to support streaming, pushing a previously created file, >and print by reference (pull). The simple push case doesn't get >covered as this section is written. > >Also, the second paragraph seems confusing and I am not sure it >adds much to the document. In any case, the three bullets listed here >are all outside the scope of IPP. I believe that everything that needs to >be said in terms of requirements here is said in the following paragraphs. > >o In the second paragraph of section 2.1.6, the second sentence begins >"New notification means ...". I don't think the word New is required here. > >o In section 2.1.6, I would prefer that we say changing job properties or >changing job attributes, instead of Altering the print job. > >o Section 4 would seem to better fit before section 3. Thus all of the >general discussion of requiremetns comes first, then the high level >scenarios, then the datailed scemarios comes last. > >o In section 3.0, there is quite some discussion of the three physical >environments supported in the scenarios. In fact, the physical >environments are quite transparent and aren't discussed in any >way in any of the scenarios. If it is appropriate to keep these three >models in the requirements document, then I'd suggest that this >discussion be moved to section 1.o and replace or supplement >the third paragraph in section 1 which says that "No assumption >is made about multi-tiered environments." > >Also, we long ago decided to get rid of the notion of inside and >outside of firewalls in the security document. I'd suggest taking >this discussion out of section 3 and supplementing the security >discussion in paragraph 4.1. > >o Replace section 4.1 with the following (from the security ID): > >It is required that the Internet Printing Protocol be able to operate >within a secure environment. Wherever possible, IPP ought to make >use of existing security protocols and services. IPP will not invent new >security features when the requirements described in this document >can be met by existing protocols and services. Examples of such >services inlcude Transport Layer Security (TLS) and HTTP Digest >Authentication. > >Since we cannot anticipate the security levels or the specific threats >that any given IPP print administrator may be concerned with, IPP >must be capable of operating with different secuity mechanisms and >policies as required by the individual installation. The initial security >needs of IPP are derived from two primary considerations. First, the >printing environments describes in this document take into account >that the client, the Printer, and the document to be printed may all exist >in different security domains. When objects are in different security >domains the requirements for authentication and message protection >are much stronger than when they are all in the same domain. > >Secondly, the sensitivity and value of the content being printed will >vary from one instance of a print job to another. For example, a >publicly available document does not need the same level of >protection as a payroll document does. Message protection >requirements include data origin authentication, privacy, integrity, >and non-repudiation. > >o In section 8, the appendix, you should preface this entire section >with the caveat that these scenarios describe internet printing >applications, which are **enabled** with IPP, and that many of the >flows shown are not actually within the scope of IPP. Also, you >should mention that many of the IPP flows are beyond the scope of >version 1.0. > > >Roger K deBry >Senior Technical Staff Member >Architecture and Technology >IBM Printing Systems >email: rdebry@us.ibm.com >phone: 1-303-924-4080 > > 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 From ipp-archive Thu Oct 9 15:58:53 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA20275 for ipp-outgoing; Thu, 9 Oct 1997 15:56:00 -0400 (EDT) Date: Thu, 9 Oct 1997 12:48:52 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199710091948.MAA10063@woden.eng.sun.com> To: hastings@cp10.es.xerox.com, masinter@parc.xerox.com Subject: Re: IPP> Re: MOD - RESEND: Proposal for IPP to meet IESG Language and CharSet requirements Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk > From masinter@parc.xerox.com Wed Oct 8 16:45:25 1997 > > > For example, 'application/octet-stream' > > and 'application/vnd.hp-PCL'. While PCL has an optional instruction > > inside the document data that specifies the codeset, it is optional, > > even when the codeset is different from US-ASCII (or HP Roman-8). > > For 'application/vnd.hp-PCL': if it is necessary to know the codeset > in order to properly interpret application/vnd.hp-pcl, then the > definition of application/vnd.hp-pcl is deficient. If you can't > convince HP to fix their registration, you could register an > alternative value. It may well be that the range of available > 'codeset' for some printer types is different than the range > of registered Internet 'charset' values; after all, 'charset' > combines both the coded character set and the encoding scheme, > while some printer languages may employ a different mechanism > for mapping between embedded integers and visual representations. > I'm no expert in PCL, but I understand that PCL contains command (escape codes) in US-ASCII that tell the PCL interpreter how to interpret subsequent octets. So effectively, PCL is a binary octet stream which the PCL interpreter can process. Thus there is no need to specify a character set and in fact a PCL file could contain two character sets, e.g. US-ASCII followed by UCS-2. From ipp-archive Thu Oct 9 16:48:47 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA22338 for ipp-outgoing; Thu, 9 Oct 1997 16:47:40 -0400 (EDT) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: RE: IPP> Client usage of TCP port number selection Date: Thu, 9 Oct 1997 13:46:14 -0700 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk > -----Original Message----- > From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] > Sent: Thursday, October 09, 1997 12:07 PM > To: Turner, Randy; 'ipp@pwg.org' > Subject: Re: IPP> Client usage of TCP port number selection > > Randy, > > I do not have any problem in formulating the requirements like you > have > stated, but I have a couple of questions: > > 1) Are there any URI schemes that do NOT allow you to specify a port > number > as part of the URI (just a wording question)? [Turner, Randy] Yes, the potential definitely exists; but if the protocol is well defined and TCP/IP is a used, then the protocol should have a TCP port defined for it, in which case rule #2 from my original mail message would be used to determine the server port number. > 2) I hope that we are not in conflict with the HTTP 1.1 spec if we > allow an > HTTP server, providing IPP service, NOT to support the HTTP default > port 80. [Turner, Randy] These rules do not preclude this. I think it was Ira that stated (correctly) that all HTTP 1.1 servers must support 80, but may support other port numbers, like your quote from 2068 says. This scenario is covered by following my proposed rules, in order. > A couple of quotes from RFC 2068: > "The default port is 80, but other ports can be used." > "If the port (in the URI) is empty or not given, port 80 is assumed." > > This seems to indicate that an HTTP 1.1 server MAY be allowed to ONLY > listen to another port number, which I believe was the new part of > Randy's > proposal. > > Carl-Uno > > At 11:06 AM 10/9/97 PDT, Turner, Randy wrote: > > > >I think we could include these rules into the model document, and > echoed > >to the protocol document, if need be, for emphasis. The following > steps > >would be taken, in order, to determine what port number should be > used > >to contact an IPP server > > > >1. If the protocol scheme for the URI allows the port number to > >be explicity included in the URI string, and an explicit port number > >is specified, then that port number MUST > >be used by the client to contact the IPP server. > > > >2. If the protocol scheme for the URI does not allow an > >explicit port number specification, then the default port > >number for the protocol should be used. > > > >3. Consult the appropriate IPP protocol mapping document to > > determine alternamte port numbers for the protocol specified > > in the server URI. > > > >Comments? > > > >Randy > > > > > > > > > > > > > > > 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 From ipp-archive Thu Oct 9 22:03:49 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA23361 for ipp-outgoing; Thu, 9 Oct 1997 22:01:13 -0400 (EDT) Date: Thu, 9 Oct 1997 19:09:00 -0700 (PDT) From: papowell@astart.com Message-Id: <199710100209.TAA06077@astart4.astart.com> To: ipp@pwg.org, jkm@underscore.com Subject: Re: IPP> Proposal for IPP to meet IESG Language/CharSet requirements Cc: masinter@parc.xerox.com, Ned.Freed@innosoft.com, rturner@sharplabs.com Sender: ipp-owner@pwg.org Precedence: bulk > From jkm@underscore.com Thu Oct 9 08:56:53 1997 > Date: Thu, 09 Oct 1997 11:28:23 -0400 > From: Jay Martin > To: ipp@pwg.org > CC: rturner@sharplabs.com, Ned Freed , > Larry Masinter > Subject: Re: IPP> Proposal for IPP to meet IESG Language/CharSet requirements > > This is a multi-part message in MIME format. > --------------578C7E2551A60BAD272EADE4 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > Randy's comments are right on the mark, IMHO. > > The printer industry has been successfully dealing with auto-sensed > data for quite sometime now. It should make no difference what the > official MIME type is, whether it be "application/octet-string" or > "something/go-fish". A rose by any other color, etc... > > Perhaps I'm missing something here, but it seems painfully obvious > to me that we have put a big stake in the ground to support legacy > printing systems as part of the philosophy/strategy of wide-scale > IPP deployment. As such, auto-sensing is absolutely mandatory to > for the interoperable implementations to succeed. > > The less baggage we attach to the auto-sense situation, the better. > It just seems that the rest of the world has long embraced the MIME > type "application/octet-stream" to be "unknown type, go fish", and > I don't understand why we can't follow that lead. (Sorry if I'm > not up on the latest, greatest IETF trends in this area.) > > ...jay > I agree with this: the application/octet-string is an obvious choice for "I dunno what this is, but can you print it?" Patrick Powell From ipp-archive Thu Oct 9 22:48:50 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA24017 for ipp-outgoing; Thu, 9 Oct 1997 22:48:03 -0400 (EDT) Message-Id: <1.5.4.32.19971010024516.006893f0@pop3.holonet.net> X-Sender: cumanros@pop3.holonet.net X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 09 Oct 1997 19:45:16 -0700 To: ipp@pwg.org From: The IESG (by way of Carl-Uno Manros ) Subject: IPP> Last Call: Augmented BNF for Syntax Specifications: ABNF to Proposed Standard Sender: ipp-owner@pwg.org Precedence: bulk FYI, The ABNF has now gone to the IETSG, so we should be OK to reference that when we show up at the IESG with our texts. Carl-Uno --- The IESG has received a request from the Detailed Revision/Update of Message Standards Working Group to consider Augmented BNF for Syntax Specifications: ABNF as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by October 23, 1997. Files can be obtained via ftp://ds.internic.net/internet-drafts/draft-ietf-drums-abnf-04.txt From ipp-archive Fri Oct 10 02:08:52 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA24906 for ipp-outgoing; Fri, 10 Oct 1997 02:08:25 -0400 (EDT) Date: Thu, 09 Oct 1997 22:53:33 -0700 (PDT) From: Ned Freed Subject: Re: IPP> Re: MOD - RESEND: Proposal for IPP to meet IESG Language and CharSet requirements In-reply-to: "Your message dated Thu, 09 Oct 1997 09:58:14 -0700 (PDT)" <3.0.1.32.19971009095814.00bac100@garfield> To: Carl-Uno Manros Cc: Ned Freed , Larry Masinter , Tom Hastings , ipp@pwg.org Message-id: <01IOMC4YSX8S9JD5JJ@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii References: <01IOL0HKRCLI9JD7O7@INNOSOFT.COM> Sender: ipp-owner@pwg.org Precedence: bulk > FYI, many existing proprietary products successfully supports the > auto-detection feature. It may obviously not always work, but works most of > the time. FYI, several existing proprietary mail systems use private labelling methodologies in RFC822 messages rather than MIME. The nature of these systems is such that they obviously don't always work, but they do work much of the time. (GTW, even when they don't work, the result is fairly harmless. The same thing cannot be said of auto-detect failures on printers...) And guess what? Some of these were part of the original MIME specification. Heck, at least one of them was presented as an alterative of MIME. But there isn't a trace of any of them in any standards-track IETF document right now. There are some informational and experimental RFCs but that is all. Why is this the case? Because had they been included the specification that included them would have never made it to draft standard. > A scenario where this is very helpful, is if the user gets a file > of some unknown file type e.g. as attachment in a message or found on a web > page and wants to attempt printing it. In another scenario, a user might > know that a file is Postscript, but not whether it is Postscript 1, 2 or 3. > The auto-sensing can often help sort that out once the file arrives at the > printer. I'm well aware that auto-detect mechanisms are widely used today -- in fact I've developed print spooling software myself that does this. And I'm well aware that that this can work -- most of the time, that is. But unless I'm mistakem, this WG is trying to develop a standard. And when you build a standard, most of the time just isn't good enough. I will also reiterate that I see no problem with having an informational supplement that describes this approach. > We obviously do not want to make IPP less powerful than existing products > in this respect. It seems to me though, that we should define our own MIME > type for a document file that we want to have auto-sensed. On the contrary, I think you absolutely do want to, at least insofar as standards track documents are concerned. If you want to have an informational document describing this, that's fine. But In any case, I've said my piece. If this WG wants to include this sort of thing in their documents, that's fine. But don't be surprised when objections are raised that cause the documents to get tossed back at you for revision later on. Ned From ipp-archive Fri Oct 10 03:03:53 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id DAA25562 for ipp-outgoing; Fri, 10 Oct 1997 03:00:56 -0400 (EDT) Message-ID: <343DD23D.64444344@parc.xerox.com> Date: Thu, 9 Oct 1997 23:59:09 PDT From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: Ira Mcdonald x10962 CC: ipp@pwg.org Subject: IPP> Re: MOD - Proposed application/ipp registration text References: <9710090054.AA17254@snorkel.eso.mc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk I think that the IANA registration for application/ipp should just be part of the protocol suite, and that you shouldn't try to register it before the draft(s) get approved. I think the definition of the charset paramter you've given is pretty confusing. A parameter definition just says what the parameter means and what the allowable range of values are. But the definition you give is full of stuff about the IPP protocol and rules contained in it. If you can't define a media type independent of the protocol by which it is transported, then it's pretty suspect as a MIME media type; the whole point of 'media type' is to make the information objects independent of their transport. > IPP/1.0 keywords (eg, attribute names) are encoded in US-ASCII and > US-English. You mean 'Keywords within application/ipp bodies'? > IPP/1.0 string attributes of syntax "text" or "name" > MAY have values in ANY character set and language, and MUST use > "charset/language" prefixes, via the method specified in RFC 2184. Well, while this is interesting, why is it important to repeat this little bit of the application/ipp media type rules inside the registration of the charset parameter? > The required "charset" parameter of the "application/ipp" MIME > media type MUST be used to specify the default to use when the > "charset" of a "charset/language" prefix is empty (ie, a single > quote character). I think it's odd to make "what something is used for" to be mandatory. You just mean it the other way around. The default is from the charset parameter. The parameter is mandatory. All of this MUST-ing and SHOULD-ing really just gets in the way. > IPP/1.0 protocol requests and responses MUST > use a Content-Language header to specify a default to use when the > "language" of a "charset/language" prefix is empty (ie, a single > quote character). This is very confusing in a media type registration. It's not just 'IPP/1.0 protocol requests and responses', is it? It's any mechanism used to transport this media type MUST specify a default language, too. > IPP/1.0 protocol requests and responses MAY contain long lines and > MUST always contain binary data and therefore MUST be encoded > using Content-Transfer-Encoding: binary. You're saying 'IPP/1.0 protocol requests' rather than 'application/ipp bodies' again. And "COntent-Transfer-Encoding" is appropriate for mail and not for HTTP transport. I think you mean 'must be transfered using an encoding appropriate for the protocol and binary data'. At some point in the earlier life of IPP, it made sense to think about mailing an application/ipp print request to a printer, as a way of initiating a print job. > Security considerations: > > IPP/1.0 requests and responses MAY be secured via the use of a > transport layer security protocol (below HTTP/1.1). No, 'security considerations' doesn't mean 'encryption used'. What it is used for is "what risks are entailed by accepting one of these bodies and trying to interpret it?". For example, application/postscript has a security consideration that some postscript programs could maliciously delete files on your print system or tie up your printer or otherwise do harm unless you're careful. What attacks could be mounted by a print client onto a print server, and what have you done to protect against them? > Interoperability considerations: > > IPP/1.0 Printer objects (ie, servers) MUST support the attributes > "printer-charset-supported" (MAY be multi-valued) and > "printer-natural-language-supported" (MAY be multi-valued), to > facilitate interoperability with IPP/1.0 clients. Is there an interoperability considerations section in a media type registration? Is this new? What are you trying to say here? > Intended usage: > > COMMON Actually, no, the intended use of application/ipp is with a very narrow domain: within an implementation of IPP that tries to bundle a request/response protocol inside a MIME object body and tunnel it through using HTTP. So, it's a narrow intended use, and you probably should say so. Regards, Larry -- http://www.parc.xerox.com/masinter From ipp-archive Fri Oct 10 03:28:53 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id DAA26196 for ipp-outgoing; Fri, 10 Oct 1997 03:26:49 -0400 (EDT) Message-ID: <343DD89D.58796710@parc.xerox.com> Date: Fri, 10 Oct 1997 00:26:21 PDT From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: Carl-Uno Manros CC: "Turner, Randy" , "'ipp@pwg.org'" Subject: Re: IPP> Client usage of TCP port number selection References: <3.0.1.32.19971009120648.00ca0100@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk > I hope that we are not in conflict with the HTTP 1.1 spec if we allow an > HTTP server, providing IPP service, NOT to support the HTTP default port 80. It's done all the time. From ipp-archive Fri Oct 10 03:38:53 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id DAA26215 for ipp-outgoing; Fri, 10 Oct 1997 03:35:24 -0400 (EDT) X-Mailer: exmh version 1.6.9 8/22/96 From: Harald.T.Alvestrand@uninett.no To: Tom Hastings cc: fyergeau@alis.com, Keith Moore , ipp@pwg.org Subject: IPP> Re: MOD - Comment on RFC 2044: need to specify the ISO 10646 conformance level In-reply-to: Your message of "Wed, 08 Oct 1997 21:52:15 PDT." <3.0.1.32.19971008215215.00f613b0@garfield> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 10 Oct 1997 09:34:54 +0200 Message-ID: <9611.876468894@dale.uninett.no> Sender: ipp-owner@pwg.org Precedence: bulk Tom, actually I think the conformance levels are a Bad Thing. According to 10646-1:1993, the conformance is a bit different than you say: level 1 says to avoid combining characters and the HANGUL JAMOS block, level 2 says to avoid a specific, short list of 30 combining characters, including things like the IDEOGRAPHIC LEVEL TONE MARK (don't ask me!) and the COMBINING CYRILLIC PALATALIZATION, while level 3 says that you have to do all of it. (My sneaking suspicion is that these 30 are marks that are commonly used together with other marks on the same character, but the standard is silent on this point; Greek, for instance, commonly uses > 1 accent on letters, and the standard doesn't say "no double diacritics". Would you believe the (precomposed) Greek letter U+0390, GREEK SMALL LETTER IOTA WITH DIALYTICA AND TONOS?) The Unicode standard, version 2.0, seems to say nothing about levels. All of these levels are requirements on the sender: Don't send certain characters. I, like you, believe that a 10646 usage that uses NO combining characters is simply Not The Right Thing. And wrt the 30 characters not allowed in The recipient is already allowed to do "magic" whenever unrecognized characters are encountered; telling him to include the code for ignoring unrecognized diacritcs is not a big deal, and allowing him to skip the code for handling 30 more "unrecognized" diacritics is simply not worth it. The coding of comparator functions is another, and complex matter; it is with good reason that I'm far from explicit about this in the policy document. And comparision is not a tagging function, but and end-system operation function; that's why I thought I could get away with it. (of course, protocols that require comparision of values and don't address this problem are deficent - but we're not at a point where we can make policy for those problems. See the ACAP protocol for one example of language trying to address the issue) BTW, the mailing list for discussion of the character set policy is ietf-charsets@innosoft.com; mail to ietf-charsets-request@innosoft.com to be added. Harald A From ipp-archive Fri Oct 10 10:23:57 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA27662 for ipp-outgoing; Fri, 10 Oct 1997 10:21:34 -0400 (EDT) From: don@lexmark.com Message-Id: <199710101421.AA08954@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: cmanros@cp10.es.xerox.coM Cc: ipp@pwg.org Date: Fri, 10 Oct 1997 10:21:06 -0400 Subject: IPP> Re: REQ - Requirements Document Issues Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Precedence: bulk Here are the actions and responses to Carl-Uno's suggestions for the Requirements document.... >Not to keep you in suspense any longer, here are a number of things that I >found, while scanning through the latest version of the requirements document: >Page 6: > >Users want to limit the scope of their search when locating a printer: >- inside a functional sub-domain >- include only a particular domain >- exclude specified domains > >We have no Directory or Printer attributes defined to support this. "Outside the scope" statement added; >Page 13: > >Printer discovery: >- cost per page to print [also in several other places] >- maximum job size (spool size) >- payment required for printing >- printer supports compression > >We have no Directory or Printer attributes to support this. "Outside the scope" statement added >Page 15: > >We talk about "marking technology" here [and in various other places]. > >We have "printer description" which might include this in text form, but no >explicit Printer attribute, which tells whether a printer is ink-jet, >laser, etc. Deleted >Page 22: > >Select printer based on: >- usable by department J15 > >We do not have an explicit Directory or Printer attribute for this. You >could use some authorization mechanism to achieve this, but it seems a bit >farfetched. Changed to "- accessible by the client" >Page 24: > >Select a printer based on: >- is a public printer (accessible from outside a firewall) > >We have no explicit Directory or Printer attribute to support this. The >presence of a "printer-tls-uri" attribute might give a hint about this, but >does not have this semantic. Deleted "accessible from outside a firewall" >Page 26: > >Printer discovery: > >- Is in Downtown Boulder >- Give me the Printer's public key > >Although we have an unstructured Printer location attribute, is it likely >that we can do this kind of match? > >We do not have a Directory attribute for the Printer's public key. Change "Downtown Boulder" to just Boulder Colorado Deleted "Give me the Printer's public key" >Page 51: > >Searching for printers: > >- takes my VISA card >- gives me a rough cost per page > >We have a generic text Printer attribute for printer description, but can >you request and search on it? > >We have no Directory or Printer attribute to support this. Removed ------------ Don ********************************************** * Don Wright don@lexmark.com * * Manager, Strategic Alliances and Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-archive Fri Oct 10 10:23:58 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA27673 for ipp-outgoing; Fri, 10 Oct 1997 10:21:52 -0400 (EDT) From: don@lexmark.com Message-Id: <199710101420.AA08903@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: rdebry@us.ibm.com Cc: Cmanros@Cp10.Es.Xerox.Com, Ipp@Pwg.Org Date: Fri, 10 Oct 1997 10:19:58 -0400 Subject: IPP> Re: Comments on Requirements document Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@Pwg.Org Precedence: bulk Here are my comments and actions on Roger's suggestions >o I think it would be good to have something in the introductory text >explaining our rationale for determining what were version 1.0 IPP >req'ts. In particular, I think some words of the tone that our goal was >to hit the 80% mark quickly and that rapid deployment was a >major objective, would be important things to say. Otherwise it is >hard to understand why some things aren't considered valid req'ts >for version 1.0. I don't think this is appropriate in a requirements document. The model or rationale document would be a better place to say this. Saying something like "hitting 80% of the end-user requirements is a goal of the first implementation" sounds like a cop-out to me. This document lays out the requirements and the implementation can make an informed decision about what to include in the first release. Remember, this is NOT suppose to be a design specification but rather a requirements document. >o In the terminology section, the discussion is cast in terms of an >overall internet printing solution. I think this is fine, and as it should >be. However, a sentence or two simply explicitly saying that IPP is >but one key component of an internet printing solution would seem >important. Then going on to say how things like locating printers and >creating printer instances is enabled by IPP seems to work better. OK, added >o The latter part of the first paragraph in section I and the second >paragraph seem to be too Browser-centric. I think these could be >deleted altogether, or based on the previous comment simply say >that HTTP, and Web Browsers are **other** components of a >complete internet printing solution. As it stands, one could easily >come away believing that IPP running on a browser is a major >requirement of IPP. OK, added >o I think the third paragraph of section I is slightly misleading. >While it says that "No assumption is made about multi-tiered >printing solutions", it does not make clear that such solutions >are in fact supported by the protocol. I think as written, it might >leave the reader believing server congurations are not >supported. Just a few word changes would fix this. OK, changed >o Section 2 introduces the three user roles, end-user, operator, >and adminsitrator. Although we say it elsewhere, I think it important >to say right here that only end-user functions are considered as >version 1.0 requirements. This is not needed again here. It is stated multiple times in the document and is in fact stated in the immediately preceding paragraph >o In the second paragraph of section 1.2, I'd spell out the six >categories more carefully. For example, finding/locating should >be finding/locating a printer, local instance should be creating >a local isntance of a printer, etc. OK >o Add the phrase "by their IPP attributes" to the last sentence >of section 2.1.1. OK >o In the last set of bullets in section 2.1.3, I'd suggest taking out the >sentence that begins "When checking the status on jobs ...". Also >take out the last bullet, how are job priorities assigned. I don't think >there is anything in IPP that describes **HOW** priorities are >assigned. I think this would read better with these changes and >better reflect actual usage. I have reworded those two sets of bullets. >o I think section 2.1.4 needs some work. I believe we defined three >distinct usages: Printing from an application, which places a req't on >the protocol to support streaming, pushing a previously created file, >and print by reference (pull). The simple push case doesn't get >covered as this section is written. OK >Also, the second paragraph seems confusing and I am not sure it >adds much to the document. In any case, the three bullets listed here >are all outside the scope of IPP. I believe that everything that needs to >be said in terms of requirements here is said in the following paragraphs. Added a note that they are outside the scope of the IPP protocol >o In the second paragraph of section 2.1.6, the second sentence begins >"New notification means ...". I don't think the word New is required here. "New" deleted >o In section 2.1.6, I would prefer that we say changing job properties or >changing job attributes, instead of Altering the print job. 2.1.6 was previously changed to use the "cancel" concept rather than "alter." The only reference to "alter" is the statement: "Altering the print job itself is not a V1.0 requirement." >o Section 4 would seem to better fit before section 3. Thus all of the >general discussion of requiremetns comes first, then the high level >scenarios, then the datailed scemarios comes last. OK, but I won't mark the whole section as changed. >o In section 3.0, there is quite some discussion of the three physical >environments supported in the scenarios. In fact, the physical >environments are quite transparent and aren't discussed in any >way in any of the scenarios. If it is appropriate to keep these three >models in the requirements document, then I'd suggest that this >discussion be moved to section 1.o and replace or supplement >the third paragraph in section 1 which says that "No assumption >is made about multi-tiered environments." OK, I moved this into the TERMINOLOGY section. >Also, we long ago decided to get rid of the notion of inside and >outside of firewalls in the security document. I'd suggest taking >this discussion out of section 3 and supplementing the security >discussion in paragraph 4.1. I have removed it from the old section 3. >o Replace section 4.1 with the following (from the security ID): > >It is required that the Internet Printing Protocol be able to operate >within a secure environment. Wherever possible, IPP ought to make >use of existing security protocols and services. IPP will not invent new >security features when the requirements described in this document >can be met by existing protocols and services. Examples of such >services inlcude Transport Layer Security (TLS) and HTTP Digest >Authentication. > >Since we cannot anticipate the security levels or the specific threats >that any given IPP print administrator may be concerned with, IPP >must be capable of operating with different secuity mechanisms and >policies as required by the individual installation. The initial security >needs of IPP are derived from two primary considerations. First, the >printing environments describes in this document take into account >that the client, the Printer, and the document to be printed may all exist >in different security domains. When objects are in different security >domains the requirements for authentication and message protection >are much stronger than when they are all in the same domain. > >Secondly, the sensitivity and value of the content being printed will >vary from one instance of a print job to another. For example, a >publicly available document does not need the same level of >protection as a payroll document does. Message protection >requirements include data origin authentication, privacy, integrity, >and non-repudiation. I have copied this text into the document replacing section 4.1. >o In section 8, the appendix, you should preface this entire section >with the caveat that these scenarios describe internet printing >applications, which are **enabled** with IPP, and that many of the >flows shown are not actually within the scope of IPP. Also, you >should mention that many of the IPP flows are beyond the scope of >version 1.0. OK --------------- Don ********************************************** * Don Wright don@lexmark.com * * Manager, Strategic Alliances and Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-archive Fri Oct 10 10:33:57 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA27697 for ipp-outgoing; Fri, 10 Oct 1997 10:32:08 -0400 (EDT) From: don@lexmark.com Message-Id: <199710101431.AA09450@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org Date: Fri, 10 Oct 1997 10:31:47 -0400 Subject: IPP> REQ: New Requirements Document Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Precedence: bulk I have posted a new version of the Requirements Document on the ftp server. The following files are now there.... ftp://ftp.pwg.org/pub/pwg/ipp/new_REQ/draft-ietf-ipp-req-971010-rev.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_REQ/draft-ietf-ipp-req-971010.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_REQ/draft-ietf-ipp-req-971010.txt The naming convention should be obvious. I need any last minute corrections immediately. Please remember that this is a requirements document and not a design specification. I do no believe it must exactly match the first version of the protocol. It is OK to define a set of requirements in one document and choose to implement a subset or a superset in the implementation documents. In my mind, any variations from the requirements should be specified in the implementation documents. The requirements did not change, an informed, intelligent decision was made to not address some of the requirements in the first implementation. In order to move forward with V2.0, we should not lose the original requirements by removing them from the document. In light of my previous diatribe, please don't ask me to do much more than correct a spelling or formatting error in the document. (Jay: as usual please correct my errors in the URL -- lack of sleep doesn't help in typing long lines of characters and slashes!!) Thanks! Don ********************************************** * Don Wright don@lexmark.com * * Manager, Strategic Alliances and Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-archive Fri Oct 10 10:33:58 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA27710 for ipp-outgoing; Fri, 10 Oct 1997 10:33:04 -0400 (EDT) Date: Fri, 10 Oct 1997 07:36:38 PDT From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9710101436.AA17840@snorkel.eso.mc.xerox.com> To: imcdonal@eso.mc.xerox.com, masinter@parc.xerox.com Subject: IPP> Re: MOD - Proposed application/ipp registration text Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Precedence: bulk Hi Larry, Thanks for your helpful comments. It seems to me that, from mixed signals received from Keith Moore and others, IPP will probably abandon the use of a 'charset' parameter in its MIME type and abandon any use of (or mapping to/from) Content-Language and Accept-Charset|Language headers. The 'advantages' of using HTTP/1.1 as the initial transport protocol for IPP/1.0 are contracting steadily: security (but TLS isn't finished and adopted as a standard), useful HTTP headers (but we get continuously conflicting advice from the experts about their use), conveying the target URL (but this is just one operational attribute, easily bound into the body of the IPP message itself), character set and language negotiation (but a multi-valued 'Content-Language' header has an ENTIRELY different semantic from a multi-valued 'Accept-Language' header, and the latter are optional anyway). The template that I used was copied directly from RFC 2048 (the latest MIME registration procedures). If we abandon the charset/language info in HTTP/1.1 and MIME mail headers, then the registration for 'application/ipp' can be short and simple, ie, it contains an IPP message body (a request or response). It is NOT reasonable to transfer IPP requests and their correlated responses via email - they are synchronous and have no correlators, as the model and protocol are written. Two request CANNOT be outstanding from the same client to the same server at once - while I personally question the 'simplicity' of these restrictions, they are the concensus of the IPP working group. We DO plan to register 'application/ipp' when the IPP specs are advanced, simultaneously, to the IESG/IETF. I just had the action item to write up possible text for INCLUSION in the IPP model. Thanks for your help, - Ira McDonald (outside consultant at Xerox) High North Inc 906-494-2434 From ipp-archive Mon Oct 13 01:14:37 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA02662 for ipp-outgoing; Mon, 13 Oct 1997 01:10:34 -0400 (EDT) Message-ID: <3441AD35.C02C2F78@parc.xerox.com> Date: Sun, 12 Oct 1997 22:10:13 PDT From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: Ira Mcdonald x10962 CC: ipp@pwg.org Subject: IPP> Re: MOD - Proposed application/ipp registration text References: <9710101436.AA17840@snorkel.eso.mc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk I've been thinking about this, also in the light of comments made in some other internet media type registration discussions, and I've come to the conclusion that it is probably a bad idea to rely on the 'charset' attribute of the 'application/ipp' media type *or* the content-language attribute of the enclosing MIME message. While those are the conventional ways of specifying the language and charset of media types which are not self-contained, that in fact (as was pointed out by others) it's pretty unreliable, since the MIME headers can get separated from the entity body. It's a stopgap for those types like text/plain which have no other place to put the information. Since you're defining application/ipp from scratch, this rule doesn't apply. On the other hand, it baffles me to try to construct a realistic scenario where there will be many different charset parameters for different strings in a single application/ipp message. Why not just have some part of the wrapper define the default charset for the entire message? > It is NOT reasonable to transfer IPP requests and their > correlated responses via email - they are synchronous and > have no correlators, as the model and protocol are written. Email itself has a correlator, mainly the message-id and in-reply-to link. I send you a message with a message-id, and you reply with an in-reply-to header. It's pretty clumsy, I'll admit. Larry -- http://www.parc.xerox.com/masinter From ipp-archive Mon Oct 13 13:29:46 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA04078 for ipp-outgoing; Mon, 13 Oct 1997 13:28:40 -0400 (EDT) Message-Id: <3.0.1.32.19971013103239.00cf7380@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 13 Oct 1997 10:32:39 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Updated Model sections for internationalization Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk I've posted .doc, .txt, .pdr (red rev revision), and .pdf (black revision marks) for the updates to the IPP Model document with the internationalization proposal Ira and I sent out last Tuesday that we agreed on in principle at the last Wed telecon on: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/md9709ct.* (ct for cut versions, since it only contains the sections that I changed for I18N in the 9/26/97 Model document.) The .txt is without any revision marks. Its 28 pages, so I haven't attached it to this mail message. The .pdf and .pdr files with revision marks are 24 pages long. I tried real hard not to repeat anything, but to use cross-references instead. Please send any comments before the IPP telecon, this Wednesday, 1-3pm PDT. We'll discuss this on the telecon as well. Here is the first 4 pages of the 28-page text version of the file: Subj: IPP Model with those section changed for Internationalization From: Tom Hastings Date: 10/10/97 File: md9709ct.doc This file contains only the modified sections cut from the Model document affected by the internationalization agreements that Ira and I proposed on 10/7/97 and were agreed to writeup on the 10/8/97 telecon. Therefore, there are some cross references to sections that are not in this cut version of the document. Please disregard them. They are the same as in the 9/26/97 version and will re-appear when this cut version is merged in with the rest of the document. The Table of Contents contains only the sections that are included in this document, i.e., only the sections that are affected by the proposal. The revision marks in the Table of Contents show what sections have been added or deleted and which section headings have been changed. Table of Contents 3.1.3 MANDATORY Charset and Natural Language Operation Attributes 4 3.2.1.1 Print-Job Request 7 3.2.5.1 Get-Attributes Request 8 3.2.5.2 Get-Attributes Response 9 3.2.6.2 Get-Jobs Response 10 3.3.1.1 Send-Document Request 10 3.3.3.2 Cancel-Job Response 11 4. OBJECT ATTRIBUTES 12 4.1 Attribute Syntaxes 12 4.1.1 'text' 13 4.1.2 'name' 13 4.1.3 'keyword' 14 4.1.4 'enum' 15 4.1.5 'uri' 15 4.1.6 'uriScheme' 15 4.1.7 'charSet' 15 4.1.8 'naturalLanguage' 16 4.1.9 'mimeType' 16 4.1.10 'octetString' 17 4.1.11 'boolean' 17 4.1.12 'integer' 17 4.1.13 'rangeOfInteger' 17 4.1.14 'dateTime' 17 4.1.15 'resolution' 18 4.1.16 '1setOf X' 18 4.2 Job Template Attributes 18 4.2.1 job-sheets (type4 keyword, name) 24 4.2.2.1 Event Notification Content 24 4.2.5 job-hold-until (type4 keyword, name) 25 4.2.7 media (type4 keyword, name) 26 4.2.16 document-format (mimeType) 27 4.2.21 content-charset (charSet) 61 4.2.22 content-natural-language (naturalLanguage) 28 4.3.5 job-originating-user (name) 45 7. INTERNATIONALIZATION CONSIDERATIONS 29 9. REFERENCES 31 1. 2. 3. 3.1 3.1.1 3.1.2 3.1.3 MANDATORY Charset and Natural Language Operation Attributes Some of the Job and Printer attributes have values that are text strings and names intended for human understanding rather than machine understanding. See the 'text' and 'name' attribute syntax descriptions in Sections 4.1.1 and 4.1.2. Consequently; the following MANDATORY operation attributes are defined for use in every operation request: "content-charset" (charSet): This is a MANDATORY Job Template attribute (see Section 4.2) for the client to supply and the Printer object to support. The "content-charset" attribute identifies the charset that the Printer object SHALL use for any 'text' and 'name' attributes that the Printer object generates in the operation response, such as "job-state-message", unless the Printer object does not support that charset. In such a case, the Printer object SHALL use the charset specified by the Printer's "content-charset- default" attribute instead, rather than returing an error, and SHALL prepend an explicit non-empty charset tag identifying the default charset being used in each such generated attribute value. This attribute also identifies the charset that SHALL be implied by any 'text' and 'name' attribute values with an empty charset tag supplied by the client. In create operations, the Printer object SHALL store with the Job object (1) the "content-charset" attribute and (2) any explicit attribute value charset tags, whether the Printer object supports the identified charset or not, rather than returning an error. See the 'charSet' attribute syntax description in Section 4.1.7 for the syntax of this attribute and example values. The Printer object SHALL support the 'utf-8' charset [28]. For conforming IPP Printer objects, the 'utf-8' charset value used in this attribute SHALL be restricted to mean conformance level 2 of ISO 10646 [48], so that accented letters SHALL NOT be represented with non-spacing accents. Support of additional charsets in 'text' and 'name attribute values is OPTIONAL, but all supported charsets SHALL be ones in which the code points from decimal 20 to 127 are US-ASCII [56]. "content-natural-language" (naturalLanguage): This is a MANDATORY Job Template attribute (see Section 4.2) for the client to supply and the Printer object to support. The "content-natural-language" attribute identifies the natural language that the Printer object SHALL use for any 'text' and 'name' attributes that the Printer object generates in the operation response, such as "job-state-message", unless the Printer object does not support that natural language. In such a case, the Printer object SHALL use the natural language specified by the Printer's "content-natural language-default" attribute instead, rather than returing an error, and SHALL prepend an explicit non-empty natural language tag identifying the default natural language being used in each such generated attribute value. NOTE - A Printer object that support multiple natural languages, often has separate catalogs of messges, one for each natural language supported. This attribute also identifies the natural language that SHALL be implied by any 'text' and 'name' attribute values with an empty natural language tag supplied by the client. In create operations, the Printer object SHALL store with the Job object: (1) the "content-natural language" attribute and (2) any explicit attribute value natural language tags, whether the Printer object supports the identified natural language or not, rather than returning an error. See the 'naturalLanguage' attribute syntax description in Section 4.1.8 for the syntax of this attribute and example values. For the sake of brevity in this document, the above operation attribute descriptions are not repeated with every operation request. In addition, the above operation attributes are defined for use in every operation response with the following definitions: "content-charset" (charSet): This is a MANDATORY Job Template attribute for the Printer object to return. This attribute specifies the charset used by 'text' and 'name' attributes with empty tags in this response and SHALL be the same value as supplied by the client in the request, whether the Printer object supports that value or not. Any 'text' or 'name' values in this response that have a different charset SHALL have a fully specified charset tag pre-pended to each such attribute value. In a subsequent query request (Get-Attributes or Get-Jobs), the Printer object NEED NOT convert any 'text' or 'name' attribute values that had been supplied in the original create request to the charset of the requester when it is different from that specified (and stored) in the original create request for the requested attribute. In such cases, the Printer object SHALL return an explicit charset tag pre-pended to each such attribute value. See the 'text' attribute syntax description in Section 4.1.1. "content-natural-language" (naturalLanguage): This is a MANDATORY Job Template attribute for the Printer object to return. This attribute specifies the natural language used by 'text' and 'name' attributes with empty tags in this response and SHALL be the same value as supplied by the client in the request, whether the Printer object supports that value or not. Any 'text' or 'name' values in this response that have a different natural language SHALL have a fully specified natural language tag pre-pended to each such attribute value. In a subsequent query request (Get-Attributes or Get-Jobs), the Printer object NEED NOT convert any 'text' or 'name' attribute values that had been supplied in the original create request to the natural language of the requester when it is different from that specified (and stored) in the original create request for the requested attribute. In such cases, the Printer object SHALL return an explicit natural language tag pre-pended to each such attribute value. See the 'text' attribute syntax description in Section 4.1.1. For the sake of brevity in this document, the above operation attribute descriptions are not repeated with every operation response. NOTE - In the mapping of IPP over HTTP/1.1, the "content-charset" and "content-natural-language" operation request and response attributes are conveyed in the protocol via the HTTP/1.1 "Content-Language" header and the 'charset' parameter of the 'application/ipp' media type "Content-Type" header [23]. That is, these Job Template attributes SHALL not be encoded in the 'application/ipp' body. In other mappings of IPP operations onto some other transport mechanism, these two attributes will by conveyed using some other mechanism. IPP Printer objects NEED NOT support HTTP/1.1 Accept headers and IPP/1.0 does not address the processing semantics for HTTP/1.1 Accept headers in order to simplify the specification of the IPP semantics. From ipp-archive Mon Oct 13 19:09:50 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA05031 for ipp-outgoing; Mon, 13 Oct 1997 19:04:53 -0400 (EDT) Date: Mon, 13 Oct 1997 16:03:18 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199710132303.QAA15258@woden.eng.sun.com> To: ipp@pwg.org, hastings@cp10.es.xerox.com Subject: Re: IPP> MOD - Updated Model sections for internationalization X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk I have a few comments about Tom's latest document. I have talked with Tom and we have general agreement about the suggestions below. I agreed to write them up and send them out to the mailing list. 1) I am still bothered by specifying the syntax of text and name according to RFC 2184, ( charset "'" language "'"). I don't like the idea of text and names having a "syntax". Also, the restriction of text and name values to those charsets that has ASCII as a subset bothers me -- especially as new systems move toward UCS-2 as the native representation. I propose a different solution: a) separate the charset/language information from the text/name value and put them into separate values, like a multivalued attribute. b) For the vast majority of cases where the charset and language of the text/name attribute is the same as at the operation level, the charset/language value is not needed. So the attribute stays as a single valued attribute, as it was in the July draft. c) For those rare cases where the language or charset of an attribute differs from language and charset specified at the operation level, treat the attribute as a pair of values where the first value has a new type "charset/language" and the second has a type of 'name' or 'text'. The first value is in US-ASCII and has the syntax of RFC 2184, e.g. "iso-latin-1'de'", and the second value is the text/name in the language and charset specified in the first value with no restriction on the charset for the text/name value. If either the language or charset field is empty, the value at the operation level is inherited. Note: if we had dictionaries, I would instead propose that text/name values with an overridden charset or language could be a dictionary containing the language and charset overrides along with the text/name value. But we don't have dictionaries yet. Note: alternatively, we could also add a special array type consisting of n triplets type/value-length/value where there would be three values: charset (type "charset", language (type "language") and a text/name value. d) This change makes the syntax of all requests and most responses be the same as it was before we added the two quotes syntax to text and names. 2) Why isn't content-charset an optional attribute for the client to send? a) I would prefer that the default for a request and response to be UTF-8 if no content-charset parameter is present. b) Then there is no need for a printer to have a default-content-charset. c) make it a group 1 operation attribute and not an HTTP header. Thus rename it 'attributes-charset' 3) Why isn't content-natural language an optional attribute for the client to send? a) I would prefer that the default for a request and response to be the server's default natural language. b) Then there is still a need for a printer to have a default-natural-language. c) make it a group 1 operation attribute and not an HTTP header. Thus rename it 'attributes-natural-language' 4) If my proposal is accepted, then jobs for most printers are unchanged from the July draft by this proposal. They have no operation attributes specifying charset or language and the text/name attributes contain their value only and have no information about charset and language. The default charset UTF-8 and the printer's default language are used for all requests and responses. But the mechanism is there for full support of charsets and languages if needed. From ipp-archive Tue Oct 14 11:29:59 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA06954 for ipp-outgoing; Tue, 14 Oct 1997 11:26:40 -0400 (EDT) Date: Tue, 14 Oct 1997 08:30:32 PDT From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9710141530.AA18845@snorkel.eso.mc.xerox.com> To: hastings@cp10.es.xerox.com, ipp@pwg.org Subject: Re: IPP> MOD - Updated Model sections for internationalization Sender: ipp-owner@pwg.org Precedence: bulk Hi Bob, Tuesday (14 October 1997) I read your note (below) with interest. I sympathize with your desire to avoid adding RFC 2184-style "charset/language" tags to the beginning of all "text" and "name" strings in IPP requests/responses. It would be REAL helpful if all of the IPP working group members would take the 20 minutes to read closely and carefully Harald's draft IETF Policy on Character Sets and Languages. We could deal with the realm of acceptable (to the IESG) solutions and not the simpler world we wish we lived in. For "text" strings, Harald's draft MANDATES both 'charset' and 'language' negotiation and tagging permanently. It SPECIFICALLY precludes a protocol standard from specifying a default character set OR a default language in the definition of a parameter or attribute of type "text". So we MUST have explicit printer default 'charset' and 'language' attributes. And due to the requirement for negotiation, we also MUST have explicit operation attributes for the 'charset' and 'language'. And if we allow either a printer object or a job object to have a mixture of 'charset' or 'language' in their "text" or "name" attributes, then we MUST have explicit tags in the syntax for "text" and "name" attributes. If we don't do this in the drafts of Model and Protocol which we submit to the IESG, we'll get them back for repair (and we won't finish IPP/1.0 in calendar 1997, as a result). What we COULD do, is to force ALL of the "text" and "name" attributes in a request or response to use a SINGLE 'charset' and 'language'. And require that the 'charset' and 'language' of those attributes be fixed at job creation time and be ones supported by the target printer (so that job state reason messages, eg, can be correctly generated by the printer). Cheers, - Ira McDonald (outside consultant at Xerox) PS - Bob, could you write your messages in a 'narrower' text window? My mail reader truncates and wraps at 79 columns - lots of your lines had about 85 columns, so I had to do some 'fixups' to include your note below. Thanks. >--------------------------- Bob's note -------------------------------< >Date: Mon, 13 Oct 1997 16:03:18 PDT >From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) >To: ipp@pwg.org, hastings@cp10.es.xerox.com >Subject: Re: IPP> MOD - Updated Model sections for internationalization > >I have a few comments about Tom's latest document. I have talked with Tom and >we have general agreement about the suggestions below. I agreed to write them >up and send them out to the mailing list. > >1) I am still bothered by specifying the syntax of text and name according > to RFC 2184, ( charset "'" language "'"). I don't like the idea of > text and names having a "syntax". Also, the restriction of text and > name values to those charsets that has ASCII as a subset bothers me > -- especially as new systems move toward UCS-2 as the native > representation. > > I propose a different solution: > > a) separate the charset/language information from the text/name value and > put them into separate values, like a multivalued attribute. > > b) For the vast majority of cases where the charset and language of the > text/name > attribute is the same as at the operation level, the charset/language > value is > not needed. So the attribute stays as a single valued attribute, as it > was in the July draft. > > c) For those rare cases where the language or charset of an attribute > differs from > language and charset specified at the operation level, treat the > atrribute > as a pair of values where the first value has a new type > "charset/language" > and the second has a type of 'name' or 'text'. The first value is in > US-ASCII > and has the syntax of RFC 2184, e.g. "iso-latin-1'de'", and the second > value is > the text/name in the language and charset specified in the first value > with no restriction on the charset for the text/name value. If > either the language or charset field is empty, the value at the > operation level is inherited. > > Note: if we had dictionaries, I would instead propose that text/name > values > with an overridden charset or language could be a dictionary containing > the > language and charset overrides along with the text/name value. But we > don't > have dictionaries yet. > > Note: alternatively, we could also add a special array type consisting > of > n triplets type/value-length/value where there would be three values: > charset (type "charset", language (type "language") and a text/name > value. > > d) This change makes the syntax of all requests and most responses be the > same > as it was before we added the two quotes syntax to text and names. > > >2) Why isn't content-charset an optional attribute for the client to send? > > a) I would prefer that the default for a request and response to be UTF-8 > if no content-charset parameter is present. > b) Then there is no need for a printer to have a default-content-charset. > c) make it a group 1 operation attribute and not an HTTP header. Thus > rename it 'attributes-charset' > >3) Why isn't content-natural language an optional attribute for the client to > send? > > a) I would prefer that the default for a request and response to be the > server's default natural language. > b) Then there is still a need for a printer to have a > default-natural-language. > c) make it a group 1 operation attribute and not an HTTP header. Thus > rename it 'attributes-natural-language' > >4) If my proposal is accepted, then jobs for most printers are unchanged from > the > July draft by this proposal. They have no operation attributes > specifying charset or language and the text/name attributes contain > their value only and have no information about charset and > language. The default charset UTF-8 and the printer's default > language are used for all requests and responses. But the mechanism > is there for full support of charsets and languages if needed. > From ipp-archive Tue Oct 14 13:00:00 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA07995 for ipp-outgoing; Tue, 14 Oct 1997 12:57:05 -0400 (EDT) Message-Id: <3.0.1.32.19971014094304.00cd4490@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 14 Oct 1997 09:43:04 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - PWG IPP Phone Conference on 971015 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk PWG IPP Phone Conference on 971015 - 1:00 - 3:00 pm PST We still have a few subjects for discussion: - Review and comments on proposed solutions and text to meet IEF I18N requirements - How do we handle the definition of the application/ipp specification? - What do we do with the auto-sensing feature (see comments from Ned Freed)? - Comments on Don's revised Requirements draft. - Stand of the Model & Semantics document? - Stand of the Rationale document? - Can we keep the schedule outlined in last week's phone conference? Numbers as last time: Date: 10/15 Time: 4PM Eastern, 1PM Pacific Number: 608-250-1828 Access: 190148 ---- 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 From ipp-archive Tue Oct 14 14:00:01 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA08865 for ipp-outgoing; Tue, 14 Oct 1997 13:55:26 -0400 (EDT) Message-Id: <3.0.1.32.19971014095159.00b88790@genstar.alis.ca> X-Sender: yergeau@genstar.alis.ca X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 14 Oct 1997 09:51:59 -0400 To: Tom Hastings From: Francois Yergeau Subject: IPP> Re: MOD - Comment on RFC 2044: need to specify the ISO 10646 conformance level Cc: Harald.T.Alvestrand@uninett.no, Keith Moore , ipp@pwg.org In-Reply-To: <3.0.1.32.19971008215215.00f613b0@garfield> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk =C0 21:52 08/10/97 PDT, Tom Hastings a =E9crit : >For the purposed of Internet Protocols, we suspect that level 2 is sufficient. >But the UTF-8 definition in RFC 2144 is silent on this matter. We suggest >that >a refision to RFC 2144 be issues that indicates that utf-8 means just level 2. A restriction to level 2, which excludes most combining characters, would severely restrict the expressive power of ISO 10646, and in consequence the ability of the protocols that use it (in the UTF-8 form) to represent the textual content that they need to represent for truly world-wide operation. IMHO, such a restriction is too serious to be entertained solely on the basis of "we suspect that level 2 is sufficient." ISO has not found it sufficient, it has level 3; Unicode has *only* level 3. And I think the purposes of Internet protocols (at least those that carry text) are the same as the purposes underlying ISO 10646 and Unicode: to enable communication in all the world's languages. >Alternatively, register a new value, say, 'utf-8-level-2'. There is actually a revision of RFC 2044 underway. The latest draft (ftp://ds.internic.net/internet-drafts/draft-yergeau-utf8-rev-01.txt) has a discussion of version-specific labels, which you may find relevant to your proposal of a level-specific label. Please take a look, and come back with your proposal -- preferably to the ietf-charset list, as suggested by Harald -- if you still think it is appropriate. Regards, --=20 Fran=E7ois Yergeau Alis Technologies inc., Montr=E9al T=E9l : +1 (514) 747-2547 Fax : +1 (514) 747-2561 From ipp-archive Tue Oct 14 17:40:04 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA10070 for ipp-outgoing; Tue, 14 Oct 1997 17:39:19 -0400 (EDT) Date: Tue, 14 Oct 1997 12:20:38 PDT From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9710141920.AA18937@snorkel.eso.mc.xerox.com> To: hastings@cp10.es.xerox.com, yergeau@alis.com Subject: Re: IPP> Re: MOD - Comment on RFC 2044: need to specify the ISO 10646 conformance level Cc: Harald.T.Alvestrand@uninett.no, ipp@pwg.org, moore@cs.utk.edu Sender: ipp-owner@pwg.org Precedence: bulk Hello M. Yergeau, The IPP working group has chosen to base the IPP project (partly) on ISO 10175 - DPA (Document Printing Application). In order for "text" strings specified in IPP to be transferred to and from strings in DPA implementations (there are a number), it is helpful to observe the DPA limitation to ISO 10646 Level 2. Perhaps this was an unfortunate choice in the ISO DPA standard. The rationale was in order to help support correct comparison operations for string attributes. Certainly, access to the full repertoire of ISO 10646 Level 3 is highly desirable (for the reasons you stated in your note, below). But if IPP/1.0 is to be rapidly adopted and deployed by the printing industry vendors, it must avoid unreasonable implementation costs for embedded systems. I recently read the MIME media-type registration for UTF-8 and it seemed somewhat ambiguous about which level of ISO 10646 is mandatory. The IPP working group has approximately three (3) weeks left to finish their Model and Semantics spec and Protocol spec and advance them to the IESG (per a recent note from Keith Moore, one of our IETF Applications Area Directors), if the IPP/1.0 specs are to be adopted within calendar 1997. There is a very real urgency about completing IPP/1.o specs soon. Otherwise, it is probable that single-vendor or small consortium implementations of something "similar" to IPP, but NOT interoperable. And the "window of opportunity" to solve the problem of a robust replacement for RFC 1179 will have passed. Regards, - Ira McDonald (outside consultant at Xerox) ------------------------------------------------------ >From ipp-owner@pwg.org Tue Oct 14 14:18:05 1997 Return-Path: Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA18881; Tue, 14 Oct 97 14:18:04 EDT Received: from alpha.Xerox.COM by zombi (4.1/SMI-4.1) id AB07428; Tue, 14 Oct 97 14:13:51 EDT Received: from lists.underscore.com ([199.125.85.31]) by alpha.xerox.com with SMTP id <55990(1)>; Tue, 14 Oct 1997 11:13:13 PDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA09275 for ; Tue, 14 Oct 1997 14:09:44 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 14 Oct 1997 14:05:46 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA08865 for ipp-outgoing; Tue, 14 Oct 1997 13:55:26 -0400 (EDT) Message-Id: <3.0.1.32.19971014095159.00b88790@genstar.alis.ca> X-Sender: yergeau@genstar.alis.ca X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 14 Oct 1997 06:51:59 PDT To: Tom Hastings From: Francois Yergeau Subject: IPP> Re: MOD - Comment on RFC 2044: need to specify the ISO 10646 conformance level Cc: Harald.T.Alvestrand@uninett.no, Keith Moore , ipp@pwg.org In-Reply-To: <3.0.1.32.19971008215215.00f613b0@garfield> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Status: R =C0 21:52 08/10/97 PDT, Tom Hastings a =E9crit : >For the purposed of Internet Protocols, we suspect that level 2 is sufficient. >But the UTF-8 definition in RFC 2144 is silent on this matter. We suggest >that >a refision to RFC 2144 be issues that indicates that utf-8 means just level 2. A restriction to level 2, which excludes most combining characters, would severely restrict the expressive power of ISO 10646, and in consequence the ability of the protocols that use it (in the UTF-8 form) to represent the textual content that they need to represent for truly world-wide operation. IMHO, such a restriction is too serious to be entertained solely on the basis of "we suspect that level 2 is sufficient." ISO has not found it sufficient, it has level 3; Unicode has *only* level 3. And I think the purposes of Internet protocols (at least those that carry text) are the same as the purposes underlying ISO 10646 and Unicode: to enable communication in all the world's languages. >Alternatively, register a new value, say, 'utf-8-level-2'. There is actually a revision of RFC 2044 underway. The latest draft (ftp://ds.internic.net/internet-drafts/draft-yergeau-utf8-rev-01.txt) has a discussion of version-specific labels, which you may find relevant to your proposal of a level-specific label. Please take a look, and come back with your proposal -- preferably to the ietf-charset list, as suggested by Harald -- if you still think it is appropriate. Regards, --=20 Fran=E7ois Yergeau Alis Technologies inc., Montr=E9al T=E9l : +1 (514) 747-2547 Fax : +1 (514) 747-2561 From ipp-archive Tue Oct 14 18:20:03 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA10930 for ipp-outgoing; Tue, 14 Oct 1997 18:15:58 -0400 (EDT) Date: Tue, 14 Oct 1997 15:13:52 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199710142213.PAA01577@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>PRO latest protocol document X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk I have downloaded the latest protocol document. It isn't correct with regard to i18n because that is still in process. But it should otherwise align with regard to the model document. The documents are at: ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO. The documents are: ipp-pro-971014-rev.doc MS Word V6 with revisions ipp-pro-971014.doc MS Word V6 without revisions ipp-pro-971014.txt text From ipp-archive Tue Oct 14 18:55:03 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA11575 for ipp-outgoing; Tue, 14 Oct 1997 18:54:59 -0400 (EDT) Message-Id: <3.0.1.32.19971014185441.00aa5980@genstar.alis.ca> X-Sender: yergeau@genstar.alis.ca X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 14 Oct 1997 18:54:41 -0400 To: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) From: Francois Yergeau Subject: Re: IPP> Re: MOD - Comment on RFC 2044: need to specify the ISO 10646 conformance level Cc: hastings@cp10.es.xerox.com, Harald.T.Alvestrand@uninett.no, ipp@pwg.org, moore@cs.utk.edu In-Reply-To: <9710141920.AA18937@snorkel.eso.mc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Sender: ipp-owner@pwg.org Precedence: bulk À 12:20 14/10/97 PDT, Ira Mcdonald x10962 a écrit : >The IPP working group has chosen to base the IPP project (partly) >on ISO 10175 - DPA (Document Printing Application). In order for >"text" strings specified in IPP to be transferred to and from >strings in DPA implementations (there are a number), it is helpful >to observe the DPA limitation to ISO 10646 Level 2. Makes sense. >Perhaps this was an unfortunate choice in the ISO DPA standard. Indeed! >I recently read the MIME media-type registration for UTF-8 and >it seemed somewhat ambiguous about which level of ISO 10646 >is mandatory. The charset label (not media-type) registration for UTF-8 does not mandate transmission of one level or another. The charset label is only an announcement mechanism that tells a receiving application how to turn the received bytes into characters. As such, there is nothing to stop a given protocol, say IPP, from mandating that all strings be encoded at level 2. The "UTF-8" label is then perfectly adequate -- the receiving end knows how to decode -- and the (overstated, IMHO) burden of level 3 does not come to bear on that protocol. The rationale for not having level-specific labels is that it does not seem to help anybody. In your case, if the transmitters are restricted to level 2 by the protocol definition, the receiving end gains nothing from a label that says level 2 -- they already know that. In general, a receiver that is prepared to receive level 3 will gain nothing from a level 2 label. In the opposite case (level 2 receiver, level 3 label) the only gain is a slightly earlier warning that the receiver may fail; even that gain may be illusory, as a level 3 label does not guarantee that level 3 combinations actually occur -- the level 2 receiver may well succeed if it tries. There has been ample discussion of this (and the related versioning) issue on various IETF, ISO and Unicode lists since early 1996, and the consensus is that this meager gain in one case is to small to bother, especially when faced with a potential proliferation of labels for all version-level combinations, and the possibility that it leads to less interoperability in some cases. >The IPP working group has approximately three (3) weeks left >to finish their Model and Semantics spec and Protocol spec >and advance them to the IESG (per a recent note from Keith >Moore, one of our IETF Applications Area Directors), if the >IPP/1.0 specs are to be adopted within calendar 1997. There >is a very real urgency about completing IPP/1.o specs soon. >Otherwise, it is probable that single-vendor or small >consortium implementations of something "similar" to IPP, >but NOT interoperable. And the "window of opportunity" >to solve the problem of a robust replacement for RFC 1179 >will have passed. > >Regards, >- Ira McDonald (outside consultant at Xerox) >------------------------------------------------------ >>From ipp-owner@pwg.org Tue Oct 14 14:18:05 1997 >Return-Path: >Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) > id AA18881; Tue, 14 Oct 97 14:18:04 EDT >Received: from alpha.Xerox.COM by zombi (4.1/SMI-4.1) > id AB07428; Tue, 14 Oct 97 14:13:51 EDT >Received: from lists.underscore.com ([199.125.85.31]) by alpha.xerox.com with SMTP id <55990(1)>; Tue, 14 Oct 1997 11:13:13 PDT >Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA09275 for ; Tue, 14 Oct 1997 14:09:44 -0400 (EDT) >Received: by pwg.org (bulk_mailer v1.5); Tue, 14 Oct 1997 14:05:46 -0400 >Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA08865 for ipp-outgoing; Tue, 14 Oct 1997 13:55:26 -0400 (EDT) >Message-Id: <3.0.1.32.19971014095159.00b88790@genstar.alis.ca> >X-Sender: yergeau@genstar.alis.ca >X-Mailer: Windows Eudora Pro Version 3.0.1 (32) >Date: Tue, 14 Oct 1997 06:51:59 PDT >To: Tom Hastings >From: Francois Yergeau >Subject: IPP> Re: MOD - Comment on RFC 2044: need to specify the ISO 10646 > conformance level >Cc: Harald.T.Alvestrand@uninett.no, Keith Moore , > ipp@pwg.org >In-Reply-To: <3.0.1.32.19971008215215.00f613b0@garfield> >Mime-Version: 1.0 >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable >Sender: ipp-owner@pwg.org >Status: R > >=C0 21:52 08/10/97 PDT, Tom Hastings a =E9crit : >>For the purposed of Internet Protocols, we suspect that level 2 is >sufficient. >>But the UTF-8 definition in RFC 2144 is silent on this matter. We suggest >>that >>a refision to RFC 2144 be issues that indicates that utf-8 means just >level 2. > >A restriction to level 2, which excludes most combining characters, would >severely restrict the expressive power of ISO 10646, and in consequence the >ability of the protocols that use it (in the UTF-8 form) to represent the >textual content that they need to represent for truly world-wide operation. > IMHO, such a restriction is too serious to be entertained solely on the >basis of "we suspect that level 2 is sufficient." ISO has not found it >sufficient, it has level 3; Unicode has *only* level 3. And I think the >purposes of Internet protocols (at least those that carry text) are the >same as the purposes underlying ISO 10646 and Unicode: to enable >communication in all the world's languages. > >>Alternatively, register a new value, say, 'utf-8-level-2'. > >There is actually a revision of RFC 2044 underway. The latest draft >(ftp://ds.internic.net/internet-drafts/draft-yergeau-utf8-rev-01.txt) has a >discussion of version-specific labels, which you may find relevant to your >proposal of a level-specific label. Please take a look, and come back with >your proposal -- preferably to the ietf-charset list, as suggested by >Harald -- if you still think it is appropriate. > >Regards, > > >--=20 >Fran=E7ois Yergeau >Alis Technologies inc., Montr=E9al >T=E9l : +1 (514) 747-2547 >Fax : +1 (514) 747-2561 > > > -- François Yergeau Alis Technologies inc., Montréal Tél : +1 (514) 747-2547 Fax : +1 (514) 747-2561 From ipp-archive Tue Oct 14 19:05:03 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA11601 for ipp-outgoing; Tue, 14 Oct 1997 19:04:59 -0400 (EDT) Message-Id: <3.0.1.32.19971014190128.00aa9880@genstar.alis.ca> X-Sender: yergeau@genstar.alis.ca X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 14 Oct 1997 19:01:28 -0400 To: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) From: Francois Yergeau Subject: Re: IPP> Re: MOD - Comment on RFC 2044: need to specify the ISO 10646 conformance level Cc: hastings@cp10.es.xerox.com, Harald.T.Alvestrand@uninett.no, ipp@pwg.org, moore@cs.utk.edu In-Reply-To: <9710141920.AA18937@snorkel.eso.mc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Sender: ipp-owner@pwg.org Precedence: bulk I'm sorry, I pressed the wrong button and sent an unfinished message. I wanted to add a little something: À 12:20 14/10/97 PDT, Ira Mcdonald x10962 a écrit : >The IPP working group has approximately three (3) weeks left >to finish their Model and Semantics spec and Protocol spec >and advance them to the IESG (per a recent note from Keith There is nothing to stop you from mandating level 2, but that would be a mistakeIMHO, for the reasons I gave in my reply to Tom Hastings. If you are sure that you *must* have that restriction early on, please entertain the possibility of having 10646 level 3 as an option in IPP. I know nothing about IPP -- negotiation, etc. -- but at least such an option would give implementers the possibility of advertising that their implementation supports it, instead of restricting forever to level 2. Regards, -- François Yergeau Alis Technologies inc., Montréal Tél : +1 (514) 747-2547 Fax : +1 (514) 747-2561 From ipp-archive Tue Oct 14 23:25:06 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA13299 for ipp-outgoing; Tue, 14 Oct 1997 23:20:32 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 14 Oct 1997 16:26:55 -0600 From: Scott Isaacson To: ipp@pwg.org Subject: IPP> MOD - new Model document Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org Precedence: bulk I have posted a 971014 version of the model document. ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-971014-rev.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-971014-w60.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-971014.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-971014.txt It is not as clean as I would have liked, but it has a bunch of new stuff So don't bother with review comments on: 1. References still are not fixed up 2. Some internal links are broken 3. Model document has "mimeType" syntax type, protocol document has "mediaType" syntax type I rolled in Tom's I18N document, but it sounds like that is still under flux. Comments are welcome on that whole proposal. The rest is free game. I still have a few issues marked as "Issue:". Scott ************************************************************ Scott A. Isaacson Corporate Architect Novell Inc., MS PRV-C-112 122 E 1700 S, Provo, UT 84606 voice: (801) 861-7366, (800) 453-1267 x17366 fax: (801) 861-4025 email: scott_isaacson@novell.com web: http://www.novell.com ************************************************************ From ipp-archive Wed Oct 15 01:40:08 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA14168 for ipp-outgoing; Wed, 15 Oct 1997 01:38:17 -0400 (EDT) Message-Id: <3.0.1.32.19971014224210.00d0bcb0@garfield> X-Sender: hastings@garfield (Unverified) X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 14 Oct 1997 22:42:10 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Further Simplification of Internationalization - from Bob, Ira, and Tom [no RFC 2184 tags] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk This is a simplification of the IPP internationalization proposal that Ira and I put out on Monday, 10/13/97 and that Bob and Ira responded to via e-mail. Bob, Ira, and I collaborated on this one. We believe that this proposal meets the IETF Character Set and Language Policy. The text changes to incorporate this are straightforward to make in the text changes that I sent out on 10/13/97. We'd like to discuss this at the Wednesday, 10/15/97 1:00-3:00 pm PDT telecon. The 'text' and 'name' attributes involved are: Operation Attributes: document-name (name) Job Attributes: job-name (name) job-originating-user (name) job-state-message (text) job-message-from-operator (text) Printer Attributes: printer-name (name) printer-location (text) printer-info (text) printer-make-and-model (text) printer-state-message (text) printer-message-from-operator (text) Each numbered point applies to both charset and natural language. Points with "a" are just charset and points with "b" are just natural language. Here are the major points of the simplification: 1. Instead of using RFC 2184 charset and natural language tags in each attribute of type 'text' or 'name', require that all 'text' and 'name' attributes in a single operation request or operation response (including multiple Jobs in a single Get-Jobs response) be in the same charset. For each 'text' and 'name' attribute specify whether the natural language SHALL be as the client requested, the Printer's default, or that supplied by the client that created the Job. Eliminating the charset and natural language tags makes it easier to support legacy systems, and also allows direct support of charsets that do not have US-ASCII as a subset, such as ISO 10646/Unicode/UCS-2 (which NT, Java, and Novell directories support). In the future, if it becomes necessary to support more than one charset or natural language in an operation request or response, then we can do one of any: (1) add new 'taggedText' and 'taggedName' attribute syntaxes which do use the RFC 2184 tags, (2) use dictionaries, or (3) Bob's scheme in his e-mail that splits the charset/language into one value and the rest in a separate value. 2a. Continue to require the client to supply the "content-charset" operation attribute in the request to unambiguously identify the charset for all 'text' and 'name' attributes in the request or response. This meets the IETF character set and language policy. MINOR ISSUE: Ask Harald whether the charset policy would allows us to specify that omission of the "content-charset" operation attribute could be defined to be identical to supplying a value of 'utf-8' or not. 2b. Allow the client to supply the "content-natural-language" operation attribute in order to indicate the natural language of all 'text' and 'name' attributes that the client is supplying. If omitted, the Printer object shall behave as if the client had supplied the Printer's "natural-language-default" attribute value. Omission of "content-natural-language" is allowed in requests by the IETF character set and language policy. 3. For the create operations, the Printer object shall store the content-charset" and "content-natural-language" attributes supplied by the client in the Job object for use in subsequent event notifications. 4a. A Printer object SHALL respond with 'text' and 'name' attributes in the charset identified by the client in the request and SHALL return the "content-charset" operation attribute with the same value. This may require the Printer object to code convert from one of its supported charsets to another one of its supported charsets. Such a code conversion is performed on a 'best efforts' basis and may result in some loss of information. For example, the Printer object may charset convert from a UTF-8 'a' to a US-ASCII 'a' (with no loss of information), from an ISO Latin 1 CAPITAL LETTER A WITH ACUTE ACCENT to US-ASCII 'A' (losing the accent), or from a UTF-8 Japanese Kanji character to some ISO Latin 1 error character indication such as '?', decimal code eqivalent, or to the absence of a character, depending on implementation. 4b. A Printer object SHALL respond with 'text' and 'name' attributes in the natural language (1) identified by the client in the request, (2) identified by the Printer's "natural-language-default" attribute, or (3) the natural-language supplied by the client that created the Job object, depending on the attribute as follows: A. For 'text' and 'name' attributes generated by the Printer object, i.e., for "job-state-message", "printer-state-message", the Printer is required to generate attributes in all of the supported languages identified by the Printer's "natural-language-supported" attribute. B. For 'text' and 'name' attribute supplied by the operator, system administrator, or manufacturer, i.e., for " job-message-from-operator" (text), "printer-name" (name), "printer-location" (text), "printer-info", and "printer-make-and-model" (text), the Printer SHALL only support the default natural language of the Printer identified by the Printer's "natural-language-default" attribute.. C. For 'name' and 'text' attributes supplied by the client, i.e., "job-name" (name) and "job-originating-user" (name), the Printer object stores the supplied "content-natural-language" with the Job object (as long as it is one of the Printer's supported natural languages identified by the Printer's "natural-language-supported" attribute). The description for each 'text' and 'name' attribute, including future registration proposals, SHALL specify which other attribute identifies the natural language of the attribute as indicated above. To help the client determine the natural language of each 'text' and 'name' attribute returned in each operation response, the Printer object SHALL return the "content-natural-language" with the same value and the Printer's "content-natural-language-default" as operational attributes. NOTE - In the Get-Jobs operation response, each Job's natural language may be different, so the client will have to explicitly request the "content-natural-langauge" Job attribute in order to determine the natural language of the "job-name" and "job-originating-user" Job attributes. 5. The Printer object SHALL identify the supported charsets and natural languages in its "charset-supported" and "content-natural-language-supported" Printer attributes that it is capable of accepting in requests and returning in responses as described above. 6a. Require that a Printer object support the UTF-8, ISO 8859-1 (ISO Latin1), and US-ASCII charsets, to facilitate inter-working. 6b. No particular natural languages are required for a Printer object to support. 7. If a client supplies a value for the "content-charset" or "content-natural-language" operation attribute that is not supported by the Printer object, the Printer SHALL reject the request and return error code ???. Otherwise, the Printer object might have to perform a code conversion to an unknown (or at least unsupported) charset. 8. Leave "content-charset" and "content-natural-language" attributes as Job Template attribute, but put a "No" in the default column for content-charset-default, since there isn't a default attribute. 9. Don't pass the "content-charset" and "content-natural-language" operation attributes as HTTP/1.1 header and "Content-Type", but just as other IPP operation attributes. Therefore, rename them to "attribute-charset" and "attribute-natural-language" Job Template attributes. Please send comments before the telecon, if possible. Thanks, Tom From ipp-archive Wed Oct 15 03:45:09 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id DAA15042 for ipp-outgoing; Wed, 15 Oct 1997 03:41:56 -0400 (EDT) X-Mailer: exmh version 1.6.9 8/22/96 From: Harald.T.Alvestrand@uninett.no To: Francois Yergeau cc: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962), hastings@cp10.es.xerox.com, ipp@pwg.org, moore@cs.utk.edu Subject: Re: IPP> Re: MOD - Comment on RFC 2044: need to specify the ISO 10646 conformance level In-reply-to: Your message of "Tue, 14 Oct 1997 18:54:41 EDT." <3.0.1.32.19971014185441.00aa5980@genstar.alis.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Oct 1997 09:41:31 +0200 Message-ID: <24642.876901291@dale.uninett.no> Sender: ipp-owner@pwg.org Precedence: bulk Ira, I think an appropriate solution for IPP is to put the following note into the spec: NOTE: For the case where IPP requests are gatewayed into DPA, the text strings in the protocol must be limited to conform to ISO 10646 level 2. This means that the following characters are dropped when copying strings from an IPP PDU into a DPA PDU: 0483 COMBINING CYRILLIC TITLO 0484 COMBINING CYRILLIC PALATALIZATION 0485 COMBINING CYRILLIC DASIA PNEUMATA 0486 COMBINING CYRILLIC PSILI PNEUMATA 093C DEVANAGARI SIGN NUKTA 0953 DEVANAGARI GRAVE ACCENT 0954 DEVANAGARI ACUTE ACCENT 09BC BENGALI SIGN NUKTA 09D7 BENGALI AU LENGTH MARK 0A3C GURMUKHI SIGN NUKTA 0A70 GURMUKHI TIPPI 0A71 GURMUKHI ADDAK 0ABC GUJARTI SIGN NUKTA 0B3C ORIYA SIGN NUKTA 0B56 ORIYA AI LENGTH MARK 0B57 ORIYA AU LENGTH MARK 0BD7 TAMIL AU LENGTH MARK 0C55 TELUGU LENGTH MARK 0C56 TELUGU AI LENGTH MARK 0CD5 KANNADA LENGTH MARK 0CD6 KANNADA AI LENGTH MARK 0D57 MALAYALAM AU LENGTH MARK 302A IDEOGRAPHIC LEVEL TONE MARK 302B IDEOGRAPHIC RISING TONE MARK 302C IDEOGRAPHIC DEPARTING TONE MARK 302D IDEOGRAPHIC ENTERING TONE MARK 302E HANGUL SINGLE DOT TONE MARK 302F HANGUL DOUBLE DOT TONE MARK 3099 COMBINING KATAKANA-HIRAGANA VOICED SOUND MARK 309A COMBINING KATAKANA-HIRAGANA SEMI-VOICED SOUND MARK It always helps to be explicit about those things.... Harald A From ipp-archive Wed Oct 15 05:50:13 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id FAA15928 for ipp-outgoing; Wed, 15 Oct 1997 05:48:41 -0400 (EDT) From: Harald.T.Alvestrand@uninett.no cc: Francois Yergeau , imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962), hastings@cp10.es.xerox.com, ipp@pwg.org, moore@cs.utk.edu Subject: Re: IPP> Re: MOD - Comment on RFC 2044: need to specify the ISO 10646 conformance level In-reply-to: Your message of "Wed, 15 Oct 1997 09:41:31 +0200." <24642.876901291@dale.uninett.no> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25427.876908904.1@dale.uninett.no> Date: Wed, 15 Oct 1997 11:48:26 +0200 Message-ID: <25429.876908906@dale.uninett.no> Sender: ipp-owner@pwg.org Precedence: bulk Oops - I missed the following text in the description of implementation level 2: The characters in the subset collections COMBINING DIACRITICAL MARKS (0300 to 036F), COMBINING DIACRITICAL MARKS FOR SYMBOLS (20D0 to 20FF), HANGUL JAMO (1100 to 11FF) and COMBINING HALF MARKS (FE20 to FE2F) are not allowed in implementation level 2. So the difference between Level 1 and Level 2 is that in Level 2 you get the vowel and point marks required for various languages, but still can't use the diacritical marks for Western languages. My mistake.... Harald A From ipp-archive Wed Oct 15 10:10:17 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA16788 for ipp-outgoing; Wed, 15 Oct 1997 10:10:08 -0400 (EDT) Date: Wed, 15 Oct 1997 07:00:00 PDT From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9710151400.AA19436@snorkel.eso.mc.xerox.com> To: Harald.T.Alvestrand@uninett.no, imcdonal@eso.mc.xerox.com Subject: Re: IPP> Re: MOD - Comment on RFC 2044: need to specify the ISO 10646 conformance level Cc: hastings@cp10.es.xerox.com, ipp@pwg.org, moore@cs.utk.edu, yergeau@alis.com Sender: ipp-owner@pwg.org Precedence: bulk Hi Harald, Thanks for your suggestion. I agree that clarity is the objective. Tom and I will urge that the IPP Model and Semantics spec include such a clarification for the use of ISO 10646. Regards, - Ira McDonald (outside consultant at Xerox) From ipp-archive Wed Oct 15 11:15:19 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA17473 for ipp-outgoing; Wed, 15 Oct 1997 11:12:50 -0400 (EDT) From: "Zehler,Peter" To: "Redirector IPP (E-mail)" Subject: IPP> TES> Outbound binary request bug in NetScape Proxy V2 Date: Wed, 15 Oct 1997 08:15:54 PDT X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Message-Id: <97Oct15.081239pdt."51884(1)"@alpha.xerox.com> Sender: ipp-owner@pwg.org Precedence: bulk All, At least in version 2 of the Netscape HTTP Proxy there is a problem. The proxy does not handle outbound binary data very well. Outbound requests that contains an 0xFF are truncated at the 0xFF. Inbound traffic works fine. This (I hope) is a bug in this particular version of the Netscape Proxy Server. (the current version is 2.5 and a prerelease of 3.5 is available) Just a heads up for anyone else testing with a Netscape proxy in there way. Pete __________________________________ Email: pzehler@channels.mc.xerox.com US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. Webster NY, 14580-9701 Voice: (716) 265-8755 FAX: (716)265-8792 __________________________________ "I always wanted to be somebody, but I should have been more specific." Lily Tomlin __________________________________ From ipp-archive Wed Oct 15 11:35:20 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA18111 for ipp-outgoing; Wed, 15 Oct 1997 11:31:40 -0400 (EDT) From: "Zehler,Peter" To: "Redirector IPP (E-mail)" Subject: IPP> RE: TES> Outbound binary request bug in NetScape Proxy V2 Date: Wed, 15 Oct 1997 08:32:51 PDT X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Message-Id: <97Oct15.083017pdt."53549(5)"@alpha.xerox.com> Sender: ipp-owner@pwg.org Precedence: bulk All, This bug is limited to version 2 of the Netscape Proxy. Version 2.53 works fine. Pete __________________________________ Email: pzehler@channels.mc.xerox.com US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. Webster NY, 14580-9701 Voice: (716) 265-8755 FAX: (716)265-8792 __________________________________ "I always wanted to be somebody, but I should have been more specific." Lily Tomlin __________________________________ > -----Original Message----- > From: Zehler,Peter > Sent: Wednesday, October 15, 1997 11:11 AM > To: Redirector IPP (E-mail) > Subject: TES> Outbound binary request bug in NetScape Proxy V2 > > All, > At least in version 2 of the Netscape HTTP Proxy there is a > problem. The proxy does not handle outbound binary data very well. > Outbound requests that contains an 0xFF are truncated at the 0xFF. > Inbound traffic works fine. This (I hope) is a bug in this particular > version of the Netscape Proxy Server. (the current version is 2.5 and > a prerelease of 3.5 is available) Just a heads up for anyone else > testing with a Netscape proxy in there way. > > Pete > > __________________________________ > Email: pzehler@channels.mc.xerox.com > US Mail: Peter Zehler > Xerox Corp. > 800 Phillips Rd. > Webster NY, 14580-9701 > Voice: (716) 265-8755 > FAX: (716)265-8792 > __________________________________ > "I always wanted to be somebody, > but I should have been more specific." > Lily Tomlin > __________________________________ > From ipp-archive Wed Oct 15 15:28:41 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA21954 for ipp-outgoing; Wed, 15 Oct 1997 15:28:33 -0400 (EDT) Message-Id: <3.0.1.32.19971015123152.021c47e0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) X-Priority: 2 (High) Date: Wed, 15 Oct 1997 12:31:52 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Updated simplified internationalization proposal Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk This is a slightlty updated and further simplified proposal from the one sent out last night changing: point 4a to recommend, rather than require, charset conversion, but ALL 'text' and 'name' attributes in the response SHALL be returned in a single charset, which is either the requested charset or the charset of the Job or Printer object. 4b to specify that the language returned is either the requested language or the language of the Job or Printer object, but ALL 'text' and 'name' attributes in the response SHALL be returned in a single natural language, which is either the requested natural language or the natural language of the Job or Printer object. and adding point 5 to return the charset and natural language being used in the response for each job (since they could be different) in Get-Jobs Response. Modified proposal: This proposal is a simplification of the IPP internationalization proposal that Ira and I put out on Monday, 10/13/97 and that Bob and Ira responded to via e-mail. Bob, Ira, and I collaborated on this one. We believe that this proposal meets the IETF Character Set and Language Policy. The text changes to incorporate this are straightforward to make in the text changes that I sent out on 10/13/97. We'd like to discuss this at the Wednesday, 10/15/97 1:00-3:00 pm PDT telecon. The 'text' and 'name' attribute involved are: Operation Attributes: document-name (name) Job Attributes: job-name (name) job-originating-user (name) job-state-message (text) job-message-from-operator (text) Printer Attributes: printer-name (name) printer-location (text) printer-info (text) printer-make-and-model (text) printer-state-message (text) printer-message-from-operator (text) Each numbered point applies to both charset and natural language. Points with "a" are just charset and points with "b" are just natural language. Here are the major points of the simplification: 1. Instead of using RFC 2184 charset and natural language tags in each attribute of type 'text' or 'name', require that all 'text' and 'name' attributes in a single operation request or operation response (including multiple Jobs in a single Get-Jobs response) be in the same charset. For each 'text' and 'name' attribute specify whether the natural language SHALL be as the client requested, the Printer's default, or that supplied by the client that created the Job. Eliminating the charset and natural language tags makes it easier to support legacy systems, and also allows direct support of charsets that do not have US-ASCII as a subset, such as ISO 10646/Unicode/UCS-2 (which NT, Java, and Novell directories support). In the future, if it becomes necessary to support more than one charset or natural language in an operation request or response, then we can do one of any: (1) add new 'taggedText' and 'taggedName' attribute syntaxes which do use the RFV 2184 tags, (2) use dictionaries, or (3) Bob's scheme in his e-mail that splits the charset/language into one value and the rest in a separate value. 2a. Continue to require the client to supply the "content-charset" operation attribute in the request to unambiguously identify the charset for all 'text' and 'name' attributes in the request or response. This meets the IETF character set and language policy. MINOR ISSUE: Ask Harald whether the charset policy would allows us to specify that omission of the "content-charset" operation attribute could be defined to be identical to supplying a value of 'utf-8' or not. 2b. Allow the client to supply the "content-natural-language" operation attribute in order to indicate the natural language of all 'text' and 'name' attributes that the client is supplying. If omitted, the Printer object shall behave as if the client had supplied the Printer's "natural-language-default" attribute value. Omission of "content-natural-language" is allowed in requests by the IETF character set and language policy. 3. For the create operations, the Printer object shall store the content-charset" and "content-natural-language" attributes supplied by the client in the Job object for use in subsequent event notifications. 4a. A Printer object SHALL respond with all requested 'text' and 'name' attributes in a single charset. That charset SHALL either be (1) the one requested by the client in the request via the "content-charset" operation attribute or (2) the charset of the Job or Printer object. The Printer object SHALL return the "content-charset" operation attribute indicating the charset of the returned 'text' and 'name' attributes. The response MAY require the Printer object to code convert from one of its supported charsets to another one of its supported charsets. Such a code conversion, if performed, is on a 'best efforts' basis and may result in some loss of information. For example, the Printer object may charset convert from a UTF-8 'a' to a US-ASCII 'a' (with no loss of information), from an ISO Latin 1 CAPITAL LETTER A WITH ACUTE ACCENT to US-ASCII 'A' (losing the accent), or from a UTF-8 Japanese Kanji character to some ISO Latin 1 error character indication such as '?', decimal code eqivalent, or to the absence of a character, depending on implementation. 4b. A Printer object SHALL respond with all requested 'text' and 'name' attributes in a single natural language. That natural language SHALL either be: (1) the one requested by the client in the request via the "content-natural-language" operation attribute or (2) identified by the natural language of the Job or Printer object. The natural language of the Job object is the one supplied by the "content-natural-language" in the create operation. The natural language of the Printer object is its "natural-language-default" attribute: A. For 'text' and 'name' attributes generated by the Printer object, i.e., for "job-state-message", "printer-state-message", the Printer is required to generate attributes in all of the supported languages identified by the Printer's "natural-language-supported" attribute, if the Printer supports the "job-state-message" and/or the "printer-state-message" attributes. B. For other Printer 'text' and 'name' attributes supplied by the operator, system administrator, or manufacturer, i.e., for "printer-name" (name), "printer-location" (text), "printer-info", and "printer-make-and-model" (text), the Printer is only required to support the default natural language of the Printer identified by the Printer's "content-natural-language-default" attribute. C. For other Job 'name' and 'text' attributes supplied by the client, i.e., "job-name" (name) and "job-originating-user" (name), the Printer object stores the supplied "content-natural-language" with the Job object (as long as it is one of the Printer's supported natural languages identified by the Printer's "natural-language-supported" attribute). The description for each 'text' and 'name' attribute, including future registration proposals, SHALL specify whether the Printer object MUST support its value in all supported charsets and natural languages or not. To help the client determine the single natural language being used for all 'text' and 'name' attribute returned in each operation response, the Printer object SHALL return the actual natural language being used as the value of "content-natural-language" operational attribute. 5. In the Get-Jobs operation response, each Job's charset and natural language may be different, so the response SHALL include the "content-charset" and the "content-natural-language" in the returned Job attributes. 6. The Printer object SHALL identify the supported charsets and natural languages in its "charset-supported" and "content-natural-language-supported" Printer attributes that it is capable of accepting in requests and returning in responses as described above. 7a. Require that a Printer object support the UTF-8, ISO 8859-1 (ISO Latin1), and US-ASCII charsets, to facilitate inter-working. 7b. No particular natural languages are required for a Printer object to support. 8. If a client supplies a value for the "content-charset" or "content-natural-language" operation attribute that is not supported by the Printer object, the Printer SHALL reject the request and return error code ???. Otherwise, the Printer object might have to perform a code conversion to an unknown (or at least unsupported) charset. 9. Leave "content-charset" and "content-natural-language" attributes as Job Template attribute, but put a "No" in the default column for content-charset-default, since there isn't a default attribute. 10. Don't pass the "content-charset" and "content-natural-language" operation attributes as HTTP/1.1 header and "Content-Type", but just as other IPP operation attributes. Therefore, rename them to "attribute-charset" and "attribute-natural-language" Job Template attributes. Please send comments. Thanks, Tom From ipp-archive Wed Oct 15 18:48:43 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA22747 for ipp-outgoing; Wed, 15 Oct 1997 18:46:04 -0400 (EDT) Message-Id: <3.0.1.32.19971015153143.00bda7b0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 15 Oct 1997 15:31:43 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Minutes from PWG IPP Phone Conference 971015 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Minutes from PWG IPP Phone Conference 971015 Attending: Carl-Uno Manros Steve Zilles Tom Hastings Scott Isaacson Bob Herriot Ron Bergman Randy Turner Ira Mcdonald Patrick Powell - Review and comments on proposed solutions and text to meet the IETF I18N requirements: Long and intensive discussion covering how many different sources you might have for languages and how much flexibility is required in one request/response as well as associated with one printer or job object. One of the major objectives was not to complicate the protocol encoding too much. A solution was schetched up. It will be further refined and documented by Tom, Bob and Ira to go out on the DL early next week. - How do we handle the definition of the application/ipp specification? Considering that we have now simplified some of the I18N solution, the specification of the application/ipp text should be fairly straight forward. Ira will update his earlier draft for inclusion as Appendix in the Model document. - What do we do with the auto-sensing feature (see comments from Ned Freed)? The agreement was that the combination of a MIME type octet string document in combination with the Fidelity attribute set to FALSE, would indicate that the server would be allowed to try auto-sensing, if implemented. No new MIME type is required with this solution, and no new attribute will be added. Tom to check out and update the text if needed. - Comments on Don's revised Requirements draft. No comments at this stage on Don's latest draft circulated a couple of days ago. Instruct Don to pass the document on to the IETF ASAP. In worst case we can issue yet another draft later. - Stand of the Model & Semantics document? Scott has just circulated another intermediate draft for comments. He expects to do further tidying up of references etc., while waiting for the latest home work assignments to arrive. Steve has an outstanding home work assignment on describing relationships between different sets of attributes etc. Scott will need at least another week before being ready to send the Model document out as new I-D. Plesase read latest draft and give comments. - Stand of the Rationale document? Steve is still working on this. Expect to have the new draft out to the DL early next week. - Can we keep the schedule outlined in last week's phone conference? We are already delayed, the risk that we will not get ready this year is now relatively high, but we should try to keep up the speed. New objective is to have all texts ready and sent to the IETF to start the WG last call at the very latest before our next face-to-face meeting on October 29. Next phone conference is next Wednesday as usual. I have a scheduling problem next week and may not be able to attend. 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 From ipp-archive Wed Oct 15 19:08:44 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA23363 for ipp-outgoing; Wed, 15 Oct 1997 19:07:50 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Wed, 15 Oct 1997 17:06:43 -0600 From: Scott Isaacson To: cmanros@cp10.es.xerox.com, ipp@pwg.org Subject: Re: IPP> ADM - Minutes from PWG IPP Phone Conference 971015 Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org Precedence: bulk Additional Note: We discussed the need for ALL additional comments to be in the following form: ************ Suggested wording changes to the document using line numbers and section numbers. ************ We will not get done if we continue to allow for vague, not written, general comments about chanes, additions, or deletions. Proposals need to be rewrites of existing sections or written new sections with proposed placement within the document. All comments should be clarifications or fixes to broken things, we are not allowing new functionality. Scott >>> Carl-Uno Manros 10/15 4:31 PM >>> Minutes from PWG IPP Phone Conference 971015 Attending: Carl-Uno Manros Steve Zilles Tom Hastings Scott Isaacson Bob Herriot Ron Bergman Randy Turner Ira Mcdonald Patrick Powell - Review and comments on proposed solutions and text to meet the IETF I18N requirements: Long and intensive discussion covering how many different sources you might have for languages and how much flexibility is required in one request/response as well as associated with one printer or job object. One of the major objectives was not to complicate the protocol encoding too much. A solution was schetched up. It will be further refined and documented by Tom, Bob and Ira to go out on the DL early next week. - How do we handle the definition of the application/ipp specification? Considering that we have now simplified some of the I18N solution, the specification of the application/ipp text should be fairly straight forward. Ira will update his earlier draft for inclusion as Appendix in the Model document. - What do we do with the auto-sensing feature (see comments from Ned Freed)? The agreement was that the combination of a MIME type octet string document in combination with the Fidelity attribute set to FALSE, would indicate that the server would be allowed to try auto-sensing, if implemented. No new MIME type is required with this solution, and no new attribute will be added. Tom to check out and update the text if needed. - Comments on Don's revised Requirements draft. No comments at this stage on Don's latest draft circulated a couple of days ago. Instruct Don to pass the document on to the IETF ASAP. In worst case we can issue yet another draft later. - Stand of the Model & Semantics document? Scott has just circulated another intermediate draft for comments. He expects to do further tidying up of references etc., while waiting for the latest home work assignments to arrive. Steve has an outstanding home work assignment on describing relationships between different sets of attributes etc. Scott will need at least another week before being ready to send the Model document out as new I-D. Plesase read latest draft and give comments. - Stand of the Rationale document? Steve is still working on this. Expect to have the new draft out to the DL early next week. - Can we keep the schedule outlined in last week's phone conference? We are already delayed, the risk that we will not get ready this year is now relatively high, but we should try to keep up the speed. New objective is to have all texts ready and sent to the IETF to start the WG last call at the very latest before our next face-to-face meeting on October 29. Next phone conference is next Wednesday as usual. I have a scheduling problem next week and may not be able to attend. 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 From ipp-archive Wed Oct 15 19:33:44 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA23980 for ipp-outgoing; Wed, 15 Oct 1997 19:32:40 -0400 (EDT) Message-ID: From: "Turner, Randy" To: ipp@pwg.org Subject: RE: IPP> ADM - Minutes from PWG IPP Phone Conference 971015 Date: Wed, 15 Oct 1997 16:31:06 -0700 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: ipp-owner@pwg.org Precedence: bulk Scott (and everybody...) I sent mail out a week or so ago about the procedure for clients to determine what TCP port to use for connecting to an IPP server. I received no negative comments and was wondering about the possibility of including this text in the model document? Randy > -----Original Message----- > From: Scott Isaacson [SMTP:SISAACSON@novell.com] > Sent: Wednesday, October 15, 1997 4:07 PM > To: cmanros@cp10.es.xerox.com; ipp@pwg.org > Subject: Re: IPP> ADM - Minutes from PWG IPP Phone Conference > 971015 > > Additional Note: > > We discussed the need for ALL additional comments to be in the > following > form: > > ************ > Suggested wording changes to the document using line numbers and > section > numbers. > ************ > > We will not get done if we continue to allow for vague, not written, > general > comments about chanes, additions, or deletions. Proposals need to be > rewrites of existing sections or written new sections with proposed > placement within the document. All comments should be clarifications > or > fixes to broken things, we are not allowing new functionality. > > Scott > > > >>> Carl-Uno Manros 10/15 4:31 PM >>> > Minutes from PWG IPP Phone Conference 971015 > > Attending: Carl-Uno Manros > Steve Zilles > Tom Hastings > Scott Isaacson > Bob Herriot > Ron Bergman > Randy Turner > Ira Mcdonald > Patrick Powell > > - Review and comments on proposed solutions and text to meet the IETF > I18N > requirements: > > Long and intensive discussion covering how many different sources you > might > have for languages and how much flexibility is required in one > request/response as well as associated with one printer or job object. > One > of the major objectives was not to complicate the protocol encoding > too > much. A solution was schetched up. It will be further refined and > documented by Tom, Bob and Ira to go out on the DL early next week. > > - How do we handle the definition of the application/ipp > specification? > > Considering that we have now simplified some of the I18N solution, the > specification of the application/ipp text should be fairly straight > forward. Ira will update his earlier draft for inclusion as Appendix > in the > Model document. > > - What do we do with the auto-sensing feature (see comments from Ned > Freed)? > > The agreement was that the combination of a MIME type octet string > document > in combination with the Fidelity attribute set to FALSE, would > indicate > that the server would be allowed to try auto-sensing, if implemented. > No > new MIME type is required with this solution, and no new attribute > will be > added. Tom to check out and update the text if needed. > > - Comments on Don's revised Requirements draft. > > No comments at this stage on Don's latest draft circulated a couple of > days > ago. Instruct Don to pass the document on to the IETF ASAP. In worst > case > we can issue yet another draft later. > > - Stand of the Model & Semantics document? > > Scott has just circulated another intermediate draft for comments. He > expects to do further tidying up of references etc., while waiting for > the > latest home work assignments to arrive. Steve has an outstanding home > work > assignment on describing relationships between different sets of > attributes > etc. Scott will need at least another week before being ready to send > the > Model document out as new I-D. Plesase read latest draft and give > comments. > > - Stand of the Rationale document? > > Steve is still working on this. Expect to have the new draft out to > the DL > early next week. > > - Can we keep the schedule outlined in last week's phone conference? > > We are already delayed, the risk that we will not get ready this year > is > now relatively high, but we should try to keep up the speed. New > objective > is to have all texts ready and sent to the IETF to start the WG last > call > at the very latest before our next face-to-face meeting on October 29. > > Next phone conference is next Wednesday as usual. I have a scheduling > problem next week and may not be able to attend. > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From ipp-archive Wed Oct 15 20:03:44 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA24618 for ipp-outgoing; Wed, 15 Oct 1997 20:01:37 -0400 (EDT) From: don@lexmark.com Message-Id: <199710160001.AA04073@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org Date: Wed, 15 Oct 1997 19:54:04 -0400 Subject: IPP> Requirements Draft Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Precedence: bulk I have submitted a new version of the Requirements Document to the IETF. I also posted text and PDF versions on the ftp server as follows: ftp://ftp.pwg.org/pub/pwg/ipp/new_REQ/draft-ietf-ipp-req-01.txt ftp://ftp.pwg.org/pub/pwg/ipp/new_REQ/draft-ietf-ipp-req-01.pdf Don Wright ********************************************** * Don Wright don@lexmark.com * * Manager, Strategic Alliances and Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-archive Thu Oct 16 12:23:54 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA26266 for ipp-outgoing; Thu, 16 Oct 1997 12:22:33 -0400 (EDT) From: Carl Kugler To: Subject: IPP>PRO Magic Numbers in ipp-messages Message-ID: <5030100011049038000002L082*@MHS> Date: Thu, 16 Oct 1997 12:22:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk I'd like to propose a change to the IPP encoding that would allow more = robust implementations in a world of buggy HTTP implementations. Specifically= , I propose adding a magic number at the beginning of the ipp-message: ipp-message =3D ipp-request / ipp-response ipp-request =3D magic-number version operation *(xxx-attributes-tag xxx-attribute-sequence) data-tag data ipp-response =3D magic-number version status-code *(xxx-attributes-tag xxx-attribute-sequence) data-tag data= magic-number =3D %x3f2c59d1 ;Literal 4 byte value to be ;defined by the protocol specification Why would this be a useful addition to the protocol? Take the example = of an IPP client reading a ipp-response. The client can check the beginning = of the entity-body for the magic-number. If there is a mismatch, it's not saf= e to proceed with parsing the rest of the entity body, and the client should= raise some kind of protocol exception. It might be worth scanning a few byte= s along in the data stream looking for the magic-number in case a buggy HTTP tr= ansport layer has, say, inserted an extra CRLF after the message-header. This kind of sanity check is difficult to apply to the protocol stream = as it's defined today, for example (pulled from the INTERNET-DRAFT IPP/1.0: Pro= tocol Specification September 29, 1997): The following is the beginning of an example of a Print-Job request: Octets Symbolic Value Protocol field 0x0100 1.0 version 0x0002 PrintJob operation 0x01 start operation- operation-attributes tag attributes ... Instead, I'd like to see this: Octets Symbolic Value Protocol field 0x3f2c59d1 magic-number 0x0100 1.0 version 0x0002 PrintJob operation 0x01 start operation- operation-attributes tag attributes ... I've seen this kind of thing done before, for example, in graphics inte= rchange formats and various APIs. Unnecessary in theory, but a practical way to= add some robustness. Carl Kugler IBM kugler@us.ibm.net 303-924-5060 = From ipp-archive Thu Oct 16 16:48:57 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA27610 for ipp-outgoing; Thu, 16 Oct 1997 16:46:32 -0400 (EDT) From: "Zehler,Peter" To: "Redirector IPP (E-mail)" Cc: "Bob Herriot (E-mail)" , "Patrick Powell (E-mail)" Subject: IPP> PRO interoperability clarification request from TES Date: Thu, 16 Oct 1997 13:49:42 PDT X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain; charset="iso-8859-1" Message-Id: <97Oct16.134623pdt."52870(3)"@alpha.xerox.com> Sender: ipp-owner@pwg.org Precedence: bulk All, After some testing of two independent implementations of IPP I believe a clarification is required in the protocol specification. (IMHO)For simplicity in parsing I hope that xxx-attributes-tags should only be sent when an xxx-attribute-sequence is present in the IPP payload. I see no reason for a xxx-attributes-tags by itself. A data-tag by itself makes sense to delimit an IPP header in a data stream. Attached(PROP I) are the modifications I suggest. If we intend to allow xxx-attributes-tags without any associated attributes I believe clarification is needed. I have attached(PROP II) modification to clarify this. Of course there is always "leave it alone"(PROP III). Pete PS Pat: Let me know when your address is updated in the IPP DL. I'll stop cc'ing you. _________________________ PROP I Clarification in ipp-pro-971014.doc suggested: Section 3.1: picture of encoding stays the same line 140: "unsupported-job. The xxx-attributes-tag and xxx-attribute-sequence may be omitted if the operation has no attributes or it may be"... change to "unsupported-job. The xxx-attributes-tag and xxx-attribute-sequence MUST be omitted if the operation has no attributes or it may be" ... line 145: "An xxx-attributes-sequence consists of zero or more compound-attributes." change to "An xxx-attributes-sequence consists of one or more compound-attributes." line 182(parsing diagram): "| empty or rest of attribute | x bytes |" change to "| rest of attribute | x bytes |" section 3.2: line 202(syntax of encoding): "xxx-attribute-sequence = *compound-attribute" change to "xxx-attribute-sequence = 1*compound-attribute" section 3.6.1: no change. _________________________ PROP II Clarification in ipp-pro-971014.doc suggested: Section 3.1: picture of encoding: "| xxx-attribute-sequence | n bytes |" change to "| xxx-attribute-sequence |0 to n bytes|" line 140: "unsupported-job. The xxx-attributes-tag and xxx-attribute-sequence may be omitted if the operation has no attributes or it may be"... change to "unsupported-job. The xxx-attributes-tag and xxx-attribute-sequence or just the xxx-attribute-sequence may be omitted if the operation has no attributes. The tag and sequence may be"... parsing diagram: no change section 3.2: line 202(syntax of encoding): No change section 3.6.1: line 263 to 266: "The operation-attributes-tag SHALL precede those attributes defined as operation attributes in the model document. The job-attributes-tag SHALL precede those attributes defined as job attributes in the model document. The printer-attributes-tag SHALL precede those attributes defined as printer attributes in the model document. The unsupported-job-attributes-tag SHALL precede those attributes defined as unsupported job attributes in the model document Change to: "Those attributes defined as operation attributes in the model document SHALL be preceded by the operation-attributes-tag. Those attributes defined as job attributes in the model document SHALL be preceded by the job-attributes-tag. Those attributes defined as printer attributes in the model document SHALL be preceded by the printer-attributes-tag. Those attributes defined as unsupported job attributes in the model document SHALL be preceded by the unsupported-job-attributes-tag. Any of the tags may appear without any associated attributes." __________________________________ Email: pzehler@channels.mc.xerox.com US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. Webster NY, 14580-9701 Voice: (716) 265-8755 FAX: (716)265-8792 __________________________________ "I always wanted to be somebody, but I should have been more specific." Lily Tomlin __________________________________ From ipp-archive Thu Oct 16 21:28:59 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA00154 for ipp-outgoing; Thu, 16 Oct 1997 21:25:53 -0400 (EDT) Date: Thu, 16 Oct 1997 18:23:34 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199710170123.SAA03809@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>MOD Concern about Event Notification Content X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk I just noticed that the IPP model document now has an Event Notification Content attribute whose format is US-ASCII even though it is intended for machine consumption. I am concerned about freezing this format into the standard because I think that it is a mistake. I suggest that the format of this message should be in the IPP protocol format so that the notification content can represent whatever the protocol can represent. Text in different languages is one thing that comes to mind. This means that for HTTP, the content would go as an application/ipp entity in an HTTP request and we need a new IPP operation called "notify". For email, it could go as a Multipart/alternative with one part text/plain whose content is specified but whose format is unspecified and with another part which is application/ipp. Alternatively, we could have two variants of email, one for human consumption and one for machine consumption. Although we may be too late in the process to solve this problem as I have suggested, it is not too late to remove the specification of the Event Notification Content so that we don't freeze a mistake. Bob Herriot From ipp-archive Thu Oct 16 22:03:59 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA00820 for ipp-outgoing; Thu, 16 Oct 1997 22:03:09 -0400 (EDT) Message-ID: <3446C72A.CDFFA84E@underscore.com> Date: Thu, 16 Oct 1997 22:02:18 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.02 [en] (WinNT; I) MIME-Version: 1.0 To: Robert Herriot CC: ipp@pwg.org Subject: Re: IPP>MOD Concern about Event Notification Content References: <199710170123.SAA03809@woden.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk I think it is way too late to get notification down *right* for IPP v1.0, and therefore it should be removed altogether for v1.0 and put high on the list for v1.1 (or whatever we call the "next" version of IPP). ...jay Robert Herriot wrote: > > I just noticed that the IPP model document now has an Event Notification > Content attribute whose format is US-ASCII even though it is intended > for machine consumption. > > I am concerned about freezing this format into the standard because > I think that it is a mistake. > > I suggest that the format of this message should be in the IPP protocol > format so that the notification content can represent whatever the > protocol can represent. Text in different languages is one thing > that comes to mind. > > This means that for HTTP, the content would go as an application/ipp > entity in an HTTP request and we need a new IPP operation called "notify". > > For email, it could go as a Multipart/alternative with one part > text/plain whose content is specified but whose format is unspecified > and with another part which is application/ipp. Alternatively, we > could have two variants of email, one for human consumption and one > for machine consumption. > > Although we may be too late in the process to solve this problem as I > have suggested, it is not too late to remove the specification of the > Event Notification Content so that we don't freeze a mistake. > > Bob Herriot From ipp-archive Thu Oct 16 22:54:00 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA01468 for ipp-outgoing; Thu, 16 Oct 1997 22:52:04 -0400 (EDT) Date: Thu, 16 Oct 1997 19:50:02 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199710170250.TAA03862@woden.eng.sun.com> To: Robert.Herriot@Eng.Sun.COM, jkm@underscore.com Subject: Re: IPP>MOD Concern about Event Notification Content Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk I agree with you. It is better to remove an incomplete feature and do it correctly later, than to leave in a mistake. My original email (below) suggested that removing the feature might be the best option. Bob Herriot > From jkm@underscore.com Thu Oct 16 19:01:46 1997 > > I think it is way too late to get notification down *right* for > IPP v1.0, and therefore it should be removed altogether for v1.0 > and put high on the list for v1.1 (or whatever we call the "next" > version of IPP). > > ...jay > > > Robert Herriot wrote: > > > > I just noticed that the IPP model document now has an Event Notification > > Content attribute whose format is US-ASCII even though it is intended > > for machine consumption. > > > > I am concerned about freezing this format into the standard because > > I think that it is a mistake. > > > > I suggest that the format of this message should be in the IPP protocol > > format so that the notification content can represent whatever the > > protocol can represent. Text in different languages is one thing > > that comes to mind. > > > > This means that for HTTP, the content would go as an application/ipp > > entity in an HTTP request and we need a new IPP operation called "notify". > > > > For email, it could go as a Multipart/alternative with one part > > text/plain whose content is specified but whose format is unspecified > > and with another part which is application/ipp. Alternatively, we > > could have two variants of email, one for human consumption and one > > for machine consumption. > > > > Although we may be too late in the process to solve this problem as I > > have suggested, it is not too late to remove the specification of the > > Event Notification Content so that we don't freeze a mistake. > > > > Bob Herriot > From ipp-archive Fri Oct 17 08:24:05 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA02508 for ipp-outgoing; Fri, 17 Oct 1997 08:21:13 -0400 (EDT) Date: Fri, 17 Oct 1997 05:25:08 PDT From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9710171225.AA20324@snorkel.eso.mc.xerox.com> To: Robert.Herriot@Eng.Sun.COM, ipp@pwg.org Subject: Re: IPP>MOD Concern about Event Notification Content Sender: ipp-owner@pwg.org Precedence: bulk Hi Bob, Good catch. Tom Hastings and I also found that some "text" attributes (like xxx-state-message) were being erroneously conveyed in strict US-ASCII while we were working through issues around the simplifications for localization that you (Bob) proposed during Wednesday afternoon's IPP telecon. I agree that we should either remove the Event Notification content from the spec OR fix it to use IPP standard encoding format. Note however, that doing reverse HTTP (from a server TO a client) for notification is not a trivial burden for clients to absorb. We certainly have to fix it or remove it from IPP/1.0. Cheers, - Ira McDonald (outside consultant at Xerox) ------------------------ Bob's note ------------------------- >From ipp-owner@pwg.org Thu Oct 16 21:46:41 1997 Return-Path: Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA20235; Thu, 16 Oct 97 21:46:40 EDT Received: from alpha.xerox.com by zombi (4.1/SMI-4.1) id AA01984; Thu, 16 Oct 97 21:42:22 EDT Received: from lists.underscore.com ([199.125.85.31]) by alpha.xerox.com with SMTP id <53179(1)>; Thu, 16 Oct 1997 18:42:25 PDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA00516 for ; Thu, 16 Oct 1997 21:38:56 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Thu, 16 Oct 1997 21:36:11 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA00154 for ipp-outgoing; Thu, 16 Oct 1997 21:25:53 -0400 (EDT) Date: Thu, 16 Oct 1997 18:23:34 PDT From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199710170123.SAA03809@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>MOD Concern about Event Notification Content X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Status: R I just noticed that the IPP model document now has an Event Notification Content attribute whose format is US-ASCII even though it is intended for machine consumption. I am concerned about freezing this format into the standard because I think that it is a mistake. I suggest that the format of this message should be in the IPP protocol format so that the notification content can represent whatever the protocol can represent. Text in different languages is one thing that comes to mind. This means that for HTTP, the content would go as an application/ipp entity in an HTTP request and we need a new IPP operation called "notify". For email, it could go as a Multipart/alternative with one part text/plain whose content is specified but whose format is unspecified and with another part which is application/ipp. Alternatively, we could have two variants of email, one for human consumption and one for machine consumption. Although we may be too late in the process to solve this problem as I have suggested, it is not too late to remove the specification of the Event Notification Content so that we don't freeze a mistake. Bob Herriot From ipp-archive Fri Oct 17 09:54:06 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA03418 for ipp-outgoing; Fri, 17 Oct 1997 09:51:56 -0400 (EDT) Message-Id: <199710171351.JAA08674@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ipp@pwg.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: IPP> I-D ACTION:draft-ietf-ipp-req-01.txt Date: Fri, 17 Oct 1997 09:51:52 -0400 Sender: ipp-owner@pwg.org Precedence: bulk --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 : Requirements for an Internet Printing Protocol Author(s) : F. Wright Filename : draft-ietf-ipp-req-01.txt Pages : 55 Date : 16-Oct-97 This document is one of a set of documents which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing on the Internet. The protocol is heavily influenced by the printing model introduced in the Document Printing Application (ISO/IEC 10175 DPA) standard. Although DPA identifies the both end user and administrative features, IPP is initially focused only on the end user functionality. The full set of IPP documents include: Requirements for an Internet Printing Protocol Internet Printing Protocol/1.0: Model and Semantics Internet Printing Protocol/1.0: Protocol Specification Rationale for the Structure and Model and Protocol for the Internet Printing Protocol Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipp-req-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-req-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipp-req-01.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19971017094820.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-req-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-req-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971017094820.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-archive Fri Oct 17 12:24:07 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA04158 for ipp-outgoing; Fri, 17 Oct 1997 12:21:00 -0400 (EDT) Message-Id: <3.0.1.32.19971017092420.0113c900@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 17 Oct 1997 09:24:20 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Agreed changes for internationalization Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk This proposal was agreed to at the telecon, 10/15/97. We believe that this proposal meets the IETF Character Set and Language Policy. This proposal does not use RFC 2184 tags, changing a decision we made at the 9/17/97 Atlanta meeting. Instead, it uses an approach which does not require any extra information in attribute values for conforming implementations. Only if an implementer chooses to support the OPTION of allowing the charset and/or natural language to be different amongst attributes in the request or in the response is there additional information passed in the attribute value to indicate the different charset and/or natural language. Finally, most of the complexity here is for an implementation that supports multiple charsets and/or multiple languages in 'text' and 'name' attributes. Implementations that support only a single charset or language can avoid most of this complexity. The text changes to incorporate this are straightforward to make in the text changes of the Model document dated 10/14/97. Please send any comments ASAP, while we are writing up the exact text changes, if you see any problems. The 'text' and 'name' attribute involved are: Operation Attributes: document-name (name) Job Attributes: job-name (name) job-originating-user (name) job-state-message (text) job-message-from-operator (text) Printer Attributes: printer-name (name) printer-location (text) printer-info (text) printer-make-and-model (text) printer-state-message (text) printer-message-from-operator (text) The following attributes are described in the proposal: Operational Attributes: operation-charset operation-natural-language Job Attributes: job-charset job-natural-language Printer Attributes: printer-charset printer-charset-supported (no "s" to agree with Job Template) printer-natural-language printer-natural-language-supported (no "s" to agree with Job Template) All other IPP Job and Printer attributes are of other attribute syntaxes and so are not affected by this internationalization proposal. Each numbered point applies to both charset and natural language. Points with "a" are just charset and points with "b" are just natural language. Here are the major points of the simplification: 1. Support of the UTF-8 charset is MANDATORY for all 'text' and 'name' attributes supported by the Printer object. Support for additional charsets is optional, but if supported, SHALL be as specified below. 2. The client SHALL supply the "operation-charset" and "operation-natural-language" attributes in the operations attribute group in every request. These attributes indicate the charset and natural language of the 'text' and 'name' attributes being supplied in the request. The "operation-charset" also identifies the charset that the Printer SHALL use in the response. The "operation-natural-language' attribute identifies the natural language that the Printer SHOULD use in the response. 3. On the create job operations, the Printer object SHALL store the values of the client-supplied "operation-charset" and "operation-natural-language" attributes as the values of the "job-charset" and the "job-natural-language" Job Description attributes, which clients may query. 4. The Printer object SHALL return the "operation-charset" and "operation-natural-language" attributes in the operations attribute group in every response. These attributes indicate the charset and natural language of the 'text' and 'name' attributes being returned in the response. 5. Change the spec to NOT pass the "operation-charset" and "operation-natural-language" attributes via HTTP/1.1 header and "Content-Type", but just as other IPP operation attributes. 6a. A Printer object SHALL reject an operation that supplies an unsupported charset value in the "operation-charset" operation attribute with the error code ??? (new one or use some existing one?). 6b. A Printer object SHALL either (1) accept an operation that supplies an unsupported natural language in the "operation-natural-language" operation attribute or reject the operation with the error code??? (new one or use some existing one?), depending on implementation. NOTE: THE REMAINING POINTS ONLY APPLY TO IMPLEMENTATIONS THAT SUPPORT MORE THAN ONE CHARSET OR MORE THAN ONE NATURAL LANGUAGE. THEREFORE, THE FOLLOWING COMPLEXITY IS NOT A BURDEN TO ALL IMPLEMENTATIONS. 7a. A response MUST be in the same charset as the request. The Printer "printer-charset-supported" attribute SHALL list the charsets supported by the Printer object which SHALL contain at least the value 'utf-8'. If the Printer object supports more than just the 'utf-8' charset, the Printer object SHALL be able to code convert between each of the codesets supported on a highest fidelity possible basis. However, some information loss MAY occur curing the codeset conversion depending on the charsets involved. For example, the Printer object may convert from a UTF-8 'a' to a US-ASCII 'a' (with no loss of information), from an ISO Latin 1 CAPITAL LETTER A WITH ACUTE ACCENT to US-ASCII 'A' (losing the accent), or from a UTF-8 Japanese Kanji character to some ISO Latin 1 error character indication such as '?', decimal code eqivalent, or to the absence of a character, depending on implementation. NOTE to client implementors: When submitting a request, if your client passes a small charset, such as US-ASCII, in the "operation-charset" operation attribute, you may lose information since the Printer will be constrained to return the response in US-ASCII. 7b. A Printer SHOULD do its best to respond in the same natural language. The Printer "printer-natural-language-supported" attribute SHALL list the natural languages supported. For any of the attributes for which the Printer generates messages, i.e., for the "job-state-message" and "printer-state-message" attributes in operation responses and notifications, the Printer object SHALL be able to generate messages in any of its supported natural languages. If the Printer object supports neither the "job-state-message" nor the "printer-state-message" attribute, then the "printer-natural-language-supported" NEED NOT be implemented or MAY have the same (single) value as the "printer-natural-language" attribute. The description for each 'text' and 'name' attribute, including future registration proposals, SHALL specify whether the Printer object MUST support its value in all supported natural languages or not. For other Printer 'text' and 'name' attributes supplied by the operator, system administrator, or manufacturer, i.e., for "printer-name" (name), "printer-location" (text), "printer-info", and "printer-make-and-model" (text), the Printer object is only required to support the configured natural language of the Printer identified by the Printer's "printer-natural-language " attribute, though support of additional natural languages for these attributes is permitted. For the 'name' and 'text' attributes supplied by the client, i.e., "job-name" (name) and "job-originating-user" (name), the Printer object MAY indicate the natural language that the client supplied using the method described in 9b (below). If the client requests a natural language that is not supported, the Printer object SHALL return the "job-state-message" and/or the "printer-state-message" in the Printer's configured natural language as specified by the Printer's "printer-natural-language " attribute. 8a. Each job MAY have been submitted with a different charset. For the Get-Jobs operation response, the Printer object SHALL return 'text' and 'name' attributes in the charset requested by the client in the "operation-charset" operation attribute. This requirement may cause the Printer object to codeset convert the 'text' and 'name' attribute data to the charset requested by the client using the "highest fidelity" technique described in 7a above. 8b. Each job MAY have been submitted with a different natural langauge. For the Get-Jobs operation response, the Printer object SHALL include the job's "job-natural-language" as the first attribute returned for each Job object for each Job object which is in a different natural language than the Printer returned in the "operation-natural-language" operation attribute. 9a. We considered that the client did not need to pass in "exception" charset attribute values and the Printer is constrained to return all 'text' and 'name' in a single charset, so we don't need a way to identify a different charset for an attribute value than the one passed in the "operation-charset" operation attribute. 9b. If the client needs to pass or the Printer object needs to return a 'text' or 'name' attribute in a different natural language than the rest of the 'text' and 'name' attributes in the request as indicated by the "operation-natural-language" operation attribute, the client or Printer object may immediately precede that attribute value with a 'naturalLanguage' attribute value that indicates the differing natural language. Thus the attribute becomes multi-valued. If the attribute is multi-valued (1setOf X), then the 'naturalLanguage' value applies only to the next 'text' or 'name' value. Subsequent 'text' and 'name' values revert to the natural language of the operation attribute or the "job-natural-language" job attribute, if present in the case of a Get-Jobs response. If the client supplies a 'naturalLanguage' attribute value that is NOT one of the supported natural languages, the Printer SHALL either (1) reject the request with error code ??? or accept the unsupported natural language, depending on implementation. 10. ISSUE: Need to determine how to pass charset and natural language information in the notification content. We could continue to use the RFC 2184 tags as currently specified. Another idea is to pass additional charset and natural language attributes that affect the immediately following attribute. Still another approach would be to change the Notification Content into an application/ipp notifiy operation request and use the encoding from the protocol. The simplest approach would be only to provide for human readable notification in IPP/1.0 and add software processable notifications after V1.0. Then such human readable notification would be in the charset and natural language supplied in the create operation. The format in the Model document could become just an example. Again, please send any comments ASAP, while we are writing up the exact text changes, if you see any problems. Thanks, Tom From ipp-archive Fri Oct 17 13:19:07 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA04817 for ipp-outgoing; Fri, 17 Oct 1997 13:18:55 -0400 (EDT) Message-Id: <3.0.1.32.19971017100419.009f0640@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 17 Oct 1997 10:04:19 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: Re: IPP>MOD Concern about Event Notification Content In-Reply-To: <199710170123.SAA03809@woden.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk At 06:23 PM 10/16/97 PDT, Robert Herriot wrote: >I just noticed that the IPP model document now has an Event Notification >Content attribute whose format is US-ASCII even though it is intended >for machine consumption. > >I am concerned about freezing this format into the standard because >I think that it is a mistake. Bob and others that have responded to Bob's message, My view is that it would be highly undesirable to just take out the whole concept of notifications, about which we have had general agreement right from the start of the project. Also, trying to leave out the format specification while keeping the attributes etc., I do not think is going to fly when the IESG reviews the document. Looking at the actual text that we are discussing, it seems that there are about 30 lines of text starting with line number 1752 (from the PDF version of Scott's latest draft). Reading through that, I think that we have most of the right semantics in there already, except for an inconsistent statement about the use of ASCII. We should not throw out the baby with the bath water! My suggestion is to rewrite the text in these 30 lines and instead create an additional MIME type called "application/ipp-notification", which contains the right language and encoding for I18N in the right places, building on what we currently have. This MIME type could be carried in SMTP, over HTTP, or other protocols. This does not seem such a major job. I do not think it would be a problem to work out the details within a week. Comments? Volonteers? 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 From ipp-archive Fri Oct 17 14:29:08 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA05928 for ipp-outgoing; Fri, 17 Oct 1997 14:24:21 -0400 (EDT) Message-ID: <3447AC8A.C5D519E9@underscore.com> Date: Fri, 17 Oct 1997 14:20:58 -0400 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.02 [en] (WinNT; I) MIME-Version: 1.0 To: Carl-Uno Manros CC: ipp@pwg.org Subject: Re: IPP>MOD Concern about Event Notification Content References: <3.0.1.32.19971017100419.009f0640@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Carl-Uno, You're correct in that it probably won't take much time to hack up the existing text to nail down some kind of encoding that would be palatable to the IESG or whomever. That is not what concerns me about IPP notification, however. What does concern me is that no one has offered up any REAL scenarios illustrating how IPP notification would actually work. Sure, people have made comments to the effect of "just send an email message". But I think we really need to walk thru multiple (not just one) method of using IPP notification data to ensure that the resulting facility is indeed useful as designed. Do I have any suggestions? Not at this time...which is one reason I suggested we defer this entire capability until the next version of IPP. Event notification is NOT something we want to take lightly, nor do a half-baked job. Believe me, after spending the last 2 years on SENSE development, it's pretty easy to hack together a "solution" that appears to be useful, but ultimately falls short in the long run. (That's not to say our SENSE implementation falls short, mind you... ;-) ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- Carl-Uno Manros wrote: > > At 06:23 PM 10/16/97 PDT, Robert Herriot wrote: > >I just noticed that the IPP model document now has an Event Notification > >Content attribute whose format is US-ASCII even though it is intended > >for machine consumption. > > > >I am concerned about freezing this format into the standard because > >I think that it is a mistake. > > Bob and others that have responded to Bob's message, > > My view is that it would be highly undesirable to just take out the whole > concept of notifications, about which we have had general agreement right > from the start of the project. Also, trying to leave out the format > specification while keeping the attributes etc., I do not think is going to > fly when the IESG reviews the document. Looking at the actual text that we > are discussing, it seems that there are about 30 lines of text starting > with line number 1752 (from the PDF version of Scott's latest draft). > Reading through that, I think that we have most of the right semantics in > there already, except for an inconsistent statement about the use of ASCII. > We should not throw out the baby with the bath water! > > My suggestion is to rewrite the text in these 30 lines and instead create > an additional MIME type called "application/ipp-notification", which > contains the right language and encoding for I18N in the right places, > building on what we currently have. This MIME type could be carried in > SMTP, over HTTP, or other protocols. > > This does not seem such a major job. I do not think it would be a problem > to work out the details within a week. > > Comments? Volonteers? > > 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 From ipp-archive Fri Oct 17 16:19:09 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA06656 for ipp-outgoing; Fri, 17 Oct 1997 16:16:10 -0400 (EDT) Message-Id: <3.0.1.32.19971017130144.009f02e0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 17 Oct 1997 13:01:44 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: Re: IPP>MOD Concern about Event Notification Content In-Reply-To: <3447AC8A.C5D519E9@underscore.com> References: <3.0.1.32.19971017100419.009f0640@garfield> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk At 11:20 AM 10/17/97 PDT, you wrote: >Carl-Uno, > >You're correct in that it probably won't take much time to hack >up the existing text to nail down some kind of encoding that would >be palatable to the IESG or whomever. > >That is not what concerns me about IPP notification, however. >What does concern me is that no one has offered up any REAL >scenarios illustrating how IPP notification would actually work. > >Sure, people have made comments to the effect of "just send an email >message". But I think we really need to walk thru multiple (not >just one) method of using IPP notification data to ensure that the >resulting facility is indeed useful as designed. > >Do I have any suggestions? Not at this time...which is one reason >I suggested we defer this entire capability until the next version >of IPP. > >Event notification is NOT something we want to take lightly, nor >do a half-baked job. Believe me, after spending the last 2 years >on SENSE development, it's pretty easy to hack together a "solution" >that appears to be useful, but ultimately falls short in the long >run. (That's not to say our SENSE implementation falls short, >mind you... ;-) > > ...jay > Jay, I am not looking for anything very sophisticated here, just the ability for the end user to find out if a job completed correctly, or if not what problems it ran into. You can get that with many of the existing printing protocols already. And I claim that we already have the semantics for this in place in our current draft document. You can get very sophisticated and spend a long time on making the complete and perfect notification service for operators administrators etc., the messaging people in the IETF spent several years defining notifications, and now they spend another few years on doing receipts. But, as I said before I think that we have the semantics that we need for Version 1.0 of IPP. What we need to improve is the format and to allow flexibility for extensions in the next version of IPP. If we model that on what we alreay have in the application/ipp, I cannot see this being a monumental task. 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 From ipp-archive Fri Oct 17 16:43:04 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA07271 for ipp-outgoing; Fri, 17 Oct 1997 16:34:30 -0400 (EDT) Message-Id: <3.0.1.32.19971017131958.00b1b580@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 17 Oct 1997 13:19:58 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: Re: IPP>MOD Concern about Event Notification Content In-Reply-To: <3447AC8A.C5D519E9@underscore.com> References: <3.0.1.32.19971017100419.009f0640@garfield> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Oh, I had one more response, which I did not put in the previous message. At 11:20 AM 10/17/97 PDT, Jay Martin wrote: >Carl-Uno, > >You're correct in that it probably won't take much time to hack >up the existing text to nail down some kind of encoding that would >be palatable to the IESG or whomever. > >That is not what concerns me about IPP notification, however. >What does concern me is that no one has offered up any REAL >scenarios illustrating how IPP notification would actually work. > OK Jay, Let me try to describe a little scenario on how I think this could work. As before, the users specify their preferred language when submitting the job. The IPP sever runs into some status change that the user has asked to be notified about. The server then prepares the "application/ipp-notification" MIME content, taking into account the user's language preference. The MIME content is then sent over the protocol requested by the user and to the address(es) specified at submission time. The notification in MIME format arrives at the user's desktop and independently of how the notification got delivered, is now associated with a little application that either "translates" the content of the notification into a more user friendly display format and pops up a window, or alternatively hands it over to a log file, in which the user or an application can go and look for it at their convenience. Remember that we are only defining what goes over the protocol, we do not have to go into detail about the user interface aspects, as long as we know that there are several alternatives open. Is this a reasonable scenario that you could go along with? 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 From ipp-archive Fri Oct 17 17:59:10 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA08209 for ipp-outgoing; Fri, 17 Oct 1997 17:56:08 -0400 (EDT) Date: Fri, 17 Oct 1997 14:50:42 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199710172150.OAA04552@woden.eng.sun.com> To: cmanros@cp10.es.xerox.com, jkm@underscore.com Subject: Re: IPP>MOD Concern about Event Notification Content Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Jay, I think that you have raised some excellent points. While I agree with Carl-Uno that notification is important, the model document currently has an incomplete solution which cannot be made complete with a few small tweaks at the last minute. I do not think it is worth delaying IPP a few more months to get notification correct and I don't want to leave the existing wording in place. The current proposal has several problems: 1) the content is specified in yet another protocol format. We don't need that. It just allows us to have two protocols to solve each problem in. 2) the target schemes and their uses are not well thought out: ftp: I don't think that ftp appending-to-a-file is useful for a client. What on the client is supposed to monitor this and clean up the file when it gets too big. http: this presumes a client http server or some other mechanism we haven't thought through. Using application/ipp with a new "notify" operation makes the most sense in this case. But we haven't thought through how a client would plug into this or how a client listens to HTTP. mailto: this could be supported with free form text having certain suggested attribute values. It's not the most useful notification method, but it would work for human consumption. Notification adds up to a lot of good, but incomplete ideas. They don't belong in a standard that we will (hopefully) live with for many years. Perhaps mailto with an undefined human readable format is worth supporting in order to have notification, but even that may constrain us more in the future than we want. But if the group consensus is that we shouldn't toss out all notification from version 1.0, I could live with just mailto and free-form unspecified text. All the rest would take a lot more time to resolve and I don't think we have the time. Bob Herriot > From jkm@underscore.com Fri Oct 17 11:35:44 1997 > > Carl-Uno, > > You're correct in that it probably won't take much time to hack > up the existing text to nail down some kind of encoding that would > be palatable to the IESG or whomever. > > That is not what concerns me about IPP notification, however. > What does concern me is that no one has offered up any REAL > scenarios illustrating how IPP notification would actually work. > > Sure, people have made comments to the effect of "just send an email > message". But I think we really need to walk thru multiple (not > just one) method of using IPP notification data to ensure that the > resulting facility is indeed useful as designed. > > Do I have any suggestions? Not at this time...which is one reason > I suggested we defer this entire capability until the next version > of IPP. > > Event notification is NOT something we want to take lightly, nor > do a half-baked job. Believe me, after spending the last 2 years > on SENSE development, it's pretty easy to hack together a "solution" > that appears to be useful, but ultimately falls short in the long > run. (That's not to say our SENSE implementation falls short, > mind you... ;-) > > ...jay > > ---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com -- > -- Underscore, Inc. | Voice: (603) 889-7000 -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- > ---------------------------------------------------------------------- > > > Carl-Uno Manros wrote: > > > > At 06:23 PM 10/16/97 PDT, Robert Herriot wrote: > > >I just noticed that the IPP model document now has an Event Notification > > >Content attribute whose format is US-ASCII even though it is intended > > >for machine consumption. > > > > > >I am concerned about freezing this format into the standard because > > >I think that it is a mistake. > > > > Bob and others that have responded to Bob's message, > > > > My view is that it would be highly undesirable to just take out the whole > > concept of notifications, about which we have had general agreement right > > from the start of the project. Also, trying to leave out the format > > specification while keeping the attributes etc., I do not think is going to > > fly when the IESG reviews the document. Looking at the actual text that we > > are discussing, it seems that there are about 30 lines of text starting > > with line number 1752 (from the PDF version of Scott's latest draft). > > Reading through that, I think that we have most of the right semantics in > > there already, except for an inconsistent statement about the use of ASCII. > > We should not throw out the baby with the bath water! > > > > My suggestion is to rewrite the text in these 30 lines and instead create > > an additional MIME type called "application/ipp-notification", which > > contains the right language and encoding for I18N in the right places, > > building on what we currently have. This MIME type could be carried in > > SMTP, over HTTP, or other protocols. > > > > This does not seem such a major job. I do not think it would be a problem > > to work out the details within a week. > > > > Comments? Volonteers? > > > > 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 > From ipp-archive Fri Oct 17 23:34:18 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA09669 for ipp-outgoing; Fri, 17 Oct 1997 23:30:39 -0400 (EDT) From: don@lexmark.com Message-Id: <199710180330.AA04961@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org, jmp@pwg.prg, fin@pwg.org Date: Fri, 17 Oct 1997 23:22:51 -0400 Subject: IPP> PWG> Meeting Notice: January Joint PWG/PWG-C Meeting Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Precedence: bulk Please respond to Larry Stein (lstein@fapo.com). Don ---------------------- Forwarded by Don Wright on 10/17/97 11:20 PM --------------------------- To: p1394%pwg.org@interlock.lexmark.com, pwg%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright) Subject: PWG> Meeting Notice: January Joint PWG/PWG-C Meeting Hello all, Sorry for the duplicate lists. This is an advance meeting notice and request for the January 1998 PWG/PWG-C meeting in Hawaii. The hotel in Hawaii is not quite as flexible as one in Witchita, so I need to get some quick expectation as to how many people will be attending which meetings. Place: Maui Marriott on Kaanapali Beach When: Week of January 26-30, 1998 Schedule: 1/26-27 Joint 1394PWG/PWG-C meeting 1/28 IPP 1/29 IPP 1/30 JMP(?), FIN, TBD Room rate: $179 double, $25 per person to four people plus meeting charge TBD I have rooms set aside from Friday, 1/23 through Sunday, 2/1. In order to make this a smooth meeting setup I need to get a good idea of who is coming when, for how long and if there will be others coming. The facility has day programs for kids. We are going to try to plan something for Tuesday night. Please let me know if you want to attend (whatever it may be?). I realize that this is quite advance notice but please provide me with the following information as soon as possible: Name: Date arrival: Date checkout: What meetings: # Adults: # Kids: Tuesday night: y/n Thanks, Larry *************************************************************** Larry A. Stein Phone: (619)292-2742 Warp Nine Engineering Fax: (619)292-8020 Web: http://www.fapo.com *************************************************************** From ipp-archive Mon Oct 20 10:59:54 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA12443 for ipp-outgoing; Mon, 20 Oct 1997 10:56:17 -0400 (EDT) Date: Mon, 20 Oct 1997 08:08:37 -0700 (PDT) From: papowell@astart.com Message-Id: <199710201508.IAA25442@astart4.astart.com> To: cmanros@cp10.es.xerox.com, jkm@underscore.com Subject: Re: IPP>MOD Concern about Event Notification Content Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Precedence: bulk Asynchronous event notification. This area is extremely difficult to pin down and implement, in spite of what you might think. 1. Transport protocol to be used? TCP? UDP? 2. Application protocol to be used? TCP: SMTP? HTTP? Totally new one? UDP: SMTP? Totally new one? 3. OK, assume that we decide to use mail. 1. Use SMTP? ESMTP? 2. What headers in the message? 3. What is the format of the text? 4. Security issues? Using IPP for mail bombs? I think that quietly dropping notification until the next version of the protocol makes good sense. Patrick Powell From ipp-archive Mon Oct 20 16:24:01 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA13412 for ipp-outgoing; Mon, 20 Oct 1997 16:13:11 -0400 (EDT) From: don@lexmark.com Message-Id: <199710202012.AA00130@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: pwg@pwg.org, ipp@pwg.org, JMP@pwg.org, PMP@pwg.org, fin@pwg.org, sense@pwg.org, P1394@pwg.org Date: Mon, 20 Oct 1997 16:12:15 -0400 Subject: IPP> Boulder PWG Schedule / LA Meeting Details Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Precedence: bulk Unfortunately, I will not be in attendance at the October PWG meetings in Boulder. (First one I have ever missed -- there goes my record.) Below is the schedule for the meetings. Please read this very close as there are a couple of new things and some new starting times. October 27, 1997 8:30 - 5:30 1394 Printing - Greg LeClair October 28, 1997 8:30 - 5:30 1394 Printing - Greg LeClair October 29, 1997 8:00 - 8:30 Printer MIB Update - Lloyd Young 8:30 - 5:30 IPP - Carl-Uno Manros October 30, 1997 8:30 - 12:00 IPP - Carl-Uno Manros 1:00 - 6:00 Sense - JK Martin October 31, 1997 8:30 - 12:00 Finisher MIB - Harry Lewis 1:00 - 5:30 Job MIB - Ron Bergman If appropriate, more detailed agendas for each working group will be posted to the appropriate mailing list by the designated chairman. ------------- The details on the LA Meeting are as follows: Crown Plaza Hotel Los Angeles Airport 5985 W. Century Blvd. Los Angeles, CA 90045 PH: 310-642-7500 FAX: 310-216-6646 Room rate: $79.00 per night Parking: $6.00 per day Meeting room etc. about $30.00 - 35.00 per person per day The registration is in the name of: Xerox Deadline for the special room rate: November 7, 1997 This is at the airport, so you do not really need a car. The hotel has shuttles from the airport. -------------- Enjoy! Don Wright PWG Chair ********************************************** * Don Wright don@lexmark.com * * Manager, Strategic Alliances and Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-archive Mon Oct 20 19:34:59 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA15626 for ipp-outgoing; Mon, 20 Oct 1997 19:32:44 -0400 (EDT) Message-Id: <3.0.1.32.19971020161737.00a59a10@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 20 Oct 1997 16:17:37 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Agenda for PWG IPP Phone Conference on 971022 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Agenda for PWG IPP Phone Conference on 971022, 1:00 to 3:00 PST I have only got two agenda points for this Wednesday: 1) How should we fix the identified problem with asynchronous notifications? 2) Where do we stand on home work assignments and editing tasks? As I will be talking about IPP at the IOC'97 conference in San Diego on Wednesday, Steve Zilles will lead the discussion this week. The dial-in information is the same as last week: Date: 10/22 Time: 4PM Eastern, 1PM Pacific Number: 608-250-1828 Access: 190148 ---- 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 From ipp-archive Mon Oct 20 20:15:00 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA16276 for ipp-outgoing; Mon, 20 Oct 1997 20:14:26 -0400 (EDT) Message-Id: <3.0.1.32.19971020171823.010e93a0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 20 Oct 1997 17:18:23 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - ISSUE: # of octets of 'text'/'name' SHALL a Printer support? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Our current Model text gives upper bounds on the lengths of the 'text' and 'name' attributes as 4095 and 255 octets, respectively. However, we don't say how many of those octets a Printer object SHALL store. We also don't say what happens if a client supplies a value that is longer than the maximum size that a Printer supports. These are two issues that will affect interoperability. I suggest that we add two sentences something like: A Printer object SHALL support at least nnn octets in requests and responses. If a client supplies a value that exceeds nnn, the Printer object SHALL truncate the value on the right after the nnn-th octet. I propose that 'nnn' be 255 for text and 127 for names. UTF-8 takes about 1.7 octets per character on average for Western European names. Comments? Lets discuss at Wednesdays telecon. Thanks, Tom Here is the current text: 4.1.1 'text' The 'text' attribute syntax is a sequence of one or more characters with a limit of 1 to 4095 octets. The Printer object SHALL support UTF-8 [28] and MAY support additional charsets provided that they are registered with IANA [54]. ... 4.1.2 'name' The 'name' attribute syntax is the same as 'text', including the MANDATORY support of UTF-8 and the exception natural language mechanism, except that the sequence of characters is limited so that its encoded form is of length 1 to 255 octets. This syntax type is used for user-friendly strings, such as a Printer name, that, for humans, are more meaningful than identifiers. ... From ipp-archive Mon Oct 20 21:20:00 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA16941 for ipp-outgoing; Mon, 20 Oct 1997 21:16:33 -0400 (EDT) Message-Id: <3.0.1.32.19971020180122.00a33580@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 20 Oct 1997 18:01:22 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: Re: IPP> MOD - ISSUE: # of octets of 'text'/'name' SHALL a Printer support? In-Reply-To: <3.0.1.32.19971020171823.010e93a0@garfield> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Hmmm, Tom seems to have worked in other standardization projects than I have. In messaging and directory standards the meaning of an upper bound limit is that all implementations have be able to handle it if they get a text string of that length (without truncating it). Only if the upper limit is exceeded, it might be truncated by the receiving side, or alternatively a protocol error might be returned. Hence in my view the upper bound values ARE the length that the Printer object SHALL be able to store. My 2 cents. Carl-Uno At 05:18 PM 10/20/97 PDT, Tom Hastings wrote: >Our current Model text gives upper bounds on the lengths of the 'text' and >'name' attributes as 4095 and 255 octets, respectively. However, we don't >say how many of those octets a Printer object SHALL store. We also don't >say what happens if a client supplies a value that is longer than >the maximum size that a Printer supports. > >These are two issues that will affect interoperability. > >I suggest that we add two sentences something like: > >A Printer object SHALL support at least nnn octets in requests and responses. >If a client supplies a value that exceeds nnn, the Printer object SHALL >truncate the value on the right after the nnn-th octet. > >I propose that 'nnn' be 255 for text and 127 for names. UTF-8 takes about >1.7 octets per character on average for Western European names. > >Comments? Lets discuss at Wednesdays telecon. > >Thanks, >Tom > >Here is the current text: > > >4.1.1 'text' > >The 'text' attribute syntax is a sequence of one or more characters with a >limit of 1 to 4095 octets. The Printer object SHALL support UTF-8 [28] and >MAY support additional charsets provided that they are registered with IANA >[54]. > >... > > >4.1.2 'name' > >The 'name' attribute syntax is the same as 'text', including the MANDATORY >support of UTF-8 and the exception natural language mechanism, except that >the sequence of characters is limited so that its encoded form is of length >1 to 255 octets. This syntax type is used for user-friendly strings, such >as a Printer name, that, for humans, are more meaningful than identifiers. > >... > > > > 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 From ipp-archive Mon Oct 20 22:55:02 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA17666 for ipp-outgoing; Mon, 20 Oct 1997 22:52:47 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Mon, 20 Oct 1997 09:00:18 -0600 From: Scott Isaacson To: cmanros@cp10.es.xerox.com, Robert.Herriot@Eng.Sun.COM, jkm@underscore.com Cc: ipp@pwg.org Subject: Re: IPP>MOD Concern about Event Notification Content Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org Precedence: bulk >From day one, we said that we were not going to define a new "nofication protocol" for IPP and that for IPP/1.0 we would not define new "notify" operations. I want to adamantly stand by this. We can not and should not allow ourselves to get distracted by the absence of an messaging/event service for the Internet. As Jay has pointed out, this is something that needs to be designed and architected. Look at all the work that OMG COS event has done and all of the non-open solution providers have done - this is a big job and SHALL NOT be done as a "side effort" of the IPP working group. For the longest time we said "any supported URI scheme as the notification method with unspecified content or format". Then we said "boo, boo, ...., broken, bad...." and we started to say "any supported URI scheme with ONE specified content format for all notification methods FTP, MAILTO, etc." I hope we can all agree that what we now got is still "boo, boo, ...., broken, bad, ...." So we should retreat for 1.0, however still allow for some hooks (like we have done for driver download and "more info") but not formally specify it. Just leave it as hooks that might work in some given implementations. I think that we should suggest somewhere what the mail-safe message might look like. My comments below preceded by SAI> Scott >>> Robert Herriot 10/17 3:50 PM >>> ftp: I don't think that ftp appending-to-a-file is useful for a client. What on the client is supposed to monitor this and clean up the file when it gets too big. SAI> True, but why disallow it in an environment that may have client side file SAI> montoring already. These should just be hooks to allow something SAI> to maybe work, not full specifications of what to do with log file wrap SAI> and overflow. http: this presumes a client http server or some other mechanism we haven't thought through. Using application/ipp with a new "notify" operation makes the most sense in this case. But we haven't thought through how a client would plug into this or how a client listens to HTTP. SAI> True, but why disallow it in an environment where the address is SAI> not the client but a web server posting all event summaries? SAI> Again, these should just be hooks to allow something SAI> to maybe work, not full specifications of what the back end of the SAI> web server should do the event content. mailto: this could be supported with free form text having certain suggested attribute values. It's not the most useful notification method, but it would work for human consumption. SAI> This is how we should word the suggested content for all forms of SAI> notification. Perhaps mailto with an undefined human readable format is worth supporting in order to have notification, but even that may constrain us more in the future than we want. SAI> Perhaps allowing any supported URI with undefined content is SAI> worth supporting Scott From ipp-archive Tue Oct 21 08:25:07 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA18702 for ipp-outgoing; Tue, 21 Oct 1997 08:24:41 -0400 (EDT) From: don@lexmark.com Message-Id: <199710211224.AA04142@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org Date: Tue, 21 Oct 1997 08:24:25 -0400 Subject: IPP> MOD - ISSUE: # of octets of 'text'/'name' SHALL a Printer support? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Precedence: bulk Tom Hastings said: > >Our current Model text gives upper bounds on the lengths of the 'text' and >'name' attributes as 4095 and 255 octets, respectively. However, we don't >say how many of those octets a Printer object SHALL store. We also don't >say what happens if a client supplies a value that is longer than >the maximum size that a Printer supports. > >These are two issues that will affect interoperability. > >I suggest that we add two sentences something like: > >A Printer object SHALL support at least nnn octets in requests and responses. >If a client supplies a value that exceeds nnn, the Printer object SHALL >truncate the value on the right after the nnn-th octet. > >I propose that 'nnn' be 255 for text and 127 for names. UTF-8 takes about >1.7 octets per character on average for Western European names. > >Comments? Lets discuss at Wednesdays telecon. IMHO, people who read what we have and don't design to what you have explicitly required deserve the wrath of the users they will surely get. I can't see wasting the toner for two more paragraphs of SHALLs for something that is intuitively obvious. I'm not going to waste my time but I suspect if I looked, I could find 1000 other places where we have not defined every word of the Emglish language. Don ********************************************** * Don Wright don@lexmark.com * * Manager, Strategic Alliances and Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-archive Tue Oct 21 10:45:09 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA19402 for ipp-outgoing; Tue, 21 Oct 1997 10:45:03 -0400 (EDT) Message-Id: <3.0.1.32.19971021074853.011aa5f0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 21 Oct 1997 07:48:53 PDT To: ipp@pwg.org From: Tom Hastings Subject: Re: IPP> MOD - ISSUE: # of octets of 'text'/'name' SHALL a Printer support? In-Reply-To: <3.0.1.32.19971020171823.010e93a0@garfield> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk To make the discussion more concrete on the length (text=4095, name=255 octets), here are the attributes in IPP/1.0 that are involved: The 'text' and 'name' attribute involved are: Supplied by client? Operation Attributes: document-name (name) Yes Job Attributes: job-name (name) Yes job-originating-user (name) Yes job-state-message (text) No job-message-from-operator (text) No (at least not in V1.0) Printer Attributes: printer-name (name) No printer-location (text) No printer-info (text) No printer-make-and-model (text) No printer-state-message (text) No printer-message-from-operator (text) No (at least not in V1.0) So far the initial reaction (Don and Carl-Uno) is that the full length is intended to be supported by the Printer object. Fine with me if we agree to that. The reason that I brought up the issue, is that in SNMP the MAX length is separate from the MIN required for conformance. So we need to discuss and clarify the document. Else we will have some interoperability problems. Tom At 17:18 10/20/1997 PDT, Tom Hastings wrote: >Our current Model text gives upper bounds on the lengths of the 'text' and >'name' attributes as 4095 and 255 octets, respectively. However, we don't >say how many of those octets a Printer object SHALL store. We also don't >say what happens if a client supplies a value that is longer than >the maximum size that a Printer supports. > >These are two issues that will affect interoperability. > >I suggest that we add two sentences something like: > >A Printer object SHALL support at least nnn octets in requests and responses. >If a client supplies a value that exceeds nnn, the Printer object SHALL >truncate the value on the right after the nnn-th octet. > >I propose that 'nnn' be 255 for text and 127 for names. UTF-8 takes about >1.7 octets per character on average for Western European names. > >Comments? Lets discuss at Wednesdays telecon. > >Thanks, >Tom > >Here is the current text: > > >4.1.1 'text' > >The 'text' attribute syntax is a sequence of one or more characters with a >limit of 1 to 4095 octets. The Printer object SHALL support UTF-8 [28] and >MAY support additional charsets provided that they are registered with IANA >[54]. > >... > > >4.1.2 'name' > >The 'name' attribute syntax is the same as 'text', including the MANDATORY >support of UTF-8 and the exception natural language mechanism, except that >the sequence of characters is limited so that its encoded form is of length >1 to 255 octets. This syntax type is used for user-friendly strings, such >as a Printer name, that, for humans, are more meaningful than identifiers. > >... > > > > From ipp-archive Tue Oct 21 11:55:10 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA20062 for ipp-outgoing; Tue, 21 Oct 1997 11:50:20 -0400 (EDT) Message-Id: <3.0.1.32.19971021085419.011b7c00@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 21 Oct 1997 08:54:19 PDT To: Scott Isaacson , cmanros@cp10.es.xerox.com, Robert.Herriot@Eng.Sun.COM, jkm@underscore.com From: Tom Hastings Subject: Re: IPP>MOD Concern about Event Notification Content Cc: ipp@pwg.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk I agree with Scott, and his replies to the other comments on notification, that we need to define some hooks and that we don't need to define what a client (or some notification service that receives the notifications) looks like. I'm against removing everything, and I think we can defined hooks in a way that we won't regret what we put into the standard. I think we can salvage what we have with the following changes to the current text: 0. Sections 4.2.2 "notify-events" and 4.2.3 "notify-addresses" are fine they way they are. In Section 4.2.2.1 Notification Content: 1. We should RECOMMEND, but not require, which attributes SHOULD go in human readable messages. 2. We should RECOMMEND that the message SHOULD be in the natural language that the client submits the job in. 3. For the human readable messages, the syntax should be free form, rather than the specific format that we have in the text. 4. For the human readable messages, we should remove the charset specification, since the charset to use depends on the notification mechanism, not the charset of the client that is submitting the job. 5. Add "job-name" to the list of recommended attributes to include. I'm getting annoyed with my current print notifications that just tell me the job number and not the job-name. 6. For the mailto: scheme, add a note that a MIME attachment MAY be included for program consumption. 7. After V1.0, we should define a standard media (MIME) type to use as a mail attachment and register it. Since attachments are labeled, there won't be any conflict with any private types that implementors have defined. If we define the standard type soon enough we may avoid proliferation of private types. Comments? Tom At 08:00 10/20/1997 PDT, Scott Isaacson wrote: >From day one, we said that we were not going to define a new "nofication >protocol" for IPP and that for IPP/1.0 we would not define new "notify" >operations. I want to adamantly stand by this. We can not and should not >allow ourselves to get distracted by the absence of an messaging/event >service for the Internet. As Jay has pointed out, this is something that >needs to be designed and architected. Look at all the work that OMG COS >event has done and all of the non-open solution providers have done - this >is a big job and SHALL NOT be done as a "side effort" of the IPP working >group. > >For the longest time we said "any supported URI scheme as the notification >method with unspecified content or format". Then we said "boo, boo, ...., >broken, bad...." and we started to say "any supported URI scheme with ONE >specified content format for all notification methods FTP, MAILTO, etc." I >hope we can all agree that what we now got is still "boo, boo, ...., broken, >bad, ...." > >So we should retreat for 1.0, however still allow for some hooks (like we >have done for driver download and "more info") but not formally specify it. >Just leave it as hooks that might work in some given implementations. > >I think that we should suggest somewhere what the mail-safe message might >look like. > >My comments below preceded by SAI> > >Scott > >>>> Robert Herriot 10/17 3:50 PM >>> > > ftp: I don't think that ftp appending-to-a-file is useful for a client. > What on the client is supposed to monitor this and clean up > the file when it gets too big. > >SAI> True, but why disallow it in an environment that may have client side >file >SAI> montoring already. These should just be hooks to allow something >SAI> to maybe work, not full specifications of what to do with log file wrap >SAI> and overflow. > > http: this presumes a client http server or some other mechanism we > haven't thought through. Using application/ipp with a new > "notify" operation makes the most sense in this case. But > we haven't thought through how a client would plug into this > or how a client listens to HTTP. > >SAI> True, but why disallow it in an environment where the address is >SAI> not the client but a web server posting all event summaries? >SAI> Again, these should just be hooks to allow something >SAI> to maybe work, not full specifications of what the back end of the >SAI> web server should do the event content. > > mailto: this could be supported with free form text having certain > suggested attribute values. It's not the most useful > notification method, but it would work for human consumption. > >SAI> This is how we should word the suggested content for all forms of >SAI> notification. > >Perhaps mailto with an undefined human readable format is worth >supporting in order to have notification, but even that may constrain >us more in the future than we want. > >SAI> Perhaps allowing any supported URI with undefined content is >SAI> worth supporting > >Scott > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From ipp-archive Tue Oct 21 12:55:12 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA20836 for ipp-outgoing; Tue, 21 Oct 1997 12:54:47 -0400 (EDT) Message-ID: <344CDDD5.BED6B199@parc.xerox.com> Date: Tue, 21 Oct 1997 09:52:37 PDT From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: Tom Hastings CC: Scott Isaacson , cmanros@cp10.es.xerox.com, Robert.Herriot@eng.sun.com, jkm@underscore.com, ipp@pwg.org Subject: Re: IPP>MOD Concern about Event Notification Content References: <3.0.1.32.19971021085419.011b7c00@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk If event notifications are supplied in a multipart/alternative, with, for example, the first part being the vendor's proprietary notification format, and the second in text/plain, then there will be a cleaner migration path than if only a single part is expected by recipients of notifications. -- http://www.parc.xerox.com/masinter From ipp-archive Tue Oct 21 12:55:13 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA20816 for ipp-outgoing; Tue, 21 Oct 1997 12:50:32 -0400 (EDT) Message-Id: <1.5.4.32.19971021164740.006fea48@pop3.holonet.net> X-Sender: cumanros@pop3.holonet.net X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 21 Oct 1997 09:47:40 -0700 To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> I-D ACTION:draft-ietf-drums-abnf-05.txt Sender: ipp-owner@pwg.org Precedence: bulk FYI, Thee were a few minor changes done to the previous draft, so here is yet another "final" draft for ABNF. Carl-Uno >To: IETF-Announce@ietf.org >Cc: drums@cs.utk.edu >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-ietf-drums-abnf-05.txt >Date: Tue, 21 Oct 1997 11:03:31 -0400 >Sender: cclark@cnri.reston.va.us > >A Revised Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Detailed Revision/Update of Message Standards Working Group of the IETF. > >Note: This revision reflects comments received during the last call period. > > Title : Augmented BNF for Syntax Specifications: ABNF > Author(s) : D. Crocker, P. Overell > Filename : draft-ietf-drums-abnf-05.txt > Pages : 9 > Date : 17-Oct-97 > >Internet technical specifications often need to define a format >syntax and are free to employ whatever notation their authors >deem useful. Over the years, a modified version of Backus-Naur >Form (BNF), called Augmented BNF (ABNF), has been popular among >many Internet specifications. It balances compactness and >simplicity, with reasonable representational power. In the early >days of the Arpanet, each specification contained its own >definition of ABNF. This included the email specifications, >RFC733 and then RFC822 which have come to be the common citations >for defining ABNF. The current document separates out that >definition, to permit selective reference. Predictably, it also >provides some modifications and enhancements. > >The differences between standard BNF and ABNF involve naming >rules, repetition, alternatives, order-independence, and value >ranges. Appendix A (Core) supplies rule definitions and encoding >for a core lexical analyzer of the type common to several >Internet specifications. It is provided as a convenience and is >otherwise separate from the meta language defined in the body of >this document, and separate from its formal status. > > >Internet-Drafts are available by anonymous FTP. Login wih the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-drums-abnf-05.txt". >A URL for the Internet-Draft is: >ftp://ds.internic.net/internet-drafts/draft-ietf-drums-abnf-05.txt > >Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nis.garr.it > > Pacific Rim: munnari.oz.au > > US East Coast: ds.internic.net > > US West Coast: ftp.isi.edu > >Internet-Drafts are also available by mail. > >Send a message to: mailserv@ds.internic.net. In the body type: > "FILE /internet-drafts/draft-ietf-drums-abnf-05.txt". > >NOTE: The mail server at ds.internic.net 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. >Content-Type: text/plain >Content-ID: <19971017133306.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-drums-abnf-05.txt >Content-Type: text/plain >Content-ID: <19971017133306.I-D@ietf.org> > From ipp-archive Tue Oct 21 13:00:13 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA20857 for ipp-outgoing; Tue, 21 Oct 1997 12:55:39 -0400 (EDT) Message-Id: <1.5.4.32.19971021165531.0070d418@pop3.holonet.net> X-Sender: cumanros@pop3.holonet.net X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 21 Oct 1997 09:55:31 -0700 To: ipp@pwg.org From: Carl-Uno Manros Subject: Re: IPP>MOD Concern about Event Notification Content Sender: ipp-owner@pwg.org Precedence: bulk It is clear to me that we are all running out of time and steam to do a MIME definition for notifications as I previously suggested. I concur with Scott's proposal to leave in the current hooks in anticipation of future addition of a fully fledged notification service later. If we are going to leave things undefined about how notifications might actually get delivered to users in Version 1.0, I see no reason to limit outselves to only e-mail. If we are going to be vague, let us be vague in a consistent manner. This is in support of Scott's proposal. Carl-Uno At 08:54 AM 10/21/97 PDT, you wrote: >I agree with Scott, and his replies to the other comments on notification, >that we need to define some hooks and that we don't need to define what a >client (or some notification service that receives the notifications) looks >like. > >I'm against removing everything, and I think we can defined hooks in a way >that we won't regret what we put into the standard. I think we can salvage >what we have with the following changes to the current text: > >0. Sections 4.2.2 "notify-events" and 4.2.3 "notify-addresses" are >fine they way they are. > >In Section 4.2.2.1 Notification Content: > >1. We should RECOMMEND, but not require, which attributes >SHOULD go in human readable messages. > >2. We should RECOMMEND that the message SHOULD be in the >natural language that the client submits the job in. > >3. For the human readable messages, the syntax should be free form, >rather than the specific format that we have in the text. > >4. For the human readable messages, we should remove the charset >specification, since the charset to use depends on the notification >mechanism, not the charset of the client that is submitting the job. > >5. Add "job-name" to the list of recommended attributes to include. >I'm getting annoyed with my current print notifications that just tell >me the job number and not the job-name. > >6. For the mailto: scheme, add a note that a MIME attachment MAY be >included for program consumption. > >7. After V1.0, we should define a standard media (MIME) type to use as a >mail attachment and register it. Since attachments are labeled, there >won't be any conflict with any private types that implementors have defined. >If we define the standard type soon enough we may avoid proliferation >of private types. > >Comments? >Tom > >At 08:00 10/20/1997 PDT, Scott Isaacson wrote: >>From day one, we said that we were not going to define a new "nofication >>protocol" for IPP and that for IPP/1.0 we would not define new "notify" >>operations. I want to adamantly stand by this. We can not and should not >>allow ourselves to get distracted by the absence of an messaging/event >>service for the Internet. As Jay has pointed out, this is something that >>needs to be designed and architected. Look at all the work that OMG COS >>event has done and all of the non-open solution providers have done - this >>is a big job and SHALL NOT be done as a "side effort" of the IPP working >>group. >> >>For the longest time we said "any supported URI scheme as the notification >>method with unspecified content or format". Then we said "boo, boo, ...., >>broken, bad...." and we started to say "any supported URI scheme with ONE >>specified content format for all notification methods FTP, MAILTO, etc." I >>hope we can all agree that what we now got is still "boo, boo, ...., broken, >>bad, ...." >> >>So we should retreat for 1.0, however still allow for some hooks (like we >>have done for driver download and "more info") but not formally specify it. >>Just leave it as hooks that might work in some given implementations. >> >>I think that we should suggest somewhere what the mail-safe message might >>look like. >> >>My comments below preceded by SAI> >> >>Scott >> >>>>> Robert Herriot 10/17 3:50 PM >>> >> >> ftp: I don't think that ftp appending-to-a-file is useful for a client. >> What on the client is supposed to monitor this and clean up >> the file when it gets too big. >> >>SAI> True, but why disallow it in an environment that may have client side >>file >>SAI> montoring already. These should just be hooks to allow something >>SAI> to maybe work, not full specifications of what to do with log file wrap >>SAI> and overflow. >> >> http: this presumes a client http server or some other mechanism we >> haven't thought through. Using application/ipp with a new >> "notify" operation makes the most sense in this case. But >> we haven't thought through how a client would plug into this >> or how a client listens to HTTP. >> >>SAI> True, but why disallow it in an environment where the address is >>SAI> not the client but a web server posting all event summaries? >>SAI> Again, these should just be hooks to allow something >>SAI> to maybe work, not full specifications of what the back end of the >>SAI> web server should do the event content. >> >> mailto: this could be supported with free form text having certain >> suggested attribute values. It's not the most useful >> notification method, but it would work for human consumption. >> >>SAI> This is how we should word the suggested content for all forms of >>SAI> notification. >> >>Perhaps mailto with an undefined human readable format is worth >>supporting in order to have notification, but even that may constrain >>us more in the future than we want. >> >>SAI> Perhaps allowing any supported URI with undefined content is >>SAI> worth supporting >> >>Scott >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > > From ipp-archive Tue Oct 21 14:18:40 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA22813 for ipp-outgoing; Tue, 21 Oct 1997 14:02:54 -0400 (EDT) Message-Id: <3.0.1.32.19971021104925.00fb75f0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 21 Oct 1997 10:49:25 PDT To: don@lexmark.com, ipp@pwg.org From: Tom Hastings Subject: Re: IPP> MOD - ISSUE: # of octets of 'text'/'name' SHALL a Printer support? In-Reply-To: <199710211224.AA04142@interlock2.lexmark.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Don, I wish that we could depend on the market place and product acceptance to get reasonable behavior from various vendors that have products that customers try to get to work together. But if each vendor has a different idea about the agreements, then the products won't fit together the way that the customer would hope. Take the "job-name" (name) attribute as an example. Windows clients puts the name of the application as the first n characters of the job name, followed by a dash and the document file name. So "Microsoft Word - ", takes up 17 characters. But BSD lpq only returns 18 characters in the lpq command (at least on my system produced by another company in the PWG). So only the first letter of the document is shown in the list of jobs in the lpq command! Not exactly helpful. But RFC 1179 says that the job name is up to 99 characters (analoguous to our statement about up to 255 octets in IPP 'name' attribute syntax). We could get the same sort of disconnect in IPP implementations, if we don't agreee as to what a conforming implementation SHALL accept, store, and return in operation responses. I don't see the market place helping to fix the different ideas about the length of the job-name between Windows and LPD. Lets not repeat this same mistake for IPP. For clarity, I think we should add some kind of NOTE to "job-name" to indicate that the client MAY add an application name as part of the job-name, to make it clear to all (clients, users, IPP Printer object implementors), that the job-name may not be just the document name and/or file name. Then they might allocate a few more characters to the job name. I suggest something like, after the 4th sentence: If the user doesn't supply an explicit job name, the client MAY automatically supply a job name that consists of the document name (or file name) and, possibly, the application program name. Tom At 05:24 10/21/1997 PDT, don@lexmark.com wrote: > >Tom Hastings said: >> >>Our current Model text gives upper bounds on the lengths of the 'text' and >>'name' attributes as 4095 and 255 octets, respectively. However, we don't >>say how many of those octets a Printer object SHALL store. We also don't >>say what happens if a client supplies a value that is longer than >>the maximum size that a Printer supports. >> >>These are two issues that will affect interoperability. >> >>I suggest that we add two sentences something like: >> >>A Printer object SHALL support at least nnn octets in requests and >responses. >>If a client supplies a value that exceeds nnn, the Printer object SHALL >>truncate the value on the right after the nnn-th octet. >> >>I propose that 'nnn' be 255 for text and 127 for names. UTF-8 takes about >>1.7 octets per character on average for Western European names. >> >>Comments? Lets discuss at Wednesdays telecon. >IMHO, people who read what we have and don't design to what you have >explicitly >required deserve the wrath of the users they will surely get. I can't see >wasting the >toner for two more paragraphs of SHALLs for something that is intuitively >obvious. I'm not going to waste my time but I suspect if I looked, I could >find 1000 other places where we have not defined every word of the Emglish >language. > >Don > >********************************************** >* Don Wright don@lexmark.com * >* Manager, Strategic Alliances and Standards * >* Lexmark International * >* 740 New Circle Rd * >* Lexington, Ky 40550 * >* 606-232-4808 (phone) 606-232-6740 (fax) * >********************************************** > > > > From ipp-archive Tue Oct 21 14:40:14 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA23640 for ipp-outgoing; Tue, 21 Oct 1997 14:32:32 -0400 (EDT) Message-Id: <3.0.1.32.19971021102054.00fb07f0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 21 Oct 1997 10:20:54 PDT To: Larry Masinter From: Tom Hastings Subject: Re: IPP>MOD Concern about Event Notification Content Cc: Scott Isaacson , cmanros@cp10.es.xerox.com, Robert.Herriot@eng.sun.com, jkm@underscore.com, ipp@pwg.org In-Reply-To: <344CDDD5.BED6B199@parc.xerox.com> References: <3.0.1.32.19971021085419.011b7c00@garfield> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Larry, Building on your idea... How about making your first part (vendor proprietary) be a mail attachment in whatever media type the vendor wants or defines? Make your second part be the text/plain body of the mail message and be human readable in any format (hopefully in the language of the user, but in a charset that the transport system can handle). When the PWG agrees (soon after IPP V1.0) to a media type for notification purposes, the Printer vendor can include that as an attachment as well. If he had a proprietary media type, he can attach both as separate attachments, correct? Then we have a good migration path as you urge, correct? Tom At 09:52 10/21/1997 PDT, Larry Masinter wrote: >If event notifications are supplied in a multipart/alternative, >with, for example, the first part being the vendor's proprietary notification >format, and the second in text/plain, then >there will be a cleaner migration path than if only a single >part is expected by recipients of notifications. >-- >http://www.parc.xerox.com/masinter > > From ipp-archive Tue Oct 21 15:10:14 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA24498 for ipp-outgoing; Tue, 21 Oct 1997 15:05:23 -0400 (EDT) From: don@lexmark.com Message-Id: <199710211905.AA23822@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: hastings@cp10.es.xerox.coM, ipp@pwg.org Date: Tue, 21 Oct 1997 15:05:07 -0400 Subject: IPP> MOD - ISSUE: # of octets of 'text'/'name' SHALL a Printer support? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Precedence: bulk Tom Hastings said: >Take the "job-name" (name) attribute as an example. > >Windows clients puts the name of the application as the first n characters of >the job name, followed by a dash and the document file name. >So "Microsoft Word - ", takes up 17 characters. But BSD lpq only >returns 18 characters in the lpq command (at least on my system >produced by another company in the PWG). >So only the first letter of the document is shown in the list of jobs in >the lpq command! Not exactly helpful. > > >But RFC 1179 says that the job name is up to 99 characters (analoguous >to our statement about up to 255 octets in IPP 'name' attribute syntax). Remember RFC1170 is not a standard. It documented existing practice and some implementations. >We could get the same sort of disconnect in IPP implementations, if we >don't agreee as to what a conforming implementation SHALL accept, store, >and return in operation responses. > >I don't see the market place helping to fix the different ideas about >the length of the job-name between Windows and LPD. Lets not repeat >this same mistake for IPP. I bet most of the LPD implmentations were originally written before any applications generated job-names longer than 18 characters!! No one noticed -- no one cared -- until Windows came along. >For clarity, I think we should add some kind of NOTE to "job-name" to >indicate that the client MAY add an application name as part of the >job-name, to make it clear to all (clients, users, IPP Printer object >implementors), that the job-name may not be just the document name >and/or file name. Then they might allocate a few more characters >to the job name. I suggest something like, after the 4th sentence: > >If the user doesn't supply an explicit job name, the client MAY >automatically supply a job name that consists of the document name >(or file name) and, possibly, the application program name. If IPP says the job-name is x octets and some implementation only supports 16 octets I suspect that market pressures will force compliance. In a world now used to browsers and the GUI interfaces, a truncated job-name will stand out like a sore thumb. In the only recently GUI-ed UNIX world, everyone expects highly irregular and inconsistent print implementations. There will be a lot of reviews in magazines, etc. because this is going to hit the mainstream Windows users. What are they maybe one or two magazines that review Unix? As I said before, if we were to look at every little corner and find places like this there would be so many SHALLs shouting at the reader that the standard would be unreadable. Don ********************************************** * Don Wright don@lexmark.com * * Manager, Strategic Alliances and Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-archive Tue Oct 21 18:30:16 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA25437 for ipp-outgoing; Tue, 21 Oct 1997 18:27:30 -0400 (EDT) Message-ID: <344D2C22.D4D70C4E@parc.xerox.com> Date: Tue, 21 Oct 1997 15:26:43 PDT From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: Tom Hastings CC: Scott Isaacson , cmanros@cp10.es.xerox.com, Robert.Herriot@eng.sun.com, jkm@underscore.com, ipp@pwg.org Subject: Re: IPP>MOD Concern about Event Notification Content References: <3.0.1.32.19971021085419.011b7c00@garfield> <3.0.1.32.19971021102054.00fb07f0@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Yes, that's how multipart/alternative works. It's for an 'attachment' that is available in multiple formats. You give the same information in each form, but the reciever picks the best (first) it can view. (The plain text version comes last.) Larry -- http://www.parc.xerox.com/masinter From ipp-archive Tue Oct 21 19:35:16 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA26086 for ipp-outgoing; Tue, 21 Oct 1997 19:32:14 -0400 (EDT) Message-Id: <3.0.1.32.19971021155912.00d0c210@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 21 Oct 1997 15:59:12 PDT To: don@lexmark.com, ipp@pwg.org From: Tom Hastings Subject: Re: IPP> MOD - ISSUE: # of octets of 'text'/'name' SHALL a Printer support? In-Reply-To: <199710211905.AA23822@interlock2.lexmark.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Don, How about if we just clarify the conformance section that talks about implementation of the attribute syntaxes. Then we won't be adding any more SHALLs, but we will be clarifying that the ranges of each syntax is required? Then it will be clear that 'text' attributes are 4095 octets and 'name' are 255 octets. (So far there are no 'text' attributes that a client can supply and only 3 'name' attributes: "document-name", "job-name", and "job-originating-user".) For those attributes that can only be returned, if an implementation has a lower limit, who is to know? The current text is: 5.2.5 Attribute Syntaxes A Printer SHALL be able to accept any of the attribute syntaxes defined in Section 4.1 in any operation in which a client may supply attributes. Furthermore, a Printer SHALL return attributes to the client in operation responses that conform to the syntax specified in Section 4.1. I propose that we clarify it as: 5.2.5 Attribute Syntaxes A Printer SHALL be able to accept any of the attribute syntaxes defined in Section 4.1, including their full range, in any operation in which a client may supply attributes. Furthermore, a Printer SHALL return attributes to the client in operation responses that conform to the syntax specified in Section 4.1, including their full range if supplied previously by a client. Tom At 12:05 10/21/1997 PDT, don@lexmark.com wrote: > >Tom Hastings said: > >>Take the "job-name" (name) attribute as an example. >> >>Windows clients puts the name of the application as the first n characters >of >>the job name, followed by a dash and the document file name. >>So "Microsoft Word - ", takes up 17 characters. But BSD lpq only >>returns 18 characters in the lpq command (at least on my system >>produced by another company in the PWG). >>So only the first letter of the document is shown in the list of jobs in >>the lpq command! Not exactly helpful. >> >> >>But RFC 1179 says that the job name is up to 99 characters (analoguous >>to our statement about up to 255 octets in IPP 'name' attribute syntax). > >Remember RFC1170 is not a standard. It documented existing practice >and some implementations. >>We could get the same sort of disconnect in IPP implementations, if we >>don't agreee as to what a conforming implementation SHALL accept, store, >>and return in operation responses. >> >>I don't see the market place helping to fix the different ideas about >>the length of the job-name between Windows and LPD. Lets not repeat >>this same mistake for IPP. >I bet most of the LPD implmentations were originally written before >any applications generated job-names longer than 18 characters!! >No one noticed -- no one cared -- until Windows came along. > >>For clarity, I think we should add some kind of NOTE to "job-name" to >>indicate that the client MAY add an application name as part of the >>job-name, to make it clear to all (clients, users, IPP Printer object >>implementors), that the job-name may not be just the document name >>and/or file name. Then they might allocate a few more characters >>to the job name. I suggest something like, after the 4th sentence: >> >>If the user doesn't supply an explicit job name, the client MAY >>automatically supply a job name that consists of the document name >>(or file name) and, possibly, the application program name. > >If IPP says the job-name is x octets and some implementation >only supports 16 octets I suspect that market pressures will >force compliance. In a world now used to browsers and the >GUI interfaces, a truncated job-name will stand out like a >sore thumb. In the only recently GUI-ed UNIX world, everyone >expects highly irregular and inconsistent print implementations. >There will be a lot of reviews in magazines, etc. because >this is going to hit the mainstream Windows users. What are >they maybe one or two magazines that review Unix? > >As I said before, if we were to look at every little corner >and find places like this there would be so many SHALLs >shouting at the reader that the standard would be unreadable. > >Don > >********************************************** >* Don Wright don@lexmark.com * >* Manager, Strategic Alliances and Standards * >* Lexmark International * >* 740 New Circle Rd * >* Lexington, Ky 40550 * >* 606-232-4808 (phone) 606-232-6740 (fax) * >********************************************** > > > > From ipp-archive Tue Oct 21 21:00:17 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA26757 for ipp-outgoing; Tue, 21 Oct 1997 20:57:04 -0400 (EDT) Message-Id: <3.0.1.32.19971021174134.009c2170@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 21 Oct 1997 17:41:34 PDT To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> MOD - Suggested replacement text on notifications Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Replace the whole section 4.2.2.1 with the following text: 4.2.2.1 Event Notification Content The exact content of and format for event notification content is not defined in this version of IPP. Further work will be needed on this subject. The following guidelines are given to implementers about event notification content at this stage. For Printer object events: Printer-URI Printer-name Event reported on Printer-state Printer-state-reason Printer-state-message Time stamp For Job object events: Same as for Printer object plus the following information about the Job object: Job-URI Job-ID Job-name Job-state Job-state-reason Job-state-message Optional attributes attributes that are not supported by the implementation do not need to be present. --- Replace the second paragraph in "4.2.3 notify-addresses" and the rest of the section with the following text: The client supplies URIs in the create request. Note that the set of supported values in the "notification-addesses-supported" is not a set of addresses, but is a set of 'uriScheme' values (see section 4.1.6). ---- 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 From ipp-archive Wed Oct 22 08:25:26 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA27829 for ipp-outgoing; Wed, 22 Oct 1997 08:23:41 -0400 (EDT) From: don@lexmark.com Message-Id: <199710221223.AA03829@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: hastings@cp10.es.xerox.coM, ipp@pwg.org Date: Wed, 22 Oct 1997 08:23:15 -0400 Subject: Re: IPP> MOD - ISSUE: # of octets of 'text'/'name' SHALL a Printer support? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Precedence: bulk Tom Hastings said: >How about if we just clarify the conformance section that talks about >implementation of the attribute syntaxes. Then we won't be adding any >more SHALLs, but we will be clarifying that the ranges of each syntax >is required? Then it will be clear that 'text' attributes are 4095 octets >and 'name' are 255 octets. (So far there are no 'text' attributes that >a client can supply and only 3 'name' attributes: "document-name", >"job-name", and "job-originating-user".) For those attributes that >can only be returned, if an implementation has a lower limit, who is to >know? > >The current text is: > >5.2.5 Attribute Syntaxes >A Printer SHALL be able to accept any of the attribute syntaxes defined in >Section 4.1 in any operation in which a client may supply attributes. >Furthermore, a Printer SHALL return attributes to the client in operation >responses that conform to the syntax specified in Section 4.1. > >I propose that we clarify it as: > >5.2.5 Attribute Syntaxes >A Printer SHALL be able to accept any of the attribute syntaxes defined in >Section 4.1, including their full range, in any operation in which a client >may supply attributes. Furthermore, a Printer SHALL return attributes to >the client in operation responses that conform to the syntax specified in >Section 4.1, including their full range if supplied previously by a client. I like this much better but I have one question -- shouldn't clients have to follow the same rule for anything that come from the IPP printer, i.e. you bomb out if the job-uri is really long? Don ********************************************** * Don Wright don@lexmark.com * * Manager, Strategic Alliances and Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-archive Wed Oct 22 16:25:32 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA00162 for ipp-outgoing; Wed, 22 Oct 1997 16:21:55 -0400 (EDT) Message-Id: <3.0.1.32.19971022113604.010897f0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 22 Oct 1997 11:36:04 PDT To: don@lexmark.com, ipp@pwg.org From: Tom Hastings Subject: Re: IPP> MOD - ISSUE: # of octets of 'text'/'name' SHALL a Printer support? In-Reply-To: <199710221223.AA03829@interlock2.lexmark.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Don, It looks like we have agreement to add the text about the range of the data types to the "5.2 Printer Object Conformance Requirements" section. You bring up a good question about the client and the range. 1. I suggest that we add the same sort of statement to section "5.1 Client Conformance Requirements". The current third paragraph reads: A client SHALL be able to accept any of the attribute syntaxes defined in Section 4.1 that may be returned to it in a response from a Printer I suggest that we change it to read: A client SHALL be able to accept any of the attribute syntaxes defined in Section 4.1, including their full range, that may be returned to it in a response from a Printer object. 2. We could also add something like we have in the second paragraph about example client implementations. Perhaps something like: Truncation of long attribute values is not recommended. A recommended approach would be for the client implementation to allow the user to scroll through long attribute values. 3. Now that we have MANDATORY (and OPTIONAL) "operation attributes" we need to fix the second paragraph from: When sending a Get-Attributes or create request, an IPP client need not supply any attributes. to: When sending a Get-Attributes or create request, an IPP client NEED NOT supply any OPTIONAL attributes. Comments? Tom At 05:23 10/22/1997 PDT, don@lexmark.com wrote: > >Tom Hastings said: > >>How about if we just clarify the conformance section that talks about >>implementation of the attribute syntaxes. Then we won't be adding any >>more SHALLs, but we will be clarifying that the ranges of each syntax >>is required? Then it will be clear that 'text' attributes are 4095 octets >>and 'name' are 255 octets. (So far there are no 'text' attributes that >>a client can supply and only 3 'name' attributes: "document-name", >>"job-name", and "job-originating-user".) For those attributes that >>can only be returned, if an implementation has a lower limit, who is to >>know? >> >>The current text is: >> >>5.2.5 Attribute Syntaxes >>A Printer SHALL be able to accept any of the attribute syntaxes defined in >>Section 4.1 in any operation in which a client may supply attributes. >>Furthermore, a Printer SHALL return attributes to the client in operation >>responses that conform to the syntax specified in Section 4.1. >> >>I propose that we clarify it as: >> >>5.2.5 Attribute Syntaxes >>A Printer SHALL be able to accept any of the attribute syntaxes defined in >>Section 4.1, including their full range, in any operation in which a >client >>may supply attributes. Furthermore, a Printer SHALL return attributes to >>the client in operation responses that conform to the syntax specified in >>Section 4.1, including their full range if supplied previously by a >client. > >I like this much better but I have one question -- shouldn't clients have >to follow the same rule for anything that come from the IPP printer, i.e. >you bomb out if the job-uri is really long? > >Don > >********************************************** >* Don Wright don@lexmark.com * >* Manager, Strategic Alliances and Standards * >* Lexmark International * >* 740 New Circle Rd * >* Lexington, Ky 40550 * >* 606-232-4808 (phone) 606-232-6740 (fax) * >********************************************** > > > > From ipp-archive Wed Oct 22 18:00:32 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA00979 for ipp-outgoing; Wed, 22 Oct 1997 17:58:19 -0400 (EDT) X-Sender: szilles@elroy Message-Id: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="============_-1334561324==_============" Date: Wed, 22 Oct 1997 14:59:28 -0800 To: ipp@pwg.org From: Steve Zilles Subject: IPP> ADM - minutes of 10/22 Phone Conference Cc: szilles@Adobe.COM Sender: ipp-owner@pwg.org Precedence: bulk --============_-1334561324==_============ Content-Type: text/plain; charset="us-ascii" The minutes of the phone conference on Oct 22 are attached. Steve Zilles --============_-1334561324==_============ Content-Type: text/plain; name="MinutesPhoneConf.97.10.22.txt"; charset="us-ascii" Content-Disposition: attachment; filename="MinutesPhoneConf.97.10.22.txt" Phone Meeting, October 22, 1PM PDT. (minutes taken by Steve Zilles) Attendees Ira McDonald Tom Hastings Bob Herriot Peter Zehler Roger deBry Scott Isaacson Don Wright Steve Zilles Jay Martin (late) Notification Discussed Carl-Uno's text: Is Notification in scope? Need to make it clear that the mechanism is out of scope, but that the format of the message is in scope. We should say the message SHOULD be human readable; the problem with this is that the experience with PostScript error messages has shown that machines will begin to parse and use the "human readable" messages and we will be stuck with them forever. Resolved (Unanimous): Remove the Notification mechanism, including the two attributes, "notifiy- events" and "notify-addresses", from the Model Draft and begin work on a separate document to define IPP Notification. The removed attributes would be registered using the IPP extension mechanism when a suitable interoperable draft exists. Range of attribute syntaxes: Resolved (Unanimous): the proposed text fix (re: full range) for 5.2.5 will be adopt and similar text for 5.1 will be added as well. Bob Herriot will clean up Protocol document re description of xxx-attributes-tags. Scott will call Paul and Sylvan re: Why does the protocol allows 1, 2 and 4 byte integers? Most things are now 4 byte. Relationship between the Printer MIB and Job MIB and IPP Resolved (Unanimous): that the relationship between the Printer MIB and Job MIB and IPP will be described in a separate I-D authored by Harry Lewis and Tom Hastings. This action was taken to reduce dependencies between documents with different progression rates. it should not in any way be interpreted as indicating that these documents are not important; the document is very important! Ira will do a separate draft of the IANA message with the registration of the application/ipp Media type and send it to the mailing. Scott is targetting Friday for an new draft of the Model document; he is only awaiting text from Steve Zilles re handling of proceesing attributes. Bob has issued a version a week ago; a new version is needed to describe the Internationalization changes, the description of xxx-attributes-tag and notification changes. This draft is targeted for Friday. The meeting was adjourned at 2:10 PDT. --============_-1334561324==_============-- From ipp-archive Wed Oct 22 21:15:45 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA02546 for ipp-outgoing; Wed, 22 Oct 1997 21:09:21 -0400 (EDT) From: Harry Lewis To: , , , , , Subject: IPP> October PING list Message-ID: <5030300012781291000002L012*@MHS> Date: Wed, 22 Oct 1997 21:14:20 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk Here's what I've got for a PING list. Please send any corrections ASAP.= My estimates were based on the larger attendance we had in the past. Sp= reading fixed costs (like the room, AV etc) across a smaller group, the meeting= cost has ended up at $42 per day. The hotel is not collecting fees, I am hav= ing to do this, myself. Please be prepared, with a company or personal check m= ade out to Harry Lewis for $42 for each day that you attend. I will provide a r= eceipt. P1394 (Monday/Tuesday) ----- Brian Batchelder - HP Alan Berkema - HP Dan Bye - SGS-Thomson (Monday) Dave Doman - Motorola Lee Farrell - Canon Osamu Hirata - Canon Greg LeClair - Epson Kerry Lee Harry Lewis - IBM Fumio Nagasaka - Epson Akihiro Shimura - Canon Greg Shue - HP Jerry Thrasher - Lexmark Atsushi Uchino - Seiko-Epson IPP (Wednesday/Thursday) --- Lee Farrell - Canon Steve Gebert - IBM Tom Hastings - Xerox Scott Isaacson - Novell David Kellerman - Northlake Software Carl Kugler - IBM Kerry Lee Harry Lewis - IBM Carl-Uno Manros - Xerox Jay Martin - Underscore Bob Pentecost - HP Jerry Podojil - Genicom (Thursday) Stuart Rowley - Kyocera Roberto Sannino - SGS-Thomson (Thursday) Yuji Sasaki - Japan Computer Industry Atsushi Uchino - Seiko-Epson Dale Wick - TrueSpectra Lloyd Young - Lexmark Peter Zehler - Xerox JMP/FIN (Friday) ------- Carlos Cantu - IBM Dennis Carney - IBM Lee Farrell - Canon Tom Hastings - Xerox David Kellerman - Northlake Software Harry Lewis - IBM Jay Martin - Underscore Kathy Melton - IBM Lisa Morgan - IBM Bob Pentecost - HP Jerry Podojil - Genicom Stuart Rowley - Kyocera Roberto Sannino - SGS-Thomson Lloyd Young - Lexmark Harry Lewis = From ipp-archive Wed Oct 22 21:20:47 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA03375 for ipp-outgoing; Wed, 22 Oct 1997 21:19:25 -0400 (EDT) From: szilles@Adobe.COM (Stephen Zilles) Message-Id: <199710230118.SAA27432@bulletin> To: ipp@pwg.org Subject: IPP> MOD - draft of text on document processing Phone: (408) 536-4766 Fax: (408) 537-4042 Office: W14-504 Cc: szilles@Adobe.COM Date: Wed, 22 Oct 1997 18:18:05 PDT Sender: ipp-owner@pwg.org Precedence: bulk The following is the proprosed text to add a section 16.4 to Appendix E for the purpose of describing how the processing attributes, such as Nup, Duplex, etc., are used in processing the document. Because I had to do some creative thinking is writing this algorithm, I am sending it out for comment as well as for inclusion in the draft. I am missing the suggested edits for the attribute descriptions them selves. I think each of the attributes mentioned below should have a sentence like, "The relationship of this attribute and the other attributes that control document processing is described in Appendix E, section 16.4" Glossary (I haven't the foggiest where these defns should go in the Model document) print-stream page: a page according to the definition of pages in the language used to express the document data. imposed page: a page created by placing N print-stream pages onto a single page. 16.4 Using Job-template attributes during document processing. Some of the Job-template attributes are to be used during the processing of the document data. These include, but are not limited to, "orientation", "number-up", "sides", "media" "copies". The processing of each Document Object in a Job Object SHALL follow the algorithm below. This algorithm is intended only to identify when and how attributes are to be used in processing document data and any algorithm that accomplishs the same effect can be used to implement this specification. 1. Using the "document-format" attribute or some form of format detection algorithm (if the value of "document-format" is not specific enough), determine whether or not the document data has already been formatted for printing. If the document data has been formatted, then goto step 2. Otherwise, the document data SHALL be formatted. The formatting algorithm is implementation defined and is not specified by this specification. The formatting of the document data uses the "orientation" attribute to determine how the formatted print data is place on a print-stream page, see section 4.2.15 for the details. 2. The document data is in the form of a print-stream in a known media type. The "page-range" attribute is used to select, as specified in section 4.2.14, a sub-sequence of the pages in the print-stream that are to be processed and images. 3. The input to this step is sequence of print-stream pages. This step is controlled by the "number-up" attribute. If value of "number-up" is N, then during the processing of the print-stream pages, each N print-stream pages are positioned, as specified in section 4.2.8, to create a single imposed page. If a given Document Object does not have N more print-stream pages, then the completion of the imposed page is controlled by the "multiple-document-handling" attribute as described in section 4.2.6; when the value of this attribute is 'separate-documents-collated-copies', the document data from subsequent Document Objects is used to complete the imposed page. The size(scaling), position(translation) and rotation of the print-stream pages on the imposed page is implementation defined. Note that during this process the print-stream pages may be rendered to a form suitable for placing on the imposed page; this rendering is controlled by the values of the "printer-resolution" and "print-quality" attributes as described in sections 4.2.10 and 4.2.11. In the case N=1, the imposed pages are are nearly the same as the print-stream pages; the differences would only be in the size, postion and rotation of the print-stream page and/or any decoration, such as a frame to the page, that is added by the implementation. 4. The collection of imposed pages is placed, in sequence, onto sides of the print media. This placement is controled by the "sides" attribute and the orientation of the page, as described in section 4.2.9. The orientation of the page is defined by the orientation of the imposed pages; for example, if "number-up" equals 2, then, typically, two portrait print-stream pages become one landscape imposed page. Note that the placement of imposed pages onto media instances is also controlled by the "multiple-document-handling" attribute as described in section 4.2.6. 5. The "copies" and "multiple-document-handling" attributes are used to determine how many copies of each media instance are created and in what order. See sections 4.2.6 and 4.2.13 for the details. 6. When the correct number of copies are created, the media instances are finished according to the values of the "finishings" attribute as described in 4.2.12. Note that sometimes finishing operations may require manual intervention to perform the finishing operations on the copies, especially uncollated copies. This specification allows any or all of the processing steps to be performed automatically or manually at the descretion of the implementation of the Printer Object. From ipp-archive Wed Oct 22 22:35:36 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA04886 for ipp-outgoing; Wed, 22 Oct 1997 22:32:03 -0400 (EDT) Date: Wed, 22 Oct 1997 19:30:28 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199710230230.TAA13073@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>PRO latest protocol document X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk I have just downloaded the latest protocol document to: ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO The files are: ipp-pro-971022.doc MS Word 6 with no revision marks ipp-pro-971022.txt text file with no revisions marks ipp-pro-971022-rev.doc MS Word 6 with revision marks I expect these changes are the last before the Boulder meeting next week. The revisions are for the following issues: Peter Zehler's request for clarifications with no changes to protocol Changes for notification removal -- none Changes for charset and language: description of text, examples, table of attributes for operations. bug fix: I found that the naturalLanguage type couldn't be used with both the value of the attribute attributes-natural-language and to override one attribute value because in the former case the value stands alone and in the latter case it combines with the following text or name value. So I added a naturalLanguagePrefix type into the old slot for 'language' type which should have been removed in the last edition when 'naturalLanguage' was added. From ipp-archive Thu Oct 23 08:10:41 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA06274 for ipp-outgoing; Thu, 23 Oct 1997 08:07:43 -0400 (EDT) From: don@lexmark.com Message-Id: <199710231207.AA03234@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: Robert.Herriot@Eng.Sun.COM Cc: Ipp@Pwg.Org Date: Thu, 23 Oct 1997 08:07:24 -0400 Subject: Re: IPP>PRO latest protocol document Mime-Version: 1.0 Content-Type: multipart/mixed; Boundary="0__=YiMK4BON5urkfO8Hdlq3lDdPM7GUjgpMm2XBpbYbwwhnjw8Jye7spxkZ" Sender: ipp-owner@Pwg.Org Precedence: bulk --0__=YiMK4BON5urkfO8Hdlq3lDdPM7GUjgpMm2XBpbYbwwhnjw8Jye7spxkZ Content-type: text/plain; charset=us-ascii Neither of the WORD documents are readable by Word for Windows 95. Were they uploaded as binary? Don ********************************************** * Don Wright don@lexmark.com * * Manager, Strategic Alliances and Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** (Embedded image moved Robert.Herriot%Eng.Sun.COM@interlock.lexmark.com to file: 10/22/97 10:30 PM PIC18679.PCX) To: ipp%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright) Subject: IPP>PRO latest protocol document I have just downloaded the latest protocol document to: ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO The files are: ipp-pro-971022.doc MS Word 6 with no revision marks ipp-pro-971022.txt text file with no revisions marks ipp-pro-971022-rev.doc MS Word 6 with revision marks I expect these changes are the last before the Boulder meeting next week. The revisions are for the following issues: Peter Zehler's request for clarifications with no changes to protocol Changes for notification removal -- none Changes for charset and language: description of text, examples, table of attributes for operations. bug fix: I found that the naturalLanguage type couldn't be used with both the value of the attribute attributes-natural-language and to override one attribute value because in the former case the value stands alone and in the latter case it combines with the following text or name value. So I added a naturalLanguagePrefix type into the old slot for 'language' type which should have been removed in the last edition when 'naturalLanguage' was added. --0__=YiMK4BON5urkfO8Hdlq3lDdPM7GUjgpMm2XBpbYbwwhnjw8Jye7spxkZ Content-type: application/octet-stream; name="PIC18679.PCX" Content-transfer-encoding: base64 CgUBCAAAAABoACwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAABaQABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAD1E9sTzRPHE8MTwhP1E9sTzRPHE8MTwhP1E9sTzRPHE8MTwhP1E9sTzRPH E8MTwhP1E9sTzRPHE8MTwhP1E9sTzRPHE8MTwhP1E9sTzRPHE8MTwhP1E9sTzRPHE8MTwhP1E9sT zRPHE8MTwhPwEwzIBgzYE8wTxhPDE8IT7hPOBtcTzBPGE8MTE+wTwgbCBwbCEgbCEgbCEsUG1hPL E8YTwxMT6hMMwgYHwgLCAwISwgfEEsMCwwbVE8sTxRPDExPpE8MGAwcCBwMCwhLDB8ISwgISwgLD BtUTyhPFE8MTE+gTwgIHA8ICEw4DDgLDE8USwwLCEMIG1BPKE8UTwxMT5xMCAwcDAg4TDgITwgIS D8ISD8ISBRICEcICwwbUE8oTxRPCExPmEwYCBwMCDgIOwgLDExITEhPCEg8GxgLDBtMMDAfJE8QT whMT5hMGwwITBgMCDhLFEw8SE8ISBgIDwhIDEsMGB9MDxwwHxRPDExPlEwYHAhESAg8CwhMPwhMP xBMPxRIQwgIDAgMCBtMDxwPEDAfDE8IT4RMHwwzCBgLCEhMCDxLIE8MSD8MSwwIQAwIDBgfSDMkD wgPCDAfCExPbEwfGDMIDDAIHERITEhMSwxMPwxMPwxPDEgIDAgMCwwMCBgzREwfHDMYDDMITE9YT B8UMyAMGB8ICBhLDAsYTEhMSExIPwhIHAgcCAwUQAgYRBgfSE8UTB8QMwgMMwhMT0hMHxAzLA8IM BsISDxESExITAw4DxBMSExITwxICBwPCAsMDDMIGB9ITyRMHwwzCExPPEwfDDMkDxQwHwhMGBxIT AhECEwMOAg7DExITDxMPwxIDAgMCBwMCDAYRBgfSE8kTwhPCDMITE8wTB8MMxwPEDMIHxxMGxBLD Ag4DDgIGwg/IEgIDwgIDAgwCEMIGB9ITyRMHDAcMwhMTyhMHwgzGA8MMwgfMEwYHwhLCEAIOAg4C DhDDAhIPxhIFAgXDAgUCEQYH0hPHEwfCDAcPDMITE8gTB8IMxQPDDAfQEwbDEhDEAhAOEA4QwgLG EgcSBhIGBcMCBcIGB9ATB8UMEwfCDA8HDwwHwhMTxhMHwgzEA8MMB9MTBgfCEhADEMICDhAOEMIC EQIDxxIGBwbCAgUCEQYHyxMHxAwHwhMHEwzCEwcPBw8MB8MTE8UTBwzEA8IMB9YTBsQSEAMCA8UC EQIDAgPDEgcSBgfCBgUQAhDCBgfGEwfEDAfGE8INEwzCEw8HwgwHwxPCE8QTBwzDA8IMB9gTBgfE EhACEMYCEQIDAsQSBhLDBsICEALCBgfCEwfDDAfKEwfCDRMHwhPCDAfEE8ITE8MTBwzCA8IMB9oT DBIHwxLDDBEDxQIDAgPDEgYSBgfCBgIQAhAGDAfCEwzDE8MHyRMHwhPCBxMHxRPDExPDEwzCAwwH 3RMGxxICEQPDAgMCA8MSBhIGBwYMBhACEAIGDMMTDBPCB8YTwwfHEwfGE8MTwhPDEwwDDAfeEwYH xxICEQPDAgMCwhIGEgYHBgwGEAIQAsIGB8MTDMYTwwfKEwzGE8MTwhPDE8IMB98TDBLCB8USAgMR xAISB8ISBgcGDAYQBhAGEAYMB8MMB8kTwwfHEwzGE8MTwhPDEwwPwgzfEwYSB8ISB8ISAhECAwID EgcSBwYHBgwGEAYQxgzDD8IHxRPDB8kTBwzGE8MTwhPDEwzDD8QM3BPCBhIGwxIGAhECAwIHBgcG yAzJDxMHzRMHwwwHxxPDE8ITwxMHDMYPxwwH1BMGEgYSBhLLDM4PwwwTDMcTwgfEDAfJE8QTwhMT xBMHwgzLD9sM0w/GDAfDEwzDEwfEDAfLE8YTwxMTxhMHxAztD8gMBgfIE8QMB84TxxPDE8ITyhMH xwzbD8sMEAUMBcIMwgYH1RPKE8UTwxMT0RMH2wwGEAYQBhACBQwFDAUMBgwHBgfWE8sTxRPDExPu EwYMBhAGEAIGDAYMwwYH1xPLE8YTwxMT8BPKBgfYE8wTxhPDExP1E9sTzRPHE8MTwhP1E9sTzRPH E8MTwhMMAAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vwoKCkgICA/wAAAP8A//8AAAD/ /wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vwoKCkgICA/wAAAP8A//8A AAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vwoKCkgICA/wAAAP8A //8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vwoKCkgICA/wAA AP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vwoKCkgICA /wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vwoKCk gICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vw oKCkgICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw //vwoKCkgICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzA psrw//vwoKCkgICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDA wNzApsrw//vwoKCkgICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICA wMDAwNzApsrw//vwoKCkgICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACA AICAwMDAwNzApsrw//vwoKCkgICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACA gACA//vwoKCkgICA/wAAAP8A//8AAAD//wD/AP////// --0__=YiMK4BON5urkfO8Hdlq3lDdPM7GUjgpMm2XBpbYbwwhnjw8Jye7spxkZ-- From ipp-archive Thu Oct 23 13:15:44 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA13724 for ipp-outgoing; Thu, 23 Oct 1997 13:15:08 -0400 (EDT) Message-Id: <3.0.1.32.19971023101914.0113f270@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 23 Oct 1997 10:19:14 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> ADM - I posted the minutes of 10/22 Phone Conference Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk I've copied the .txt and created a .pdf to the usual place with the usual names: ftp://ftp.pwg.org/pub/pwg/ipp/minutes/971022-ipp-conference-call.txt .pdf I didn't make a .doc file though. Tom >Return-Path: >X-Sender: szilles@elroy >Date: Wed, 22 Oct 1997 15:59:28 PDT >To: ipp@pwg.org >From: Steve Zilles >Subject: IPP> ADM - minutes of 10/22 Phone Conference >Cc: szilles@Adobe.COM >Sender: ipp-owner@pwg.org > >The minutes of the phone conference on Oct 22 are attached. > Steve Zilles > > > From ipp-archive Thu Oct 23 13:35:51 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA14691 for ipp-outgoing; Thu, 23 Oct 1997 13:34:16 -0400 (EDT) Message-Id: <3.0.1.32.19971023103804.01136100@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 23 Oct 1997 10:38:04 PDT To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - ISSUE: Make "page-range" multi-valued Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk In reading Steve's document processing note, I realized that Windows (and DPA) allows more than one page range to be specified in a single (document) print job. [I've already passed on to Scott the typo that the data type is 'rangeOfInteger', not rangeOf integer' in the table and the heading, so I've assumed that change here.] 1. To capture that same functionlaty I suggest that we change the heading from: 4.2.14 page-range (rangeOfInteger) to: 4.2.14 page-ranges (1setOf rangeOfInteger) 2. Also the Job Template table would need to be changed from: page-range No page-range-supported (rangeOfInteger) (boolean) to: page-ranges No page-ranges-supported (1setOF rangeOfInteger) (boolean) 3. By the way, the description in 4.2.14 (soon to be renumbered with notify-events and notify-addresses being deleted), last sentence refers to the "page-range-default" attribute always having a value of zero (0) meaning that the default is always the entire document. I suggest that we delete that sentence, since a 0 isn't a valid value for a rangeOfInteger, and the table says "No". Or Change the sentence from: The page-range-default value is zero (0) and indicates that all pages of the document will be printed if a page-range is not specified. to: There is no "page-ranges-default" attribute. If the "page-ranges" attribute is not supplied, all pages of the document will be printed. Comments? Tom From ipp-archive Thu Oct 23 16:40:46 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA15899 for ipp-outgoing; Thu, 23 Oct 1997 16:37:55 -0400 (EDT) From: szilles@Adobe.COM (Stephen Zilles) Message-Id: <199710232037.NAA05116@bulletin> To: ipp@pwg.org Subject: IPP> MOD - draft of text on document processing (again) Phone: (408) 536-4766 Fax: (408) 537-4042 Office: W14-504 Cc: szilles@Adobe.COM Date: Thu, 23 Oct 1997 13:36:59 PDT Sender: ipp-owner@pwg.org Precedence: bulk Because the following message seemed to have been mangled somewhere in the transmission process, here it is again: The following is the proposed text to add a section 16.4 to Appendix E for the purpose of describing how the processing attributes, such as Nup, Duplex, etc., are used in processing the document. Because I had to do some creative thinking is writing this algorithm, I am sending it out for comment as well as for inclusion in the draft. I am missing the suggested edits for the attribute descriptions them selves. I thin each of the attributes mentioned below should have a sentence like, "The relationship of this attribute and the other attributes that control document processing is described in Appendix E, section 16.4" Glossary (I haven't the foggiest where these defns should go in the Model document) print-stream page: a page according to the definition of pages in the language used to express the document data. imposed page: a page created by placing N print-stream pages onto a single page. 16.4 Using Job-template attributes during document processing. Some of the Job-template attributes are to be used during the processing of the document data. These include, but are not limited to, "orientation", "number-up", "sides", "media" "copies". The processing of each Document Object in a Job Object SHALL follow the algorithm below. This algorithm is intended only to identify when and how attributes are to be used in processing document data and any algorithm that accomplishs the same effect can be used to implement this specification. 1. Using the "document-format" attribute or some form of format detection algorithm (if the value of "document-format" is not specific enough), determine whether or not the document data has already been formatted for printing. If the document data has been formatted, then goto step 2. Otherwise, the document data SHALL be formatted. The formatting algorithm is implementation defined and is not specified by this specification. The formatting of the document data uses the "orientation" attribute to determine how the formatted print data is place on a print-stream page, see section 4.2.15 for the details. 2. The document data is in the form of a print-stream in a known media type. The "page-range" attribute is used to select, as specified in section 4.2.14, a sub-sequence of the pages in the print-stream that are to be processed and images. 3. The input to this step is sequence of print-stream pages. This step is controlled by the "number-up" attribute. If value of "number-up" is N, then during the processing of the print-stream pages, each N print-stream pages are positioned, as specified in section 4.2.8, to create a single imposed page. If a given Document Object does not have N more print-stream pages, then the completion of the imposed page is controlled by the "multiple-document-handling" attribute as described in section 4.2.6; when the value of this attribute is 'separate-documents-collated-copies', the document data from subsequent Document Objects is used to complete the imposed page. The size(scaling), position(translation) and rotation of the print-stream pages on the imposed page is implementation defined. Note that during this process the print-stream pages may be rendered to a form suitable for placing on the imposed page; this rendering is controlled by the values of the "printer-resolution" and "print-quality" attributes as described in sections 4.2.10 and 4.2.11. In the case N=1, the imposed pages are are nearly the same as the print-stream pages; the differences would only be in the size, postion and rotation of the print-stream page and/or any decoration, such as a frame to the page, that is added by the implementation. 4. The collection of imposed pages is placed, in sequence, onto sides of the print media. This placement is controled by the "sides" attribute and the orientation of the page, as described in section 4.2.9. The orientation of the page is defined by the orientation of the imposed pages; for example, if "number-up" equals 2, then, typically, two portrait print-stream pages become one landscape imposed page. Note that the placement of imposed pages onto media instances is also controlled by the "multiple-document-handling" attribute as described in section 4.2.6. 5. The "copies" and "multiple-document-handling" attributes are used to determine how many copies of each media instance are created and in what order. See sections 4.2.6 and 4.2.13 for the details. 6. When the correct number of copies are created, the media instances are finished according to the values of the "finishings" attribute as described in 4.2.12. Note that sometimes finishing operations may require manual intervention to perform the finishing operations on the copies, especially uncollated copies. This specification allows any or all of the processing steps to be performed automatically or manually at the descretion of the implementation of the Printer Object. From ipp-archive Thu Oct 23 20:15:50 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA16717 for ipp-outgoing; Thu, 23 Oct 1997 20:11:19 -0400 (EDT) Date: Thu, 23 Oct 1997 17:09:40 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199710240009.RAA14128@woden.eng.sun.com> To: ipp@pwg.org, szilles@Adobe.COM Subject: Re: IPP> MOD - draft of text on document processing (again) X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Two comments below. > From szilles@Adobe.COM Thu Oct 23 13:51:17 1997 > Some systems during the formatting process will perform step 2 and perhaps even step 3 in step 1. > > 2. The document data is in the form of a print-stream in a known media > type. The "page-range" attribute is used to select, as specified in > section 4.2.14, a sub-sequence of the pages in the print-stream that are > to be processed and images. > > 3. The input to this step is sequence of print-stream pages. This step > is controlled by the "number-up" attribute. If value of "number-up" is > N, then during the processing of the print-stream pages, each N > print-stream pages are positioned, as specified in section 4.2.8, to > create a single imposed page. If a given Document Object does not have N > more print-stream pages, then the completion of the imposed page is > controlled by the "multiple-document-handling" attribute as described in > section 4.2.6; when the value of this attribute is > 'separate-documents-collated-copies', the document data from subsequent > Document Objects is used to complete the imposed page. I think you mean 'single-document' rather than 'separate-documents-collated-copies'. In fact a 'NOT' seems to have crept into line 1754 where separate-documents-collated-copies is defined. ! > > > ! > > From ipp-archive Thu Oct 23 22:50:51 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA17657 for ipp-outgoing; Thu, 23 Oct 1997 22:46:17 -0400 (EDT) Date: Thu, 23 Oct 1997 19:44:44 -0700 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199710240244.TAA14438@woden.eng.sun.com> To: ipp@pwg.org Subject: IPP>PRO corrected protocol document X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk It appears that ftp truncated 16 bytes off one file and 18 off of another even though I remember using binary mode. The files were both corrupted at around byte 60,000 So I have downloaded new files, which at least have the correct byte count. I removed all the old corrupt files. They are in: ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO. The files are ipp-pro-971023.doc MS Word with no revision marks ipp-pro-971023-rev.doc MS Word with revisions marks ipp-pro-971023.txt text with no revision marks The revisions are with respect to the October 14 release. The changes are: The revisions are for the following issues: Peter Zehler's request for clarifications with no changes to protocol A minor typo in the grammar. Changes for notification removal -- none Changes for charset and language: description of text, examples, table of attributes for operations. bug fix: I found that the naturalLanguage type couldn't be used with both the value of the attribute attributes-natural-language and to override one attribute value because in the former case the value stands alone and in the latter case it combines with the following text or name value. So I added a compoundValue value-tag type whose value specifies the number of following "values" that form a compound value. A name with a Canadian French override would consists of 3 "values": a compoundValue whose value is 2, a naturalLanguage whose value is "fr-CA" and the name value. (This solution is slightly different from the one I put in yesterday's version, but this is a more general solution that offers extensibility for things like a charset override.) From ipp-archive Fri Oct 24 00:15:52 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA18383 for ipp-outgoing; Fri, 24 Oct 1997 00:14:29 -0400 (EDT) From: szilles@Adobe.COM (Stephen Zilles) Message-Id: <199710240413.VAA20554@bulletin> To: ipp@pwg.org Subject: IPP> Revision of section 4.2.6 multiple-document-handling Phone: (408) 536-4766 Fax: (408) 537-4042 Office: W14-504 Cc: szilles@Adobe.COM Date: Thu, 23 Oct 1997 21:13:50 PDT Sender: ipp-owner@pwg.org Precedence: bulk [The terminology in this section seems to muddle "document" meaning document data and "document" meaning what has finishing operations applied to it. For this reason the entire section has been redone.] The current text is: 4.2.6 multiple-document-handling (type2 keyword) This job attribute is relevant only if a job consists of two or more documents. It controls finishing operations, and job- sheet placement. When the copies attribute exceeds 1, it also controls the order of documents. Standard values are: 'single-document': If the files for the job are a and b, then files a and b SHALL be treated as a single document for finishing operations. The Printer SHALL NOT force each document to start on a new page or new media sheet. If more than one copy is made, the ordering SHALL be a, b, a, b,...., and the Printer SHALL force each copy to start on a new sheet. 'separate-documents-uncollated-copies': If the files for the job are a and b, then each file SHALL be treated as a single document for finishing operations. The Printer shall force each document copy to start on a new sheet. If more than one copy is made, the ordering SHALL be a, a, b, b, .... 'separate-documents-collated-copies': If the files for the job are a and b, then each file SHALL be treated as a single document for finishing operations. The Printer SHALL NOT force each document copy to start on a new sheet. If more than one copy is made, the ordering SHALL be a, b, a, b, ...., and the Printer shall force each document copy to start on a new sheet . [Note the use of "files" instead of "document data" which is used in the operation descriptions in 3.2 and 3.3; the mis-use of "document" noted above and the confusion of pages and media sheets. Nothing is said in these descriptions about the placement of job-sheets. Finally, I do not understand the final case at all; it says "each file SHALL be treated as a single document for finishing operations. The Printer SHALL NOT force each document copy to start on a new sheet. There is no way if parts of two files are place on opposite sides of the same sheet (because of the SHALL NOT) that they will be finished separately. I am also not really sure which use of "document" is being used in the SHALL NOT clause. This suggests the following revision of the section. Note that I had to introduce a somewhat awkward term, "set of media sheets" for the second (mis-) use of "document" above.] 4.2.6 multiple-document-handling (type2 keyword) This job attribute is relevant only if a job consists of two or more documents. The attribute controls finishing operations and the placement of print-stream pages into imposed pages and onto media sheets. When the value of the "copies" attribute exceeds 1, it also controls the order in which the copies that result from processing the documents are produced. For the purposes of this explanations, if "a" represents an instance of document data, then the result of processing the data in document "a" is a sequence of media sheets represented by "a'". Standard values are: 'single-document': If a Job object has multiple documents, say the document data is called a and b, then the result of processing all the document data (a and then b) SHALL be treated as a single sequence of media sheets for finishing operations; that is, finishing would be performed on the concatenation of the seqeunces a',b'. The Printer SHALL NOT force the data in each document instance to be formatted onto a new print-stream page, nor to start a new imposed page or a new media sheet. If more than one copy is made, the ordering of the sets of media sheets resulting from processing the document data SHALL be a', b', a', b',...., and the Printer SHALL force each copy to start on a new media sheet. 'separate-documents-uncollated-copies': If a Job object has multiple documents, say the document data is called a and b, then the result of processing the data in each document instance SHALL be treated as a single sequence of media sheets for finishing operations; that is, the sets a' and b' would each be finished separately. The Printer SHALL force each copy of the result of process the data in a single document to start on a new media sheet. If more than one copy is made, the ordering of the sets of media sheets resulting from processing the document data SHALL be a', a', b', b' .... 'separate-documents-collated-copies': If a Job object has multiple documents, say the document data is called a and b, then the result of processing the data in each document instance SHALL be treated as a single sequence of media sheets for finishing operations; that is, the sets a' and b' would each be finished separately. If more than one copy is made, the ordering of the sets of media sheets resulting from processing the document data SHALL be a', b', a', b', ...., and the Printer SHALL force each document copy to start on a new sheet . [Note that in the last case, the internal conflict in the description noted above was resolved by removing the apparently un-intented SHALL NOT clause. With this change, the last case becomes the same as the first case with respect to ordering and media sheet generation, but different with respect to finishing.] [Note also the this text does not say anything about the placement of job-sheets because the prior text also did not say anything about the placement of job-sheets.] From ipp-archive Fri Oct 24 11:11:01 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA20017 for ipp-outgoing; Fri, 24 Oct 1997 11:10:58 -0400 (EDT) Message-Id: <3.0.1.32.19971024081456.0108c490@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 24 Oct 1997 08:14:56 PDT To: szilles@Adobe.COM (Stephen Zilles), ipp@pwg.org From: Tom Hastings Subject: Re: IPP> Revision of section 4.2.6 multiple-document-handling Cc: szilles@Adobe.COM In-Reply-To: <199710240413.VAA20554@bulletin> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk I haven't had a chance to analyze the complete new proposal for multiple-document-handling, but had the following comments on the comments at the end: >[Note that in the last case, the internal conflict in the description >noted above was resolved by removing the apparently un-intented SHALL >NOT clause. 1. The SHALL NOT was introduced in the Sept 26 version when adding the entire sentence to the third value to make it like the second value. I agree that the NOT should be removed in the sentence: "The Printer SHALL NOT force each document copy to start on a new sheet." so that the third value has the same sentence as the second value. > With this change, the last case becomes the same as the >first case with respect to ordering and media sheet generation, but >different with respect to finishing.] 2. I disagreed slightly with the characterization of the three values: 'single-document' 'separate-documents-uncollatted-copies' 'separate-documents-collated-copies' I believe that the last case becomes the same as the first case with respect to ordering of pages, but NOT media sheet generation, since the first case will put the first page of the next document on the back side of a sheet if an odd number of pages have been produced so far for the job, while the third case always force the next document or document copy on to a new sheet. Perhaps you meant the "ordering of pages and the ordering of media sheet generation". > >[Note also the this text does not say anything about the placement of >job-sheets because the prior text also did not say anything >about the placement of job-sheets.] 3. The September 26 version deleted the sentences about "slip sheets" from all three values since IPP doesn't have a way for a client to specify that a slip sheet is to be placed anywhere. ISO DPA we defined a whole bunch of different values for the "job-sheet" attribute that controlled whether extra (slip) sheets were introduced between documents and/or between copies. We could register additional values for the "job-sheet" attribute (after V1.0). Or we could register an IPP attribute that controls slip sheets (after V1.0), if that is desired. Here is Steve's entire message for context (with no comments inserted): At 21:13 10/23/1997 PDT, Stephen Zilles wrote: >[The terminology in this section seems to muddle "document" meaning >document data and "document" meaning what has finishing operations >applied to it. For this reason the entire section has been redone.] > >The current text is: > > 4.2.6 multiple-document-handling (type2 keyword) > > This job attribute is relevant only if a job consists of two > or more documents. It controls finishing operations, and job- > sheet placement. When the copies attribute exceeds 1, it > also controls the order of documents. > > Standard values are: > > 'single-document': If the files for the job are a and > b, then files a and b SHALL be treated as a single > document for finishing operations. The Printer > SHALL NOT force each document to start on a new > page or new media sheet. If more than one copy is > made, the ordering SHALL be a, b, a, b,...., and > the Printer SHALL force each copy to start on a > new sheet. > 'separate-documents-uncollated-copies': If the files > for the job are a and b, then each file SHALL be > treated as a single document for finishing > operations. The Printer shall force each document > copy to start on a new sheet. If more than one > copy is made, the ordering SHALL be a, a, b, b, > .... > 'separate-documents-collated-copies': If the files for > the job are a and b, then each file SHALL be > treated as a single document for finishing > operations. The Printer SHALL NOT force each > document copy to start on a new sheet. If more > than one copy is made, the ordering SHALL be a, > b, a, b, ...., and the Printer shall force each > document copy to start on a new sheet . > > >[Note the use of "files" instead of "document data" which is used in the >operation descriptions in 3.2 and 3.3; the mis-use of "document" noted >above and the confusion of pages and media sheets. Nothing is said in >these descriptions about the placement of job-sheets. Finally, I do not >understand the final case at all; it says "each file SHALL be treated as >a single document for finishing operations. The Printer SHALL NOT force >each document copy to start on a new sheet. There is no way if parts of >two files are place on opposite sides of the same sheet (because of the >SHALL NOT) that they will be finished separately. I am also not really >sure which use of "document" is being used in the SHALL NOT clause. > > This suggests the following revision of the section. Note that I had to >introduce a somewhat awkward term, "set of media sheets" for the second >(mis-) use of "document" above.] > > > 4.2.6 multiple-document-handling (type2 keyword) > > This job attribute is relevant only if a job consists of two or more > documents. The attribute controls finishing operations and the placement > of print-stream pages into imposed pages and onto media sheets. When > the value of the "copies" attribute exceeds 1, it also controls the > order in which the copies that result from processing the documents are > produced. For the purposes of this explanations, if "a" represents an > instance of document data, then the result of processing the data in > document "a" is a sequence of media sheets represented by "a'". > > Standard values are: > > 'single-document': If a Job object has multiple documents, say the > document data is called a and b, then the result of processing > all the document data (a and then b) SHALL be treated as a > single sequence of media sheets for finishing operations; that is, > finishing would be performed on the concatenation of the > seqeunces a',b'. The Printer SHALL NOT force the data in each > document instance to be formatted onto a new print-stream > page, nor to start a new imposed page or a new media sheet. If > more than one copy is made, the ordering of the sets of media > sheets resulting from processing the document data SHALL be > a', b', a', b',...., and the Printer SHALL force each copy to > start on a new media sheet. > 'separate-documents-uncollated-copies': If a Job object has > multiple documents, say the document data is called a and b, > then the result of processing the data in each document > instance SHALL be treated as a single sequence of media sheets for > finishing operations; that is, the sets a' and b' would each > be finished separately. The Printer SHALL force each copy of the > result of process the data in a single document to start on a > new media sheet. If more than one copy is made, the ordering > of the sets of media sheets resulting from processing the > document data SHALL be a', a', b', b' .... > 'separate-documents-collated-copies': If a Job object has multiple > documents, say the document data is called a and b, then the > result of processing the data in each document instance SHALL > be treated as a single sequence of media sheets for finishing > operations; that is, the sets a' and b' would each be finished > separately. If more than one copy is made, the ordering of the > sets of media sheets resulting from processing the document > data SHALL be a', b', a', b', ...., and the Printer SHALL > force each document copy to start on a new sheet . > > >[Note that in the last case, the internal conflict in the description >noted above was resolved by removing the apparently un-intented SHALL >NOT clause. With this change, the last case becomes the same as the >first case with respect to ordering and media sheet generation, but >different with respect to finishing.] > >[Note also the this text does not say anything about the placement of >job-sheets because the prior text also did not say anything >about the placement of job-sheets.] > > From ipp-archive Fri Oct 24 12:41:03 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA20965 for ipp-outgoing; Fri, 24 Oct 1997 12:39:30 -0400 (EDT) Message-Id: <3.0.1.32.19971024094329.0108f3c0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 24 Oct 1997 09:43:29 PDT To: Robert.Herriot@Eng.Sun.COM (Robert Herriot), ipp@pwg.org From: Tom Hastings Subject: Re: IPP>PRO corrected protocol document [.pdf files posted] In-Reply-To: <199710240244.TAA14438@woden.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk I've distilled the two .doc files and posted: ipp-pro-971023.pdf PDF with no revision marks ipp-pro-971023-rev-red.pdf PDF with red revisions marks ipp-pro-971023-rev-black.pdf PDF with black revision marks Tom At 19:44 10/23/1997 PDT, Robert Herriot wrote: > >It appears that ftp truncated 16 bytes off one file and 18 off of another >even though I remember using binary mode. The files were both corrupted >at around byte 60,000 > >So I have downloaded new files, which at least have the correct byte count. >I removed all the old corrupt files. > >They are in: > >ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO. > >The files are > > ipp-pro-971023.doc MS Word with no revision marks > ipp-pro-971023-rev.doc MS Word with revisions marks > ipp-pro-971023.txt text with no revision marks > >The revisions are with respect to the October 14 release. > >The changes are: > >The revisions are for the following issues: > > Peter Zehler's request for clarifications with no changes to protocol > > A minor typo in the grammar. > > Changes for notification removal -- none > > Changes for charset and language: description of text, examples, table > of attributes for operations. > > bug fix: I found that the naturalLanguage type couldn't be used with > both the value of the attribute attributes-natural-language and > to override one attribute value because in the former case the > value stands alone and in the latter case it combines with the > following text or name value. So I added a compoundValue value-tag > type whose value specifies the number of following "values" that > form a compound value. A name with a Canadian French override > would consists of 3 "values": a compoundValue whose value is 2, > a naturalLanguage whose value is "fr-CA" and the name value. > (This solution is slightly different from the one I put in yesterday's > version, but this is a more general solution that offers extensibility > for things like a charset override.) > > From ipp-archive Fri Oct 24 12:41:04 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA20952 for ipp-outgoing; Fri, 24 Oct 1997 12:38:43 -0400 (EDT) Date: Fri, 24 Oct 1997 09:42:21 PDT From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9710241642.AA23767@snorkel.eso.mc.xerox.com> To: imcdonal@eso.mc.xerox.com, ipp@pwg.org, masinter@parc.xerox.com Subject: IPP> MOD - Revised 'application/ipp' MIME type Sender: ipp-owner@pwg.org Precedence: bulk Copies To: masinter@parc.xerox.com imcdonal@eso.mc.xerox.com ipp@pwg.org Hi folks, Friday (24 October 1997) At our IPP Telecon on Wednesday (22 October), I got the action item to write up new text for registration of MIME media type "application/ipp". This template came from the IETF MIME Part Four: Registration Procedures (RFC 2048, November 1996). Note_1: We need not actually apply for registration of this media-type until the IPP/1.0 specs are accepted by the IESG onto the 'standards track'. The application is made by mail (see below) and need not be supported by a separate Informational RFC. Note_2: The 'Intended usage' of 'LIMITED USE' (rather than 'COMMON') is based on advice earlier this month from Larry Masinter. Cheers, - Ira McDonald (outside consultant at Xerox) High North Inc PO Box 221 Grand Marais, MI 49839 906-494-2434 ------------------------------------------------------------------------ To: ietf-types@iana.org Subject: Registration of MIME media type "application/ipp" MIME type name: application MIME subtype name: ipp A Content-Type of "application/ipp" indicates an Internet Printing Protocol message body (request or response). Currently there is one version: IPP/1.0, described in [IPP-MOD] and [IPP-PRO]. Required parameters: none Optional parameters: none Encoding considerations: IPP/1.0 protocol requests/responses MAY contain long lines and ALWAYS contain binary data (for example attribute value lengths). Security considerations: IPP/1.0 protocol requests/responses do not introduce any security risks not already inherent in underlying transport protocols. Interoperability considerations: IPP/1.0 requests (generated by clients) and responses (generated by servers) MUST comply with all conformance requirements imposed by the normative specifications [IPP-MOD] and [IPP-PRO]. Protocol encoding rules specified in [IPP-PRO] are complete and unambiguous so interoperability between conforming implementations is ensured (although support for specific optional features is not ensured). Both the "charset" and "natural-language" of all IPP/1.0 attribute values of syntax "text" or "name" are explicit within IPP protocol requests/responses (without recourse to any external information in MIME, HTTP, or other message transport headers). Published specification: [IPP-MOD] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, "Internet Printing Protocol/1.0: Model and Semantics", work in progress , October 1997. [IPP-PRO] S. Butler, R. Herriot, P. Moore, R. Turner, "Internet Printing Protocol/1.0: Protocol Specification", work in progress , October 1997. Applications which use this media type: Internet Printing Protocol (IPP) print clients and print servers. Person & email address to contact for further information: Scott A. Isaacson Novell, Inc. 122 E 1700 S Provo, UT 84606 Phone: 801-861-7366 Fax: 801-861-4025 Email: scott_isaacson@novell.com or Robert Herriot Sun Microsystems Inc. 901 San Antonio Road, MPK-17 Palo Alto, CA 94303 Phone: 650-786-8995 Fax: 650-786-7077 Email: robert.herriot@eng.sun.com Intended usage: LIMITED USE ------------------------------------------------------------------------ From ipp-archive Fri Oct 24 17:21:06 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA23590 for ipp-outgoing; Fri, 24 Oct 1997 17:16:33 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Fri, 24 Oct 1997 15:15:39 -0600 From: Scott Isaacson To: ipp@pwg.org Subject: IPP> MOD - new model document Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org Precedence: bulk I posted a new version of the model document. I will be sending this to the IETF (not for final call for comments, just as yet another version of the document). As usual: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-971021-rev.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-971021-rev.rtf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-971021.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-971021.rtf ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-971021.txt Please use ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-971021.pdf for all comments (no rev marks, line numbers) I forgot to change the internal date - still says 10/14/97 even though the filename is 971021. Scott From ipp-archive Fri Oct 24 19:21:07 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA24595 for ipp-outgoing; Fri, 24 Oct 1997 19:18:30 -0400 (EDT) Message-Id: <3.0.1.32.19971024162235.01025150@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 24 Oct 1997 16:22:35 PDT To: ipp@pwg.org From: Tom Hastings Subject: Re: IPP> MOD - Revised 'application/ipp' MIME type Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Here is Larry's answer to my question as to what it means for the application/ipp media type to be "limited use". Sounds reasonable to me. Tom >Return-Path: >Date: Fri, 24 Oct 1997 12:11:34 PDT >From: Larry Masinter >Organization: Xerox PARC >To: Tom Hastings >Cc: Ira Mcdonald x10962 >Subject: Re: IPP> MOD - Revised 'application/ipp' MIME type > >Uh, this was an area where I was trying to set a pointer to >'ask a real expert'. However, 'application/ipp' is not intended >for use in email, in server PUSH, or in arbitrary applications >that use MIME objects. You probably shouldn't expect >to find files labelled as 'application/ipp' sitting in a document >repository. Since it is solely intended for use within >the IPP protocol which is implemented by tunnelling through >HTTP/1.1, it's applicability is limited. > >Larry >-- >http://www.parc.xerox.com/masinter > > From ipp-archive Fri Oct 24 21:21:08 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA25644 for ipp-outgoing; Fri, 24 Oct 1997 21:19:34 -0400 (EDT) Message-Id: <3.0.1.32.19971024182343.00d00e70@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 24 Oct 1997 18:23:43 PDT To: Scott Isaacson , ipp@pwg.org From: Tom Hastings Subject: Re: IPP> MOD - new model document In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Be careful. Not only does the date still say 10/14/97 as Scott points out, but the file name at the top of first page says . It should be 07. This will confuse the IETF secretariat a lot. I had the same problem with the Job Monitoring MIB. Tom At 14:15 10/24/1997 PDT, Scott Isaacson wrote: >I posted a new version of the model document. I will be sending this >to the IETF (not for final call for comments, just as yet another version >of the document). > >As usual: > >ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ > >ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-971021-rev.pdf >ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-971021-rev.rtf >ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-971021.pdf >ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-971021.rtf >ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-971021.txt > >Please use > >ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-971021.pdf > >for all comments (no rev marks, line numbers) > >I forgot to change the internal date - still says 10/14/97 even though the >filename is 971021. > >Scott > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From ipp-archive Fri Oct 24 22:06:09 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA26674 for ipp-outgoing; Fri, 24 Oct 1997 22:06:04 -0400 (EDT) Message-Id: <199710250205.TAA24278@bulletin> To: Tom Hastings cc: ipp@pwg.org, szilles@Adobe.COM Subject: Re: IPP> Revision of section 4.2.6 multiple-document-handling In-reply-to: Your message of "Fri, 24 Oct 1997 08:14:56 PDT." <3.0.1.32.19971024081456.0108c490@garfield> Date: Fri, 24 Oct 1997 19:05:19 PDT From: "Steve Zilles" Sender: ipp-owner@pwg.org Precedence: bulk > From: Tom Hastings > >[Note that in the last case, the internal conflict in the description > >noted above was resolved by removing the apparently un-intented SHALL > >NOT clause. > > 1. The SHALL NOT was introduced in the Sept 26 version when adding the > entire sentence to the third value to make it like the second value. > I agree that the NOT should be removed in the sentence: > "The Printer SHALL NOT force each document copy to start on a new sheet." > so that the third value has the same sentence as the second value. I agree that dropping the NOT would solve the conflict and it is a stronger statement to say, "The Printer SHALL force each copy of the result of processing the data in a single document to start on a new media sheet." than to say nothing at all. > > With this change, the last case becomes the same as the >first case > with respect to ordering and media sheet generation, but >different > with respect to finishing.] 2. I disagreed slightly with the > characterization of the three values: 'single-document' > 'separate-documents-uncollatted-copies' > 'separate-documents-collated-copies' I believe that the last case > becomes the same as the first case with respect to ordering of pages, > but NOT media sheet generation, since the first case will put the > first page of the next document on the back side of a sheet if an odd > number of pages have been produced so far for the job, while the third > case always force the next document or document copy on to a new > sheet. Perhaps you meant the "ordering of pages and the ordering of > media sheet generation". I think I was just getting tired when I wrote the text and was not very careful. I had already observed that >Finally, I do not >understand the final case at all; it says "each file SHALL be treated as >a single document for finishing operations. The Printer SHALL NOT force >each document copy to start on a new sheet. There is no way if parts of >two files are placed on opposite sides of the same sheet (because of the >SHALL NOT) that they will be finished separately. So I (earlier in the evening) knew that the page placement was not the same as case 1. What is the same as case 1 is that the ordering of the sequences of media sheets, once created, is the same as case 1; namely, a', b', a', b', .... Steve From ipp-archive Sun Oct 26 08:51:33 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA02214 for ipp-outgoing; Sun, 26 Oct 1997 08:51:25 -0500 (EST) From: don@lexmark.com Message-Id: <199710261351.AA24550@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org, p1394@pwg.org Date: Sun, 26 Oct 1997 08:50:26 -0500 Subject: IPP> Denver weather - yuck!! Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Precedence: bulk 4 feet of snow!!!!!! Considering how much I hate snow, I couldn't have picked a better meeting to miss. Its sunny and mid 50's here in Paris. Ah, the Marriott on the Champs-Elysees is really excellent. See you all in LA! (No snow, OK Carl-uno!!) Don ********************************************** * Don Wright don@lexmark.com * * Manager, Strategic Alliances and Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-archive Sun Oct 26 11:01:34 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA03375 for ipp-outgoing; Sun, 26 Oct 1997 10:57:30 -0500 (EST) Date: Sun, 26 Oct 1997 08:01:31 PST From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9710261601.AA25031@snorkel.eso.mc.xerox.com> To: ipp@pwg.org Subject: IPP> ADM - RFC 2223 - Instructions to RFC Authors Sender: ipp-owner@pwg.org Precedence: bulk Scott, Bob, and Tom, This new RFC 2223 (October 1997) updates the ancient RFC 1543. It includes new text on Security Considerations and Full Copyright. I suggest you pull it off the IETF server at 'ftp.ds.internic.net', in 'rfc/rfc2223.txt'. There is also a brand new version of the RFC Index in 'rfc/rfc-index.txt', dated 25 October 1997. Good luck in Boulder this week, - Ira McDonald (outside consultant at Xerox) PS - Nancy and I will be travelling on Tuesday (28 October) and will arrive in Rochester, NY over the coming weekend. I should be picking up my mail again from Monday (3 November). Sorry to go off the map this week, when you're all having fun buttoning up IPP/1.0. From ipp-archive Sun Oct 26 13:01:35 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA04218 for ipp-outgoing; Sun, 26 Oct 1997 13:01:11 -0500 (EST) From: "Rajesh Chawla" To: "IPP Mailing List" Subject: IPP> IPP Test Suite Date: Sun, 26 Oct 1997 12:58:44 -0500 Message-ID: <01bce238$cd461760$8dc245c6@rajesh.ari.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: ipp-owner@pwg.org Precedence: bulk Hello, TR Computing Solutions is creating a test suite that will be able to test IPP servers. Functionality that will be provided by this test suite will include: Batch testing from a command line. Testing valid protocol requests. Testing invalid protocol requests. Allowing customization of test to allow private extensions to be tested. Logging of all requests and responses to the server being tested. The test suite is being written in Java to provide portability. If you have interest in this test suite please contact me at rajesh@trcs.com for further information. Regards, Rajesh ======================================================================= Rajesh Chawla TR Computing Solutions rajesh@trcs.com 13622 Flintwood Place 703-904-9689 Herndon VA 22071 From ipp-archive Sun Oct 26 21:16:44 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA06657 for ipp-outgoing; Sun, 26 Oct 1997 21:11:52 -0500 (EST) From: Harry Lewis To: , , Subject: IPP> Boulder Weather Message-ID: <5030300012998465000002L052*@MHS> Date: Sun, 26 Oct 1997 21:16:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk I've had a few questions about the weather. Anyone trying to arrive Sat= urday probably had quite a difficult time. Two feet of snow fell in most part= s. Today (Sunday) is warm and sunny. Roads are clear. Forecast is high's in the = 50's, lows in the 20's all week. Should be a great week! Harry Lewis - IBM Printing Systems = From ipp-archive Mon Oct 27 03:21:44 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id DAA08367 for ipp-outgoing; Mon, 27 Oct 1997 03:16:56 -0500 (EST) Message-Id: <1.5.4.32.19971027071613.00680bb8@pop3.holonet.net> X-Sender: cumanros@pop3.holonet.net X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 26 Oct 1997 23:16:13 -0800 To: Tom Hastings From: Carl-Uno Manros Subject: Re: IPP> MOD - new model document Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Precedence: bulk At 06:23 PM 10/24/97 PDT, you wrote: >Be careful. Not only does the date still say 10/14/97 as Scott points >out, but the file name at the top of first page says >. It should be 07. > >This will confuse the IETF secretariat a lot. I had the same problem >with the Job Monitoring MIB. > >Tom > Tom, You are the one who is confused. Version 06 was never sent to the IETF earlier. Carl-Uno From ipp-archive Mon Oct 27 10:36:50 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA09890 for ipp-outgoing; Mon, 27 Oct 1997 10:36:04 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Mon, 27 Oct 1997 08:33:01 -0600 From: Scott Isaacson To: hastings@cp10.es.xerox.com, ipp@pwg.org Subject: Re: IPP> MOD - new model document Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org Precedence: bulk I had never before sent an "06" version into the IETF so they should not be confused (I hope). Scott >>> Tom Hastings 10/24 7:23 PM >>> Be careful. Not only does the date still say 10/14/97 as Scott points out, but the file name at the top of first page says . It should be 07. This will confuse the IETF secretariat a lot. I had the same problem with the Job Monitoring MIB. Tom At 14:15 10/24/1997 PDT, Scott Isaacson wrote: >I posted a new version of the model document. I will be sending this >to the IETF (not for final call for comments, just as yet another version >of the document). > >As usual: > >ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ > >ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-971021-rev.pdf >ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-971021-rev.rtf >ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-971021.pdf >ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-971021.rtf >ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-971021.txt > >Please use > >ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-971021.pdf > >for all comments (no rev marks, line numbers) > >I forgot to change the internal date - still says 10/14/97 even though the >filename is 971021. > >Scott > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From ipp-archive Mon Oct 27 14:06:52 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA12034 for ipp-outgoing; Mon, 27 Oct 1997 14:04:05 -0500 (EST) Message-Id: <3.0.1.32.19971027104751.00cd85d0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 27 Oct 1997 10:47:51 PST To: Keith Moore , wg-chairs@apps.ietf.org From: Carl-Uno Manros Subject: IPP> Re: WG feedback: I-Ds in HTML, etc. Cc: ipp@pwg.org In-Reply-To: <199710270709.CAA24987@spot.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk At 11:09 PM 10/26/97 PST, Keith Moore wrote: >In a couple of weeks, IESG is having a face-to-face meeting. >One of the things we've agreed to discuss is the possibility of >allowing Internet-Draft submissions in HTML. > >I've done a lot of carping about WGs not doing things the >Traditional IETF Way (tm) -- like not having all working documents >published as plain ascii I-Ds, or not having ftp accessible >mail archives with the messages available in pure RFC 822 format. > >But since I know that various WGs have been experimenting with >ways of keeping track of issues and documents using the web >or other tools, I'd like to know of any techniques that you >have found especially useful -- things we might want to encourage >on a wider basis. > >And if there are needless encumberances in our mechanisms or >processes, we need to hear that also. (IESG cannot change the >process rules but it might be able to smooth out difficulties >with the I-D submission process, interactions with the RFC >Editor, or the IESG itself.) > >Thanks! > >Keith > Speaking for the IPP group, we have found the following complementary tools very useful: 1) Having a web site with pointers to all the latest working documents and other back-up material, which is stored on our FTP site. 2) To also store documents in PDF format, which can show mark-ups from previous versions (generated from WinWord) and contain line numbers for easier referencing. Carl-Uno Manros Co-chair IPP WG 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 From ipp-archive Mon Oct 27 14:31:53 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA12913 for ipp-outgoing; Mon, 27 Oct 1997 14:29:17 -0500 (EST) Message-Id: <3.0.1.32.19971027111422.009f0360@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 27 Oct 1997 11:14:22 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Subjects for discussion in Boulder Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Subjects for discussion in Boulder: My assumption is that the Model and Protocol documents are still not quite ready to initiate the WG last call from and that priority ONE is to make sure we get any remaining comments reviewed, so that we can get the "final" draft version of the documents out and start the last call some time next week. Other subjects, which we decided to leave out from Version 1.0 or other left overs are: 1) The Mapping document to LPD/LPR 2) Asynchronous Notifications 3) Document level attributes 4) Dictionary Syntax 5) IPP use of TLS (when that spec gets frozen) 6) IPP prototyping/interoperability testing We need to come up with a recommendation whether we still want to do some of these things before wrapping up the IETF WG at this stage. I am down with a cold today, but still expect to drag myself to the Boulder winter landscape tomorrow. Who came up with this schedule in the first place? Isn't Boulder a place to be visited in the summer (unless you are a skiing fan)? Regards, 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 From ipp-archive Mon Oct 27 15:16:53 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA13621 for ipp-outgoing; Mon, 27 Oct 1997 15:12:00 -0500 (EST) Message-Id: <199710272011.MAA14586@bulletin> To: Keith Moore cc: wg-chairs@apps.ietf.org, ipp@pwg.org, szilles@Adobe.COM Subject: IPP> Re: WG feedback: I-Ds in HTML, etc. In-reply-to: Your message of "Mon, 27 Oct 1997 02:09:29 EST." <199710270709.CAA24987@spot.cs.utk.edu> Date: Mon, 27 Oct 1997 12:11:23 PST From: "Steve Zilles" Sender: ipp-owner@pwg.org Precedence: bulk I very much applaud efforts to make the development of specification by working groups be a simpler and easier to use process. In that light, being able to use HTML would be a help. Carl-Uno Manros has already indicated that the IPP group has been using PDF because it allows development of the the standards text on a variety of platforms and allows distributing documents with change markings. Although, it is somewhat self serving, I did want to point out that HTML has some of the same problems that producing ASCII has. At least, tools that produce good HTML are more easily available. But, HTML is not really a final form format and it is primarily a text format. This means that HTML alone will not suffice for document publication. One must also pick a format for graphic and image data. One could use an image format such as PNG, but then printing of the document will look awful unless the PNG images are stored in high resolution (not currenty common for Web documents). Secondly, HTML prints poorly. Some browsers have been known to print half of one line on one page and the other half on the next page. There is currently little or no support for headers, footers and page sizes, although there are properties in HTML 4.0 and CSS 2.0 that will help here. One of the nice things about the ASCII format (for better or worse) was that the pages were already formatted and would reproduce the same way (give or take an extra half inch on the side or bottom of the 8.5x11 or A4 paper) everwhere. PDF is has been designed to capture final form output from most any generator of final form. It is a complete solution handling fonts, text, graphics and images within a single file. The presentation results are not dependent on where they are reproduced. I think that you should seriously consider adding PDF to the set of acceptable formats, either by itself or, as was done with PostScript, as a secondary format. PDF is used by a number of standards organizations as a way of distributing formatted documents and now has the kind of standing that PostScript had when it was authorized by IETF. Steve Zilles > From: Keith Moore > In a couple of weeks, IESG is having a face-to-face meeting. > One of the things we've agreed to discuss is the possibility of > allowing Internet-Draft submissions in HTML. > > I've done a lot of carping about WGs not doing things the > Traditional IETF Way (tm) -- like not having all working documents > published as plain ascii I-Ds, or not having ftp accessible > mail archives with the messages available in pure RFC 822 format. > > But since I know that various WGs have been experimenting with > ways of keeping track of issues and documents using the web > or other tools, I'd like to know of any techniques that you > have found especially useful -- things we might want to encourage > on a wider basis. > > And if there are needless encumberances in our mechanisms or > processes, we need to hear that also. (IESG cannot change the > process rules but it might be able to smooth out difficulties > with the I-D submission process, interactions with the RFC > Editor, or the IESG itself.) ----------------------------------------------------------------- Stephen N. Zilles | e-mail: szilles@adobe.com Adobe Systems Incorporated | Mailstop W14 | tel: (work) (408) 536-4766 345 Park Avenue | (Admin)(408) 536-4658 San Jose, CA 95110-2704 | fax: (408) 537-4042 ----------------------------------------------------------------- From ipp-archive Mon Oct 27 20:51:56 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA15409 for ipp-outgoing; Mon, 27 Oct 1997 20:47:28 -0500 (EST) Message-Id: <3.0.1.32.19971027175116.010d77f0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 27 Oct 1997 17:51:16 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD/PRO - ISSUE Do we need to represent "unknown" value or not? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Currently the Model document has copied some integer attributes from the Job Montoring MIB where a -2 value indicates that the Printer object does not (yet) know what the correct value is, i.e., the value is "unknown". The current Model document describes the -2 values as unknown, but the allowed range is constrained to 0:MAX: Alternatives: 1. Specify that the Printer object SHALL not return an attribute when the value is "unknown". 2. Add "unknown" as an out of band value in the Protocol. 3. Clarify that the current out of band value "no-value" may be used for when the Printer doesn't know the value. 4. Increase the range, so that -2 is a legal value, as in the Job Monitoring MIB. The attribute so effected are: 4.2.16 job-k-octets (integer(0:2**31 - 1)) This attribute specifies the total size of the document data in K octets, i.e., in units of 1024 octets requested to be processed in the job. The value SHALL be rounded up, so that a job between 1 and 1024 octets SHALL be indicated as being 1, 1025 to 2048 SHALL be 2, etc. This value SHALL not include the multiplicative factors contributed by the number of copies specified by the "copies" attribute, independent of whether the device can process multiple copies without making multiple passes over the document data and independent of whether the output is collated or not. Thus the value is independent of the implementation. Note: This attribute and the following two attributes ("job-impressions" and "job-media-sheets") are not intended to be counters; they are intended to be useful routing and scheduling information if known. For these three attributes, the Printer may try to compute the value if it is not supplied in the create request. Even if the client does supply a value for this attribute in the create request, the Printer may choose to change the value if the Printer is able to compute a value which is more accurate than the client supplied value. The Printer may be able to determine the correct value for this attribute either right at job submission time or at any later point in time. If the value of this attribute is unknown, the Printer may choose to respond with a value of '-2' (which signifies "unknown") rather than choose to not support the attribute at all. 4.2.17 job-impressions (integer(0:2**31 - 1)) This attribute specifies the total number of impressions of the document(s) being requested by this job to produce. This value SHALL not include the multiplicative factors contributed by the number of copies specified by the "copies" attribute, independent of whether the device can process multiple copies without making multiple passes over the document data and independent of whether the output is collated or not. Thus the value is independent of the implementation. 4.2.18 job-media-sheets (integer(0:2**31 - 1)) This attribute specifies the total number of media sheets to be processed for this job. Unlike the "job-k-octets" and the "job-impressions" attributes, this value SHALL include the multiplicative factors contributes by the number of copies specified by the "copies" attribute 4.3.16 job-k-octets-processed (integer(0:2**31 - 1)) This attribute specifies the number of octets processed in K octets, i.e., in units of 1024 octets. The value SHALL be rounded up, so that a job between 1 and 1024 octets SHALL be indicated as being 1, 1025 to 2048 SHALL be 2, etc. For implementations where multiple copies are produced by the interpreter with only a single pass over the data, the final value SHALL be equal to the value of the "job-k-octets" attribute. For implementations where multiple copies are produced by the interpreter by processing the data for each copy, the final value SHALL be a multiple of the value of the "job-k-octets" attribute. Note: This attribute and the following two attributes ("job-impressions-completed" and "job-sheets-completed") are intended to be counters. That is, if the "job-state" is 'processing' or 'processing-stopped', this value is intended to contain the amount of the job that has been processed to the time at which the attributes are requested. For any of these three attributes, the Printer may choose to return the value '-2' (which represents "unknown") rather than choose to not support the attribute at all. 4.3.17 job-impressions-completed (integer(0:2**31 - 1)) This job attribute specifies the number of impressions completed for the job so far. For printing devices, the impressions completed includes interpreting, marking, and stacking the output. This attribute is intended to be a counter as in the Job Monitoring MIB. For implementations where multiple copies are produced by the interpreter with only a single pass over the data, the final value SHALL be equal to the value of the "job-impressions" attribute. For implementations where multiple copies are produced by the interpreter by processing the data for each copy, the final value SHALL be a multiple of the value of the "job-impressions" attribute. 4.3.18 job-media-sheets-completed (integer(0:2**31 - 1)) This job attribute specifies the media-sheets completed marking and stacking for the entire job so far whether those sheets have been processed on one side or on both. This attribute is intended to be a counter as in the Job Monitoring MIB. From ipp-archive Tue Oct 28 09:47:04 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA17676 for ipp-outgoing; Tue, 28 Oct 1997 09:47:01 -0500 (EST) Message-Id: <199710281446.JAA25058@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ipp@pwg.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: IPP> I-D ACTION:draft-ietf-ipp-model-06.txt Date: Tue, 28 Oct 1997 09:46:35 -0500 Sender: ipp-owner@pwg.org Precedence: bulk --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.0: Model and Semantics Author(s) : P. Powell, T. Hasting, R. Herriot, S. Isaacson, R. deBry Filename : draft-ietf-ipp-model-06.txt Pages : 128 Date : 27-Oct-97 This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technology. The protocol is heavily influenced by the printing model introduced in the Document Printing Application (DPA) [ISO10175] standard. Although DPA specifies both end user and administrative features, IPP version 1.0 is focused only on end user functionality. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipp-model-06.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-model-06.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipp-model-06.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19971027152812.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-model-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-model-06.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971027152812.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-archive Tue Oct 28 16:57:08 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA19708 for ipp-outgoing; Tue, 28 Oct 1997 16:55:03 -0500 (EST) Date: Tue, 28 Oct 1997 13:54:39 -0800 From: Robert.Herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199710282154.NAA21726@woden.eng.sun.com> To: ipp@pwg.org, hastings@cp10.es.xerox.com Subject: Re: IPP> MOD/PRO - ISSUE Do we need to represent "unknown" value or not? X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Though the issue you raise for unknown values could arise for any type, not just integers. > From hastings@cp10.es.xerox.com Mon Oct 27 18:00:42 1997 > > Currently the Model document has copied some integer attributes from the Job > Montoring MIB where a -2 value indicates that the Printer object does not > (yet) know what the correct value is, i.e., the value is "unknown". > > The current Model document describes the -2 values as unknown, but the > allowed range is constrained to 0:MAX: > > Alternatives: > > 1. Specify that the Printer object SHALL not return an attribute when > the value is "unknown". > > 2. Add "unknown" as an out of band value in the Protocol. > > 3. Clarify that the current out of band value "no-value" may be used > for when the Printer doesn't know the value. > > 4. Increase the range, so that -2 is a legal value, as in the Job Monitoring > MIB. > > > > The attribute so effected are: > > 4.2.16 job-k-octets (integer(0:2**31 - 1)) > > This attribute specifies the total size of the document data in K octets, > i.e., in units of 1024 octets requested to be processed in the job. The > value SHALL be rounded up, so that a job between 1 and 1024 octets SHALL be > indicated as being 1, 1025 to 2048 SHALL be 2, etc. > > This value SHALL not include the multiplicative factors contributed by the > number of copies specified by the "copies" attribute, independent of > whether the device can process multiple copies without making multiple > passes over the document data and independent of whether the output is > collated or not. Thus the value is independent of the implementation. > > Note: This attribute and the following two attributes ("job-impressions" > and "job-media-sheets") are not intended to be counters; they are intended > to be useful routing and scheduling information if known. For these three > attributes, the Printer may try to compute the value if it is not supplied > in the create request. Even if the client does supply a value for this > attribute in the create request, the Printer may choose to change the value > if the Printer is able to compute a value which is more accurate than the > client supplied value. The Printer may be able to determine the correct > value for this attribute either right at job submission time or at any > later point in time. If the value of this attribute is unknown, the > Printer may choose to respond with a value of '-2' (which signifies > "unknown") rather than choose to not support the attribute at all. > > 4.2.17 job-impressions (integer(0:2**31 - 1)) > > This attribute specifies the total number of impressions of the document(s) > being requested by this job to produce. > > This value SHALL not include the multiplicative factors contributed by the > number of copies specified by the "copies" attribute, independent of > whether the device can process multiple copies without making multiple > passes over the document data and independent of whether the output is > collated or not. Thus the value is independent of the implementation. > > 4.2.18 job-media-sheets (integer(0:2**31 - 1)) > > This attribute specifies the total number of media sheets to be processed > for this job. > > Unlike the "job-k-octets" and the "job-impressions" attributes, this value > SHALL include the multiplicative factors contributes by the number of > copies specified by the "copies" attribute > > 4.3.16 job-k-octets-processed (integer(0:2**31 - 1)) > > This attribute specifies the number of octets processed in K octets, i.e., > in units of 1024 octets. The value SHALL be rounded up, so that a job > between 1 and 1024 octets SHALL be indicated as being 1, 1025 to 2048 SHALL > be 2, etc. > For implementations where multiple copies are produced by the interpreter > with only a single pass over the data, the final value SHALL be equal to > the value of the "job-k-octets" attribute. For implementations where > multiple copies are produced by the interpreter by processing the data for > each copy, the final value SHALL be a multiple of the value of the > "job-k-octets" attribute. > > Note: This attribute and the following two attributes > ("job-impressions-completed" and "job-sheets-completed") are intended to be > counters. That is, if the "job-state" is 'processing' or > 'processing-stopped', this value is intended to contain the amount of the > job that has been processed to the time at which the attributes are > requested. For any of these three attributes, the Printer may choose to > return the value '-2' (which represents "unknown") rather than choose to > not support the attribute at all. > > 4.3.17 job-impressions-completed (integer(0:2**31 - 1)) > > This job attribute specifies the number of impressions completed for the > job so far. For printing devices, the impressions completed includes > interpreting, marking, and stacking the output. This attribute is intended > to be a counter as in the Job Monitoring MIB. > > For implementations where multiple copies are produced by the interpreter > with only a single pass over the data, the final value SHALL be equal to > the value of the "job-impressions" attribute. For implementations where > multiple copies are produced by the interpreter by processing the data for > each copy, the final value SHALL be a multiple of the value of the > "job-impressions" attribute. > > 4.3.18 job-media-sheets-completed (integer(0:2**31 - 1)) > > This job attribute specifies the media-sheets completed marking and > stacking for the entire job so far whether those sheets have been processed > on one side or on both. This attribute is intended to be a counter as in > the Job Monitoring MIB. > > > From ipp-archive Tue Oct 28 19:17:10 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA20623 for ipp-outgoing; Tue, 28 Oct 1997 19:16:26 -0500 (EST) Message-Id: <3.0.1.32.19971028151544.01028a00@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 28 Oct 1997 15:15:44 PST To: szilles@Adobe.COM (Stephen Zilles), ipp@pwg.org From: Tom Hastings Subject: Re: IPP> Revision of section 4.2.6 multiple-document-handling Cc: szilles@Adobe.COM In-Reply-To: <199710240413.VAA20554@bulletin> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Instead of introducing the new term "imposed page", how about using the term "impression", which we have an attribute that counts them. We ought to defined "impression" though in place of "imposed page" in section 12.2.5. Tom At 21:13 10/23/1997 PDT, Stephen Zilles wrote: >[The terminology in this section seems to muddle "document" meaning >document data and "document" meaning what has finishing operations >applied to it. For this reason the entire section has been redone.] > >The current text is: > > 4.2.6 multiple-document-handling (type2 keyword) > > This job attribute is relevant only if a job consists of two > or more documents. It controls finishing operations, and job- > sheet placement. When the copies attribute exceeds 1, it > also controls the order of documents. > > Standard values are: > > 'single-document': If the files for the job are a and > b, then files a and b SHALL be treated as a single > document for finishing operations. The Printer > SHALL NOT force each document to start on a new > page or new media sheet. If more than one copy is > made, the ordering SHALL be a, b, a, b,...., and > the Printer SHALL force each copy to start on a > new sheet. > 'separate-documents-uncollated-copies': If the files > for the job are a and b, then each file SHALL be > treated as a single document for finishing > operations. The Printer shall force each document > copy to start on a new sheet. If more than one > copy is made, the ordering SHALL be a, a, b, b, > .... > 'separate-documents-collated-copies': If the files for > the job are a and b, then each file SHALL be > treated as a single document for finishing > operations. The Printer SHALL NOT force each > document copy to start on a new sheet. If more > than one copy is made, the ordering SHALL be a, > b, a, b, ...., and the Printer shall force each > document copy to start on a new sheet . > > >[Note the use of "files" instead of "document data" which is used in the >operation descriptions in 3.2 and 3.3; the mis-use of "document" noted >above and the confusion of pages and media sheets. Nothing is said in >these descriptions about the placement of job-sheets. Finally, I do not >understand the final case at all; it says "each file SHALL be treated as >a single document for finishing operations. The Printer SHALL NOT force >each document copy to start on a new sheet. There is no way if parts of >two files are place on opposite sides of the same sheet (because of the >SHALL NOT) that they will be finished separately. I am also not really >sure which use of "document" is being used in the SHALL NOT clause. > > This suggests the following revision of the section. Note that I had to >introduce a somewhat awkward term, "set of media sheets" for the second >(mis-) use of "document" above.] > > > 4.2.6 multiple-document-handling (type2 keyword) > > This job attribute is relevant only if a job consists of two or more > documents. The attribute controls finishing operations and the placement > of print-stream pages into imposed pages and onto media sheets. When > the value of the "copies" attribute exceeds 1, it also controls the > order in which the copies that result from processing the documents are > produced. For the purposes of this explanations, if "a" represents an > instance of document data, then the result of processing the data in > document "a" is a sequence of media sheets represented by "a'". > > Standard values are: > > 'single-document': If a Job object has multiple documents, say the > document data is called a and b, then the result of processing > all the document data (a and then b) SHALL be treated as a > single sequence of media sheets for finishing operations; that is, > finishing would be performed on the concatenation of the > seqeunces a',b'. The Printer SHALL NOT force the data in each > document instance to be formatted onto a new print-stream > page, nor to start a new imposed page or a new media sheet. If > more than one copy is made, the ordering of the sets of media > sheets resulting from processing the document data SHALL be > a', b', a', b',...., and the Printer SHALL force each copy to > start on a new media sheet. > 'separate-documents-uncollated-copies': If a Job object has > multiple documents, say the document data is called a and b, > then the result of processing the data in each document > instance SHALL be treated as a single sequence of media sheets for > finishing operations; that is, the sets a' and b' would each > be finished separately. The Printer SHALL force each copy of the > result of process the data in a single document to start on a > new media sheet. If more than one copy is made, the ordering > of the sets of media sheets resulting from processing the > document data SHALL be a', a', b', b' .... > 'separate-documents-collated-copies': If a Job object has multiple > documents, say the document data is called a and b, then the > result of processing the data in each document instance SHALL > be treated as a single sequence of media sheets for finishing > operations; that is, the sets a' and b' would each be finished > separately. If more than one copy is made, the ordering of the > sets of media sheets resulting from processing the document > data SHALL be a', b', a', b', ...., and the Printer SHALL > force each document copy to start on a new sheet . > > >[Note that in the last case, the internal conflict in the description >noted above was resolved by removing the apparently un-intented SHALL >NOT clause. With this change, the last case becomes the same as the >first case with respect to ordering and media sheet generation, but >different with respect to finishing.] > >[Note also the this text does not say anything about the placement of >job-sheets because the prior text also did not say anything >about the placement of job-sheets.] > > From ipp-archive Tue Oct 28 19:22:10 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA20641 for ipp-outgoing; Tue, 28 Oct 1997 19:18:06 -0500 (EST) Message-Id: <3.0.1.32.19971028150732.00f6bc20@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 28 Oct 1997 15:07:32 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - ISSUE: Should there be a "printer-tls-uri" Printer attribute or not? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Section 8.5 last paragraph mentions the "printer-tls-uri", but the Model doesn't have such a Printer attribute. The directory section does have both the "printer-tls-uri" and the "printer-uri". A printer can have non-secure, secure, or both, I believe. We could eliminate the both case and say that the way to have both a secure and a non-secure Printer object is to require that there be two Printer objects. With fan-in, both Printer objects can be driving the same physical output device. Then we could get rid of the "printer-tls-uri" attribute from the directory section and the 8.5 security section in the Model document. Or we could add the "printer-tls-uri" attribute to the Printer object. What happens for the printer that is only secure? From ipp-archive Tue Oct 28 19:54:03 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA21697 for ipp-outgoing; Tue, 28 Oct 1997 19:45:07 -0500 (EST) Message-ID: <345686AD.53F5267F@underscore.com> Date: Tue, 28 Oct 1997 19:43:25 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.02 [en] (Win95; I) MIME-Version: 1.0 To: Tom Hastings CC: Stephen Zilles , ipp@pwg.org Subject: Re: IPP> Revision of section 4.2.6 multiple-document-handling References: <3.0.1.32.19971028151544.01028a00@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Good point, Tom. No need to define new terms. ...jay Tom Hastings wrote: > > Instead of introducing the new term "imposed page", how about > using the term "impression", which we have an attribute that counts > them. We ought to defined "impression" though in place of "imposed page" > in section 12.2.5. > > Tom > > At 21:13 10/23/1997 PDT, Stephen Zilles wrote: > >[The terminology in this section seems to muddle "document" meaning > >document data and "document" meaning what has finishing operations > >applied to it. For this reason the entire section has been redone.] > > > >The current text is: > > > > 4.2.6 multiple-document-handling (type2 keyword) > > > > This job attribute is relevant only if a job consists of two > > or more documents. It controls finishing operations, and job- > > sheet placement. When the copies attribute exceeds 1, it > > also controls the order of documents. > > > > Standard values are: > > > > 'single-document': If the files for the job are a and > > b, then files a and b SHALL be treated as a single > > document for finishing operations. The Printer > > SHALL NOT force each document to start on a new > > page or new media sheet. If more than one copy is > > made, the ordering SHALL be a, b, a, b,...., and > > the Printer SHALL force each copy to start on a > > new sheet. > > 'separate-documents-uncollated-copies': If the files > > for the job are a and b, then each file SHALL be > > treated as a single document for finishing > > operations. The Printer shall force each document > > copy to start on a new sheet. If more than one > > copy is made, the ordering SHALL be a, a, b, b, > > .... > > 'separate-documents-collated-copies': If the files for > > the job are a and b, then each file SHALL be > > treated as a single document for finishing > > operations. The Printer SHALL NOT force each > > document copy to start on a new sheet. If more > > than one copy is made, the ordering SHALL be a, > > b, a, b, ...., and the Printer shall force each > > document copy to start on a new sheet . > > > > > >[Note the use of "files" instead of "document data" which is used in the > >operation descriptions in 3.2 and 3.3; the mis-use of "document" noted > >above and the confusion of pages and media sheets. Nothing is said in > >these descriptions about the placement of job-sheets. Finally, I do not > >understand the final case at all; it says "each file SHALL be treated as > >a single document for finishing operations. The Printer SHALL NOT force > >each document copy to start on a new sheet. There is no way if parts of > >two files are place on opposite sides of the same sheet (because of the > >SHALL NOT) that they will be finished separately. I am also not really > >sure which use of "document" is being used in the SHALL NOT clause. > > > > This suggests the following revision of the section. Note that I had to > >introduce a somewhat awkward term, "set of media sheets" for the second > >(mis-) use of "document" above.] > > > > > > 4.2.6 multiple-document-handling (type2 keyword) > > > > This job attribute is relevant only if a job consists of two or more > > documents. The attribute controls finishing operations and the placement > > of print-stream pages into imposed pages and onto media sheets. When > > the value of the "copies" attribute exceeds 1, it also controls the > > order in which the copies that result from processing the documents are > > produced. For the purposes of this explanations, if "a" represents an > > instance of document data, then the result of processing the data in > > document "a" is a sequence of media sheets represented by "a'". > > > > Standard values are: > > > > 'single-document': If a Job object has multiple documents, say the > > document data is called a and b, then the result of processing > > all the document data (a and then b) SHALL be treated as a > > single sequence of media sheets for finishing operations; that is, > > finishing would be performed on the concatenation of the > > seqeunces a',b'. The Printer SHALL NOT force the data in each > > document instance to be formatted onto a new print-stream > > page, nor to start a new imposed page or a new media sheet. If > > more than one copy is made, the ordering of the sets of media > > sheets resulting from processing the document data SHALL be > > a', b', a', b',...., and the Printer SHALL force each copy to > > start on a new media sheet. > > 'separate-documents-uncollated-copies': If a Job object has > > multiple documents, say the document data is called a and b, > > then the result of processing the data in each document > > instance SHALL be treated as a single sequence of media sheets for > > finishing operations; that is, the sets a' and b' would each > > be finished separately. The Printer SHALL force each copy of the > > result of process the data in a single document to start on a > > new media sheet. If more than one copy is made, the ordering > > of the sets of media sheets resulting from processing the > > document data SHALL be a', a', b', b' .... > > 'separate-documents-collated-copies': If a Job object has multiple > > documents, say the document data is called a and b, then the > > result of processing the data in each document instance SHALL > > be treated as a single sequence of media sheets for finishing > > operations; that is, the sets a' and b' would each be finished > > separately. If more than one copy is made, the ordering of the > > sets of media sheets resulting from processing the document > > data SHALL be a', b', a', b', ...., and the Printer SHALL > > force each document copy to start on a new sheet . > > > > > >[Note that in the last case, the internal conflict in the description > >noted above was resolved by removing the apparently un-intented SHALL > >NOT clause. With this change, the last case becomes the same as the > >first case with respect to ordering and media sheet generation, but > >different with respect to finishing.] > > > >[Note also the this text does not say anything about the placement of > >job-sheets because the prior text also did not say anything > >about the placement of job-sheets.] > > > > From ipp-archive Tue Oct 28 21:27:12 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA23330 for ipp-outgoing; Tue, 28 Oct 1997 21:24:51 -0500 (EST) From: Harry Lewis To: , Subject: IPP> Wednesday/Thursday agenda Message-ID: <5030300013169434000002L042*@MHS> Date: Tue, 28 Oct 1997 21:29:59 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk There has been some confusion regarding the IPP/PMP/SENSE agenda. Here = is what we currently have planned... Wednesday 8:30-9:00 - PMP Update (Lloyd Young) 9:00-6pm IPP Thursday 8:30 - noon IPP 1-6pm SENSE Firday is JMP and FIN, as previously indicated Harry Lewis - IBM Printing Systems = From ipp-archive Tue Oct 28 21:37:13 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA23566 for ipp-outgoing; Tue, 28 Oct 1997 21:32:14 -0500 (EST) Message-Id: <3.0.1.32.19971028145913.01046c50@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 28 Oct 1997 14:59:13 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD/PRO - ISSUE: Model and Protocol disagree on naturalLanguage override/exception Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk The Model document describes the override of the natural language for a single 'text' or 'name' attribute as just inserting an extra 'naturalLanguage' value in front of the 'text' or 'name' attribute value which qualified the next value only. The Protocol document uses a more general mechanism that includes a new "out-of-band" tag called a 'compoundValue' whose values indicates the number of following values that are to be treated as a single value. For the natural language override, the compoundValue would always have the value 2, so that only the next 'text' or 'name' value is combined with the naturalLanguage value. We need to pick one method or the other. The first method would require removing the 'compoundValue' from the Protocol. The second method would require changing the description of the 'text' attribute syntax to use the term "natural language override" (which I think is a better term), instead of "natural language exception", and to remove the example which shows just the two values. Tom From ipp-archive Wed Oct 29 10:02:18 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA26891 for ipp-outgoing; Wed, 29 Oct 1997 09:59:03 -0500 (EST) Message-Id: <199710291458.JAA17355@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ipp@pwg.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: IPP> I-D ACTION:draft-ietf-ipp-protocol-01.txt Date: Wed, 29 Oct 1997 09:57:57 -0500 Sender: ipp-owner@pwg.org Precedence: bulk --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.0: Protocol Specification Author(s) : R. Turner, R. Herriot, S. Butler, P. Moore Filename : draft-ietf-ipp-protocol-01.txt Pages : 26 Date : 28-Oct-97 This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technology. The protocol is heavily influenced by the printing model introduced in the Document Printing Application (ISO/IEC 10175 DPA) standard. Although DPA specifies both end user and administrative features, IPP version 1.0 is focused only on end user functionality. The full set of IPP documents includes: Internet Printing Protocol: Requirements Internet Printing Protocol/1.0: Model and Semantics Internet Printing Protocol/1.0: Security Internet Printing Protocol/1.0: Protocol Specification Internet Printing Protocol/1.0: Directory Schema The requirements document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. The requirements document calls out a subset of end user requirements that MUST be satisfied in the first version of IPP. Operator and administrator requirements are out of scope for v1.0. The model and semantics document describes a simplified model with abstract objects, their attributes, and their operations. The model introduces a Printer object and a Job object. The Job object supports multiple documents per job. The security document covers potential threats and proposed counters to those threats. The protocol specification is formal document which incorporates the ideas in all the other documents into a concrete mapping using clearly defined data representations and transport protocol mappings that real implementers can use to develop interoperable client and server side components. Finally, the directory schema document shows a generic schema for directory service entries that represent instances of IPP Printers. This document is the ''Internet Printing Protocol/1.0: Protocol Specification'' document. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipp-protocol-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-protocol-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipp-protocol-01.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19971028142417.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-protocol-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-protocol-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971028142417.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-archive Wed Oct 29 10:42:18 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA27564 for ipp-outgoing; Wed, 29 Oct 1997 10:40:30 -0500 (EST) Mime-Version: 1.0 Date: Wed, 29 Oct 1997 10:40:05 -0500 Message-ID: <0002A713.3036@okidata.com> From: pthambid@okidata.com (Philip Thambidurai) To: ipp@pwg.org Subject: IPP> New protocol document? Content-Type: multipart/mixed; boundary="IMA.Boundary.004041878" Sender: ipp-owner@pwg.org Precedence: bulk --IMA.Boundary.004041878 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part The new protocol document referred to by the recent posting (shown below) has the same date as the earlier protocol I-D (July 30). ______________________________ Forward Header __________________________________ Subject: IPP> I-D ACTION:draft-ietf-ipp-protocol-01.txt Author: Internet-Drafts@ietf.org at INTERNET Date: 10/29/97 9:57 AM 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.0: Protocol Specification Author(s) : R. Turner, R. Herriot, S. Butler, P. Moore Filename : draft-ietf-ipp-protocol-01.txt Pages : 26 Date : 28-Oct-97 This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technology. The protocol is heavily influenced by the printing model introduced in the Document Printing Application (ISO/IEC 10175 DPA) standard. Although DPA specifies both end user and administrative features, IPP version 1.0 is focused only on end user functionality. The full set of IPP documents includes: Internet Printing Protocol: Requirements Internet Printing Protocol/1.0: Model and Semantics Internet Printing Protocol/1.0: Security Internet Printing Protocol/1.0: Protocol Specification Internet Printing Protocol/1.0: Directory Schema The requirements document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. The requirements document calls out a subset of end user requirements that MUST be satisfied in the first version of IPP. Operator and administrator requirements are out of scope for v1.0. The model and semantics document describes a simplified model with abstract objects, their attributes, and their operations. The model introduces a Printer object and a Job object. The Job object supports multiple documents per job. The security document covers potential threats and proposed counters to those threats. The protocol specification is formal document which incorporates the ideas in all the other documents into a concrete mapping using clearly defined data representations and transport protocol mappings that real implementers can use to develop interoperable client and server side components. Finally, the directory schema document shows a generic schema for directory service entries that represent instances of IPP Printers. This document is the ''Internet Printing Protocol/1.0: Protocol Specification'' document. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipp-protocol-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-protocol-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipp-protocol-01.txt". NOTE: The mail server at ds.internic.net 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. --IMA.Boundary.004041878 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Content-Type: text/plain Content-ID: <19971028142417.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-protocol-01.txt --IMA.Boundary.004041878 Content-Type: text/plain; charset=US-ASCII; name="draft-ietf-ipp-protocol-01.txt" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Content-Disposition: inline; filename="draft-ietf-ipp-protocol-01.txt" Content-Type: text/plain Content-ID: <19971028142417.I-D@ietf.org> --IMA.Boundary.004041878-- From ipp-archive Thu Oct 30 00:07:26 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA29231 for ipp-outgoing; Thu, 30 Oct 1997 00:05:43 -0500 (EST) Message-Id: <3.0.1.32.19971029210918.00fecaa0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 29 Oct 1997 21:09:18 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - I-D ACTION:draft-ietf-ipp-protocol-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk NOTE: The file name is 01, not 02. This maybe because we didn't forward the 01 protocol document to the secretariate? The 02 file name appears on the Protocol document that Bob posted. So it looks like the secretariate updates the number by 1 each time, no matter what we say. To reduce confusion we should rename the 02 version to have a 1 plus additional words on our FTP server, like draft-ietf-ipp-protocol-01-published-i-d.txt. Then the next version can have 02 on it (again). Tom >Return-Path: >To: IETF-Announce@ietf.org >Cc: ipp@pwg.org >From: Internet-Drafts@ietf.org >Reply-To: Internet-Drafts@ietf.org >Subject: IPP> I-D ACTION:draft-ietf-ipp-protocol-01.txt >Date: Wed, 29 Oct 1997 06:57:57 PST >Sender: ipp-owner@pwg.org > >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.0: Protocol > Specification > Author(s) : R. Turner, R. Herriot, S. Butler, P. Moore > Filename : draft-ietf-ipp-protocol-01.txt > Pages : 26 > Date : 28-Oct-97 > >This document is one of a set of documents, which together describe all >aspects of a new Internet Printing Protocol (IPP). IPP is an >application level protocol that can be used for distributed printing >using Internet tools and technology. The protocol is heavily influenced >by the printing model introduced in the Document Printing Application >(ISO/IEC 10175 DPA) standard. Although DPA specifies both end user and >administrative features, IPP version 1.0 is focused only on end user >functionality. > >The full set of IPP documents includes: > > Internet Printing Protocol: Requirements > Internet Printing Protocol/1.0: Model and Semantics > Internet Printing Protocol/1.0: Security > Internet Printing Protocol/1.0: Protocol Specification > Internet Printing Protocol/1.0: Directory Schema > >The requirements document takes a broad look at distributed printing >functionality, and it enumerates real-life scenarios that help to >clarify the features that need to be included in a printing protocol for >the Internet. It identifies requirements for three types of users: end users, operators, and administrators. The requirements document calls >out a subset of end user requirements that MUST be satisfied in the >first version of IPP. Operator and administrator requirements are out >of scope for v1.0. The model and semantics document describes a >simplified model with abstract objects, their attributes, and their >operations. The model introduces a Printer object and a Job object. The >Job object supports multiple documents per job. The security document >covers potential threats and proposed counters to those threats. The >protocol specification is formal document which incorporates the ideas >in all the other documents into a concrete mapping using clearly defined >data representations and transport protocol mappings that real >implementers can use to develop interoperable client and server side >components. Finally, the directory schema document shows a generic >schema for directory service entries that represent instances of IPP >Printers. > >This document is the ''Internet Printing Protocol/1.0: Protocol >Specification'' document. > > >Internet-Drafts are available by anonymous FTP. Login wih the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-ipp-protocol-01.txt". >A URL for the Internet-Draft is: >ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-protocol-01.txt > >Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nis.garr.it > > Pacific Rim: munnari.oz.au > > US East Coast: ds.internic.net > > US West Coast: ftp.isi.edu > >Internet-Drafts are also available by mail. > >Send a message to: mailserv@ds.internic.net. In the body type: > "FILE /internet-drafts/draft-ietf-ipp-protocol-01.txt". > >NOTE: The mail server at ds.internic.net 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. > > > From ipp-archive Thu Oct 30 00:22:32 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA29517 for ipp-outgoing; Thu, 30 Oct 1997 00:18:45 -0500 (EST) Message-Id: <3.0.1.32.19971029212232.00fecaa0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 29 Oct 1997 21:22:32 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - I-D ACTION:draft-ietf-ipp-protocol-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk I should have pulled the document from the IETF FTP server before sending the following message. The 01 file is from last July 30. I guess we haven't forwarded a new Protocol document since then. So 02 is the correct file name. But for some reason the 02 file is NOT on the IETF FTP servers. So disregard my suggestion about the file name. We need to query the IETF secretariat about this. Tom >Date: Wed, 29 Oct 1997 21:09:18 -0800 >To: ipp@pwg.org >From: Tom Hastings >Subject: IPP> MOD - I-D ACTION:draft-ietf-ipp-protocol-01.txt > >NOTE: The file name is 01, not 02. This maybe because we didn't forward >the 01 protocol document to the secretariate? The 02 file name appears >on the Protocol document that Bob posted. So it looks like the secretariate >updates the number by 1 each time, no matter what we say. > >To reduce confusion we should rename the 02 version to have a 1 plus additional >words on our FTP server, like draft-ietf-ipp-protocol-01-published-i-d.txt. Then the next version can have 02 on it (again). > >Tom > >>Return-Path: >>To: IETF-Announce@ietf.org >>Cc: ipp@pwg.org >>From: Internet-Drafts@ietf.org >>Reply-To: Internet-Drafts@ietf.org >>Subject: IPP> I-D ACTION:draft-ietf-ipp-protocol-01.txt >>Date: Wed, 29 Oct 1997 06:57:57 PST >>Sender: ipp-owner@pwg.org >> >>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.0: Protocol >> Specification >> Author(s) : R. Turner, R. Herriot, S. Butler, P. Moore >> Filename : draft-ietf-ipp-protocol-01.txt >> Pages : 26 >> Date : 28-Oct-97 >> >>This document is one of a set of documents, which together describe all >>aspects of a new Internet Printing Protocol (IPP). IPP is an >>application level protocol that can be used for distributed printing >>using Internet tools and technology. The protocol is heavily influenced >>by the printing model introduced in the Document Printing Application >>(ISO/IEC 10175 DPA) standard. Although DPA specifies both end user and >>administrative features, IPP version 1.0 is focused only on end user >>functionality. >> >>The full set of IPP documents includes: >> >> Internet Printing Protocol: Requirements >> Internet Printing Protocol/1.0: Model and Semantics >> Internet Printing Protocol/1.0: Security >> Internet Printing Protocol/1.0: Protocol Specification >> Internet Printing Protocol/1.0: Directory Schema >> >>The requirements document takes a broad look at distributed printing >>functionality, and it enumerates real-life scenarios that help to >>clarify the features that need to be included in a printing protocol for >>the Internet. It identifies requirements for three types of users: end users, operators, and administrators. The requirements document calls >>out a subset of end user requirements that MUST be satisfied in the >>first version of IPP. Operator and administrator requirements are out >>of scope for v1.0. The model and semantics document describes a >>simplified model with abstract objects, their attributes, and their >>operations. The model introduces a Printer object and a Job object. The >>Job object supports multiple documents per job. The security document >>covers potential threats and proposed counters to those threats. The >>protocol specification is formal document which incorporates the ideas >>in all the other documents into a concrete mapping using clearly defined >>data representations and transport protocol mappings that real >>implementers can use to develop interoperable client and server side >>components. Finally, the directory schema document shows a generic >>schema for directory service entries that represent instances of IPP >>Printers. >> >>This document is the ''Internet Printing Protocol/1.0: Protocol >>Specification'' document. >> >> >>Internet-Drafts are available by anonymous FTP. Login wih the username >>"anonymous" and a password of your e-mail address. After logging in, >>type "cd internet-drafts" and then >> "get draft-ietf-ipp-protocol-01.txt". >>A URL for the Internet-Draft is: >>ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-protocol-01.txt >> >>Internet-Drafts directories are located at: >> >> Africa: ftp.is.co.za >> >> Europe: ftp.nordu.net >> ftp.nis.garr.it >> >> Pacific Rim: munnari.oz.au >> >> US East Coast: ds.internic.net >> >> US West Coast: ftp.isi.edu >> >>Internet-Drafts are also available by mail. >> >>Send a message to: mailserv@ds.internic.net. In the body type: >> "FILE /internet-drafts/draft-ietf-ipp-protocol-01.txt". >> >>NOTE: The mail server at ds.internic.net 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. >> >> >> From ipp-archive Thu Oct 30 00:37:30 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA00486 for ipp-outgoing; Thu, 30 Oct 1997 00:36:54 -0500 (EST) Message-ID: <34581BE0.EF94D173@sharplabs.com> Date: Wed, 29 Oct 1997 21:32:16 -0800 From: Randy Turner Organization: Sharp Labs of America X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: IPP> FYI...on SSL Content-Type: multipart/mixed; boundary="------------7215BB89CEC7B735D3F379A5" Sender: ipp-owner@pwg.org Precedence: bulk This is a multi-part message in MIME format. --------------7215BB89CEC7B735D3F379A5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I thought some of you might want to know how SSL will be tunneled through firewalls for IPP.... Randy --------------7215BB89CEC7B735D3F379A5 Content-Type: text/html; charset=us-ascii; name="tunneling_ssl.html" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="tunneling_ssl.html" Content-Base: "file:///C|/WINDOWS/DESKTOP/tunneling_s sl.html" Tunneling SSL Through a WWW Proxy
INTERNET-DRAFT
Expires: June 14, 1996
<draft-luotonen-ssl-tunneling-02.txt>
        Ari Luotonen
Netscape Communications Corporation
December 14, 1995

Tunneling SSL Through a WWW Proxy

Status of this Memo

This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.''

To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).

Table of Contents

  • Overview
  • General Considerations
  • The CONNECT Method
  • Proxy Response
  • Security Considerations
  • Extensibility
Overview

The wide success of SSL (Secure Sockets Layer from Netscape Communications Corporation) has made it vital that the current WWW proxy protocol be extended to allow an SSL client to open a secure tunnel through the proxy.

The HTTPS protocol, which is just HTTP on top of SSL, can be proxied in the same way that currently other protocols are handled by the proxies: to have the proxy initiate a secure session with the remote HTTPS server, and then perform the HTTPS transaction. This is the way

Luotonen [Page 1]


SSL TUNNELING INTERNET-DRAFT December 1995

FTP and Gopher get handled by proxies, too. However, this approach has two disadvantages:

  • The connection between the client and the proxy is normal HTTP, and hence, not secure. This is, however, often acceptable if the clients are in a trusted subnet (behind a firewall).
  • The proxy will need to have full SSL implementation incorporated into it.
This document describes a way to do SSL tunneling without an implementation of SSL, in a way that is compatible with the current WWW proxy protocol (as defined by the HTTP/1.0 specification). The existing implementation of SSL tunneling in the Netscape Navigator and the Netscape Proxy Server conform to this specification. A patch implementing this feature also exists for the CERN proxy server (CERN httpd).

General Considerations

When tunneling SSL, the proxy must not have access to the data being transferred in either direction, for sake of security. The proxy merely knows the source and destination addresses, and possibly, if the proxy supports user authentication, the name of the requesting user.

In other words, there is a handshake between the client and the proxy to establish the connection between the client and the remote server through the proxy. In order to make this extension be backwords compatible, the handshake must be in the same format as HTTP/1.0 requests, so that proxies without support for this feature can still cleanly determine the request as impossible for them to service, and give proper error responses (rather than e.g. get hung on the connection).

SSL tunneling isn't really SSL specific -- it's a general way to have a third party establish a connection between two points, after which bytes are simply copied back and forth by this intermediary.

When SSL tunneling support is put into the SSL source code, it will work for any SSL enhanced application.

The CONNECT Method

The client connects to the proxy, and uses the CONNECT method to specify the hostname and the port number to connect to. The hostname

Luotonen [Page 2]


SSL TUNNELING INTERNET-DRAFT December 1995

and port number are separated by a colon, and both of them must be specified.

The host:port part is followed by a space and a string specifying the HTTP version number, e.g. HTTP/1.0, and the line terminator (CR LF pair, or a single LF).

After that there is a series of zero or more of HTTP request header lines, followed by an empty line. Each of those header lines is also terminated by the CR LF pair, or a single LF. The empty line is simply another CR LF pair, or another LF.

After the empty line, if the handshake to establish the connection was successful, SSL data transfer can begin.

Example:

CONNECT home.netscape.com:443 HTTP/1.0
User-agent: Mozilla/1.1N
The advantage of this approach is that this protocol is freely extensible; for example, the proxy authentication can be used.

Example:

CONNECT home.netscape.com:443 HTTP/1.0
User-agent: Mozilla/1.1N
Proxy-authorization: basic aGVsbG86d29ybGQ=
Proxy Response

After the empty line in the request, the client will wait for a response from the proxy. The proxy will evaluate the request, make sure that it is valid, and that the user is authorized to request such a connection. If everything is in order, the proxy will make a connection to the destination server, and, if successful, send a "200 Connection established" response to the client. Again, the response follows the HTTP/1.0 protocol, so the response line starts with the protocol version specifier, and the response line is followed by zero or more response headers, followed by an empty line. The line separator is CR LF pair, or a single LF.

Example:

HTTP/1.0 200 Connection established
Proxy-agent: Netscape-Proxy/1.1

Luotonen [Page 3]


SSL TUNNELING INTERNET-DRAFT December 1995

After the empty line, the proxy will start passing data from the client connection to the remote server connection, and vice versa. At any time, there may be data coming from either connection, and that data should be forwarded to the other connection immediately.

If at any point either one of the peers gets disconnected, any outstanding data that came from that peer will be passed to the other one, and after that also the other connection will be terminated by the proxy. If there is outstanding data to that peer undelivered, that data will be discarded.

Security Considerations

CONNECT is really a lower-level function than the rest of the HTTP methods, kind of an escape mechanism for saying that the proxy should not interfere with the transaction, but merely forward the data. This is because the proxy should not need to know the entire URI that is being accessed (privacy, security), only the information that it explicitly needs (hostname and port number). Due to this fact, the proxy cannot verify that the protocol being spoken is really SSL, and so the proxy configuration should explicitly limit allowed connections to well-known SSL ports (such as 443 for HTTPS, 563 for SNEWS, as assigned by the Internet Assigned Numbers Authority).

Extensibility

The SSL tunneling handshake is freely extensible using the HTTP/1.0 headers; as an example, to enforce authentication for the proxy the proxy will simply use the 407 status code and the Proxy-authenticate response header (as defined by the HTTP/1.0 specification) to ask the client to send authentication information:

HTTP/1.0 407 Proxy authentication required
Proxy-authenticate: ...
The client would then send the authentication information in the Proxy-authorization header:
CONNECT home.netscape.com:443 HTTP/1.0
User-agent: ...
Proxy-authorization: ...
Multiple Proxy Servers

Luotonen [Page 4]


SSL TUNNELING INTERNET-DRAFT December 1995

This specification applies also to proxy servers talking to other proxy servers. As an example, double firewalls make this necessary. In this case, the inner proxy is simply considered a client with respect to the outer proxy.

References
[HTTP] T. Berners-Lee, R. Fielding, H. Frystyk, "Hypertext
Transfer Protocol -- HTTP/1.0",
draft-ietf-http-v10-spec-04.html, October 14, 1995.
[SSL] K. Hickman, T. Elgamal, "The SSL Protocol",
draft-hickman-netscape-ssl-01.txt,
Netscape Communications Corporation, June 1995

Author's Address:

Ari Luotonen <ari@netscape.com>
Netscape Communications Corporation
501 E. Middlefield Road
Mountain View, CA 94043
USA

Luotonen [Page 5] --------------7215BB89CEC7B735D3F379A5-- From ipp-archive Thu Oct 30 13:32:38 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA01791 for ipp-outgoing; Thu, 30 Oct 1997 13:31:37 -0500 (EST) Message-Id: <3.0.32.19971030102851.006bfae4@13.240.96.62> X-Sender: rick@13.240.96.62 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 30 Oct 1997 10:29:04 PST To: ipp@pwg.org From: Rick Yardumian Subject: IPP> MOD/PRO Should mediaType be mimeType in the Protocol spec? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Hi, I just noticed that the protocol spec (23Oct97) lists a new mediaType value tag but does not contain a mime type value tag. Should the mediaType value tage be changed to mimeType? Rick ______________________________________________________________________ Rick Yardumian Xerox Corporation Voice: (310) 333-8303 / 8*823-8303 Corporate Research & Technology Fax: (310) 333-6342 / 8*823-6342 701 S. Aviation Blvd, ESAE-242 Email: rick@cp10.es.xerox.com El Segundo, CA 90245 ______________________________________________________________________ From ipp-archive Thu Oct 30 16:47:41 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA03422 for ipp-outgoing; Thu, 30 Oct 1997 16:43:11 -0500 (EST) Message-Id: <3.0.32.19971030134042.00730a98@13.240.96.62> X-Sender: rick@13.240.96.62 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 30 Oct 1997 13:40:43 PST To: ipp@pwg.org From: Rick Yardumian Subject: IPP>MOD - Must charset and natural-language always be sent? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk The latest model spec states that the attributes "attributes-charset" and "attributes-natural-language" are MANDATORY. Does this mean that they must be sent by the client even when the client does not send any text and/or name type attributes? Up until now, none of the IPP request operations had required attributes. I don't have an opinion one way or the other but I was assuming that some companies were pushing for no mandatory attributes on requests. Rick ______________________________________________________________________ Rick Yardumian Xerox Corporation Voice: (310) 333-8303 / 8*823-8303 Corporate Research & Technology Fax: (310) 333-6342 / 8*823-6342 701 S. Aviation Blvd, ESAE-242 Email: rick@cp10.es.xerox.com El Segundo, CA 90245 ______________________________________________________________________ From ipp-archive Thu Oct 30 17:17:41 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA04108 for ipp-outgoing; Thu, 30 Oct 1997 17:15:57 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 30 Oct 1997 15:15:09 -0700 From: Scott Isaacson To: rick@cp10.es.xerox.com, ipp@pwg.org Subject: Re: IPP> MOD/PRO Should mediaType be mimeType in the Protocol spec? Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org Precedence: bulk It should be mediaType, but since we already have "media" we will use "mimeMediaType" in both the Model and Protocol documents. See the meeting minutes from the 10/29/97 meeting and the new documents in the next few days. Scott >>> Rick Yardumian 10/30 11:29 AM >>> Hi, I just noticed that the protocol spec (23Oct97) lists a new mediaType value tag but does not contain a mime type value tag. Should the mediaType value tage be changed to mimeType? Rick ______________________________________________________________________ Rick Yardumian Xerox Corporation Voice: (310) 333-8303 / 8*823-8303 Corporate Research & Technology Fax: (310) 333-6342 / 8*823-6342 701 S. Aviation Blvd, ESAE-242 Email: rick@cp10.es.xerox.com El Segundo, CA 90245 ______________________________________________________________________ From ipp-archive Thu Oct 30 17:17:42 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA04097 for ipp-outgoing; Thu, 30 Oct 1997 17:13:24 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 30 Oct 1997 15:12:13 -0700 From: Scott Isaacson To: rick@cp10.es.xerox.com, ipp@pwg.org Subject: Re: IPP>MOD - Must charset and natural-language always be sent? Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: ipp-owner@pwg.org Precedence: bulk Yes they will always be sent. See the notes from the 10/29/97 IPP meetings and see the new document that will come out in the next few days. Scott >>> Rick Yardumian 10/30 2:40 PM >>> The latest model spec states that the attributes "attributes-charset" and "attributes-natural-language" are MANDATORY. Does this mean that they must be sent by the client even when the client does not send any text and/or name type attributes? Up until now, none of the IPP request operations had required attributes. I don't have an opinion one way or the other but I was assuming that some companies were pushing for no mandatory attributes on requests. Rick ______________________________________________________________________ Rick Yardumian Xerox Corporation Voice: (310) 333-8303 / 8*823-8303 Corporate Research & Technology Fax: (310) 333-6342 / 8*823-6342 701 S. Aviation Blvd, ESAE-242 Email: rick@cp10.es.xerox.com El Segundo, CA 90245 ______________________________________________________________________ From ipp-archive Fri Oct 31 18:39:38 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA07370 for ipp-outgoing; Fri, 31 Oct 1997 18:29:11 -0500 (EST) Message-Id: <3.0.1.32.19971031151202.00b8cc60@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 31 Oct 1997 15:12:02 PST To: ipp@pwg.org, pwg@pwg.org, JMP@pwg.org, PMP@pwg.org, fin@pwg.org, sense@pwg.org, P1394@pwg.org From: Carl-Uno Manros Subject: IPP> PING for Los Angeles Meeting December 1-5 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Hi, As host for the LA Meeting on December 1 - 5, 1997 I would like to know if you are planning to attend. Please make your own booking with the hotel, the deadline is: November 7th It is a very favorable rate for this class of hotel, so you do not want to miss the deadline. But please also send me a mail note with the following information: 1) The dates that you will stay at the Crown Plaza Hotel 2) The dates that you plan to attend meetings The details on the LA Meeting are as follows: Crown Plaza Hotel Los Angeles Airport 5985 W. Century Blvd. Los Angeles, CA 90045 PH: 310-642-7500 FAX: 310-216-6646 Room rate: $79.00 per night Parking: $6.00 per day Meeting room etc. about $30.00 - 35.00 per person per day The registration is in the name of: Xerox Deadline for the special room rate: November 7, 1997 Hotel contact: Helen McCaughan This is at the airport, so you do not really need a car. The hotel has shuttles from the airport. Welcome to LA. If you need any help with planning your visit, you can either look things up on the Web at: http://www.at-la.com./ or contact me. Regards, 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 From ipp-archive Fri Oct 31 19:22:58 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA09437 for ipp-outgoing; Fri, 31 Oct 1997 19:22:05 -0500 (EST) Message-Id: <3.0.1.32.19971031141209.00c38a80@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 31 Oct 1997 14:12:09 PST To: Robert.Herriot@Eng.Sun.COM, Scott_isaacson@novell.com From: Carl-Uno Manros Subject: IPP> Use of SSL3 Framing Cc: ipp@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Bob, The decision to require SSL3 framing has a number of consequences which needs to be reflected in the Protocol document. Where you speak about Encoding of Transport Layer (lines 350 - 357), you now need to say that we are using the combination of SSL3/HTTP. The default port for this is 443 (rather than 80), and the scheme for SSL3/HTTP is: https (rather than http). All Printer-URI and Job-URIs will now start with "https://" Hope this reaches you in time to get these changes in. Scott may need to check for similar changes in the Model document. 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 From ipp-archive Fri Oct 31 20:02:59 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA10082 for ipp-outgoing; Fri, 31 Oct 1997 19:59:49 -0500 (EST) Message-Id: <3.0.1.32.19971031161951.009c0100@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 31 Oct 1997 16:19:51 PST To: Harald.T.Alvestrand@uninett.no, moore@cs.utk.edu, agenda@ietf.org From: Carl-Uno Manros Subject: IPP> Re: Washington Scheduling: My traditional message Cc: szilles@adobe.com, ipp@pwg.org In-Reply-To: <2444.877961250@dale.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk At 06:07 AM 10/27/97 PST, you wrote: >OK, here it is: > >Please send in your requests to meet at the Washington IETF. > >I've been late - the stream of requests BEFORE I sent this out was >large enough to make me think it wasn't needed, but it seems that >it was. >There is not yet a preliminary agenda from the agenda keepers, so >I feel hesitant about announcing the track made so far - but you are >not forgotten! > >DO read the instructions from the IETF agenda keepers before sending >in a request - we DO use that information! > >The core is reproduced below. > >See you all in Washington! > > Harald A > ----- a. Working Group (or BOF) Name. Internet Printing Protocol (ipp) b. Area under which Working Group appears: Application c. Conflicts you wish to avoid: HTTP, IFAX, TLS d. Expected Attendance: 20 - 30 e. Any special requests: None f. Timeslot in preliminary schedule: December 10, 1997, 0900-1130 Agenda: Discuss any remaining issues associated with the IPP WG I-Ds: - Requirements for an Internet Printing Protocol or later - Internet Printing Protocol/1.0: Model and Semantics or later - Internet Printing Protocol/1.0: Protocol Specification or later - Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol or later - Mapping between LPD and IPP Protocols or later ----- Carl-Uno Manros Co-chair IPP WG 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 From ipp-archive Sat Nov 1 03:38:02 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id DAA11061 for ipp-outgoing; Sat, 1 Nov 1997 03:33:07 -0500 (EST) Message-ID: <345AE81E.4011A1D4@sharplabs.com> Date: Sat, 01 Nov 1997 00:28:14 -0800 From: Randy Turner Organization: Sharp Labs of America X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: Carl-Uno Manros CC: Robert.Herriot@Eng.Sun.COM, ipp@pwg.org Subject: Re: IPP> Use of SSL3 Framing References: <3.0.1.32.19971031141209.00c38a80@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk As an action item from the Boulder meeting, I am preparing a proposal document that addresses the order of operations for negotiating security. This document also discusses, in part, the use of URLs to designate security. A number of outside parties involved with security (TLS working group and others) will be reviewing this short document prior to distribution to the IPP working gruop at large. This is in order to save the IPP WG time reviewing and trying to understand something that is technically inaccurate. Carl Kugler at IBM has also volunteered to help review and verify a security negotitation proposal for IPP. One of the ideas expressed in this document is that the working group does not have to explicitly mandate the use of HTTPS for a security scheme. I will try to have this document out late next week. Randy Carl-Uno Manros wrote: > > Bob, > > The decision to require SSL3 framing has a number of consequences which > needs to be reflected in the Protocol document. > > Where you speak about Encoding of Transport Layer (lines 350 - 357), you > now need to say that we are using the combination of SSL3/HTTP. The default > port for this is 443 (rather than 80), and the scheme for SSL3/HTTP is: > https (rather than http). All Printer-URI and Job-URIs will now start with > "https://" > > Hope this reaches you in time to get these changes in. > > Scott may need to check for similar changes in the Model document. > > 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 From ipp-archive Sat Nov 1 14:03:07 1997 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA12137 for ipp-outgoing; Sat, 1 Nov 1997 14:00:12 -0500 (EST) Message-Id: <1.5.4.32.19971101175747.006752cc@pop3.holonet.net> X-Sender: cumanros@pop3.holonet.net X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 01 Nov 1997 09:57:47 -0800 To: Randy Turner From: Carl-Uno Manros Subject: Re: IPP> Use of SSL3 Framing Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Precedence: bulk Randy, This is probably a good idea. It would have been an even better idea if you had come up with it a month or so ago... Could you try to explain to us what the impact would be of this new document you plan to write. 1) Would it impact anything in our current Model and Protocol documents? 2) Would the new negotiation mechanism be mandatory for all IPP clients and servers? 3) Will this hold up our current plans for progressing the Model and Protocol documents? I think we all need quick answers to these questions. Thanks, Carl-Uno At 12:28 AM 11/1/97 -0800, you wrote: >As an action item from the Boulder meeting, I am preparing a >proposal document that addresses the order of operations for >negotiating security. This document also discusses, in part, >the use of URLs to designate security. A number of outside >parties involved with security (TLS working group and others) >will be reviewing this short document prior to distribution to >the IPP working gruop at large. This is in order to save the >IPP WG time reviewing and trying to understand something that >is technically inaccurate. Carl Kugler at IBM has also >volunteered to help review and verify a security >negotitation proposal for IPP. > >One of the ideas expressed in this document is that the >working group does not have to explicitly mandate the use >of HTTPS for a security scheme. > >I will try to have this document out late next week. > >Randy > > >Carl-Uno Manros wrote: >> >> Bob, >> >> The decision to require SSL3 framing has a number of consequences which >> needs to be reflected in the Protocol document. >> >> Where you speak about Encoding of Transport Layer (lines 350 - 357), you >> now need to say that we are using the combination of SSL3/HTTP. The default >> port for this is 443 (rather than 80), and the scheme for SSL3/HTTP is: >> https (rather than http). All Printer-URI and Job-URIs will now start with >> "https://" >> >> Hope this reaches you in time to get these changes in. >> >> Scott may need to check for similar changes in the Model document. >> >> 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 > >