From ipp-archive Mon Mar 2 12:47:39 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA22661 for ipp-outgoing; Mon, 2 Mar 1998 12:46:33 -0500 (EST) Message-Id: <3.0.1.32.19980302094131.00b95da0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 2 Mar 1998 09:41:31 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> Suggested Apps track for Los Angeles Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Harald has now put out a tentative agenda for the Application Area. The IPP is scheduled for 1:00 pm to 3:00 pm on the Wednesday. Carl-Uno >X-Sender: hta@dokka.kvatro.no >Date: Sun, 1 Mar 1998 01:44:25 PST >To: wg-chairs@apps.ietf.org >From: Harald Tveit Alvestrand >Subject: Suggested Apps track for Los Angeles >Cc: agenda@ietf.org, directorate@apps.ietf.org >Sender: owner-wg-chairs@dokka.kvatro.no > >I've now gone through the request I've received for Los Angeles. >It seems that there are a lot missing; I'm pretty sure I've seen some >that aren't included. Signs of a disorganized mind.... > >Please resend everything not included ASAP; there's not much time left! >Agenda: this time it seems as if only a few slots will be doubled, >even when I tentatively schedule what I think should be scheduled. > >The URL is http://www.apps.ietf.org/apps/track-la-mar98.html. >Mind the instructions!!!!!!!!!!!!!!!! > > Harald A > > > > > >-- >Harald Tveit Alvestrand, Maxware, Norway >Harald.Alvestrand@maxware.no > 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 Mar 2 13:37:44 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA23391 for ipp-outgoing; Mon, 2 Mar 1998 13:33:18 -0500 (EST) Message-Id: <3.0.1.32.19980302101809.009c8d50@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 2 Mar 1998 10:18:09 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> Protocol Action: An Extensible Message Format for Message Disposition Notifications to Proposed Standard Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk FYI, Carl-Uno >To: IETF-Announce:; >Cc: RFC Editor >Cc: Internet Architecture Board >Cc: receipt@cs.utk.edu >From: The IESG >Subject: Protocol Action: An Extensible Message Format for Message Disposition > Notifications to Proposed Standard >Date: Mon, 2 Mar 1998 08:44:03 PST >Sender: scoya@cnri.reston.va.us > > > >The IESG has approved the Internet-Draft 'An Extensible Message Format >for Message Disposition Notifications' >as a Proposed Standard. This document is the product of the Receipt >Notifications for Internet Mail Working Group. The IESG contact >persons are Harald Alvestrand and Keith Moore. > > >Technical Summary > > This memo defines a MIME content-type that may be used by a mail > user agent (UA) or electronic mail gateway to report the disposition > of a message after it has been sucessfully delivered to a recipient > ("receipt report" or "read report"). > > Other WGs may also be using this for delivering information about > automated processing of messages, for instance in the EDI context. > > >Working Group Summary > The working group came to consensus on the document as written; > it is believed that any kind of on-reading notification involves > serious tradeoffs, especially with regard to privacy; the WG > believes that the current document is a reasonable approach. > >Protocol Quality > > The document was reviewed for the IESG by Harald Alvestrand > > > 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 Mar 2 17:12:42 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA25676 for ipp-outgoing; Mon, 2 Mar 1998 17:09:59 -0500 (EST) Message-Id: <199803022208.OAA13763@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 02 Mar 1998 14:11:03 -0800 To: Keith Carter , From: Robert Herriot Subject: Re: IPP> Call in number for UPD meeting on March 3 In-Reply-To: <5040300013270834000002L042*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Is the meeting at 7pm or 6:30pm? Don and the pwg web site think that the meeting is at 6:30pm CST. Keith's email now and in the past has said 7pm CST I prefer 7pm, but 6:30 is OK too. We just need a definitive statement. Bob Herriot At 01:22 PM 3/2/98 , Keith Carter wrote: >The call in number for the UPD meeting at 7:00PM CST on Tuesday, March 3 is as >follows: > >Phone = 1-800-369-1883 >Passcode = 24427 (the call is unattended so enter the passcode when prompted to >do so) > >There are 10 lines reserved for the call. > >Unfortunately, I will not be able to attend the UPD meeting so whomever is at >the meeting please dial the above number and passcode on the phone in the >meeting room. > >Have a super day, > >Keith Carter >Senior Software Engineer >IBM Network Computing Software Division in Austin, Texas >internet email: carterk@us.ibm.com >Notes email: Keith Carter/Austin/IBM@IBMUS >phone: 512-838-2155 >tie-line: 678-2155 >fax: 512-838-0169 > From ipp-archive Mon Mar 2 17:53:44 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA26436 for ipp-outgoing; Mon, 2 Mar 1998 17:50:26 -0500 (EST) Message-Id: <34FB37A1.B9C8EA40@pogo.wv.tek.com> Date: Mon, 02 Mar 1998 14:50:09 -0800 From: Chuck Adams Organization: Tektronix, Inc. X-Mailer: Mozilla 4.03 [en] (X11; U; SunOS 5.5.1 sun4m) Mime-Version: 1.0 To: ipp@pwg.org Subject: Re: IPP> Call in number for UPD meeting on March 3 References: <199803022208.OAA13763@woden.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Robert Herriot wrote: > > Is the meeting at 7pm or 6:30pm? I prefer 7pm also. Chuck Adams Tektronix, Inc. > > Don and the pwg web site think that the meeting is at 6:30pm CST. > Keith's email now and in the past has said 7pm CST > > I prefer 7pm, but 6:30 is OK too. We just need a definitive statement. > > Bob Herriot > > At 01:22 PM 3/2/98 , Keith Carter wrote: > >The call in number for the UPD meeting at 7:00PM CST on Tuesday, March 3 > is as > >follows: > > > >Phone = 1-800-369-1883 > >Passcode = 24427 (the call is unattended so enter the passcode when prompted > to > >do so) > > > >There are 10 lines reserved for the call. > > > >Unfortunately, I will not be able to attend the UPD meeting so whomever is at > >the meeting please dial the above number and passcode on the phone in the > >meeting room. > > > >Have a super day, > > > >Keith Carter > >Senior Software Engineer > >IBM Network Computing Software Division in Austin, Texas > >internet email: carterk@us.ibm.com > >Notes email: Keith Carter/Austin/IBM@IBMUS > >phone: 512-838-2155 > >tie-line: 678-2155 > >fax: 512-838-0169 > > From ipp-archive Mon Mar 2 22:52:49 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA29275 for ipp-outgoing; Mon, 2 Mar 1998 22:49:50 -0500 (EST) Message-Id: <199803030348.TAA14312@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 02 Mar 1998 19:51:24 -0800 To: ipp@pwg.org From: Robert Herriot Subject: IPP>PRO A Definition of IPP using an XML schema 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 have downloaded a document in which I have defined the XML encoding of IPP using an XML schema. This schema covers most of section 15.3 in the model document and in particular defines the following =B7 The structure with regard to the attribute groups=20 =B7 Which attribute groups are mandatory or optional in each operation=20 =B7 Which operation attributes are mandatory, optional for the client and optional to implement=20 =B7 Which job and printer attributes are mandatory, optional for the sender,= and optional to implement=20 =B7 Which attributes must be implemented as a group.=20 =B7 What types and values are allowed for each attribute=20 =B7 Which types must be explicitly typed for an attribute.=20 =B7 The order or lack of order of various components. =20 The document has comments in blue and is meant to illustrate what is= possible with XML. I have downloaded the documents to: ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO= .=20 The documents are named: Ipp-xml-shema-980302-6.doc MS Word 6 Ipp-xml-shema-980302.doc MS Word 97 Ipp-xml-shema-980302.html HTML Ipp-xml-shema-980302.prn PostScript From ipp-archive Tue Mar 3 18:51:23 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA16559 for ipp-outgoing; Tue, 3 Mar 1998 18:43:15 -0500 (EST) From: Carl Kugler To: Subject: IPP> Need clarification: Job Template Attributes: Optional or n Message-ID: <5030100018137864000002L042*@MHS> Date: Tue, 3 Mar 1998 18:42:44 -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 Section 15.3.4.3, "Validate the presence of a single occurrence of requ= ired Operation attributes", shows Job Template attributes as (M*) for Print-= Job, Validate-Job, Create-Job, and Print-URI requests. (M*) indicates MANDA= TORY attributes that an IPP object MUST support, but that a client may omit = in a request or an IPP object may omit in a response. The reader is referre= d to Section 4.2, where it says "Support for Job Template attributes by a Pr= inter ob ject is OPTIONAL" and refers the reader to 12.2.3, to read "Even though= support for Job Template attributes by a Printer object is OPTIONAL, it is RECO= MMENDED that if the device behind a Printer object is capable of realizing any = feature or function that corresponds to an IPP attribute and some associated va= lue, th en that implementation SHOULD support that IPP attribute and value." Is there a contradiction between 15.3.4.3 and (4.2 or 12.2.3), or am I = missing something? = From ipp-archive Tue Mar 3 19:12:57 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA17306 for ipp-outgoing; Tue, 3 Mar 1998 19:12:26 -0500 (EST) Message-Id: <3.0.1.32.19980303155013.01167610@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 3 Mar 1998 15:50:13 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> Slides for IPP meeting: printer system configurations Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk I've down-loaded the slides that Roger and I put together as an action item to facilitate the discussion on host-to-device protocol and notification on Wed. Its in: ftp://ftp.pwg.org/pub/pwg/ipp/new_RAT/printer-flows.ppt ftp://ftp.pwg.org/pub/pwg/ipp/new_RAT/printer-flows.pdf I'm bringing 30 copies on hard copy and one set of tranparencies. Tom From ipp-archive Wed Mar 4 18:33:14 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA05166 for ipp-outgoing; Wed, 4 Mar 1998 18:29:33 -0500 (EST) Message-Id: <34FDE3C4.3427@hprnd.rose.hp.com> Date: Wed, 04 Mar 1998 15:29:08 -0800 From: Van Dang Organization: Hewlett-Packard Co. X-Mailer: Mozilla 3.03 (X11; I; HP-UX B.10.20 9000/780) Mime-Version: 1.0 To: ipp@pwg.org Subject: Re: IPP> Need clarification: Job Template Attributes: Optional or n References: <5030100018137864000002L042*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Carl Kugler wrote: > > Section 15.3.4.3, "Validate the presence of a single occurrence of required > Operation attributes", shows Job Template attributes as (M*) for Print-Job, > Validate-Job, Create-Job, and Print-URI requests. (M*) indicates MANDATORY > attributes that an IPP object MUST support, but that a client may omit in a > request or an IPP object may omit in a response. The reader is referred to > Section 4.2, where it says "Support for Job Template attributes by a Printer ob > ject is OPTIONAL" and refers the reader to 12.2.3, to read "Even though support > for Job Template attributes by a Printer object is OPTIONAL, it is RECOMMENDED > that if the device behind a Printer object is capable of realizing any feature > or function that corresponds to an IPP attribute and some associated value, th > en that implementation SHOULD support that IPP attribute and value." > Is there a contradiction between 15.3.4.3 and (4.2 or 12.2.3), or am I missing > something? I had the same question when I was going over the document. Perhaps Section 15.3.4.3 should indicate that the Job Template Attributes are (O*) instead of (M*) since the attribute group itself is OPTIONAL. From ipp-archive Thu Mar 5 16:48:27 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA21724 for ipp-outgoing; Thu, 5 Mar 1998 16:48:11 -0500 (EST) From: Carl Kugler To: Cc: Subject: Re: IPP> MOD Need Clarification re: Type4 keywords [input fo Message-ID: <5030100018210342000002L022*@MHS> Date: Thu, 5 Mar 1998 16:46:00 -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 Tom- > Why are there attributes that have both 'type4 keyword' and 'name' > (and hence 'nameWithLanguage) data types? I think that this is a new, different question, and a good one. Aren't= these the only attributes for which a multi-valued attribute instance may hav= e a mixture of its defined attribute syntaxes? If true, collapsing the redundant '(type4 keyword | name)' to 'name', w= ould allow one attribute syntax tag to apply to a whole attribute, even a multi-valued one. It would also make life easier for implementers tryin= g to use strong typing. -Carl hastings@cp10.es.xerox.com on 02/09/98 04:46:51 PM Please respond to hastings@cp10.es.xerox.com @ internet To: ipp@pwg.org @ internet, Carl Kugler/Boulder/IBM@ibmus cc: Subject: Re: IPP> MOD Need Clarification re: Type4 keywords [input fo At 14:06 02/02/1998 PST, Carl Kugler wrote: >Attributes with type 4 keywords also allow the 'name' attribute syntax= for >administrator defined names. Keywords SHALL be in U.S. English, but attributes >that are indicated to have the 'name' attribute syntax also automatica= lly have >the 'nameWithLanguage' attribute syntax. > >So in general, attributes with type 4 keywords can use the Language Ov= erride >Mechanism? Correct, but because the 13 attributes that have 'type 4 keyword' data = type, also have the 'name' data type: +-------------------+----------------------+----------------------+ | job-hold-until | job-hold-until- |job-hold-until- | | (type4 keyword | | default | supported | | name) | (type4 keyword | |(1setOf | | | name) | type4 keyword | name)| +-------------------+----------------------+----------------------+ | job-sheets | job-sheets-default |job-sheets-supported | | (type4 keyword | | (type4 keyword | |(1setOf | | name) | name) | type4 keyword | name)| +-------------------+----------------------+----------------------+ +-------------------+----------------------+----------------------+ | media | media-default | media-supported | | (type4 keyword | | (type4 keyword | |(1setOf | | name) | name) | type4 keyword | name)| | | | | | | | media-ready | | | |(1setOf | | | | type4 keyword | name)| +-------------------+----------------------+----------------------+ not just because they have the 'type 4 keyword' data type. But we thought that if an administrator is making up names (which is what type 4 keywords are), that an implementation may want to be simple and treat them as names in the language that the administrator is using or may want to be more complex and allow the administrator to define keywords that clients can localize into various languages. Sounds like something for the FAQ: Why are there attributes that have both 'type4 keyword' and 'name' (and hence 'nameWithLanguage) data types? Tom > > -Carl > > = From ipp-archive Fri Mar 6 15:02:18 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA07181 for ipp-outgoing; Fri, 6 Mar 1998 14:59:44 -0500 (EST) Message-Id: <3.0.1.32.19980306115206.0097ba10@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 6 Mar 1998 11:52:06 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> NOT - [ENP] Justification -- Why ENP? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Hi, Just to call your attention to the fact that the WebDAV group seems to be on the verge of inventing a new notification mechanism. Scott, are you aware of this? Carl-Uno >Resent-Date: Thu, 5 Mar 1998 10:12:03 PST >Resent-Message-Id: <199803051812.NAA12027@www19.w3.org> >X-Authentication-Warning: www10.w3.org: Host inet-gw.indy.tce.com [157.254.232.6] claimed to be tcemail.indy.tce.com >From: Fisher Mark >To: "'Ron Daniel Jr.'" , "'Jim Whitehead'" , > "'Josh Cohen'" , > "'Masinter Larry'" , > "'Surendra Reddy'" , > "'Markus Fleck'" >Cc: "'w3c-dist-auth'" >Date: Thu, 5 Mar 1998 10:11:33 PST >Resent-To: >Subject: [ENP] Justification -- Why ENP? >Resent-From: w3c-dist-auth@w3.org >X-Mailing-List: archive/latest/1620 >X-Loop: w3c-dist-auth@w3.org >Sender: w3c-dist-auth-request@w3.org >Resent-Sender: w3c-dist-auth-request@w3.org > >First, thanks to all of you who expressed an interest in ENP. I've been >buried with other projects, so I am just now coming back to this. Below >is a very rough draft of a paragraph I plan to put near the front of the >ENP draft, explaining why there should be yet another event notification >protocol. > >Surendra Reddy has offered to co-edit the draft with me, and I gladly >accept his offer. Surendra -- I suggest that we go off-line and discuss >the request part of the protocol, then once we are happy with that, we >will bring it to the rest of the WebDAV working group, or a separate >working group if others feel that ENP is way beyond the bounds of what >WebDAV should itself cover, as I think it probably is. > >All -- I will look into hosting the (potential) ENP working group >mailing list (TCE has never done that before, to my knowledge). >========================================================== >Mark Leighton Fisher Thomson Consumer Electronics >fisherm@indy.tce.com Indianapolis, IN >"Browser Torture Specialist, First Class" > > > >*** Why ENP? >There are several different network event notification protocols already >-- CORBA Event Services, X Window System events, SGAP, BSCW, etc. -- so >why should there be another event notification protocol? In two words >-- size and decentralization: >* Size is an issue, as the 2 most popular network event notification >protocols -- CORBA Event Services and X Window System events -- under >their current codebases require dragging along all of their other >services. This code bloat makes it impractical to use network event >notification services in lightweight and embedded-systems applications. >* Centralization is an issue, as centralized network event notification >servers are only needed when there are multiple recipients of event >notifications and/or multiple disjoint event types for notifications >(i.e. multiple event types on a server to be notified about). > >ENP is a lightweight network event notification protocol that can be >used either by itself (when there is one notification requester and one >major event type) or as part of a centralized network event notification >service (where there are multiple event notification requesters and >multiple major event types). > > > 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 Mar 6 19:37:19 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA08992 for ipp-outgoing; Fri, 6 Mar 1998 19:36:39 -0500 (EST) Message-Id: <199803070031.QAA18149@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 06 Mar 1998 16:34:19 -0800 To: Carl Kugler , From: Robert Herriot Subject: Re: IPP> MOD Need Clarification re: Type4 keywords [input fo Cc: In-Reply-To: <5030100018210342000002L022*@MHS> 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 agree with you that there is some confusion here, particularly where the= =20 document says "An administrator MAY define additional values using the=20 'name' or 'keyword' attribute syntax, depending on implementation." [ line= =20 2248, section 4.2.3]. Our intent was to allow an administrator to add new values locally. I have= =20 always assumed that a GUI would convert the standard keywords into some=20 localized word or phrase, but that a GUI would display values created by an= =20 administrator as is (to keep things simple). Attributes that allow new=20 administator values need to distinguish between those values that should be= =20 converted and those that should not. But the statement in the model document leaves me confused because it says= =20 that an administrator can call a new value a keyword or a name, and that=20 some implementation may not support both ways. This makes me think that one= =20 of these choices needs to be removed from the standard. The solution should= =20 be one of the two below. o We eliminate the concept of type 4 keywords, and let "name" be the way= =20 administrators make extensions. We should encourage GUIs to localize= =20 keywords and display names as is. All attributes whose values are type 4= =20 keywords currently have "name" as an alternate type. So we change their type to "type 3 keyword | name" o We eliminate "name" from the attributes that are "type 4 keyword |=20 name" and let a language be associated with keywords. We encourage= GUIs to=20 leave keywords as is if they aren't in the localization table. =20 I like the first option best. It still leaves two data types for some=20 attributes, but it is better than allowing a language with keywords when=20 most have no language associated with them. Bob Herriot At 01:46 PM 3/5/98 , Carl Kugler wrote: >Tom- > >> Why are there attributes that have both 'type4 keyword' and 'name' >> (and hence 'nameWithLanguage) data types? > >I think that this is a new, different question, and a good one.=A0 Aren't= these >the only attributes for which a multi-valued attribute instance may have a >mixture of its defined attribute syntaxes? > >If true, collapsing the redundant '(type4 keyword | name)' to 'name', would >allow one attribute syntax tag to apply to a whole attribute, even a >multi-valued one. It would also make life easier for implementers trying to use >strong typing. > >=A0 -Carl > > > >hastings@cp10.es.xerox.com on 02/09/98 04:46:51 PM >Please respond to hastings@cp10.es.xerox.com @ internet >To: ipp@pwg.org @ internet, Carl Kugler/Boulder/IBM@ibmus >cc: >Subject: Re: IPP> MOD Need Clarification re: Type4 keywords [input fo > > >At 14:06 02/02/1998 PST, Carl Kugler wrote: >>Attributes with type 4 keywords also allow the 'name' attribute syntax for >>administrator defined names.=A0 Keywords SHALL be in U.S. English, but >attributes >>that are indicated to have the 'name' attribute syntax also automatically >have >>the 'nameWithLanguage' attribute syntax. >> >>So in general, attributes with type 4 keywords can use the Language= Override >>Mechanism? > >Correct, but because the 13 attributes that have 'type 4 keyword' data= type, >also have the 'name' data type: > >=A0 +-------------------+----------------------+----------------------+ >=A0 | job-hold-until=A0=A0=A0 | job-hold-until-=A0=A0=A0=A0=A0= |job-hold-until-=A0=A0=A0=A0=A0=A0 | >=A0 | (type4 keyword |=A0 |=A0 default=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= | supported=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | >=A0 |=A0=A0=A0 name)=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 (type4 keyword |=A0=A0= =A0 |(1setOf=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | >=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0= name)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | type4 keyword | name)| >=A0 +-------------------+----------------------+----------------------+ >=A0 | job-sheets=A0=A0=A0=A0=A0=A0=A0 | job-sheets-default=A0=A0= |job-sheets-supported=A0 | >=A0 | (type4 keyword |=A0 | (type4 keyword |=A0=A0=A0=A0= |(1setOf=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | >=A0 |=A0=A0=A0 name)=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0= name)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | type4 keyword | name)| >=A0 +-------------------+----------------------+----------------------+ > >=A0 +-------------------+----------------------+----------------------+ >=A0 | media=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | media-default=A0=A0=A0=A0= =A0=A0=A0 | media-supported=A0=A0=A0=A0=A0 | >=A0 | (type4 keyword |=A0 | (type4 keyword |=A0=A0=A0=A0= |(1setOf=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | >=A0 |=A0=A0=A0 name)=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0= name)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | type4 keyword | name)| >=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | >=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |= media-ready=A0=A0=A0=A0=A0=A0=A0=A0=A0 | >=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= |(1setOf=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | >=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | type4= keyword | name)| >=A0 +-------------------+----------------------+----------------------+ > >not just because they have the 'type 4 keyword' data type.=A0 But we >thought that if an administrator is making up names (which is what >type 4 keywords are), that an implementation may want to be simple >and treat them as names in the language that the administrator is >using or may want to be more complex and allow the administrator to >define keywords that clients can localize into various languages. > >Sounds like something for the FAQ: > >Why are there attributes that have both 'type4 keyword' and 'name' >(and hence 'nameWithLanguage) data types? > >Tom > >> >>=A0 -Carl >> >> >=20 From ipp-archive Fri Mar 6 21:47:24 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA09941 for ipp-outgoing; Fri, 6 Mar 1998 21:42:25 -0500 (EST) Message-ID: <5CEA8663F24DD111A96100805FFE6587030BC369@red-msg-51.dns.microsoft.com> From: Paul Moore To: "'ipp@pwg.org'" Subject: IPP> MS requirements for UPD Date: Fri, 6 Mar 1998 18:42:09 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: ipp-owner@pwg.org Precedence: bulk At the Austin UPD session I was asked if I could post the MS requirements for our Unidrive 5 product. Sadly I cannot find any - this is not unusual inside MS - we make it up as we go along :-) From ipp-archive Mon Mar 9 12:23:04 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA14941 for ipp-outgoing; Mon, 9 Mar 1998 12:20:05 -0500 (EST) From: Harry Lewis To: Cc: Roger K Debry Subject: IPP> Notification content Message-ID: <5030300018795096000002L062*@MHS> Date: Mon, 9 Mar 1998 12:26:37 -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 In Austin, I think we discussed the IPP notification requirement that a= ny attribute may be requested during registration for a given event. I thi= nk the requirement stems from the notion that notification content should just= "mimic" the response to a query. But this is probably unrealistic. A query/resp= onse is synchronous - during which, the "agent's" job is to gather the requeste= d information and package the response. With notifications, you pre-regis= ter for asynchronous events. It would be a much greater burden on the agent, wh= ether it be IPP, SNMP or whatever, to maintain, not only of who wants which notifications, but also what information they requested with each type = of event! Harry Lewis - IBM Printing Systems = From ipp-archive Mon Mar 9 12:37:58 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA15589 for ipp-outgoing; Mon, 9 Mar 1998 12:34:31 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'Harry Lewis'" , ipp@pwg.org Cc: Roger K Debry Subject: RE: IPP> Notification content Date: Mon, 9 Mar 1998 09:34:30 -0800 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 seem to remember there was some concensus towards the end of the discussion that two items needed to be defined: 1. What events cause a notification to be generated, and 2. What parameters get transmitted along with the event notification. I emphasized at the meeting that the parameters that are transmitted along with a particular event are "standardized" (fixed) in a standards-track document. If a client needs to know more about the particular event, the client can subsequently issue an IPP request or possibly an SNMP request depending upon the original event. Randy -----Original Message----- From: Harry Lewis [SMTP:harryl@us.ibm.com] Sent: Monday, March 09, 1998 9:27 AM To: ipp@pwg.org Cc: Roger K Debry Subject: IPP> Notification content In Austin, I think we discussed the IPP notification requirement that any attribute may be requested during registration for a given event. I think the requirement stems from the notion that notification content should just "mimic" the response to a query. But this is probably unrealistic. A query/response is synchronous - during which, the "agent's" job is to gather the requested information and package the response. With notifications, you pre-register for asynchronous events. It would be a much greater burden on the agent, whether it be IPP, SNMP or whatever, to maintain, not only of who wants which notifications, but also what information they requested with each type of event! Harry Lewis - IBM Printing Systems From ipp-archive Mon Mar 9 12:49:20 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA16688 for ipp-outgoing; Mon, 9 Mar 1998 12:45:49 -0500 (EST) From: Harry Lewis To: Subject: RE: IPP> Notification content Message-ID: <5030300018796328000002L082*@MHS> Date: Mon, 9 Mar 1998 12:52:28 -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 Yes, thank you Randy. We went on, at the JMP meeting, to discuss this q= uite at length. I am preparing the JMP minutes for distribution today or tomorr= ow. I will cross post a reference (if that's still allowed). Harry Lewis - IBM Printing Systems rturner@sharplabs.com on 03/09/98 10:34:27 AM Please respond to rturner@sharplabs.com @ internet To: ipp@pwg.org @ internet, Harry Lewis/Boulder/IBM@ibmus cc: Roger K Debry/Boulder/IBM@ibmus Subject: RE: IPP> Notification content I seem to remember there was some concensus towards the end of the discussion that two items needed to be defined: 1. What events cause a notification to be generated, and 2. What parameters get transmitted along with the event notification. I emphasized at the meeting that the parameters that are transmitted along with a particular event are "standardized" (fixed) in a standards-track document. If a client needs to know more about the particular event, the client can subsequently issue an IPP request or possibly an SNMP request depending upon the original event. Randy -----Original Message----- From: Harry Lewis [SMTP:harryl@us.ibm.com] Sent: Monday, March 09, 1998 9:27 AM To: ipp@pwg.org Cc: Roger K Debry Subject: IPP> Notification content In Austin, I think we discussed the IPP notification requirement that any attribute may be requested during registration for a given event. I think the requirement stems from the notion that notification content should just "mimic" the response to a query. But this is probably unrealistic. A query/response is synchronous - during which, the "agent's" job is to gather the requested information and package the response. With notifications, you pre-register for asynchronous events. It would be a much greater burden on the agent, whether it be IPP, SNMP or whatever, to maintain, not only of who wants which notifications, but also what information they requested with each type of event! Harry Lewis - IBM Printing Systems = From ipp-archive Mon Mar 9 12:49:21 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA16208 for ipp-outgoing; Mon, 9 Mar 1998 12:41:59 -0500 (EST) Message-Id: <3.0.1.32.19980309085553.00c72650@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 9 Mar 1998 08:55:53 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> I-D ACTION:draft-fielding-uri-syntax-02.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk FYI, Carl-Uno -- >To: IETF-Announce:; >From: Internet-Drafts@ns.ietf.org >Reply-to: Internet-Drafts@ns.ietf.org >Subject: I-D ACTION:draft-fielding-uri-syntax-02.txt >Date: Mon, 9 Mar 1998 07:43:40 PST >Sender: cclark@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Uniform Resource Identifiers (URI): Generic Syntax > Author(s) : T. Berners-Lee, L. Masinter, R. Fielding > Filename : draft-fielding-uri-syntax-02.txt > Pages : 26 > Date : 06-Mar-98 > > A Uniform Resource Identifier (URI) is a compact string of characters > for identifying an abstract or physical resource. This document > defines the general syntax of URIs, including both absolute and > relative forms, and guidelines for their use; it revises and replaces > the generic definitions in RFC 1738 and RFC 1808. > >Internet-Drafts are available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-fielding-uri-syntax-02.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-fielding-uri-syntax-02.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@ietf.org. In the body type: > "FILE /internet-drafts/draft-fielding-uri-syntax-02.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > > 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 Mar 9 13:23:23 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA17815 for ipp-outgoing; Mon, 9 Mar 1998 13:15:59 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Mon, 09 Mar 1998 11:15:02 -0700 From: "Scott Isaacson" To: ipp@pwg.org Subject: IPP> Notification - Austin presentation posted Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: ipp-owner@pwg.org Precedence: bulk I have posted the presentation that I did for the Austin meeting. See: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/events-and-notification-980304.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/events-and-notification-980304.ppt These are PDF and PowerPoint 97 formats respectively. Scott ************************************************************ Scott A. Isaacson Corporate Architect Novell Inc., M/S PRV-C-121=20 122 E 1700 S, Provo, UT 84606 voice: (801) 861-7366, (800) 453-1267 x17366 fax: (801) 861-2517 email: sisaacson@novell.com web: http://www.novell.com ************************************************************ From ipp-archive Mon Mar 9 13:23:27 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA17572 for ipp-outgoing; Mon, 9 Mar 1998 13:14:14 -0500 (EST) Message-ID: <35043164.9123B8D5@underscore.com> Date: Mon, 09 Mar 1998 13:13:56 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Harry Lewis CC: ipp@pwg.org, Sense mailing list Subject: Re: IPP> Notification content References: <5030300018795096000002L062*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Harry, I agree with your observations entirely. And these concerns are *exactly* why SENSE was designed to _not_ support any kind of filtering, so as to ease the burden on the SENSE server (which is the "agent" in your text below). ...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 -- ---------------------------------------------------------------------- Harry Lewis wrote: > > In Austin, I think we discussed the IPP notification requirement that any > attribute may be requested during registration for a given event. I think the > requirement stems from the notion that notification content should just "mimic" > the response to a query. But this is probably unrealistic. A query/response is > synchronous - during which, the "agent's" job is to gather the requested > information and package the response. With notifications, you pre-register for > asynchronous events. It would be a much greater burden on the agent, whether it > be IPP, SNMP or whatever, to maintain, not only of who wants which > notifications, but also what information they requested with each type of event! > > Harry Lewis - IBM Printing Systems From ipp-archive Mon Mar 9 13:23:45 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA17664 for ipp-outgoing; Mon, 9 Mar 1998 13:14:56 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Mon, 09 Mar 1998 11:12:45 -0700 From: "Scott Isaacson" To: ipp@pwg.org Subject: IPP> Directory - Austin presentation posted Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: ipp-owner@pwg.org Precedence: bulk I have posted the presentation that I did for the Austin meeting. See: ftp://ftp.pwg.org/pub/pwg/ipp/new_DIR/directory-mapping-980304.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_DIR/directory-mapping-980304.ppt These are PDF and PowerPoint 97 formats respectively. Scott ************************************************************ Scott A. Isaacson Corporate Architect Novell Inc., M/S PRV-C-121=20 122 E 1700 S, Provo, UT 84606 voice: (801) 861-7366, (800) 453-1267 x17366 fax: (801) 861-2517 email: sisaacson@novell.com web: http://www.novell.com ************************************************************ From ipp-archive Mon Mar 9 14:25:31 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA19997 for ipp-outgoing; Mon, 9 Mar 1998 13:48:58 -0500 (EST) From: Harry Lewis To: Cc: , Subject: Re: IPP> Notification content Message-ID: <5030300018799170000002L002*@MHS> Date: Mon, 9 Mar 1998 13:55:02 -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 Jay, with a generic event broker, like SENSE, I can understand how filt= ering could get out of hand. For the specific case of Job events, however, I = am actually advocating an EVENT TYPE filter. In my note, I was trying to p= oint out that allowing arbitrary CONTENT per event type is probably out of scope= From ipp-archive Mon Mar 9 14:28:01 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA20564 for ipp-outgoing; Mon, 9 Mar 1998 13:53:41 -0500 (EST) Message-Id: <3.0.1.32.19980309101423.011811a0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 9 Mar 1998 10:14:23 PST To: Van Dang , ipp@pwg.org From: Tom Hastings Subject: Re: IPP> Need clarification: Job Template Attributes: Optional or Mandatory? In-Reply-To: <34FDE3C4.3427@hprnd.rose.hp.com> References: <5030100018137864000002L042*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Yes, it is a mistake in section 15.3.4.3. The M* should be O*, since Job Template attributes are not MANDATORY for a Printer to support (just recommended if the device supports the feature). This was agreed at the IPP meeting as well as being a typo that will be fixed by the editor, Scott Isaacson, in consultation with the RFC editor as the document becomes an RFC. Since the notation also refers to section 4.2 which refers to section 12.2.3 which recommends that a Printer object support a Job Template attribute that a device realizes, we could introduce the notation "R" for recommended in section 15.3.4.3. We don't want to mis-lead implementors that are using section 153.4.3 as a check list. Or we could just change section 15.3.4.3 (4 times): Group 2: Job Template Attributes (M) Job Template attributes (M*) (see section 4.2) to: Group 2: Job Template Attributes (M) Job Template attributes (O*) (recommended, see section 4.2) Please send any other discrepancies or contradictions like this to the e-mail list so that we can fix them as the document becomes an RFC. Thanks, Tom At 15:29 03/04/1998 PST, Van Dang wrote: >Carl Kugler wrote: >> >> Section 15.3.4.3, "Validate the presence of a single occurrence of required >> Operation attributes", shows Job Template attributes as (M*) for Print-Job, >> Validate-Job, Create-Job, and Print-URI requests. (M*) indicates MANDATORY >> attributes that an IPP object MUST support, but that a client may omit in a >> request or an IPP object may omit in a response. The reader is referred to >> Section 4.2, where it says "Support for Job Template attributes by a Printer ob >> ject is OPTIONAL" and refers the reader to 12.2.3, to read "Even though support >> for Job Template attributes by a Printer object is OPTIONAL, it is RECOMMENDED >> that if the device behind a Printer object is capable of realizing any feature >> or function that corresponds to an IPP attribute and some associated value, th >> en that implementation SHOULD support that IPP attribute and value." >> Is there a contradiction between 15.3.4.3 and (4.2 or 12.2.3), or am I missing >> something? > >I had the same question when I was going over the document. Perhaps >Section 15.3.4.3 should indicate that the Job Template Attributes are >(O*) instead of (M*) since the attribute group itself is OPTIONAL. > > From ipp-archive Tue Mar 10 11:18:15 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA09368 for ipp-outgoing; Tue, 10 Mar 1998 11:17:15 -0500 (EST) From: Harry Lewis To: Cc: Subject: IPP> Austin JMP (trap) minutes Message-ID: <5030300018837125000002L052*@MHS> Date: Tue, 10 Mar 1998 11:23:56 -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 have uploaded the meeting minutes for the March meeting in Austin. ftp://ftp.pwg.org/pub/pwg/jmp/minutes/jmp-0398.pdf The file is also available in HTML. IPP Notification folks may want to review item (3) under the "Job MIB t= rap topics" section. Here you will find a list of Notification Types (calle= d trap types for JMP) and a table of Notification content, per type. This shou= ld be useful for IPP notification, as well. Harry Lewis - IBM Printing Systems = From ipp-archive Tue Mar 10 14:08:18 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA11507 for ipp-outgoing; Tue, 10 Mar 1998 14:06:48 -0500 (EST) From: don@lexmark.com Message-Id: <199803101906.AA27408@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org Date: Tue, 10 Mar 1998 14:06:24 -0500 Subject: IPP> March Meeting Minutes Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Precedence: bulk Here are the meeting minutes from the March Meeting in Austin. I have also posted these to the ftp server as: ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-0398.txt ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-0398.pdf ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** ----------------------------------------------------------------- Internet Printing Project Meeting Minutes March 4/5, 1998 Austin, Texas The meeting started on March 4, 1998 at 1:00 PM led by Carl-Uno Manros. These minutes were recorded by Don Wright. The attendees were: - Randy Turner - Sharp - Ron Bergman - DataProducts - Peter Zehler - Xerox - Lee Farrell - Canon - Bob Pentecost - HP - Kris Schoff - HP - Don Wright - Lexmark - Tom Hastings - Xerox - Carl-Uno Manros - Xerox - Bob Herriot - Sun - Henrik Holst - I-Data - Harry Lewis - IBM - Paul Moore - Microsoft - Jim Walker - Dazel - Scott Isaacson - Novell - Shivaun Albright - HP - Mabry Dozier - QMS - Yuji Sasaki - JCI - Marvin Heffler - IBM - Roger deBry- IBM - Lloyd Young - Lexmark - Bill Wagner - Osicom/DPI - Brian Batchelder - HP - Chuck Adams - Tektronix - David Kellerman - Northlake Software - Keith Carter - IBM - Philip Thambidurai - Okidata - Praveen Kanipakam - Sharp - Peter Michaleu - Shinesoft - Bob Broecolo - Kodak Carl-Uno Manros reviewed the agenda for the day. Carl-Uno announced that Scott Isaacson will be presenting an overview of IPP at WWW7 in Brisbane in April. DEVICE-TO-PRINTER PROTOCOL -------------------------- Roger deBry presented the "Print Systems Configuration" document which provides a framework of the various configurations of print systems. This document is available in PDF and PPT versions on the PWG FTP server as ftp://ftp.pwg.org/pub/pwg/ipp/new_REQ/printer-flows.pdf and as ftp://ftp.pwg.org/pub/pwg/ipp/new_REQ/printer-flows.ppt. There was significant discussion over the usage and arrangement of various terminologies (e.g. what is a server versus client.) The group discussed the need for a host-to-printer protocol. Should IPP evolve upwards to provide the functionality of a robust host-to-printer protocol? Does something new need to be created or does something already exist? How much similarity does there need to be between a client-to-server protocol (like IPP) and the device-to-printer protocol. Paul Moore led and others created a list of the deficiencies in IPP as a host-to-printer protocol: 1) IPP is asymmetrical: No way for the printer to generate an alert. 2) Today there is no peer conflict resolution in IPP. How does an IPP printer resolve being asked to print by two clients. 3) There is no way for the printer to solicit data from the client. For example to throttle data transfers. 4) The current security model might be too complex for printer devices. 5) Not transport neutral, depends on HTTP. 6) Fairly heavy duty. 7) No way to move data backwards. 8) No separate channel for control while data is being printed. 9) Detailed configuration and status not available. 10) Feature set of IPP was constrained to support low-end printer implementations. 11) No accounting outside of device. 12) No resource server 13) The data representation may not be sophisticated enough. Don Wright presented an overview of IEEE Std. 1284.1-1997 to the group as an example of an existing standard for device-to-printer protocol. This presentation is available at ftp://ftp.lexmark.com/pub/ieee/1284.1/pwg12841.pdf. Due to the absence of Jay Martin, David Kellerman and Tom Hastings briefly highlighted the characteristics and capabilities of CPAP. CPAP version 1 was released as an Informational RFC. The CPAP version 2 draft is available on the PWG ftp server. The CPAP specification is available at ftp://ftp.pwg.org/pub/pwg/cpap/cpap.pdf The group discussed the possible courses of action on the device-to- printer protocol. Possibilities include: 1) Enhancing IPP, adding access to MIB objects, etc. 2) Mapping an enhanced IPP to raw TCP/IP 3) adopting/modifying an existing device-to-printer protocol 4) A version of IPP for devices that supports a subset of IPP plus device control specific additions Randy Turner plans to put out a document that adds some of the desired control functionality and maps it to TCP/IP rather than using HTTP. Don Wright will do a comparison of the IPP attributes and TIP/SI. Scott Isaacson and Tom Hastings will investigate using an IPP follow-on (aka IPP') to access the MIB in the printer. TESTING ------- Peter Zehler presented and overview of the testing and verification plan. This document is available on the PWG server as ftp://www.pwg.org/pub/pwg/ipp/new_TES/IPP-Test-Plan-980216.pdf Several work items were identified that could be added to the test plan: -- Test of error codes - boundary conditions - unsupported operations, etc. - bad syntax Peter Zehler will be collecting experience information from the test cycle that could be included as implementation experience. No significant changes were made to the plan based upon discussion. The group discussed the need for some tools that could make the testing and interoperation verification easier. For example, a special "DIFF" that ignored things like the job id, submission time, etc. Another tool that would be useful would be a print formatter that would take the binary data and convert it into something more human readable. Right now, the traces are stored on the ftp server as simply an binary files containing the wire transactions. The meeting recessed at 6:00 PM. The meeting resumed at 8:35 on March 5, 1997. Carl-Uno reviewed the agenda for the day. The first topic of discussion was notification. NOTIFICATION ------------ Roger deBry discussed the requirements of IPP notifications ID which is available on the PWG ftp server as ftp.pwg.org/pub/pwg/ipp/new_NOT/IPP- notify-980219.txt. It was pointed out that a delivery means might have different quality of service levels. For example a notification like an SNMP trap might have two qualities of service levels, one that sends the trap just once and another that continues to retry until the requestor receives it. Roger will update the document. The group discussed the issues of security in the notification space and the possibility of intercepting notification as a way to get around IPP security that would prevent someone from looking at the printers job queue. Roger will submit an update of the Notification Requirements document to the IETF before March 13th in order to be discussed at the LA IETF meeting. Randy Turner reviewed the notification work being done in the IFAX/EMAIL working group. First Randy reviewed the existing "delivery status notification" (DSN) and "message disposition notification" (MDN) processes that are used by e-mail (SMTP) today. It had been proposed on the mailing list that IPP use MDN's for IPP job complete notifications. If we were to use something like the multi-part disposition-notification we would need to include in the machine-readable section information to identify the language of any text strings. DSN's are described in RFCs 1891-1894 (especially 1894) and MDN's in draft-ietf-receipt-mdn-08.txt. Randy Turner next reviewed SNMP traps. SNMPv1 traps were unreliable and had not standard way to specify trap destination. In SNMPv3, there are some additions to traps called "informs." Traps are still unreliable in v3 but a standard way to specify destinations for both traps and informs were added. SNMPv3 "informs" can be reliable. Both "informs" and traps can be secure. SNMPv3 added a Target MIB that specifies destination for traps and "informs": - names - transport domain (upd/ip, tcp/ip, ipx, etc.) - transport address (depends on domain) - message processing model (V1, V2, V2C, V3) - security method (e.g. TLS) - security level (e.g. RC2) - security name ("fred") - timeout - retry count This is all documented in RFC2273. RFC1908 talks about interoperation between SNMPv3 and SNMPv1. Additionally, the Notification MIB allows the agent to store what traps and informs are sent to which destinations. The group discussed a number of possible ways to use these concepts for notification; however, no direction was set. Scott Isaacson then reviewed several other notification schemes. His slides will be posted to the PWG ftp server (ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/events-and-notification- 980304.pdf). The presentation covered: - OMG -> IDL and CORBA based - The Open Group - Java - NPDS (uses RPC -- RFC1831/1832) The group discussed what the IETF would be receptive to in this notification area. SNMPv3 and other means are available out of devices but it doesn't address the scalability issue, i.e. how do a large number of clients get information about a large numbers of printers. The concept discussed is that of an event delivery channel that would collect events from printers and distribute them to interested clients. In the Novell NDPS implementation, registration for events get sent to the printer and forwarded on to the "channel" which distributes the events. Conceptually, IPP could be used as the registration means and a different protocol could be used to delivery the notification back to the registered client. Harry Lewis showed a presentation covering IBM's concepts of JOB MIB Traps. Harry Lewis will be posting this presentation in the PWG ftp server in the JMP directory tree. DIRECTORY Scott Isaacson presented material on the issues of mapping of IPP attributes to a directory schema. This material will be posted to the ftp server(ftp://ftp.pwg.org/pub/pwg/ipp/new_DIR/directory-mapping- 980304.pdf). Scott compared the original IPP schema proposal with SLP and what would be capable using LDAP. Scott will get back with Pete St. Pierre, who wrote the SLP printer mapping, and point out the inconsistencies between IPP and the SLP printer mapping. MODEL DOCUMENT Scott reviewed a number of comments made to the DL about the model document. There were no technical changes made; several typos were identified and clarified. The new name for the IPP Protocol Document will be "Internet Printing Protocol/1.0: Encoding and Transport". ACTION ITEMS: * Tom Hastings and Roger deBry will be doing some work on dictionary syntax. * Tom Hastings will be doing some work on improving the document object and document object attributes for a future version of IPP. * Steve Zilles will write a proposal for adding font support to IPP. OTHER ISSUES Peter Zehler has done some work on Automatic Printer Installation. He presented an overview of his thoughts and work in this area. This work has been written up and posted on the PWG ftp server as ftp://www.pwg.org/pub/pwg/ipp/new_INST/ipp-printer-install-980213.pdf. There was a lot of discussion about how this could be used. There was a reluctance to add anything to the IPP protocol but rather to create an informational RFC or a "best practices" document that would describe how the features of IPP could be used to do automatic driver installation. Tom Hastings has written a paper Early Binding Defaulting which was posted to the mailing list ftp:/ftp.pwg.org/pub/pwg/ipp/new_MOD/clearer- defaulting.pdf as well as ftp:/ftp.pwg.org/pub/pwg/ipp/new_MOD/clearer- defaulting.txt. After some discussion about boundary conditions and printer cascading effects, Tom will update the document and re-post it to the mailing list. The results of this proposal are probably a significant change to the model and would probably need to be a "Model" change. IPP has a two hour time slot at the LA IETF meeting on Wednesday, April 1, 1998 from 1PM until 3PM. Any documents to be discussed need to be sent to the IETF editor by 3/13. The next IPP meeting (outside the LA IETF meeting) will be held April 8/9 in Portland, Or. Details are available from http://www.pwg.org/chair. The meeting adjourned at 5:10PM From ipp-archive Tue Mar 10 14:28:20 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA12134 for ipp-outgoing; Tue, 10 Mar 1998 14:25:12 -0500 (EST) Message-Id: <3.0.1.32.19980310111925.0121a4d0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 10 Mar 1998 11:19:25 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - PWG IPP Conference Call - 980311 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk PWG IPP Conference Call - 980311 We will hold a conference call tomorrow as usual. Sorry for the late announcement, which was due to some confusion about who was setting up the call. I have just done that now, see the details below. I expect us to do some follow-up of the homework assignments from last week's meeting in Austin and to discuss how we should best organize the work on some of the new subjects, in particular on IPP Notifications and on the host-to-device subjects. Don will try to get the minutes out later today. I would also like to check up on getting an Implementor's Guide document started and also discuss a bit further about the interest to plan for a multi-vendor demo in the autumn. The phone-in information is: Date and Time: March 11, 10:00-12:00 am PST (remember the earlier time slot) Phone number: 402-331-6491 (For Xerox participants 8*535-5000) Pass code: cmanros Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-archive Tue Mar 10 15:28:24 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA12818 for ipp-outgoing; Tue, 10 Mar 1998 15:25:10 -0500 (EST) Message-Id: <3.0.1.32.19980310122336.011dcbc0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 10 Mar 1998 12:23:36 PST To: ipp@pwg.org From: Tom Hastings Subject: Re: IPP> Slides for IPP meeting: printer system configurations In-Reply-To: <3.0.1.32.19980303155013.01167610@garfield> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk The correct directory was new_REQ, not new_RAT, for our host-to-device discussion: ftp://ftp.pwg.org/pub/pwg/ipp/new_REQ/printer-flows.ppt ftp://ftp.pwg.org/pub/pwg/ipp/new_REQ/printer-flows.pdf At 15:50 03/03/1998 PST, Tom Hastings wrote: >I've down-loaded the slides that Roger and I put together as an >action item to facilitate the discussion on host-to-device protocol >and notification on Wed. > >Its in: > >ftp://ftp.pwg.org/pub/pwg/ipp/new_RAT/printer-flows.ppt >ftp://ftp.pwg.org/pub/pwg/ipp/new_RAT/printer-flows.pdf > >I'm bringing 30 copies on hard copy and one set of tranparencies. > >Tom > > From ipp-archive Tue Mar 10 16:03:22 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA13504 for ipp-outgoing; Tue, 10 Mar 1998 15:59:31 -0500 (EST) Message-Id: <3.0.1.32.19980310125409.009ff100@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 10 Mar 1998 12:54:09 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> 41st IETF-LOS ANGELES: IPP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk >X-Sender: mbeaulie@ietf.org >Date: Tue, 10 Mar 1998 11:57:56 PST >To: Carl-Uno Manros >From: Marcia Beaulieu >Subject: 41st IETF-LOS ANGELES: IPP >Cc: , > >This is to confirm one session for IPP as follows: > > Wednesday, April 1 at 1300-1500 (opposite dhc, pint, vrrp, mboned) > >Thanks, > >Marcia > > >********************************************************************** >Marcia Beaulieu >Meeting Coordinator >Voice: 703-620-8990 ext. 210 >Fax: 703-758-5913 > > 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 Mar 11 09:38:27 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA25234 for ipp-outgoing; Wed, 11 Mar 1998 09:37:54 -0500 (EST) Message-Id: <199803111437.JAA26480@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipp@pwg.org From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: IPP> I-D ACTION:draft-ietf-ipp-dhcp-option-00.txt Date: Wed, 11 Mar 1998 09:37:44 -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 : DHCP Option for Internet Printing Protocol Services Author(s) : R. Turner Filename : draft-ietf-ipp-dhcp-option-00.txt Pages : 3 Date : 10-Mar-98 This document defines a new DHCP option for automatic configuration of Internet Printing Protocol (IPP)[1] services to potential clients. Services. This new option provides an IPP client with enough configuration information to initiate a session with an IPP server without manual configuration of the client, and without existing directory services. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipp-dhcp-option-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-dhcp-option-00.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@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipp-dhcp-option-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980310134553.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-dhcp-option-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-dhcp-option-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980310134553.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-archive Wed Mar 11 10:03:30 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA25864 for ipp-outgoing; Wed, 11 Mar 1998 09:59:04 -0500 (EST) From: Roger K Debry To: Subject: IPP> New notification requirements document posted Message-ID: <5030100018373836000002L062*@MHS> Date: Wed, 11 Mar 1998 09:58:30 -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 have posted the updated requirements document for notifications. They can be found at - - ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ draft-ietf-ipp-not-01.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ draft-ietf-ipp-not-01.txt 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 Wed Mar 11 10:58:29 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA26661 for ipp-outgoing; Wed, 11 Mar 1998 10:57:12 -0500 (EST) Message-ID: <3506B44D.C7229912@underscore.com> Date: Wed, 11 Mar 1998 10:57:01 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: IPP Mailing List Subject: IPP> Public concerns regarding the use of XML in standards efforts Content-Type: multipart/mixed; boundary="------------AF19E378F4F264900FC5F48E" Sender: ipp-owner@pwg.org Precedence: bulk This is a multi-part message in MIME format. --------------AF19E378F4F264900FC5F48E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Attached is a message just posted to the ACAP DL. (ACAP is the IETF WG for "Application Configuration Access Protocol", an effort I have been monitoring for quite some time with regard to SENSE.) This group is now considering whether to incorporate XML in ACAP, having all the same kinds of interest/concern the IPP WG has shown. These words are very disturbing. Unless anyone has any objections, I'd like to post related messages on this ACAP thread to the IPP DL so that others don't have to monitor the ACAP DL themselves. Please note that I am *not* against using XML; in fact, I find it rather interesting for IPP and other protocol efforts. I just want to make sure we have both eyes open should we pursue XML at this stage. ...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 -- ---------------------------------------------------------------------- --------------AF19E378F4F264900FC5F48E Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from po9.andrew.cmu.edu (PO9.ANDREW.CMU.EDU [128.2.10.109]) by uscore.underscore.com (8.8.4/8.7.2) with ESMTP id WAA04160 for ; Tue, 10 Mar 1998 22:26:06 -0500 (EST) Received: (from postman@localhost) by po9.andrew.cmu.edu (8.8.5/8.8.2) id WAA16996; Tue, 10 Mar 1998 22:05:12 -0500 (EST) Received: via switchmail for ietf-acap+@andrew.cmu.edu; Tue, 10 Mar 1998 22:05:11 -0500 (EST) Received: from po5.andrew.cmu.edu via qmail ID ; Tue, 10 Mar 1998 22:03:23 -0500 (EST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by po5.andrew.cmu.edu (8.8.5/8.8.2) with ESMTP id WAA17471 for ; Tue, 10 Mar 1998 22:03:15 -0500 (EST) Received: from cambyses.cyrusoft.com (cambyses.cyrusoft.com [206.31.218.198]) by darius.cyrusoft.com (8.8.5/8.8.5) with SMTP id WAA17678; Tue, 10 Mar 1998 22:02:27 -0500 (EST) Date: Tue, 10 Mar 1998 22:03:51 -0500 From: "Matthew Wall" To: "IETF ACAP Discussion List" cc: "Chris Newman" Subject: Re: Transfer of ACAP data was Re: I-D ACTION:draft-ietf-asid-mime-direct-06.txt (fwd) Message-ID: <524524.3098556231@cambyses.cyrusoft.com> X-Mailer: Mulberry (MacOS) [1.4.0a2, s/n S-171717] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --On Tue, Mar 10, 1998 16:16 -0800 "Chris Newman" wrote: > Some people would suggest we use XML as the representation format. It's > not a bad format, but there's no stable spec to reference. Someone would > have to publish XML in an RFC first. [other stuff snipped] I categorically refuse to endorse any representation format or other alleged standard that requires paid membership in a consortium to access or reference. It's a closed standard no matter how good and no matter how many companies endorse it. Just my 2 c, but that's why this is an IETF group, after all. And as Chris points out, we can't legally reference this as an ACAP practice as long as there's no referenceable RFC or equivalent public document. To provide some catty backfill, one of the original proponents of XML was at our '97 ACAP meeting at the Holiday Inn in Pittsburgh. He actually provided useful participation at the time, as those of you who were there may recall. On this, I have no quibble. However, we were promised full access to, and participation in, the development of the XML specification at the time with the understanding we'd conjointly work on an XML-ACAP interop model. After several months of fruitless private email exchanges with this person and the designated W3C contacts, I was finally told any ACAP-interested party would also have to be a member of the W3C consortium, period, to participate. End of exchanges. If it stinks like dung, I don't want to have to taste it to find out what it really is. This one stinks of closed system thinking. I give it a big thumbs down (or, nose-held, to continue the metaphor) for this reason. - matt --------------AF19E378F4F264900FC5F48E-- From ipp-archive Wed Mar 11 12:08:33 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA27700 for ipp-outgoing; Wed, 11 Mar 1998 12:03:36 -0500 (EST) Message-Id: <3.0.1.32.19980311085808.009e6c40@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 11 Mar 1998 08:58:08 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> I-D ACTION:draft-ietf-stdguide-ops-06.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk FYI. Now they tell us... Carl-Uno ---- >To: IETF-Announce:; >Cc: stdguide@midnight.com >From: Internet-Drafts@ns.ietf.org >Reply-to: Internet-Drafts@ns.ietf.org >Subject: I-D ACTION:draft-ietf-stdguide-ops-06.txt >Date: Wed, 11 Mar 1998 06:25:46 PST >Sender: cclark@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Guide for Internet Standards Writers >Working Group of the IETF. > > Title : Guide for Internet Standards Writers > Author(s) : G. Scott > Filename : draft-ietf-stdguide-ops-06.txt > Pages : 19 > Date : 10-Mar-98 > > This document is a guide for Internet standard writers. It defines > those characteristics that make standards coherent, unambiguous, and > easy to interpret. Also, it singles out usage believed to have led > to unclear specifications, resulting in non-interoperable > interpretations in the past. These guidelines are to be used with > RFC 1543, ''Instructions to RFC Authors.'' > > This version of the document is a draft. > >Internet-Drafts are available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-stdguide-ops-06.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-stdguide-ops-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@ietf.org. In the body type: > "FILE /internet-drafts/draft-ietf-stdguide-ops-06.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > > 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 Mar 11 13:18:42 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA28920 for ipp-outgoing; Wed, 11 Mar 1998 13:13:36 -0500 (EST) Message-Id: <3.0.1.32.19980311093307.010ba2d0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 11 Mar 1998 09:33:07 PST To: Paul Moore , "'ipp@pwg.org'" From: Tom Hastings Subject: Re: IPP> MS requirements for UPD In-Reply-To: <5CEA8663F24DD111A96100805FFE6587030BC369@red-msg-51.dns.mi crosoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Then I suggest that we develop a requirements document for UPD based on the meeting that took place last week. Any volunteers? How do the UPD and the GPD file requirements relate to the host-to-device protocol requirement additions to IPP that we are considering? Tom At 18:42 03/06/1998 PST, Paul Moore wrote: >At the Austin UPD session I was asked if I could post the MS requirements >for our Unidrive 5 product. Sadly I cannot find any - this is not unusual >inside MS - we make it up as we go along :-) > > From ipp-archive Wed Mar 11 13:18:44 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA28921 for ipp-outgoing; Wed, 11 Mar 1998 13:13:36 -0500 (EST) Message-Id: <3.0.1.32.19980311093213.010be660@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 11 Mar 1998 09:32:13 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> NOT - device-to-host events, not end-user events Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk In discussing the host-to-device requirements, we came up with a requirement that the printer be able to feed back information about whether it was choked up with data or needed more data for the current job. So we could have events like: Slow down data transfer Speed up data transfer There is an even more important event for a device to send to a host: Ready for another job This event is useful for a number of configurations: 1. Such an event could anticipate the completion of the current job, so that the devices could overlap jobs. Printers that completely interpret a job or document before marking would want to indicate that they are ready for the next job much sooner that printers that mark as they interpret. Printers with a long output paper path may want to ask for the next job while the output paper path is being emptied, so that the printer doesn't slow down between jobs. A host that has a job would then be advised that this device could accept it now. If the host did not have a job, the host could still keep an indication that this device is a candidate for a job when a new job is submitted to the host. 2. This event is especially useful for the IPP fan-out case of a server/host that controls multiple devices represented by a single IPP Printer object. 3. This event is also useful for the simpler case where a device is controlled by more than one host and the device wants to indicate that it is ready for another job from any of the hosts (or from a particular one, if the device is trying to be fair). I just read the current Notification Requirements and it is focused on events that end users needs, so the above event are ones that hosts need, not end-users. But these events are NOT events that administrators need. Usually in the IPP WG, we have been making the distinction between end-users vs. system operators/adminstrators, not between end-users versus servers/hosts that are submitting jobs to devices on behalf of end-users. So are the above events in-scope for our IPP notification effort or out of scope? I think the answer depends on whether the IPP WG is going to tackle the host-to-device requirements for IPP. Tom From ipp-archive Wed Mar 11 13:18:44 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA28930 for ipp-outgoing; Wed, 11 Mar 1998 13:13:40 -0500 (EST) Message-Id: <3.0.1.32.19980311095040.01182800@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 11 Mar 1998 09:50:40 PST To: Harry Lewis , From: Tom Hastings Subject: RE: IPP> Notification content In-Reply-To: <5030300018796328000002L082*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk If the notification transport is SNMP, then I can see why the registration would be difficult if it included sending attributes that the registration specified. On the other hand, if the registration mechanism is simply attributes in a Job object that remain stored in that Job object for the life of the job, then allowing the requester to include the attribute names to be sent with the notification is straightforward and natural. >From a model point of view, we could cover both by saying that on an SNMP transport binding, the trap recipient has to go and read the attributes desired, but in a notification transport binding to, say, UDP data grams or email, the attributes and their current values at the time of the event would be bound into the notification information. Tom At 09:52 03/09/1998 PST, Harry Lewis wrote: >Yes, thank you Randy. We went on, at the JMP meeting, to discuss this quite at >length. I am preparing the JMP minutes for distribution today or tomorrow. I >will cross post a reference (if that's still allowed). > >Harry Lewis - IBM Printing Systems > > > > >rturner@sharplabs.com on 03/09/98 10:34:27 AM >Please respond to rturner@sharplabs.com @ internet >To: ipp@pwg.org @ internet, Harry Lewis/Boulder/IBM@ibmus >cc: Roger K Debry/Boulder/IBM@ibmus >Subject: RE: IPP> Notification content > > > >I seem to remember there was some concensus towards the end of the >discussion that two items needed to be defined: > >1. What events cause a notification to be generated, and >2. What parameters get transmitted along with the event >notification. > >I emphasized at the meeting that the parameters that are transmitted >along with a particular event are "standardized" (fixed) in a >standards-track document. If a client needs to know more about the >particular event, the client can subsequently issue an IPP request or >possibly an SNMP request depending upon the original event. > >Randy > > -----Original Message----- > From: Harry Lewis [SMTP:harryl@us.ibm.com] > Sent: Monday, March 09, 1998 9:27 AM > To: ipp@pwg.org > Cc: Roger K Debry > Subject: IPP> Notification content > > In Austin, I think we discussed the IPP notification requirement >that any > attribute may be requested during registration for a given >event. I think the > requirement stems from the notion that notification content >should just "mimic" > the response to a query. But this is probably unrealistic. A >query/response is > synchronous - during which, the "agent's" job is to gather the >requested > information and package the response. With notifications, you >pre-register for > asynchronous events. It would be a much greater burden on the >agent, whether it > be IPP, SNMP or whatever, to maintain, not only of who wants >which > notifications, but also what information they requested with >each type of event! > > Harry Lewis - IBM Printing Systems > > > > > > > From ipp-archive Wed Mar 11 13:48:37 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA00873 for ipp-outgoing; Wed, 11 Mar 1998 13:46:21 -0500 (EST) Message-ID: <3506DB1F.4D905747@underscore.com> Date: Wed, 11 Mar 1998 13:42:39 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Tom Hastings CC: ipp@pwg.org Subject: Re: IPP> NOT - device-to-host events, not end-user events References: <3.0.1.32.19980311093213.010be660@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Tom Hastings wrote: > > In discussing the host-to-device requirements, we came up with a requirement > that the printer be able to feed back information about whether it was > choked up with data or needed more data for the current job. > > So we could have events like: > > Slow down data transfer > Speed up data transfer This doesn't quite sound right. I mean, flow control should be mandated by the underlying transport, right? We certainly don't want to reinvent such a key aspect of end-to-end communications within IPP. ...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 -- ---------------------------------------------------------------------- From ipp-archive Wed Mar 11 14:23:34 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA01614 for ipp-outgoing; Wed, 11 Mar 1998 14:21:29 -0500 (EST) Date: Wed, 11 Mar 1998 11:10:20 -0800 (Pacific Standard Time) From: Ron Bergman To: Jay Martin cc: Tom Hastings , ipp@pwg.org Subject: Re: IPP> NOT - device-to-host events, not end-user events In-Reply-To: <3506DB1F.4D905747@underscore.com> Message-ID: X-X-Sender: rbergma@newmai.dpc.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Tom, I certainly agree with Jay on this subject. I don't know of any transport that does not provide some method of flow control. Certainly TCP provides an excellent flow control mechanism. I don't recall this requirement discussed in any of the meetings in Austin. Where did this come from? Ron Bergman Dataproducts Corp. On Wed, 11 Mar 1998, Jay Martin wrote: > Tom Hastings wrote: > > > > In discussing the host-to-device requirements, we came up with a requirement > > that the printer be able to feed back information about whether it was > > choked up with data or needed more data for the current job. > > > > So we could have events like: > > > > Slow down data transfer > > Speed up data transfer > > This doesn't quite sound right. I mean, flow control should be mandated > by the underlying transport, right? We certainly don't want to reinvent > such a key aspect of end-to-end communications within IPP. > > ...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 -- > ---------------------------------------------------------------------- > From ipp-archive Wed Mar 11 14:58:34 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA02326 for ipp-outgoing; Wed, 11 Mar 1998 14:57:28 -0500 (EST) From: Roger K Debry To: Subject: IPP> Minutes of 3/11/98 telephone conference Message-ID: <5030100018385778000002L082*@MHS> Date: Wed, 11 Mar 1998 14:56:32 -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 Minutes of 3/11 Telephone Conference Attending: Carl-Uno Manros, Tom Hastings, Pete Zahler, Roger deBry, Scott Isaacson, Jay Martin, Ira MacDonald, Randy Turner 1. Carl-Uno said that Don Wright cannot continue as secretary for IPP telephone conference calls. Carl-Uno will find someone to replace Don.= 2. Paul Moore had said he would try to get the requirements document from Microsoft on UDP. He has subsequently said that a formal requirements document does not exist. 3. Randy is working on a proposal for host-to-device. He said he will h= ave a document ready by the end of this week. There was some discussion= whether or not host-to-device was an IETF issue. Carl-Uno wants to = be sure that it is posted as a personl contribution at this point, sin= ce there has been no review by the working group. Randy's document will include: - an abstraction of transport layer - mapping of IPP to TCP/IP - discussion on notifications 4. Don was to provide documentation on TIPSI elements that would apply to a host-to-device protocol. Nothing reported yet. 5. Tom and Scott to work on MIB attributes that would be aappropriate f= or host-to-device protocols. Nothing done to date. 6. Some discussion was held on Randy's recent submission on DHCP option= for IPP. Randy said that it was supposed to have been a personal s= ubmission and not an IPP workgroup submission. Randy said that this was requ= ired for his host-to-device proposal and he wanted it to be on the IETF sta= ndards track. 7. Brief discussion of Pete Zahler's testing work. Pete said that he is= working on getting a printer on the network for testing and is working on upd= ates for the test plan document 8. Discussion of Notification work items - Requirements document has be= en updated and submitted. Scott and Harry have posted presentation ma= terial to the ftp site. Tom asked whether or not anyone had considered d= atagrams for notifications. Ira said that there was some issues with SNMP N= otify. 9. Carl-Uno said that he wants to find a "Champion" for each of the notification and host-to-device work items. He will work on this. 10. Scott is having ongoing discussions with IPP mapping to SLP and dri= ving this with the SLP people. 11. Discussed the need to define a new error code and words to go with = it on printer busy condition. Randy has posted a discussion to the FTP = site and said that he will write up the text for the Model document. 12. Dictionary attributes - Tom and Roger will work on this with the go= al of having a proposal for the enxt PWG meeting. 13. Carl Uno asked if anyone wanted to work with Tom on Document attrib= utes. No one offered. 14. An old homework item was discussed - the registration of mime types= with IANA. No specific action item was taken. 15. There was some discussion of Tom's proposal for early binding of de= fault attributes. The consensus seemd to be that this was not just a s= mall change to the Model document. The possibility of having some vendor(s) = do this as a private extension was discussed. 16. Carl-uno is looking for someone to be the editor of an "Implementor= 's Guide." 17. There was soem discussion on UDP, but no one felt that they unders= tood what follow-on activities were planned. UDP should be a separa= te working group from IPP. 18. Reminder that the next IPP face to face meeting is April 8-9 in Por= tland. 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 Wed Mar 11 16:08:39 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA03174 for ipp-outgoing; Wed, 11 Mar 1998 16:05:00 -0500 (EST) Message-ID: <19980311210445.11550.qmail@hotmail.com> X-Originating-IP: [156.153.255.194] From: "Puru Bish" To: ipp@pwg.org Subject: IPP> Printer state Content-Type: text/plain Date: Wed, 11 Mar 1998 13:04:45 PST Sender: ipp-owner@pwg.org Precedence: bulk I was looking into the different printer states defined in Model document (page: 99 - 100). The document says "The following standard values are defined '3' 'idle' '4' 'processing' '5' 'stopped' .. " I looked at the definition of 'stopped' state, and it says, "If a Printer receives a job (whose required resources are ready) while in this state, such a job SHALL transit into the pending state immediately...." There may be a situation when the actual output device is powered off. In that case, should IPP server respond with a state 'stopped'? If so, does that mean that IPP server still accepts print-job request instead of sending an error like "server-error-internal-error"? IMHO, if an output device is powered off, all IPP print job requests should fail with the above-mentioned server error. Also, the printer should have another state '6' 'no-device' to represent this condition. Any comments/suggestions? PB ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From ipp-archive Wed Mar 11 16:23:38 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA03875 for ipp-outgoing; Wed, 11 Mar 1998 16:21:11 -0500 (EST) Message-ID: <35070017.1D7BDF96@underscore.com> Date: Wed, 11 Mar 1998 16:20:23 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Puru Bish CC: ipp@pwg.org Subject: Re: IPP> Printer state References: <19980311210445.11550.qmail@hotmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk If the IPP server is a *spooling* server (eg, process(es) running on a general host system), then job submissions should not fail if the associated output device is powered off, IHMO. ...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 -- ---------------------------------------------------------------------- Puru Bish wrote: > > I was looking into the different printer states defined in Model > document (page: 99 - 100). The document says > > "The following standard values are defined > '3' 'idle' > '4' 'processing' > '5' 'stopped' .. " > > I looked at the definition of 'stopped' state, and it says, > "If a Printer receives a job (whose required > resources are ready) while in this state, such a job > SHALL transit into the pending state immediately...." > There may be a situation when the actual output device is > powered off. In that case, should IPP server respond with > a state 'stopped'? If so, does that mean that IPP server > still accepts print-job request instead of sending an error like > "server-error-internal-error"? > > IMHO, if an output device is powered off, all IPP print job requests > should fail with the above-mentioned server error. Also, > the printer should have another state > '6' 'no-device' > to represent this condition. > > Any comments/suggestions? > PB > > ______________________________________________________ > Get Your Private, Free Email at http://www.hotmail.com From ipp-archive Wed Mar 11 16:23:39 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA03839 for ipp-outgoing; Wed, 11 Mar 1998 16:20:44 -0500 (EST) Message-Id: <3506FF42.833F0AD9@dazel.com> Date: Wed, 11 Mar 1998 15:16:50 -0600 From: James Walker Reply-To: walker@dazel.com Organization: DAZEL Corporation X-Mailer: Mozilla 4.04 [en] (WinNT; I) Mime-Version: 1.0 To: Harry Lewis Cc: ipp@pwg.org Subject: Re: IPP> Notification content References: <5030300018795096000002L062*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Harry Lewis wrote: > > In Austin, I think we discussed the IPP notification requirement that any > attribute may be requested during registration for a given event. I think the > requirement stems from the notion that notification content should just "mimic" > the response to a query. But this is probably unrealistic. A query/response is > synchronous - during which, the "agent's" job is to gather the requested > information and package the response. With notifications, you pre-register for > asynchronous events. It would be a much greater burden on the agent, whether it > be IPP, SNMP or whatever, to maintain, not only of who wants which > notifications, but also what information they requested with each type of event! IMHO, this is one of those areas where the requirements differ depending upon whether we are talking about a host->device protocol, or the more general client->server protocol. In the case of a host->device protocol, I agree 100%... the host should be able to register for specific event types, where the event associated with each event type has some fixed, standardized content. This is along the lines of what was discussed in the JMP meeting in Austin. However, in the more general client->server case, I think that variable content is an important requirement. Specifically, I think that it is important that the notification be capable of holding enough information such that the client does *not* have to go back and query the server to get what it needs. Seeing as how we cannot mandate what information the client should be interested in, this implies that we should allow the client to specify its interest. Furthermore, if we are to allow vendors to extend IPP, then the only way that clients can get at that extended information in a notification is if we allow the client to ask for what it wants. one man's opinion... ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX From ipp-archive Wed Mar 11 16:33:59 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA05083 for ipp-outgoing; Wed, 11 Mar 1998 16:30:42 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: FW: IPP> NOT - device-to-host events, not end-user events Date: Wed, 11 Mar 1998 13:30:35 -0800 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 -----Original Message----- From: Turner, Randy Sent: Wednesday, March 11, 1998 1:30 PM To: 'Jay Martin' Subject: RE: IPP> NOT - device-to-host events, not end-user events I agree with Jay completely. It would be very difficult for me to agree any more on this....but I'll try. ;) Randy. -----Original Message----- From: Jay Martin [SMTP:jkm@underscore.com] Sent: Wednesday, March 11, 1998 10:43 AM To: Tom Hastings Cc: ipp@pwg.org Subject: Re: IPP> NOT - device-to-host events, not end-user events Tom Hastings wrote: > > In discussing the host-to-device requirements, we came up with a requirement > that the printer be able to feed back information about whether it was > choked up with data or needed more data for the current job. > > So we could have events like: > > Slow down data transfer > Speed up data transfer This doesn't quite sound right. I mean, flow control should be mandated by the underlying transport, right? We certainly don't want to reinvent such a key aspect of end-to-end communications within IPP. ...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 -- ---------------------------------------------------------------------- From ipp-archive Wed Mar 11 16:43:36 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA05749 for ipp-outgoing; Wed, 11 Mar 1998 16:43:05 -0500 (EST) Message-ID: <35070456.F1D6BC37@xionics.com> Date: Wed, 11 Mar 1998 16:38:30 -0500 From: Adrian Hall Organization: Xionics Document Technologies, Inc. X-Mailer: Mozilla 4.04 [en] (WinNT; U) MIME-Version: 1.0 To: Jay Martin CC: Puru Bish , ipp@pwg.org Subject: Re: IPP> Printer state References: <19980311210445.11550.qmail@hotmail.com> <35070017.1D7BDF96@underscore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk This would depend. I can certainly see a couple of scenarios: 1. The Printer turned off is a part of a pool of printers - the server should continue spooling and simply use one of the other printers in the pool. 2. The user wants the print-out semi-immediately - in which case some sort of notification that the printer is turned off. Both are valid for the same condition. -- Adrian Hall Sr. Software Developer Xionics Document Technologies, Inc. Jay Martin wrote: > > If the IPP server is a *spooling* server (eg, process(es) running > on a general host system), then job submissions should not fail > if the associated output device is powered off, IHMO. > > ...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 -- > ---------------------------------------------------------------------- > > Puru Bish wrote: > > > > I was looking into the different printer states defined in Model > > document (page: 99 - 100). The document says > > > > "The following standard values are defined > > '3' 'idle' > > '4' 'processing' > > '5' 'stopped' .. " > > > > I looked at the definition of 'stopped' state, and it says, > > "If a Printer receives a job (whose required > > resources are ready) while in this state, such a job > > SHALL transit into the pending state immediately...." > > There may be a situation when the actual output device is > > powered off. In that case, should IPP server respond with > > a state 'stopped'? If so, does that mean that IPP server > > still accepts print-job request instead of sending an error like > > "server-error-internal-error"? > > > > IMHO, if an output device is powered off, all IPP print job requests > > should fail with the above-mentioned server error. Also, > > the printer should have another state > > '6' 'no-device' > > to represent this condition. > > > > Any comments/suggestions? > > PB > > > > ______________________________________________________ > > Get Your Private, Free Email at http://www.hotmail.com From ipp-archive Wed Mar 11 16:58:36 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA06411 for ipp-outgoing; Wed, 11 Mar 1998 16:58:20 -0500 (EST) Message-ID: <350708E2.6ECE3659@underscore.com> Date: Wed, 11 Mar 1998 16:57:55 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Adrian Hall CC: Puru Bish , ipp@pwg.org Subject: Re: IPP> Printer state References: <19980311210445.11550.qmail@hotmail.com> <35070017.1D7BDF96@underscore.com> <35070456.F1D6BC37@xionics.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Yes, of course, the user should see some sort of "device problem" when a job is spooled but the device is powered off. The point I was making was that the job submission itself should not fail. ...jay Adrian Hall wrote: > > This would depend. I can certainly see a couple of scenarios: > > 1. The Printer turned off is a part of a pool of > printers - the server should continue spooling > and simply use one of the other printers in > the pool. > > 2. The user wants the print-out semi-immediately - > in which case some sort of notification that > the printer is turned off. > > Both are valid for the same condition. > > -- > Adrian Hall > Sr. Software Developer > Xionics Document Technologies, Inc. > > Jay Martin wrote: > > > > If the IPP server is a *spooling* server (eg, process(es) running > > on a general host system), then job submissions should not fail > > if the associated output device is powered off, IHMO. > > > > ...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 -- > > ---------------------------------------------------------------------- > > > > Puru Bish wrote: > > > > > > I was looking into the different printer states defined in Model > > > document (page: 99 - 100). The document says > > > > > > "The following standard values are defined > > > '3' 'idle' > > > '4' 'processing' > > > '5' 'stopped' .. " > > > > > > I looked at the definition of 'stopped' state, and it says, > > > "If a Printer receives a job (whose required > > > resources are ready) while in this state, such a job > > > SHALL transit into the pending state immediately...." > > > There may be a situation when the actual output device is > > > powered off. In that case, should IPP server respond with > > > a state 'stopped'? If so, does that mean that IPP server > > > still accepts print-job request instead of sending an error like > > > "server-error-internal-error"? > > > > > > IMHO, if an output device is powered off, all IPP print job requests > > > should fail with the above-mentioned server error. Also, > > > the printer should have another state > > > '6' 'no-device' > > > to represent this condition. > > > > > > Any comments/suggestions? > > > PB > > > > > > ______________________________________________________ > > > Get Your Private, Free Email at http://www.hotmail.com From ipp-archive Wed Mar 11 17:23:37 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA07104 for ipp-outgoing; Wed, 11 Mar 1998 17:22:25 -0500 (EST) Message-Id: <35070DC4.42DDF332@dazel.com> Date: Wed, 11 Mar 1998 16:18:44 -0600 From: James Walker Reply-To: walker@dazel.com Organization: DAZEL Corporation X-Mailer: Mozilla 4.04 [en] (WinNT; I) Mime-Version: 1.0 To: Tom Hastings Cc: ipp@pwg.org Subject: Re: IPP> NOT - device-to-host events, not end-user events References: <3.0.1.32.19980311093213.010be660@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Tom Hastings wrote: > > In discussing the host-to-device requirements, we came up with a requirement > that the printer be able to feed back information about whether it was > choked up with data or needed more data for the current job. > > So we could have events like: > > Slow down data transfer > Speed up data transfer I agree with others comments regarding these events... I think that is an issue for the underlying transport. However... > There is an even more important event for a device to send to a host: > > Ready for another job I think that this could/would be a very useful event. As Tom pointed out, it is another case of something that is more appropriate for the host->device protocol than it is for a client application (I know that I am probably starting to sound like a broken record, but I think that it is important to point out these differences, as there are some who believe that there are none). The one point that I would add about a "ready for job" event is that, unless we make notifications absolutely reliable (very unlikely), an application could not rely on just this event to know that a printer was ready to accept another job. In that case, we would also want to model this piece of information as an attribute (or some sort of state value) for the printer. That way, if the server application missed the "ready for job" event, it would still be able to pick up this information by polling the printer object. ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX From ipp-archive Wed Mar 11 20:23:40 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA07946 for ipp-outgoing; Wed, 11 Mar 1998 20:22:35 -0500 (EST) Message-Id: <3.0.1.32.19980311172044.011668d0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 11 Mar 1998 17:20:44 PST To: Paul Moore , Ron Bergman , Jay Martin From: Tom Hastings Subject: Re: IPP> NOT - device-to-host events, not end-user events Cc: ipp@pwg.org In-Reply-To: References: <3506DB1F.4D905747@underscore.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk At 11:10 03/11/1998 PST, Ron Bergman wrote: >Tom, > >I certainly agree with Jay on this subject. I don't know of any transport >that does not provide some method of flow control. Certainly TCP provides >an excellent flow control mechanism. > >I don't recall this requirement discussed in any of the meetings in >Austin. Where did this come from? Paul Moore suggested this. It is NOT flow control but rather advisory to a host that is controlling a large number of devices at once. Paul says he has NT systems that control a large number of devices, like 500, so that knowing which devices the host is getting ahead and which devices the host is falling behind in getting PDL data to the device would be useful. My understanding of what Paul was saying was that the host would then increase the priority of the threads that were getting behind and lower the priority of the threads that were getting ahead. Or does TCP/IP have such advisory events (as opposed to stop sending and start sending)? Tom > > > Ron Bergman > Dataproducts Corp. > > >On Wed, 11 Mar 1998, Jay Martin wrote: > >> Tom Hastings wrote: >> > >> > In discussing the host-to-device requirements, we came up with a requirement >> > that the printer be able to feed back information about whether it was >> > choked up with data or needed more data for the current job. >> > >> > So we could have events like: >> > >> > Slow down data transfer >> > Speed up data transfer >> >> This doesn't quite sound right. I mean, flow control should be mandated >> by the underlying transport, right? We certainly don't want to reinvent >> such a key aspect of end-to-end communications within IPP. >> >> ...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 -- >> ---------------------------------------------------------------------- >> > > > From ipp-archive Wed Mar 11 20:58:40 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA08573 for ipp-outgoing; Wed, 11 Mar 1998 20:56:46 -0500 (EST) Message-Id: <3.0.1.32.19980311175501.011816e0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 11 Mar 1998 17:55:01 PST To: Jay Martin , Adrian Hall From: Tom Hastings Subject: Re: IPP> Printer state Cc: Puru Bish , ipp@pwg.org In-Reply-To: <350708E2.6ECE3659@underscore.com> References: <19980311210445.11550.qmail@hotmail.com> <35070017.1D7BDF96@underscore.com> <35070456.F1D6BC37@xionics.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Yes, the Printer object implemented in a server object does accept the job even though the device is powered down. And the requester MAY get an indication that there is a problem, because the job's OPTIONAL "job-state-reason" attribute that MAY be returned in the Print-Job response containing the value: 'printer-stopped' (or 'printer-stopped-partly' in the case that only some of the fan-out printers are stopped). Unfortunately, the requeseter will NOT get this indication in the response, if the IPP Printer object does not implement the OPTIONAL "job-state-reasons" attribute. The client can then query the Printer's "printer-state" and "printer-state-reasons" attribute and see that the "printer-state" is 'stopped' and the "printer-state-reasons" is 'error-shutdown' ('warning-shutdown' if only some of the fan-out printers are shutdown). The explanation of the 'stopped' state on page 89 of the Model document says (in its entirity of two paragraphs): '5' 'stopped': If a Printer receives a job (whose required resources are ready) while in this state, such a job SHALL transit into the pending state immediately. Such a job SHALL transit into the processing state only after some human fixes the problem that stopped the printer and after jobs ahead of it complete printing. The "printer-state-reasons" attribute SHALL contain at least one reason, e.g. media-jam, which prevents it from either processing the current job or transitioning a pending job to the processing state. Note: if a Printer controls more than one output device, the above definition implies that a Printer is stopped only if all output devices are stopped. Also, it is tempting to define stopped as when a sufficient number of output devices are stopped and leave it to an implementation to define the sufficient number. But such a rule complicates the definition of stopped and processing. For example, with this alternate definition of stopped, a job can move from idle to processing without human intervention, even though the Printer is stopped. Does the Model document need any futher clarification? Tom At 13:57 03/11/1998 PST, Jay Martin wrote: >Yes, of course, the user should see some sort of "device problem" >when a job is spooled but the device is powered off. The point >I was making was that the job submission itself should not fail. > > ...jay > > >Adrian Hall wrote: >> >> This would depend. I can certainly see a couple of scenarios: >> >> 1. The Printer turned off is a part of a pool of >> printers - the server should continue spooling >> and simply use one of the other printers in >> the pool. >> >> 2. The user wants the print-out semi-immediately - >> in which case some sort of notification that >> the printer is turned off. >> >> Both are valid for the same condition. >> >> -- >> Adrian Hall >> Sr. Software Developer >> Xionics Document Technologies, Inc. >> >> Jay Martin wrote: >> > >> > If the IPP server is a *spooling* server (eg, process(es) running >> > on a general host system), then job submissions should not fail >> > if the associated output device is powered off, IHMO. >> > >> > ...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 -- >> > ---------------------------------------------------------------------- >> > >> > Puru Bish wrote: >> > > >> > > I was looking into the different printer states defined in Model >> > > document (page: 99 - 100). The document says >> > > >> > > "The following standard values are defined >> > > '3' 'idle' >> > > '4' 'processing' >> > > '5' 'stopped' .. " >> > > >> > > I looked at the definition of 'stopped' state, and it says, >> > > "If a Printer receives a job (whose required >> > > resources are ready) while in this state, such a job >> > > SHALL transit into the pending state immediately...." >> > > There may be a situation when the actual output device is >> > > powered off. In that case, should IPP server respond with >> > > a state 'stopped'? If so, does that mean that IPP server >> > > still accepts print-job request instead of sending an error like >> > > "server-error-internal-error"? >> > > >> > > IMHO, if an output device is powered off, all IPP print job requests >> > > should fail with the above-mentioned server error. Also, >> > > the printer should have another state >> > > '6' 'no-device' >> > > to represent this condition. >> > > >> > > Any comments/suggestions? >> > > PB >> > > >> > > ______________________________________________________ >> > > Get Your Private, Free Email at http://www.hotmail.com > > From ipp-archive Thu Mar 12 10:19:14 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA20033 for ipp-outgoing; Thu, 12 Mar 1998 10:15:07 -0500 (EST) Message-Id: <199803121514.KAA16847@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipp@pwg.org From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: IPP> I-D ACTION:draft-ietf-ipp-not-01.txt Date: Thu, 12 Mar 1998 10:14:13 -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 : Requirements for IPP Notifications Author(s) : R. deBry Filename : draft-ietf-ipp-not-01.txt Pages : 8 Date : 11-Mar-98 This document is one of a set of documents which together describe all aspects of a new Internet Printing Protocol (IPP). Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipp-not-01.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-not-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@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipp-not-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980312095213.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-not-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-not-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980312095213.I-D@ietf.org> --OtherAccess-- --NextPart-- From ipp-archive Thu Mar 12 11:08:50 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA20677 for ipp-outgoing; Thu, 12 Mar 1998 11:07:04 -0500 (EST) Message-ID: <3508072E.5928096C@underscore.com> Date: Thu, 12 Mar 1998 11:02:54 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Tom Hastings CC: Paul Moore , Ron Bergman , ipp@pwg.org Subject: Re: IPP> NOT - device-to-host events, not end-user events References: <3506DB1F.4D905747@underscore.com> <3.0.1.32.19980311172044.011668d0@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Tom, No, most (all?) TCP stack implementations do not expose data throttling events to the client. (That is one of the several "transparent" things the stream-like TCP design gives the client.) While it wouldn't be trivial, I suppose a client app could make some thread priority adjustments based on detecting a "blocked" outbound stream. That is, upon trying to send a buffer, the client would reduce the thread priority if the API write function returned the (UNIX) equivalent of EWOULDBLOCK (assuming the socket was setup for non-blocking I/O support). While I understand Paul Moore's situation, I still don't think it's a good idea to introduce this kind of communications status in an application-level protocol such as IPP. Does anyone disagree? ...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 -- ---------------------------------------------------------------------- Tom Hastings wrote: > > At 11:10 03/11/1998 PST, Ron Bergman wrote: > >Tom, > > > >I certainly agree with Jay on this subject. I don't know of any transport > >that does not provide some method of flow control. Certainly TCP provides > >an excellent flow control mechanism. > > > >I don't recall this requirement discussed in any of the meetings in > >Austin. Where did this come from? > > Paul Moore suggested this. It is NOT flow control but rather > advisory to a host that is controlling a large number of devices > at once. Paul says he has NT systems that control a large number of > devices, like 500, so that knowing which devices the host is getting > ahead and which devices the host is falling behind in getting PDL data > to the device would be useful. My understanding of what Paul was saying > was that the host would then increase the priority of the threads that > were getting behind and lower the priority of the threads that were > getting ahead. > > Or does TCP/IP have such advisory events (as opposed to stop sending > and start sending)? > > Tom > > > > > > > Ron Bergman > > Dataproducts Corp. > > > > > >On Wed, 11 Mar 1998, Jay Martin wrote: > > > >> Tom Hastings wrote: > >> > > >> > In discussing the host-to-device requirements, we came up with a > requirement > >> > that the printer be able to feed back information about whether it was > >> > choked up with data or needed more data for the current job. > >> > > >> > So we could have events like: > >> > > >> > Slow down data transfer > >> > Speed up data transfer > >> > >> This doesn't quite sound right. I mean, flow control should be mandated > >> by the underlying transport, right? We certainly don't want to reinvent > >> such a key aspect of end-to-end communications within IPP. > >> > >> ...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 -- > >> ---------------------------------------------------------------------- > >> > > > > > > From ipp-archive Thu Mar 12 12:03:50 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA21334 for ipp-outgoing; Thu, 12 Mar 1998 12:02:43 -0500 (EST) Message-ID: <3508151F.1AD453D2@underscore.com> Date: Thu, 12 Mar 1998 12:02:23 -0500 From: Jeff Schnitzer Reply-To: Roger K Debry Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: Re: IPP> NOT - device-to-host events, not end-user events Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk [Roger accidentally sent this to ipp-owner rather than ipp@pwg.org] Subject: Re: IPP> NOT - device-to-host events, not end-user events Date: Thu, 12 Mar 1998 11:52:23 -0500 From: Roger K Debry To: In IPDS we defined some data stream level constructs to return information about the state of the printer. However, we do not use these for flow control, which should be handled by the transport. However, we find these data stream constructs *VERY* useful in resynchronizing the printer with the server in the case of some error conditions. Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 > ipp-owner@pwg.org on 03/12/98 09:09:05 AM > To: hastings@cp10.es.xerox.com @ internet > cc: ipp@pwg.org @ internet, rbergma@dpc.com @ internet, paulmo@microsoft.com @internet > Subject: Re: IPP> NOT - device-to-host events, not end-user events > > > Tom, > > No, most (all?) TCP stack implementations do not expose > data throttling events to the client. (That is one of > the several "transparent" things the stream-like TCP > design gives the client.) > > While it wouldn't be trivial, I suppose a client app could > make some thread priority adjustments based on detecting a > "blocked" outbound stream. That is, upon trying to send a > buffer, the client would reduce the thread priority if the > API write function returned the (UNIX) equivalent of EWOULDBLOCK > (assuming the socket was setup for non-blocking I/O support). > > While I understand Paul Moore's situation, I still don't think > it's a good idea to introduce this kind of communications > status in an application-level protocol such as IPP. > > Does anyone disagree? > > ...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 -- > ---------------------------------------------------------------------- > > > Tom Hastings wrote: > > > > At 11:10 03/11/1998 PST, Ron Bergman wrote: > > >Tom, > > > > > >I certainly agree with Jay on this subject. I don't know of any transport > > >that does not provide some method of flow control. Certainly TCP provides > > >an excellent flow control mechanism. > > > > > >I don't recall this requirement discussed in any of the meetings in > > >Austin. Where did this come from? > > > > Paul Moore suggested this. It is NOT flow control but rather > > advisory to a host that is controlling a large number of devices > > at once. Paul says he has NT systems that control a large number of > > devices, like 500, so that knowing which devices the host is getting > > ahead and which devices the host is falling behind in getting PDL data > > to the device would be useful. My understanding of what Paul was saying > > was that the host would then increase the priority of the threads that > > were getting behind and lower the priority of the threads that were > > getting ahead. > > > > Or does TCP/IP have such advisory events (as opposed to stop sending > > and start sending)? > > > > Tom > > > > > > > > > > > Ron Bergman > > > Dataproducts Corp. > > > > > > > > >On Wed, 11 Mar 1998, Jay Martin wrote: > > > > > >> Tom Hastings wrote: > > >> > > > >> > In discussing the host-to-device requirements, we came up with a > > requirement > > >> > that the printer be able to feed back information about whether it was > > >> > choked up with data or needed more data for the current job. > > >> > > > >> > So we could have events like: > > >> > > > >> > Slow down data transfer > > >> > Speed up data transfer > > >> > > >> This doesn't quite sound right. I mean, flow control should be mandated > > >> by the underlying transport, right? We certainly don't want to reinvent > > >> such a key aspect of end-to-end communications within IPP. > > >> > > >> ...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 -- > > >> ---------------------------------------------------------------------- From ipp-archive Thu Mar 12 13:38:55 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA22088 for ipp-outgoing; Thu, 12 Mar 1998 13:34:11 -0500 (EST) Message-Id: <3.0.1.32.19980312092715.009b7120@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 12 Mar 1998 09:27:15 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> I-D ACTION:draft-palme-int-print-03.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk FYI, This I-D gives you explicit advice on how to format documents for international distribution. I actually applied these rules for many years working in ITU and ISO, but now they have also been documented! Carl-Uno >To: IETF-Announce:; >From: Internet-Drafts@ns.ietf.org >Reply-to: Internet-Drafts@ns.ietf.org >Subject: I-D ACTION:draft-palme-int-print-03.txt >Date: Thu, 12 Mar 1998 06:47:16 PST >Sender: cclark@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Making Postscript and PDF International > Author(s) : J. Palme > Filename : draft-palme-int-print-03.txt > Pages : 3 > Date : 11-Mar-98 > >Certain text formats, for example Postscript (MIME-Type: >application/postscript; file extension .ps) and Portable Document Format >(MIME-Type: application/pdf; file extension .pdf) specify exactly the >page layout of the printed document. The commonly used paper format is >different in North America and the rest of the world. North America uses >the 'Letter' format, while the rest of the world mostly uses the ISO- >standard 'A4' format. This means that documents formatted on one >continent may not be easily printable on another continent. This memo >gives advice on how to produce documents which are equally well >printable with the Letter and the A4 formats. By using the advice in >this document, you can put up a document on the Internet, which >recipients can print without problem both in and outside North America. > >A very short summary of the advice in this document: If you are using >U.S. Letter paper format, ensure that both the left and right margins >are at least 21 mm (0.8 in). If you are using A4 paper format, ensure >that both the top and bottom margins are at least 33 mm (1.3 in). > >Internet-Drafts are available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-palme-int-print-03.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-palme-int-print-03.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@ietf.org. In the body type: > "FILE /internet-drafts/draft-palme-int-print-03.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > > 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 Mar 12 13:43:53 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA22728 for ipp-outgoing; Thu, 12 Mar 1998 13:42:28 -0500 (EST) Message-ID: <35082C8A.6C6C8CCA@underscore.com> Date: Thu, 12 Mar 1998 13:42:18 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: IPP Mailing List Subject: IPP> New I-D for expressing "feature sets" Content-Type: multipart/mixed; boundary="------------50CC26D163E528D22DA6E8BB" Sender: ipp-owner@pwg.org Precedence: bulk This is a multi-part message in MIME format. --------------50CC26D163E528D22DA6E8BB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Negotiating capabilities/features is a pretty common thing in client/server protocols, including IPP. I'm forwarding this in case anyone is interested. ...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 -- ---------------------------------------------------------------------- --------------50CC26D163E528D22DA6E8BB Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from ns.ietf.org (ietf.org [132.151.1.19]) by uscore.underscore.com (8.8.4/8.7.2) with ESMTP id NAA07735 for ; Thu, 12 Mar 1998 13:28:57 -0500 (EST) Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id MAA22990 for ietf-123-outbound.05@ietf.org; Thu, 12 Mar 1998 12:55:01 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA15763; Thu, 12 Mar 1998 09:48:30 -0500 (EST) Message-Id: <199803121448.JAA15763@ns.ietf.org> Mime-Version: 1.0 To: IETF-Announce: ; Cc: ietf-medfree@imc.org From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-conneg-feature-algebra-00.txt Date: Thu, 12 Mar 1998 09:48:29 -0500 Sender: cclark@cnri.reston.va.us Content-Type: Multipart/Mixed; Boundary="NextPart" --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Content Negotiation Working Group of the IETF. Title : An algebra for describing media feature sets Author(s) : G. Klyne Filename : draft-ietf-conneg-feature-algebra-00.txt Pages : 16 Date : 11-Mar-98 A number of Internet application protocols have a need to provide content negotiation for the resources with which they interact [1]. A framework for such negotiation is described in [2]. Part of this framework is a way to describe the range of media features which can be handled by the sender, recipient or document transmission format of a message. A format for a vocabulary of individual media features and procedures for registering media features are presented in [3]. This document describes an algebra which can be used to define feature sets which are formed from combinations and relations involving individual media features. Such feature sets are used to describe the media feature handling capabilities of message senders, recipients and file formats. This document does not set out to specify a syntax for defining feature sets. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-conneg-feature-algebra-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-conneg-feature-algebra-00.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@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-conneg-feature-algebra-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980311152104.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-conneg-feature-algebra-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-conneg-feature-algebra-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980311152104.I-D@ietf.org> --OtherAccess-- --NextPart-- --------------50CC26D163E528D22DA6E8BB-- From ipp-archive Thu Mar 12 14:48:51 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA23556 for ipp-outgoing; Thu, 12 Mar 1998 14:48:31 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: IPP> Status code question Date: Thu, 12 Mar 1998 11:48:25 -0800 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 I am reevaluating the validity and placement of some of our status codes, in preparation for the addition of contention status codes into the model document. I was just curious about the "success" status code (0x0000) and what it means as a response to a PRINT-JOB request. Does it mean that the job data has been successfully delivered to the device, or does it mean the job has completed printing successfully? And if the answer is "Well, it depends upon the implementation...", then I think we may have a problem with this operation. Randy From ipp-archive Thu Mar 12 15:08:57 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA24211 for ipp-outgoing; Thu, 12 Mar 1998 15:05:25 -0500 (EST) Message-ID: <19980312200457.1307.qmail@hotmail.com> X-Originating-IP: [156.153.255.194] From: "Puru Bish" To: hastings@cp10.es.xerox.com Cc: ipp@pwg.org Subject: IPP> Re: IPP- Printer state Content-Type: text/plain Date: Thu, 12 Mar 1998 12:04:57 PST Sender: ipp-owner@pwg.org Precedence: bulk Thanks, Tom for clarifying the issue. I still have a question - should an IPP server behave the same way even when it does not spool any job? -PB >From hastings@cp10.es.xerox.com Wed Mar 11 17:57:09 1998 >Yes, the Printer object implemented in a server object does accept the >job even though the device is powered down. > >And the requester MAY get an indication that there is a problem, because >the job's OPTIONAL "job-state-reason" attribute that MAY be returned in the >Print-Job response containing the value: 'printer-stopped' >(or 'printer-stopped-partly' in the case that only some of the fan-out >printers are stopped). Unfortunately, the requeseter will NOT get this >indication in the response, if the IPP Printer object does not implement >the OPTIONAL "job-state-reasons" attribute. > >The client can then query the Printer's "printer-state" >and "printer-state-reasons" attribute and see that the "printer-state" >is 'stopped' and the "printer-state-reasons" is 'error-shutdown' >('warning-shutdown' if only some of the fan-out printers are shutdown). > > >The explanation of the 'stopped' state on page 89 of the Model document >says (in its entirity of two paragraphs): > >'5' 'stopped': If a Printer receives a job (whose required resources are >ready) while in this state, such a job SHALL transit into the pending state >immediately. Such a job SHALL transit into the processing state only after >some human fixes the problem that stopped the printer and after jobs ahead >of it complete printing. The "printer-state-reasons" attribute SHALL >contain at least one reason, e.g. media-jam, which prevents it from either >processing the current job or transitioning a pending job to the processing >state. > >Note: if a Printer controls more than one output device, the above >definition implies that a Printer is stopped only if all output devices are >stopped. Also, it is tempting to define stopped as when a sufficient >number of output devices are stopped and leave it to an implementation to >define the sufficient number. But such a rule complicates the definition >of stopped and processing. For example, with this alternate definition of >stopped, a job can move from idle to processing without human intervention, >even though the Printer is stopped. > > > >Does the Model document need any futher clarification? > >Tom ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From ipp-archive Thu Mar 12 16:43:57 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA25135 for ipp-outgoing; Thu, 12 Mar 1998 16:39:35 -0500 (EST) From: Carl Kugler To: Subject: Re: IPP> Status code question Message-ID: <5030100018438424000002L042*@MHS> Date: Thu, 12 Mar 1998 16:38:52 -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 > Does it > mean that the job data has been successfully delivered to the device,= or > does it mean the job has completed printing successfully? Neither. My understanding of sections 3.1.7, "Job Creation Operations"= and 15.4.8, "Return one of the success status codes", is that the sucess co= de is returned after the Job has been created and the request accepted, but (possibly) before the appended Document Content has been accepted. If you want to find out if the job completed printing successfully, you= have to poll, and hope that the Printer remembers a completed job for a time lo= nger than your polling interval. -Carl ipp-owner@pwg.org on 03/12/98 12:51:03 PM Please respond to ipp-owner@pwg.org @ internet To: ipp@pwg.org @ internet cc: Subject: IPP> Status code question I am reevaluating the validity and placement of some of our status codes, in preparation for the addition of contention status codes into the model document. I was just curious about the "success" status code (0x0000) and what it means as a response to a PRINT-JOB request. Does i= t mean that the job data has been successfully delivered to the device, o= r does it mean the job has completed printing successfully? And if the answer is "Well, it depends upon the implementation...", then I think w= e may have a problem with this operation. Randy = From ipp-archive Thu Mar 12 16:49:10 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA25764 for ipp-outgoing; Thu, 12 Mar 1998 16:46:57 -0500 (EST) From: Roger K Debry To: Subject: Re: IPP> Status code question Message-ID: <5030100018438734000002L042*@MHS> Date: Thu, 12 Mar 1998 16:46:07 -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 thought Randy's question was specific to Print-Job, in which case I believe a response means the job was successfully created AND received. Roger K deBry Senior Technical Staff Member Architecture and Technology IBM Printing Systems email: rdebry@us.ibm.com phone: 1-303-924-4080 ipp-owner@pwg.org on 03/12/98 02:41:23 PM Please respond to ipp-owner@pwg.org @ internet To: ipp@pwg.org @ internet cc: Subject: Re: IPP> Status code question > Does it > mean that the job data has been successfully delivered to the device,= or > does it mean the job has completed printing successfully? Neither. My understanding of sections 3.1.7, "Job Creation Operations"= and 15.4.8, "Return one of the success status codes", is that the sucess co= de is returned after the Job has been created and the request accepted, but (possibly) before the appended Document Content has been accepted. If you want to find out if the job completed printing successfully, you= have to poll, and hope that the Printer remembers a completed job for a time lo= nger than your polling interval. -Carl ipp-owner@pwg.org on 03/12/98 12:51:03 PM Please respond to ipp-owner@pwg.org @ internet To: ipp@pwg.org @ internet cc: Subject: IPP> Status code question I am reevaluating the validity and placement of some of our status codes, in preparation for the addition of contention status codes into the model document. I was just curious about the "success" status code (0x0000) and what it means as a response to a PRINT-JOB request. Does i= t mean that the job data has been successfully delivered to the device, o= r does it mean the job has completed printing successfully? And if the answer is "Well, it depends upon the implementation...", then I think w= e may have a problem with this operation. Randy = From ipp-archive Thu Mar 12 18:38:57 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA26734 for ipp-outgoing; Thu, 12 Mar 1998 18:36:36 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: IPP> IPP document set - naming convention(s) Date: Thu, 12 Mar 1998 15:36:21 -0800 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 Would anyone have any problem(s) splitting the protocol (not model) document into two documents? Document 1 would be an encoding document Document 2 would describe how to transport the encoding over HTTP 1.1 ? Randy From ipp-archive Thu Mar 12 18:53:56 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA27387 for ipp-outgoing; Thu, 12 Mar 1998 18:49:03 -0500 (EST) Message-Id: <3.0.1.32.19980312154344.00cadd40@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 12 Mar 1998 15:43:44 PST To: "Turner, Randy" , "'ipp@pwg.org'" From: Carl-Uno Manros Subject: Re: IPP> IPP document set - naming convention(s) In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk At 03:36 PM 3/12/98 PST, Turner, Randy wrote: > >Would anyone have any problem(s) splitting the protocol (not model) >document into two documents? > >Document 1 would be an encoding document >Document 2 would describe how to transport the encoding over HTTP 1.1 > >? > >Randy > Why are we getting all these "bright" ideas after the work is supposed to be finished? I don't know if we can do the split at this stage. I expect that we could try to negotiate that with the RFC editor, but it would mean actually doing another editing run and insert new cross-references etc. It would also impact references in all the other 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 Thu Mar 12 19:04:02 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA28010 for ipp-outgoing; Thu, 12 Mar 1998 18:59:55 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: RE: IPP> IPP document set - naming convention(s) Date: Thu, 12 Mar 1998 15:58:06 -0800 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 This wouldn't be changing any technical specs or semantics...just an editorial move to isolate functionality. This type of change would make it easier to address transport issues without affecting the status or advancement of an encoding specification; and vice-versa. It would also make it clearer for future IPP-related documents to reference particular aspects of IPP, without bringing any additional baggage to have to sort through. Randy -----Original Message----- From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] Sent: Thursday, March 12, 1998 3:44 PM To: Turner, Randy; 'ipp@pwg.org' Subject: Re: IPP> IPP document set - naming convention(s) At 03:36 PM 3/12/98 PST, Turner, Randy wrote: > >Would anyone have any problem(s) splitting the protocol (not model) >document into two documents? > >Document 1 would be an encoding document >Document 2 would describe how to transport the encoding over HTTP 1.1 > >? > >Randy > Why are we getting all these "bright" ideas after the work is supposed to be finished? I don't know if we can do the split at this stage. I expect that we could try to negotiate that with the RFC editor, but it would mean actually doing another editing run and insert new cross-references etc. It would also impact references in all the other 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 Thu Mar 12 19:28:57 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA28706 for ipp-outgoing; Thu, 12 Mar 1998 19:28:00 -0500 (EST) Message-ID: <35087D7F.95C97B5C@underscore.com> Date: Thu, 12 Mar 1998 19:27:43 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: "Turner, Randy" CC: "'ipp@pwg.org'" Subject: Re: IPP> IPP document set - naming convention(s) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk If the notion of "IPP-over-anything-other-than-HTTP" is ever going to be proven, then splitting the doc into two components is a great idea. ...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 -- ---------------------------------------------------------------------- Turner, Randy wrote: > > This wouldn't be changing any technical specs or semantics...just an > editorial move to isolate functionality. This type of change would make > it easier to address transport issues without affecting the status or > advancement of an encoding specification; and vice-versa. It would also > make it clearer for future IPP-related documents to reference particular > aspects of IPP, without bringing any additional baggage to have to sort > through. > > Randy > > -----Original Message----- > From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] > Sent: Thursday, March 12, 1998 3:44 PM > To: Turner, Randy; 'ipp@pwg.org' > Subject: Re: IPP> IPP document set - naming convention(s) > > At 03:36 PM 3/12/98 PST, Turner, Randy wrote: > > > >Would anyone have any problem(s) splitting the protocol (not > model) > >document into two documents? > > > >Document 1 would be an encoding document > >Document 2 would describe how to transport the encoding over > HTTP 1.1 > > > >? > > > >Randy > > > > Why are we getting all these "bright" ideas after the work is > supposed to > be finished? I don't know if we can do the split at this stage. > > I expect that we could try to negotiate that with the RFC > editor, but it > would mean actually doing another editing run and insert new > cross-references etc. It would also impact references in all the > other > 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 Thu Mar 12 19:38:58 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA29351 for ipp-outgoing; Thu, 12 Mar 1998 19:38:28 -0500 (EST) Date: Thu, 12 Mar 1998 16:43:59 PST From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9803130043.AA11671@snorkel.eso.mc.xerox.com> To: ipp@pwg.org, rturner@sharplabs.com Subject: Re: IPP> Status code question Sender: ipp-owner@pwg.org Precedence: bulk Hi Randy, "success" just means that the job was well-formed and accepted for subsequent printing. It does NOT mean that the job has completed printing successfully. Cheers, - Ira McDonald From ipp-archive Thu Mar 12 19:38:59 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA29328 for ipp-outgoing; Thu, 12 Mar 1998 19:38:17 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: RE: IPP> IPP document set - naming convention(s) Date: Thu, 12 Mar 1998 16:38:15 -0800 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 Yes, this is what I am doing in creating a host-to-device version of IPP, I noticed from a design perspective that its clearer if the encoding and transport are isolated into separate documents. Randy -----Original Message----- From: Jay Martin [SMTP:jkm@underscore.com] Sent: Thursday, March 12, 1998 4:28 PM To: Turner, Randy Cc: 'ipp@pwg.org' Subject: Re: IPP> IPP document set - naming convention(s) If the notion of "IPP-over-anything-other-than-HTTP" is ever going to be proven, then splitting the doc into two components is a great idea. ...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 -- ---------------------------------------------------------------------- Turner, Randy wrote: > > This wouldn't be changing any technical specs or semantics...just an > editorial move to isolate functionality. This type of change would make > it easier to address transport issues without affecting the status or > advancement of an encoding specification; and vice-versa. It would also > make it clearer for future IPP-related documents to reference particular > aspects of IPP, without bringing any additional baggage to have to sort > through. > > Randy > > -----Original Message----- > From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] > Sent: Thursday, March 12, 1998 3:44 PM > To: Turner, Randy; 'ipp@pwg.org' > Subject: Re: IPP> IPP document set - naming convention(s) > > At 03:36 PM 3/12/98 PST, Turner, Randy wrote: > > > >Would anyone have any problem(s) splitting the protocol (not > model) > >document into two documents? > > > >Document 1 would be an encoding document > >Document 2 would describe how to transport the encoding over > HTTP 1.1 > > > >? > > > >Randy > > > > Why are we getting all these "bright" ideas after the work is > supposed to > be finished? I don't know if we can do the split at this stage. > > I expect that we could try to negotiate that with the RFC > editor, but it > would mean actually doing another editing run and insert new > cross-references etc. It would also impact references in all the > other > 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 Thu Mar 12 19:44:07 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA00016 for ipp-outgoing; Thu, 12 Mar 1998 19:43:05 -0500 (EST) Date: Thu, 12 Mar 1998 16:48:34 PST From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9803130048.AA11674@snorkel.eso.mc.xerox.com> To: ipp@pwg.org, rturner@sharplabs.com Subject: Re: IPP> IPP document set - naming convention(s) Sender: ipp-owner@pwg.org Precedence: bulk Hi Randy, Considering splitting the protocol document (recently renamed Protocol Encoding and Transport Mappings) into two documents should definitely be delayed until after our IETF Aread Directors report the results of IESG last call on IPP/1.0. My two cents, - Ira McDonald PS - I think splitting them makes sense, but only if EACH transport mapping (http, tcp, smtp) becomes a separate document. From ipp-archive Thu Mar 12 19:54:02 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA01214 for ipp-outgoing; Thu, 12 Mar 1998 19:51:16 -0500 (EST) Message-Id: <3.0.1.32.19980312164908.011f3980@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 12 Mar 1998 16:49:08 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> PRO - Minor typo in example 9.1, "PrintJob" should be "Print-Job" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk On page 18, the symbolic value in the example in section 9.1 should be changed from "PrintJob" to "Print-Job" to reflect the spelling of operations in the Model and be consistent with the rest of the examples. However, since this symbolic value is not sent on the wire, this typo doesn't affect what is sent of the wire. Tom From ipp-archive Fri Mar 13 01:23:59 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA03839 for ipp-outgoing; Fri, 13 Mar 1998 01:23:37 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: IPP> Minor comments to latest Notification requirements doc Date: Thu, 12 Mar 1998 22:23:35 -0800 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 In Section 3.0, notification requirements are specified. In each subsection, 3.1, 3.2, 3.3, a specific requirement is listed. However in a couple of subsections identify what is NOT a requirement. And another subsection at the same section level as a formal requirement, lists a caveat to the previously numbered requirement. For ease of readability, each subsection 3.x, should list a specific requirement. If there is a caveat or other note to the requirement, then it should appear as another subsection, 3.x.y, of the requirement (i.e., 3.x) to which it is referring. For example, section 3.6 should probably be moved to section 3.1.1. Also, section 3.7 should probably be moved to 3.3.1. It there is a caveat or exception to a particular requirement, then I would like to know about it in the context of what I'm reading at the time. Also, on another item, we've talked about not requiring an event notification sender to verify reception of a particular notification message to a notification recipient. We did this (I guess) to save us the work of having to figure out how to do this. However, I think this idea is fundamentally in conflict with the other requirement that end users can specify reliability and quality-of-service to be attached to a particular notification registration. If the user specified that an event must be delivered to the intended recipient, and emphasizes this point with an associated reliability or QoS parameter, then it is critical that we provide enough information as possible as to the status of the notification delivery. Just my $0.02 Randy From ipp-archive Fri Mar 13 11:24:10 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA15939 for ipp-outgoing; Fri, 13 Mar 1998 11:20:36 -0500 (EST) Message-Id: <1.5.4.32.19980313162222.0067b624@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: Fri, 13 Mar 1998 08:22:22 -0800 To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> Early morning thougthts on features Sender: ipp-owner@pwg.org Precedence: bulk Hi, I ran across a little real life example on how you can turn a defect into a feature: I have my shirts washed by a cleaners which is located in my favorite super market. Now and again I get a shirt back with a little label stating: "We have replaced a button FREE of charge as part of our sevice". I thought this was an excellent little feature until I discovered one day that about one third of all finished shirts in the shop seemed to have such a label. It then dawned on me that apparently their washing machines are eating buttons for beakfeast, lunch and dinner. So instead of getting a lot of complaints about missing buttons, they have just hired a couple of folks that replace the buttons and at the same time turned this into a service - your shirt might actually miss a button when you hand it in. We could take the same attitude to some of our "missing" IPP features, say notifications. Notifications? We have got notifications! You can get notifications any time you want! You do not have to wait around for them to come, you just poll your IPP Printer whenever you want to find out something! This means that you get the notifications at your own convenience, they do not come rushing at your machine uncontrolled, potentially interrupting other important things you are doing etc. It is early in the morning.... Carl-Uno From ipp-archive Fri Mar 13 13:00:03 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA16629 for ipp-outgoing; Fri, 13 Mar 1998 12:55:38 -0500 (EST) Message-Id: <3.0.1.32.19980313095000.00cd55f0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 13 Mar 1998 09:50:00 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> I-D ACTION:draft-ietf-http-v11-spec-rev-03.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk FYI, >To: IETF-Announce:; >Cc: http-wg@cuckoo.hpl.hp.com >From: Internet-Drafts@ns.ietf.org >Reply-to: Internet-Drafts@ns.ietf.org >Subject: I-D ACTION:draft-ietf-http-v11-spec-rev-03.txt >Date: Fri, 13 Mar 1998 05:10:11 PST >Sender: cclark@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the HyperText Transfer Protocol Working Group of the IETF. > > Title : Hypertext Transfer Protocol -- HTTP/1.1 > Author(s) : J. Mogul, T. Berners-Lee, L. Masinter, P. Leach, > R. Fielding, H. Nielsen, J. Gettys > Filename : draft-ietf-http-v11-spec-rev-03.txt > Pages : 156 > Date : 12-Mar-98 > >The Hypertext Transfer Protocol (HTTP) is an application-level protocol >for distributed, collaborative, hypermedia information systems. It is a >generic, stateless, protocol which can be used for many tasks, such as >name servers and distributed object management systems, through >extension of its request methods. A feature of HTTP is the typing and >negotiation of data representation, allowing systems to be built >independently of the data being transferred. > >HTTP has been in use by the World-Wide Web global information initiative >since 1990. This specification defines the protocol referred to as >''HTTP/1.1'', and is an update to RFC2068 [33]. > >At the time of this revision's submission, there were no known outstanding >technical or editorial issues. The HTTP/1.1 issues list, along with >many representations of this specification including Postscript, Microsoft >Word, with and without change bars, with or without gzip compression >can be found at http://www.w3.org/Protocols/HTTP/Issues/. > >Internet-Drafts are available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-http-v11-spec-rev-03.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-http-v11-spec-rev-03.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@ietf.org. In the body type: > "FILE /internet-drafts/draft-ietf-http-v11-spec-rev-03.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > > 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 Mar 13 13:15:07 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA17253 for ipp-outgoing; Fri, 13 Mar 1998 13:10:14 -0500 (EST) Message-Id: <3.0.1.32.19980313100257.00cd39f0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 13 Mar 1998 10:02:57 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> I-D ACTION:draft-ietf-conneg-media-features-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk FYI, Carl-Uno >To: IETF-Announce:; >Cc: ietf-medfree@imc.org >From: Internet-Drafts@ns.ietf.org >Reply-to: Internet-Drafts@ns.ietf.org >Subject: I-D ACTION:draft-ietf-conneg-media-features-00.txt >Date: Fri, 13 Mar 1998 05:23:28 PST >Sender: cclark@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Content Negotiation Working Group of the IETF. > > Title : Media Features for Display, Print, and Fax > Author(s) : L. Masinter, K. Holtman, A. Mutz, D. Wing > Filename : draft-ietf-conneg-media-features-00.txt > Pages : 4 > Date : 12-Mar-98 > >This specification defines some common media features for describing >image resolution, size, color, and image representation methods that >are common to web browsing, printing, and facsimile applications. >These features are registered for use within the framework of [REG]. > >Internet-Drafts are available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-conneg-media-features-00.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-conneg-media-features-00.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@ietf.org. In the body type: > "FILE /internet-drafts/draft-ietf-conneg-media-features-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > > 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 Mar 13 14:21:36 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA17976 for ipp-outgoing; Fri, 13 Mar 1998 14:16:54 -0500 (EST) Message-Id: <3.0.1.32.19980313111043.00beabe0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 13 Mar 1998 11:10:43 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> I-D ACTION:draft-ietf-conneg-feature-reg-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk FYI, Here is yet another one... Carl-Uno >To: IETF-Announce:; >Cc: ietf-medfree@imc.org >From: Internet-Drafts@ns.ietf.org >Reply-to: Internet-Drafts@ns.ietf.org >Subject: I-D ACTION:draft-ietf-conneg-feature-reg-00.txt >Date: Fri, 13 Mar 1998 05:24:01 PST >Sender: cclark@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Content Negotiation Working Group of the IETF. > > Title : Content Feature Tag Registration Procedure > Author(s) : E. Hardie, K. Holtman, A. Mutz > Filename : draft-ietf-conneg-feature-reg-00.txt > Pages : 7 > Date : 12-Mar-98 > > Recent Internet applications, such as the World Wide Web, tie > together a great diversity in data formats, client and server > platforms, and communities. This has created a need for content > feature descriptions and negotiation mechanisms in order to identify > and reconcile the form of information to the capabilities and > preferences of the parties involved. > > Extensible content feature identification and negotiation mechanisms > require a common vocabulary in order to positively identify content > features. A registration process and authority for content features > is defined with the intent of sharing this vocabulary between > communicating parties. In addition, a URI tree is defined to enable > sharing of content feature definitions without registration. > > This document defines a registration procedure which uses the > Internet Assigned Numbers Authority (IANA) as a central registry for > the content feature vocabulary. > >Internet-Drafts are available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-conneg-feature-reg-00.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-conneg-feature-reg-00.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@ietf.org. In the body type: > "FILE /internet-drafts/draft-ietf-conneg-feature-reg-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > > 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 Mar 13 15:09:10 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA18653 for ipp-outgoing; Fri, 13 Mar 1998 15:04:23 -0500 (EST) Message-Id: <199803132002.MAA26526@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 13 Mar 1998 12:05:33 -0800 To: "Turner, Randy" , "'ipp@pwg.org'" From: Robert Herriot Subject: Re: IPP> IPP document set - naming convention(s) In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk I think we had this discussion in Austin as part of Tom's proposal. We decided to change the name of the protocol document. Its new name is “Internet Printing Protocol/1.0: Encoding and Transport”. We decided not to split the two documents. Although the IPP encoding is, in theory, transport independent. In fact, it depends on HTTP chunking. With an alternate transport, we would have to solve the chunking problem. It would be more efficient if the document data were the only part chunked, but that would require a change to the encoding layer. So, at this point, I don't endorse separating the two documents. Bob Herriot At 03:36 PM 3/12/98 , Turner, Randy wrote: > >Would anyone have any problem(s) splitting the protocol (not model) >document into two documents? > >Document 1 would be an encoding document >Document 2 would describe how to transport the encoding over HTTP 1.1 > >? > >Randy > From ipp-archive Fri Mar 13 15:14:13 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA19248 for ipp-outgoing; Fri, 13 Mar 1998 15:11:22 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'Robert Herriot'" Cc: "'ipp@pwg.org'" Subject: RE: IPP> IPP document set - naming convention(s) Date: Fri, 13 Mar 1998 12:11:15 -0800 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 I'm curious why the existing binary encoding is inherently dependent on chunking?....I thought chunking was a part of the transport of the encoding. I don't think there is anything inherent (or explicitly referenced) by the current encoding that involves chunking. You're right that another transport would have to solve the chunking problem, but it's a TRANSPORT issue, so this would naturally fall into a transport mapping document. If there was a bit or byte that specified HTTP chunking within the binary encoding, then this is a different story. Randy -----Original Message----- From: Robert Herriot [SMTP:robert.herriot@Eng.Sun.COM] Sent: Friday, March 13, 1998 12:06 PM To: Turner, Randy; 'ipp@pwg.org' Subject: Re: IPP> IPP document set - naming convention(s) I think we had this discussion in Austin as part of Tom's proposal. We decided to change the name of the protocol document. Its new name is "Internet Printing Protocol/1.0: Encoding and Transport". We decided not to split the two documents. Although the IPP encoding is, in theory, transport independent. In fact, it depends on HTTP chunking. With an alternate transport, we would have to solve the chunking problem. It would be more efficient if the document data were the only part chunked, but that would require a change to the encoding layer. So, at this point, I don't endorse separating the two documents. Bob Herriot At 03:36 PM 3/12/98 , Turner, Randy wrote: > >Would anyone have any problem(s) splitting the protocol (not model) >document into two documents? > >Document 1 would be an encoding document >Document 2 would describe how to transport the encoding over HTTP 1.1 > >? > >Randy > From ipp-archive Fri Mar 13 15:29:10 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA19871 for ipp-outgoing; Fri, 13 Mar 1998 15:27:00 -0500 (EST) Message-ID: <35099629.1055600A@underscore.com> Date: Fri, 13 Mar 1998 15:25:13 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: "Turner, Randy" CC: "'Robert Herriot'" , "'ipp@pwg.org'" Subject: Re: IPP> IPP document set - naming convention(s) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk I agree with Randy completely. The way Bob describes it, IPP is absolutely bound to HTTP...theory or not. Why is it such a big deal to split the document into its two respective parts? I would think that those who truly believe the IPP encoding is "transport independent" would insist on such a separation of the documentation. Further, I don't think the IETF cares all that much about whether there is one document or two. ...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 -- ---------------------------------------------------------------------- Turner, Randy wrote: > > I'm curious why the existing binary encoding is inherently dependent on > chunking?....I thought chunking was a part of the transport of the > encoding. I don't think there is anything inherent (or explicitly > referenced) by the current encoding that involves chunking. You're right > that another transport would have to solve the chunking problem, but > it's a TRANSPORT issue, so this would naturally fall into a transport > mapping document. If there was a bit or byte that specified HTTP > chunking within the binary encoding, then this is a different story. > > Randy > > -----Original Message----- > From: Robert Herriot [SMTP:robert.herriot@Eng.Sun.COM] > Sent: Friday, March 13, 1998 12:06 PM > To: Turner, Randy; 'ipp@pwg.org' > Subject: Re: IPP> IPP document set - naming convention(s) > > I think we had this discussion in Austin as part of Tom's > proposal. We > decided to change the name of the protocol document. Its new > name is > "Internet Printing Protocol/1.0: Encoding and Transport". We > decided not to > split the two documents. > > Although the IPP encoding is, in theory, transport independent. > In fact, it > depends on HTTP chunking. With an alternate transport, we would > have to > solve the chunking problem. It would be more efficient if the > document data > were the only part chunked, but that would require a change to > the encoding > layer. > > So, at this point, I don't endorse separating the two documents. > > Bob Herriot > > At 03:36 PM 3/12/98 , Turner, Randy wrote: > > > >Would anyone have any problem(s) splitting the protocol (not > model) > >document into two documents? > > > >Document 1 would be an encoding document > >Document 2 would describe how to transport the encoding over > HTTP 1.1 > > > >? > > > >Randy > > From ipp-archive Fri Mar 13 15:34:12 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA20464 for ipp-outgoing; Fri, 13 Mar 1998 15:32:54 -0500 (EST) Message-Id: <199803132030.MAA26566@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 13 Mar 1998 12:34:19 -0800 To: ipp@pwg.org From: Robert Herriot Subject: IPP>PRO new information on POST versus PRINT method Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk I have now discovered that IPP implementation using Java servlets can be implemented with either POST or PRINT or any collection of methods we might want, and it doesn't really matter because of the excellent design of Java Servlets. So, I no longer have objections about a PRINT method based on lack of support by the webserver. Now it is more of a network issue and I don't have enough information to know which is better in that environment. In case you care about the details of servlets, here they are: When a servlet Foo is first instantiated its 'init' method is called. It is instantiated when the web server starts or when the web server detects that the servlet 'Foo.class' file is new. In the later case, the web server calls the 'destroy' method in the running 'Foo' servlet if one is running. Each time the web server receives a request for '/servlet/Foo', it calls the 'service' method with two parameters: a request and response object. Each 'service' call is a separate thread so the servlet can be processing more than one request. If the servlet overrides the 'service' method, it can process requests for any method, and it can determine the method via the request object with the 'getMethod' method. If the servlet doesn't override the 'service' method, the superclass 'service' method calls 'doGet' for GET, 'doPost' for POST, etc, and it returns an error for the nonstandard methods. If the servlet overrides 'doGet', it can process GET methods. If the servlet overrides 'doPost', it can process POST methods. Bob Herriot From ipp-archive Fri Mar 13 15:49:12 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA21092 for ipp-outgoing; Fri, 13 Mar 1998 15:46:49 -0500 (EST) From: don@lexmark.com Message-Id: <199803132046.AA01929@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: rturner@sharplabs.com Cc: Ipp@Pwg.Org Date: Fri, 13 Mar 1998 15:45:36 -0500 Subject: Re: IPP> IPP document set - naming convention(s) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@Pwg.Org Precedence: bulk I think this issue was decided in Austin with a name change for the Protocol document. Considering the pain separating them now would be and having to deal with editing all the cross references, etc. in the IETF format is just not worth it. When the time comes to map IPP to another transport then Bob or whoever is editor of that protocol document can make the split. ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** To: ipp%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright) bcc: Don Wright Subject: IPP> IPP document set - naming convention(s) Would anyone have any problem(s) splitting the protocol (not model) document into two documents? Document 1 would be an encoding document Document 2 would describe how to transport the encoding over HTTP 1.1 ? Randy From ipp-archive Fri Mar 13 16:04:15 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA21728 for ipp-outgoing; Fri, 13 Mar 1998 16:00:05 -0500 (EST) Message-Id: <199803132057.MAA26619@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 13 Mar 1998 13:01:03 -0800 To: "Turner, Randy" , "'Robert Herriot'" From: Robert Herriot Subject: RE: IPP> IPP document set - naming convention(s) Cc: "'ipp@pwg.org'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk The current binary encoding assumes that chunking occurs at a lower layer. IPP could work without chunking, but we thought it was important to avoid the= LPD problem where the length of a document must be know before sending it. If I were writing a server for receiving IPP over a raw socket, I would= prefer not to have chunking at a lower layer because I would have to implement a lower layer to put the chunks back together for the upper layer. I would prefer to read the encoded attributes directly off the socket and chunk only the document data. =20 Therefore I would end up with a slightly difference encoding for raw sockets than for HTTP. Bob Herriot At 12:11 PM 3/13/98 , Turner, Randy wrote: > >I'm curious why the existing binary encoding is inherently dependent on >chunking?....I thought chunking was a part of the transport of the >encoding. I don't think there is anything inherent (or explicitly >referenced) by the current encoding that involves chunking. You're right >that another transport would have to solve the chunking problem, but >it's a TRANSPORT issue, so this would naturally fall into a transport >mapping document. If there was a bit or byte that specified HTTP >chunking within the binary encoding, then this is a different story. > >Randy > > > -----Original Message----- > From: Robert Herriot [SMTP:robert.herriot@Eng.Sun.COM] > Sent: Friday, March 13, 1998 12:06 PM > To: Turner, Randy; 'ipp@pwg.org' > Subject: Re: IPP> IPP document set - naming convention(s) > > I think we had this discussion in Austin as part of Tom's >proposal.=A0 We=20 > decided to change the name of the protocol document. Its new >name is=20 > "Internet Printing Protocol/1.0: Encoding and Transport".=A0 We >decided not to=20 > split the two documents. > > Although the IPP encoding is, in theory, transport independent. >In fact, it=20 > depends on HTTP chunking. With an alternate transport, we would >have to=20 > solve the chunking problem.=A0 It would be more efficient if the >document data=20 > were the only part chunked, but that would require a change to >the encoding=20 > layer. > > So, at this point, I don't endorse separating the two documents. > > Bob Herriot > > At 03:36 PM 3/12/98 , Turner, Randy wrote: > > > >Would anyone have any problem(s) splitting the protocol (not >model) > >document into two documents? > > > >Document 1 would be an encoding document > >Document 2 would describe how to transport the encoding over >HTTP 1.1 > > > >? > > > >Randy > >=20 >=20 From ipp-archive Fri Mar 13 17:09:17 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA22508 for ipp-outgoing; Fri, 13 Mar 1998 17:05:11 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: RE: IPP> IPP document set - naming convention(s) Date: Fri, 13 Mar 1998 14:05:12 -0800 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 This issue was not brought up in Austin. Only a name change for the current document was an issue. As far as I can tell, including the minutes from Austin, my split proposal is new, and is derived from my efforts at actually doing another mapping document. Randy -----Original Message----- From: don@lexmark.com [SMTP:don@lexmark.com] Sent: Friday, March 13, 1998 12:46 PM To: rturner@sharplabs.com Cc: Ipp@pwg.org Subject: Re: IPP> IPP document set - naming convention(s) I think this issue was decided in Austin with a name change for the Protocol document. Considering the pain separating them now would be and having to deal with editing all the cross references, etc. in the IETF format is just not worth it. When the time comes to map IPP to another transport then Bob or whoever is editor of that protocol document can make the split. ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** To: ipp%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright) bcc: Don Wright Subject: IPP> IPP document set - naming convention(s) Would anyone have any problem(s) splitting the protocol (not model) document into two documents? Document 1 would be an encoding document Document 2 would describe how to transport the encoding over HTTP 1.1 ? Randy From ipp-archive Fri Mar 13 17:29:17 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA23149 for ipp-outgoing; Fri, 13 Mar 1998 17:25:14 -0500 (EST) Message-Id: <3.0.1.32.19980313142333.0116eb90@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 13 Mar 1998 14:23:33 PST To: Robert Herriot , ipp@pwg.org From: Tom Hastings Subject: Re: IPP>PRO new information on POST versus PRINT method In-Reply-To: <199803132030.MAA26566@woden.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk At 12:34 03/13/1998 PST, Robert Herriot wrote: >I have now discovered that IPP implementation using Java servlets can be >implemented with either POST or PRINT or any collection of methods we might >want, and it doesn't really matter because of the excellent design of Java >Servlets. > >So, I no longer have objections about a PRINT method based on lack of >support by the webserver. Now it is more of a network issue and I don't >have enough information to know which is better in that environment. > >In case you care about the details of servlets, here they are: > >When a servlet Foo is first instantiated its 'init' method is called. It is >instantiated when the web server starts or when the web server detects that >the servlet 'Foo.class' file is new. In the later case, the web server >calls the 'destroy' method in the running 'Foo' servlet if one is running. > >Each time the web server receives a request for '/servlet/Foo', it calls >the 'service' method with two parameters: a request and response object. >Each 'service' call is a separate thread so the servlet can be processing >more than one request. If the servlet overrides the 'service' method, it >can process requests for any method, and it can determine the method via >the request object with the 'getMethod' method. If the servlet doesn't >override the 'service' method, the superclass 'service' method calls >'doGet' for GET, 'doPost' for POST, etc, and it returns an error for the >nonstandard methods. If the servlet overrides 'doGet', it can process GET >methods. If the servlet overrides 'doPost', it can process POST methods. So what happens if IPP were to use a new method, not GET or POST, such as PRINT? Wouldn't this be a "nonstandard" method and so would return an error as you say? > >Bob Herriot > > > > > From ipp-archive Fri Mar 13 18:04:12 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA23774 for ipp-outgoing; Fri, 13 Mar 1998 18:03:46 -0500 (EST) Message-Id: <199803132258.OAA26779@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 13 Mar 1998 15:01:50 -0800 To: Tom Hastings , Robert Herriot , ipp@pwg.org From: Robert Herriot Subject: Re: IPP>PRO new information on POST versus PRINT method In-Reply-To: <3.0.1.32.19980313142333.0116eb90@garfield> References: <199803132030.MAA26566@woden.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk If you implement "service" method in your servlet class, it is called for= each request coming in regardless of the HTTP method. The "doGet" and "doPost" methods allow you to implement specific HTTP methods without having to test for the others that you don't support. Thus with the current POST method, I implement "doPost" and not "service" in my "IppServlet" class and let the superclass "HttpServlet" handle the call to the "service" method. If we= were to change IPP to use a PRINT method , I would rename my "doPost" method to "service" and add a check that the method was indeed "PRINT". If we added several methods, such as PRINT_JOB, CREATE_JOB, etc, I would rename the "doPost" method to "service" but I would need some additional checks for= HTTP method names. Bob Herriot At 02:23 PM 3/13/98 , Tom Hastings wrote: >At 12:34 03/13/1998 PST, Robert Herriot wrote: >>I have now discovered that IPP implementation using Java servlets can be >>implemented with either POST or PRINT or any collection of methods we= might >>want, and it doesn't really matter because of the excellent design of Java >>Servlets. >> >>So, I no longer have objections about a PRINT=A0 method based on lack of >>support by the webserver.=A0 Now it is more of a network issue and I don't >>have enough information to know which is better in that environment. >> >>In case you care about the details of servlets, here they are: >> >>When a servlet Foo is first instantiated its 'init' method is called. It= is >>instantiated when the web server starts or when the web server detects= that >>the servlet 'Foo.class' file is new.=A0 In the later case, the web server >>calls the 'destroy' method in the running 'Foo' servlet if one is running. >> >>Each time the web server receives a request for '/servlet/Foo', it calls >>the 'service' method with two parameters: a request and response object. >>Each 'service' call is a separate thread so the servlet can be processing >>more than one request. If the servlet overrides the 'service' method, it >>can process requests for any method, and it can determine the method via >>the request object with the 'getMethod' method. If the servlet doesn't >>override the 'service' method, the superclass 'service' method calls >>'doGet' for GET, 'doPost' for POST, etc, and it returns an error for the >>nonstandard methods. If the servlet overrides 'doGet', it can process GET >>methods. If the servlet overrides 'doPost', it can process POST methods. > >So what happens if IPP were to use a new method, not GET or POST, such >as PRINT?=A0 Wouldn't this be a "nonstandard" method and so would return >an error as you say? > >> >>Bob Herriot >> >> >> >> >> >=20 From ipp-archive Fri Mar 13 18:14:18 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA24370 for ipp-outgoing; Fri, 13 Mar 1998 18:10:21 -0500 (EST) Message-Id: <3.0.1.32.19980313150834.01170e40@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 13 Mar 1998 15:08:34 PST To: Robert Herriot , "Turner, Randy" , "'Robert Herriot'" From: Tom Hastings Subject: RE: IPP> IPP document set - naming convention(s) Cc: "'ipp@pwg.org'" In-Reply-To: <199803132057.MAA26619@woden.eng.sun.com> Illegal-Object: Syntax error in References: value found on alpha.xerox.com: References: ^-illegal end of message identification Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk At 13:01 03/13/1998 PST, Robert Herriot wrote: >The current binary encoding assumes that chunking occurs at a lower layer. >IPP >could work without chunking, but we thought it was important to avoid the= LPD >problem where the length of a document must be know before sending it. > >If I were writing a server for receiving IPP over a raw socket, I would prefer >not to have chunking at a lower layer because I would have to implement a >lower >layer to put the chunks back together for the upper layer. I would prefer= to >read the encoded attributes directly off the socket and chunk only the >document >data. =20 > >Therefore I would end up with a slightly difference encoding for raw= sockets >than for HTTP. In reviewing the various host-to-device protocols at the meeting, TIPSI and CPAP both have a separate channel for the data. So the control stuff goes over and comes back over a bi-directional control TCP/IP channel and the data goes over the separate data channel. The control channel would NOT need to be chunked, I would think. The data channel could just be a simple TCP/IP socket, so it wouldn't need chunking either. For example, in CPAP, the device returns the port for the data channel, and the host opens it and send raw data without headers of any kind and then closes the channel at the end of the document (which corresponds to the end of the data for a Print-Job or=20 Send-Document IPP operation). Comments? Tom > >Bob Herriot > >At 12:11 PM 3/13/98 , Turner, Randy wrote: >> >>I'm curious why the existing binary encoding is inherently dependent on >>chunking?....I thought chunking was a part of the transport of the >>encoding. I don't think there is anything inherent (or explicitly >>referenced) by the current encoding that involves chunking. You're right >>that another transport would have to solve the chunking problem, but >>it's a TRANSPORT issue, so this would naturally fall into a transport >>mapping document. If there was a bit or byte that specified HTTP >>chunking within the binary encoding, then this is a different story. >> >>Randy >> >> >> -----Original Message----- >> From: Robert Herriot [SMTP:robert.herriot@Eng.Sun.COM] >> Sent: Friday, March 13, 1998 12:06 PM >> To: Turner, Randy; 'ipp@pwg.org' >> Subject: Re: IPP> IPP document set - naming convention(s) >> >> I think we had this discussion in Austin as part of Tom's >>proposal.=A0 We=20 >> decided to change the name of the protocol document. Its new >>name is=20 >> "Internet Printing Protocol/1.0: Encoding and Transport".=A0 We >>decided not to=20 >> split the two documents. >> >> Although the IPP encoding is, in theory, transport independent. >>In fact, it=20 >> depends on HTTP chunking. With an alternate transport, we would >>have to=20 >> solve the chunking problem.=A0 It would be more efficient if the >>document data=20 >> were the only part chunked, but that would require a change to >>the encoding=20 >> layer. >> >> So, at this point, I don't endorse separating the two documents. >> >> Bob Herriot >> >> At 03:36 PM 3/12/98 , Turner, Randy wrote: >> > >> >Would anyone have any problem(s) splitting the protocol (not >>model) >> >document into two documents? >> > >> >Document 1 would be an encoding document >> >Document 2 would describe how to transport the encoding over >>HTTP 1.1 >> > >> >? >> > >> >Randy >> >=20 >>=20 > > > From ipp-archive Fri Mar 13 20:09:14 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA25065 for ipp-outgoing; Fri, 13 Mar 1998 20:05:41 -0500 (EST) Message-Id: <199803140103.RAA27029@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 13 Mar 1998 17:06:58 -0800 To: "Turner, Randy" , "'ipp@pwg.org'" From: Robert Herriot Subject: RE: IPP> IPP document set - naming convention(s) In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk It's not new. It was part of Tom's proposal at the Austin meeting. We discussed and rejected it as too late. =20 At 02:05 PM 3/13/98 , Turner, Randy wrote: > >This issue was not brought up in Austin. Only a name change for the >current document was an issue. As far as I can tell, including the >minutes from Austin, my split proposal is new, and is derived from my >efforts at actually doing another mapping document. > >Randy > > -----Original Message----- > From: don@lexmark.com [SMTP:don@lexmark.com] > Sent: Friday, March 13, 1998 12:46 PM > To: rturner@sharplabs.com > Cc: Ipp@pwg.org > Subject: Re: IPP> IPP document set - naming convention(s) > > > I think this issue was decided in Austin with a name change for >the > Protocol document. > Considering the pain separating them now would be and having to >deal with > editing all > the cross references, etc. in the IETF format is just not worth >it.=A0 When > the time comes to > map IPP to another transport then Bob or whoever is editor of >that protocol > document > can make the split. > > ********************************************** > * Don Wright=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= don@lexmark.com * > * Product Manager, Strategic Alliances=A0=A0=A0=A0=A0=A0 * > * Lexmark International=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 * > * 740 New Circle Rd=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 * > * Lexington, Ky 40550=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 * > * 606-232-4808 (phone) 606-232-6740 (fax)=A0=A0=A0 * > ********************************************** > > > > > > > To:=A0=A0 ipp%pwg.org@interlock.lexmark.com > cc:=A0=A0=A0 (bcc: Don Wright) > bcc:=A0 Don Wright > Subject:=A0 IPP> IPP document set - naming convention(s) > > > > > > Would anyone have any problem(s) splitting the protocol (not >model) > document into two documents? > Document 1 would be an encoding document > Document 2 would describe how to transport the encoding over >HTTP 1.1 > ? > Randy >=20 From ipp-archive Fri Mar 13 20:34:15 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA25684 for ipp-outgoing; Fri, 13 Mar 1998 20:32:23 -0500 (EST) Message-Id: <3.0.1.32.19980313172719.00c12d30@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 13 Mar 1998 17:27:19 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: RE: IPP> IPP document set - naming convention(s) In-Reply-To: <199803140103.RAA27029@woden.eng.sun.com> Illegal-Object: Syntax error in References: value found on alpha.xerox.com: References: ^-illegal end of message identification Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk All, I suggest that we shelve this discussion until we get the feedback from the IESG. If they require other changes to the protocol document, then we can consider the split. If they are happy with the document as is, I do not see enough reason to change what we have. Carl-Uno At 05:06 PM 3/13/98 PST, you wrote: >It's not new. It was part of Tom's proposal at the Austin meeting. We >discussed >and rejected it as too late. =20 > > > >At 02:05 PM 3/13/98 , Turner, Randy wrote: >> >>This issue was not brought up in Austin. Only a name change for the >>current document was an issue. As far as I can tell, including the >>minutes from Austin, my split proposal is new, and is derived from my >>efforts at actually doing another mapping document. >> >>Randy >> >> -----Original Message----- >> From: don@lexmark.com [SMTP:don@lexmark.com] >> Sent: Friday, March 13, 1998 12:46 PM >> To: rturner@sharplabs.com >> Cc: Ipp@pwg.org >> Subject: Re: IPP> IPP document set - naming convention(s) >> >> >> I think this issue was decided in Austin with a name change for >>the >> Protocol document. >> Considering the pain separating them now would be and having to >>deal with >> editing all >> the cross references, etc. in the IETF format is just not worth >>it.=A0 When >> the time comes to >> map IPP to another transport then Bob or whoever is editor of >>that protocol >> document >> can make the split. >> >> ********************************************** >> * Don Wright=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= don@lexmark.com * >> * Product Manager, Strategic Alliances=A0=A0=A0=A0=A0=A0 * >> * Lexmark International=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 * >> * 740 New Circle Rd=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 * >> * Lexington, Ky 40550=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 * >> * 606-232-4808 (phone) 606-232-6740 (fax)=A0=A0=A0 * >> ********************************************** >> >> >> >> >> >> >> To:=A0=A0 ipp%pwg.org@interlock.lexmark.com >> cc:=A0=A0=A0 (bcc: Don Wright) >> bcc:=A0 Don Wright >> Subject:=A0 IPP> IPP document set - naming convention(s) >> >> >> >> >> >> Would anyone have any problem(s) splitting the protocol (not >>model) >> document into two documents? >> Document 1 would be an encoding document >> Document 2 would describe how to transport the encoding over >>HTTP 1.1 >> ? >> Randy >>=20 > > > 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 Sun Mar 15 19:29:44 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA17853 for ipp-outgoing; Sun, 15 Mar 1998 19:29:31 -0500 (EST) Date: Sun, 15 Mar 1998 16:35:07 PST From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9803160035.AA12733@snorkel.eso.mc.xerox.com> To: Joe_Filion@mc.xerox.com, ipp@pwg.org, jmp@pwg.org Subject: IPP> SNMPv3 unsuited for IPP/JMP Notifications Sender: ipp-owner@pwg.org Precedence: bulk Copies To: ipp@pwg.org jmp_pwg.org Hi folks, Sunday (15 March 1998) Extracted below (with line numbers) is summary information from the five SNMPv3 documents (RFC 2271 to RFC 2275, January 1998). As Randy Turner has argued, it IS possible to use a small subset (Target and Notification MIBs in RFC 2273) of the SNMPv3 MIB modules (there are a total of 7 SNMPv3 MIB modules) to achieve a simple (security-free) SNMP trap registration mechanism (see the 'snmpNotifyBasicCompliance' declaration at line 2773 of RFC 2273). But, the functionality provided is INFERIOR in important ways to that provided by the JAM (Job Async Monitor) MIB that Joe Filion and I posted on Wednesday (4 March 1998) or to my informal understanding of the IBM method presented by Harry Lewis during last week's PWG monthly meeting in Austin, TX. 1) The JAM MIB and Historic SNMP Party MIB (RFC 1447) support scope (traps of 'interest') specified as object identifier subtrees. The SNMPv3 Target/Notification MIBs support scope only by short (32 character) UTF-8 tags, which are NOT standardized by SNMPv3 and (due to their length) are NOT amenable to standardization. 2) The JAM MIB supports automatic trap deregistration specified as 'DateAndTime'. The SNMPv3 Target/Notification MIBs do NOT support automatic trap deregistration at all! 3) The JAM MIB supports simple integer indices for all 'read-create' object groups (written by a remote client). The SNMPv3 Target/Notification MIBs support indices ONLY as (32 character) UTF-8 'SnmpAdminString' values, seriously restricting the number of SNMP objects which can be transferred in a single packet. Since SNMP runs over UDP (in the Internet suite) and there is no 'chunking' for SNMP requests, this limitation is significant! 4) The JAM MIB supports a 'read-only' lookup table (maintained by the SNMP agent on the device) which provides direct lookup from SNMP transport domain and transport address to a client (target) trap registration entry (to avoid duplicate registrations). But, the SNMPv3 Target/Notification MIBs support only brute force (ie, read the entire Target table) for this important functionality! 5) The JAM MIB scales well to a very large number of (end-user) trap client (target) registrations. But, the SNMPv3 Target/Notification MIBs do not scale well. They are intended ONLY for use by network management stations! 6) Randy has suggested that SNMPv2/SNMPv3 'Inform' requests/responses could be used for (questionably) 'reliable' event notification. But, 'Inform' is intended by the SNMPv3 developers to be used ONLY for reporting up a hierarchy of network management stations! Also, 'Inform' is not defined in SNMPv1, so the huge installed base of SNMP agents which (almost exclusively) speak SNMPv1 cannot use 'Inform'. 7) Lastly, as SNMP agent toolkits become available from software tool vendors, any 'local' use of SNMPv3 Target/Notification MIBs by the printer industry vendors will inevitably conflict with the very different intent of the SNMPv3 developers. Recall why the Job Mon MIB is a PWG standard and NOT an IETF standard! As I hope most of you know, I'm dedicated to the use of standards where available and applicable. But the SNMPv3 MIBs were never intended to be used by many clients. They simply aren't appropriate to the problem of trap registration for PWG Job Mon MIB and IETF/PWG Printer MIB traps. Cheers, - Ira McDonald (High North, outside consultant at Xerox) ------------------------------------------------------------------------ **** SNMPv3 Documents **** rfc2271.txt: Architecture for Describing SNMP Management Frameworks - 38-44: This document describes an architecture for describing SNMP Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. The major portions of the architecture are an SNMP engine containing a Message Processing Subsystem, a Security Subsystem and an Access Control Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data. - 1913: SNMP-FRAMEWORK-MIB DEFINITIONS ::= BEGIN - 2420: snmpFrameworkMIBCompliance MODULE-COMPLIANCE rfc2272.txt: Message Processing and Dispatching for SNMP - 41-46: This document describes the Message Processing and Dispatching for SNMP messages within the SNMP architecture [RFC2271]. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. - 810: SNMP-MPD-MIB DEFINITIONS ::= BEGIN - 936: snmpMPDCompliance MODULE-COMPLIANCE - 976: SNMPv3MessageSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN rfc2273.txt: SNMPv3 Applications - 37-44: This memo describes five types of SNMP applications which make use of an SNMP engine as described in [RFC2271]. The types of application described are Command Generators, Command Responders, Notification Originators, Notification Receivers, and Proxy Forwarders. This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. - 1561: SNMP-TARGET-MIB DEFINITIONS ::= BEGIN - 2209: snmpTargetCommandResponderCompliance MODULE-COMPLIANCE - 2305: SNMP-NOTIFICATION-MIB DEFINITIONS ::= BEGIN - 2773: snmpNotifyBasicCompliance MODULE-COMPLIANCE - 2881: snmpNotifyBasicFiltersCompliance MODULE-COMPLIANCE - 2894: snmpNotifyFullCompliance MODULE-COMPLIANCE - 2960: SNMP-PROXY-MIB DEFINITIONS ::= BEGIN - 3242: snmpProxyCompliance MODULE-COMPLIANCE rfc2274.txt: User-based Security Model (USM) for SNMPv3 - 37-41: This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFC2271]. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model. - 861: USMSecurityParametersSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN - 1701: SNMP-USER-BASED-SM-MIB DEFINITIONS ::= BEGIN - 2439: usmMIBCompliance MODULE-COMPLIANCE rfc2275.txt: View-based Access Control Model (VACM) for SNMPv3 - 38-42: This document describes the View-based Access Control Model for use in the SNMP architecture [RFC2271]. It defines the Elements of Procedure for controlling access to management information. This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model. - 541: SNMP-VIEW-BASED-ACM-MIB DEFINITIONS ::= BEGIN - 1356: vacmMIBCompliance MODULE-COMPLIANCE ------------------------------------------------------------------------ From ipp-archive Sun Mar 15 20:34:46 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA18737 for ipp-outgoing; Sun, 15 Mar 1998 20:33:43 -0500 (EST) From: "Rajesh Chawla" To: "IPP Mailing List" Subject: IPP> Beta Release of IPP Test Suite Date: Sun, 15 Mar 1998 20:35:38 -0500 Message-ID: <01bd507b$d2b63d40$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 announcing the availability of the IPP Test Suite, Beta Version. The Test Suite allows you to: 1) Specify the operations to be sent to the printer in an ASCII file. 2) Allows valid and invalid data to be sent to the printer. 3) Allows the sending of user-defined attributes to the printer. 4) Provides for the capture of all data sent to and received from the printer. For more information please contact Rajesh Chawla at rajesh@trcs.com. Regards, Rajesh ====================================================== Rajesh Chawla TR Computing Solutions (703) 787-9689 (Fax) 13622 Flintwood Place Herndon VA 20171 From ipp-archive Mon Mar 16 12:00:51 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA00378 for ipp-outgoing; Mon, 16 Mar 1998 11:55:49 -0500 (EST) Message-Id: <3.0.1.32.19980316084839.00b5b980@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 16 Mar 1998 08:48:39 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> I-D ACTION:draft-ietf-http-ext-mandatory-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk FYI, Note that this document explicitly mentions printing. Carl-Uno >To: IETF-Announce:; >Cc: http-wg@cuckoo.hpl.hp.com >From: Internet-Drafts@ns.ietf.org >Reply-to: Internet-Drafts@ns.ietf.org >Subject: I-D ACTION:draft-ietf-http-ext-mandatory-00.txt >Date: Mon, 16 Mar 1998 05:20:33 PST >Sender: cclark@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the HyperText Transfer Protocol Working Group >of the IETF. > > Title : Mandatory Extensions in HTTP > Author(s) : P. Leach, H. Nielsen, S. Lawrence > Filename : draft-ietf-http-ext-mandatory-00.txt > Pages : 12 > Date : 13-Mar-98 > > HTTP is used increasingly in applications that need more facilities > than the standard version of the protocol provides, ranging from > distributed authoring, collaboration, and printing, to various remote > procedure call mechanisms. This document proposes the use of a > mandatory extension mechanism designed to address the tension between > private agreement and public specification and to accommodate > extension of applications such as HTTP clients, servers, and proxies. > The proposal associates each extension with a URI[2], and use a few > new RFC 822[1] style header fields to carry the extension identifier > and related information between the parties involved in an extended > transaction. > > >Internet-Drafts are available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-http-ext-mandatory-00.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-http-ext-mandatory-00.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@ietf.org. In the body type: > "FILE /internet-drafts/draft-ietf-http-ext-mandatory-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > > 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 Mar 16 12:15:51 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA01014 for ipp-outgoing; Mon, 16 Mar 1998 12:13:04 -0500 (EST) Message-Id: <3.0.1.32.19980316090710.00910dd0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 16 Mar 1998 09:07:10 PST To: Ipp@pwg.org From: Carl-Uno Manros Subject: IPP> I-D ACTION:draft-ietf-http-authentication-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk FYI, Carl-Uno >To: IETF-Announce:; >Cc: http-wg@cuckoo.hpl.hp.com >From: Internet-Drafts@ns.ietf.org >Reply-to: Internet-Drafts@ns.ietf.org >Subject: I-D ACTION:draft-ietf-http-authentication-01.txt >Date: Mon, 16 Mar 1998 05:21:14 PST >Sender: cclark@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the HyperText Transfer Protocol Working Group of the IETF. > > Title : HTTP Authentication: Basic and Digest > Access Authentication > Author(s) : J. Franks, E. Sink, P. Leach, J. Hostetler, > P. Hallam-Baker, L. Stewart, S. Lawrence, A. Luotonen > Filename : draft-ietf-http-authentication-01.txt > Pages : 26 > Date : 13-Mar-98 > >''HTTP/1.0'' includes the specification for a Basic Access Authentication >scheme. This scheme is not considered to be a secure method of user >authentication (unless used in conjunction with some external secure >system such as SSL [5]), as the user name and password are passed over >the network as cleartext. > >This document also provides the specification for HTTP's authentication >framework, the original Basic authentication scheme and a scheme based >on cryptographic hashes, referred to as ''Digest Access Authentication''. >It is therefore also intended to serve as a replacement for RFC 2069 >[6]. Some optional elements specified by RFC 2069 have been removed >from this specification due to problems found since its publication; >other new elements have been added -for compatibility, those new >elements have been made optional, but are strongly recommended. > >Like Basic, Digest access authentication verifies that both parties to a >communication know a shared secret (a password); unlike Basic, this >verification can be done without sending the password in the clear, >which is Basic's biggest weakness. As with most other authentication >protocols, the greatest sources of risks are usually found not in the >core protocol itself but in policies and procedures surrounding its use. > >Internet-Drafts are available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-http-authentication-01.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-http-authentication-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@ietf.org. In the body type: > "FILE /internet-drafts/draft-ietf-http-authentication-01.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > > 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 Mar 16 12:35:52 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA01668 for ipp-outgoing; Mon, 16 Mar 1998 12:32:41 -0500 (EST) Message-Id: <3.0.1.32.19980316092044.00cca4e0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 16 Mar 1998 09:20:44 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> I-D ACTION:draft-ietf-tls-https-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk FYI, Carl-Uno >To: IETF-Announce:; >Cc: ietf-tls@consensus.com >From: Internet-Drafts@ns.ietf.org >Reply-to: Internet-Drafts@ns.ietf.org >Subject: I-D ACTION:draft-ietf-tls-https-01.txt >Date: Mon, 16 Mar 1998 05:22:46 PST >Sender: cclark@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Transport Layer Security Working Group of the IETF. > > Title : HTTP Over TLS > Author(s) : E. Rescorla > Filename : draft-ietf-tls-https-01.txt > Pages : 6 > Date : 13-Mar-98 > > This memo describes how to use TLS to secure HTTP connections over > the Internet. Current practice is to layer HTTP over SSL (the prede- > cessor to TLS), distinguishing secured traffic from insecure traffic > by the use of a different server port. This document documents that > practice using TLS. A companion document describes a method for using > HTTP/TLS over the same port as normal HTTP. > >Internet-Drafts are available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-tls-https-01.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-https-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@ietf.org. In the body type: > "FILE /internet-drafts/draft-ietf-tls-https-01.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > > 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 Mar 16 14:00:59 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA02756 for ipp-outgoing; Mon, 16 Mar 1998 13:55:50 -0500 (EST) Message-Id: <3.0.1.32.19980316105000.00b47100@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 16 Mar 1998 10:50:00 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - PWG IPP Phone Conference Agenda for 980318 Cc: masinter@parc.xerox.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk PWG IPP Phone Conference Agenda for 980318 I would like to spend this week's phone conference to go over some of the new drafts from other working groups, which may impact the implementation of IPP. We should decide if we need to comment on some of these drafts in the IETF LA meeting. The relevant drafts are: - Hypertext Transfer Protocol -- HTTP/1.1 ftp://ftp.ietf.org/internet-drafts/draft-ietf-http-v11-spec-rev-03.txt This is an update of RFC 2068 and reflects some implementation experience and bug fixes to HTT 1.1. - Mandatory Extensions in HTTP ftp://ftp.ietf.org/internet-drafts/draft-ietf-http-ext-mandatory-00.txt This seems to define a few proposed extensions to RFC 2068. - HTTP Authentication: Basic and Digest Access Authentication ftp://ftp.ietf.org/internet-drafts/draft-ietf-http-authentication-01.txt This is an update of RFC 2069 and states that Basic Authentication can only be used in combination with an underlying secure transfer protocol. - HTTP Over TLS ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-https-01.txt This is the TLS profile for HTTP 1.1. Can we apply this for IPP as is? - Media Features for Display, Print, and Fax ftp://ftp.ietf.org/internet-drafts/draft-ietf-conneg-media-features-00.txt This is from the newly formed CONNEG group and partly overlaps with IPP. Seems to have been made mostly by people from the IFAX group. Is more aligned with the Printer MIB than with IPP. - Content Feature Tag Registration Procedure ftp://ftp.ietf.org/internet-drafts/draft-ietf-conneg-feature-reg-00.txt This is a companion draft to the previous one from the CONNEG group. --- If you are interested in discussing details in these documents, please read them before the phone conference. The phone-in information is: Date and Time: March 18, 10:00-12:00 am PST (remember the earlier time slot) Phone number: 212-547-0243 (For Xerox participants 8*535-5000) Pass code: cmanros Please note that the phone number is different from last 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 Mon Mar 16 14:25:51 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA03405 for ipp-outgoing; Mon, 16 Mar 1998 14:22:37 -0500 (EST) Message-Id: <3.0.1.32.19980316111116.00b45a00@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 16 Mar 1998 11:11:16 PST To: Harald.Alvestrand@maxware.no, moore@cs.utk.edu From: Carl-Uno Manros Subject: IPP> IESG feedback on IPP drafts Cc: ipp@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Harald and Keith, As you might image, the IPP WG members are getting anxious to learn about the IESG decision about our documents, and I would need to know if I have to make the IESG feedback a main agenda point for the IPP meeting in LA, or if we can use the time to discuss further work (Notifications and IPP MIB seems to be things that still needs to be done before the current scope of IPP work is finished). When is the next meeting or phone conference of the IESG, assuming that our subject is on the agenda? On a different subject, will you guys have any time for an IPP demo in LA? 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 Mar 16 14:59:56 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA04843 for ipp-outgoing; Mon, 16 Mar 1998 14:59:49 -0500 (EST) Date: Mon, 16 Mar 1998 14:59:01 -0500 (EST) From: Gail Zacharias To: ipp@pwg.org Subject: IPP> IPP implementation demo Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipp-owner@pwg.org Precedence: bulk Harlequin is going to be showing a preliminary IPP server for our ScriptWorks product at Seybold this week. If you're interested in seeing a demo, stop by Meeting Room #2 at the Javits Convention Center, and ask for Neil Epstein. From ipp-archive Mon Mar 16 17:00:02 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA05690 for ipp-outgoing; Mon, 16 Mar 1998 16:57:16 -0500 (EST) Message-ID: <350D9DB9.1B183565@underscore.com> Date: Mon, 16 Mar 1998 16:46:33 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Ira Mcdonald x10962 CC: Joe_Filion@mc.xerox.com, ipp@pwg.org, jmp@pwg.org, Sense mailing list Subject: Re: IPP> SNMPv3 unsuited for IPP/JMP Notifications References: <9803160035.AA12733@snorkel.eso.mc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Ira, Thanks so much for your review and comments regarding the applicability (or not) of the new SNMPv3 async notification facilities. I particularly liked your summary paragraph: > As I hope most of you know, I'm dedicated to the use of standards where > available and applicable. But the SNMPv3 MIBs were never intended to be > used by many clients. They simply aren't appropriate to the problem of > trap registration for PWG Job Mon MIB and IETF/PWG Printer MIB traps. This comes as no surprise to those of us developing SENSE over the last two years or so. SNMP was primarily designed for management network elements, and has never demonstrated the power required in larger, non-management applications, such as generic client-side features of network printing. That is precisely why we went off and did SENSE, to create a more scalable, more generic system for async notifications. Simply hacking onto existing (or future) SNMP facilities never seemed to make the grade. And now your analysis seems to verify that original assumption. Perhaps someday the PWG will come to understand the need for SENSE...or something just like it, anyway. ...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 -- ---------------------------------------------------------------------- Ira Mcdonald x10962 wrote: > > Copies To: ipp@pwg.org > jmp_pwg.org > > Hi folks, Sunday (15 March 1998) > > Extracted below (with line numbers) is summary information from the five > SNMPv3 documents (RFC 2271 to RFC 2275, January 1998). > > As Randy Turner has argued, it IS possible to use a small subset (Target > and Notification MIBs in RFC 2273) of the SNMPv3 MIB modules (there are > a total of 7 SNMPv3 MIB modules) to achieve a simple (security-free) > SNMP trap registration mechanism (see the 'snmpNotifyBasicCompliance' > declaration at line 2773 of RFC 2273). > > But, the functionality provided is INFERIOR in important ways to that > provided by the JAM (Job Async Monitor) MIB that Joe Filion and I posted > on Wednesday (4 March 1998) or to my informal understanding of the IBM > method presented by Harry Lewis during last week's PWG monthly meeting > in Austin, TX. > > 1) The JAM MIB and Historic SNMP Party MIB (RFC 1447) support scope > (traps of 'interest') specified as object identifier subtrees. > The SNMPv3 Target/Notification MIBs support scope only by short (32 > character) UTF-8 tags, which are NOT standardized by SNMPv3 and (due > to their length) are NOT amenable to standardization. > > 2) The JAM MIB supports automatic trap deregistration specified as > 'DateAndTime'. > The SNMPv3 Target/Notification MIBs do NOT support automatic trap > deregistration at all! > > 3) The JAM MIB supports simple integer indices for all 'read-create' > object groups (written by a remote client). > The SNMPv3 Target/Notification MIBs support indices ONLY as (32 > character) UTF-8 'SnmpAdminString' values, seriously restricting the > number of SNMP objects which can be transferred in a single packet. > Since SNMP runs over UDP (in the Internet suite) and there is no > 'chunking' for SNMP requests, this limitation is significant! > > 4) The JAM MIB supports a 'read-only' lookup table (maintained by the > SNMP agent on the device) which provides direct lookup from SNMP > transport domain and transport address to a client (target) trap > registration entry (to avoid duplicate registrations). > But, the SNMPv3 Target/Notification MIBs support only brute force > (ie, read the entire Target table) for this important functionality! > > 5) The JAM MIB scales well to a very large number of (end-user) trap > client (target) registrations. > But, the SNMPv3 Target/Notification MIBs do not scale well. They > are intended ONLY for use by network management stations! > > 6) Randy has suggested that SNMPv2/SNMPv3 'Inform' requests/responses > could be used for (questionably) 'reliable' event notification. > But, 'Inform' is intended by the SNMPv3 developers to be used ONLY > for reporting up a hierarchy of network management stations! > Also, 'Inform' is not defined in SNMPv1, so the huge installed base > of SNMP agents which (almost exclusively) speak SNMPv1 cannot use > 'Inform'. > > 7) Lastly, as SNMP agent toolkits become available from software tool > vendors, any 'local' use of SNMPv3 Target/Notification MIBs by the > printer industry vendors will inevitably conflict with the very > different intent of the SNMPv3 developers. Recall why the Job Mon > MIB is a PWG standard and NOT an IETF standard! > > As I hope most of you know, I'm dedicated to the use of standards where > available and applicable. But the SNMPv3 MIBs were never intended to be > used by many clients. They simply aren't appropriate to the problem of > trap registration for PWG Job Mon MIB and IETF/PWG Printer MIB traps. > > Cheers, > - Ira McDonald (High North, outside consultant at Xerox) > > ------------------------------------------------------------------------ > **** SNMPv3 Documents **** > > rfc2271.txt: Architecture for Describing SNMP Management Frameworks > - 38-44: > This document describes an architecture for describing SNMP > Management Frameworks. The architecture is designed to be modular to > allow the evolution of the SNMP protocol standards over time. The > major portions of the architecture are an SNMP engine containing a > Message Processing Subsystem, a Security Subsystem and an Access > Control Subsystem, and possibly multiple SNMP applications which > provide specific functional processing of management data. > - 1913: > SNMP-FRAMEWORK-MIB DEFINITIONS ::= BEGIN > - 2420: > snmpFrameworkMIBCompliance MODULE-COMPLIANCE > > rfc2272.txt: Message Processing and Dispatching for SNMP > - 41-46: > This document describes the Message Processing and Dispatching for > SNMP messages within the SNMP architecture [RFC2271]. It defines the > procedures for dispatching potentially multiple versions of SNMP > messages to the proper SNMP Message Processing Models, and for > dispatching PDUs to SNMP applications. This document also describes > one Message Processing Model - the SNMPv3 Message Processing Model. > - 810: > SNMP-MPD-MIB DEFINITIONS ::= BEGIN > - 936: > snmpMPDCompliance MODULE-COMPLIANCE > - 976: > SNMPv3MessageSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN > > rfc2273.txt: SNMPv3 Applications > - 37-44: > This memo describes five types of SNMP applications which make use of > an SNMP engine as described in [RFC2271]. The types of application > described are Command Generators, Command Responders, Notification > Originators, Notification Receivers, and Proxy Forwarders. > > This memo also defines MIB modules for specifying targets of > management operations, for notification filtering, and for proxy > forwarding. > - 1561: > SNMP-TARGET-MIB DEFINITIONS ::= BEGIN > - 2209: > snmpTargetCommandResponderCompliance MODULE-COMPLIANCE > - 2305: > SNMP-NOTIFICATION-MIB DEFINITIONS ::= BEGIN > - 2773: > snmpNotifyBasicCompliance MODULE-COMPLIANCE > - 2881: > snmpNotifyBasicFiltersCompliance MODULE-COMPLIANCE > - 2894: > snmpNotifyFullCompliance MODULE-COMPLIANCE > - 2960: > SNMP-PROXY-MIB DEFINITIONS ::= BEGIN > - 3242: > snmpProxyCompliance MODULE-COMPLIANCE > > rfc2274.txt: User-based Security Model (USM) for SNMPv3 > - 37-41: > This document describes the User-based Security Model (USM) for SNMP > version 3 for use in the SNMP architecture [RFC2271]. It defines the > Elements of Procedure for providing SNMP message level security. > This document also includes a MIB for remotely monitoring/managing > the configuration parameters for this Security Model. > - 861: > USMSecurityParametersSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN > - 1701: > SNMP-USER-BASED-SM-MIB DEFINITIONS ::= BEGIN > - 2439: > usmMIBCompliance MODULE-COMPLIANCE > > rfc2275.txt: View-based Access Control Model (VACM) for SNMPv3 > - 38-42: > This document describes the View-based Access Control Model for use > in the SNMP architecture [RFC2271]. It defines the Elements of > Procedure for controlling access to management information. This > document also includes a MIB for remotely managing the configuration > parameters for the View-based Access Control Model. > - 541: > SNMP-VIEW-BASED-ACM-MIB DEFINITIONS ::= BEGIN > - 1356: > vacmMIBCompliance MODULE-COMPLIANCE > ------------------------------------------------------------------------ From ipp-archive Mon Mar 16 18:09:59 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA07162 for ipp-outgoing; Mon, 16 Mar 1998 18:00:01 -0500 (EST) Message-Id: <199803162257.RAA20974@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Carl-Uno Manros cc: Harald.Alvestrand@maxware.no, moore@cs.utk.edu, ipp@pwg.org, moore@cs.utk.edu Subject: IPP> Re: IESG feedback on IPP drafts In-reply-to: Your message of "Mon, 16 Mar 1998 11:11:16 PST." <3.0.1.32.19980316111116.00b45a00@garfield> Date: Mon, 16 Mar 1998 17:57:58 -0500 Sender: ipp-owner@pwg.org Precedence: bulk Carl-Uno, I must apologize...the IPP review is taking longer than I had thought. The documents themselves are long, and there were an unusually large number of comments. And for the last few days I have been dealing with a family medical emergency. I hope to have the review completed by the end of this week, and will then know whether IPP needs to discuss it at the LA meeting. The next IESG meeting will be sometime after the LA IETF. Keith From ipp-archive Mon Mar 16 19:30:01 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA07992 for ipp-outgoing; Mon, 16 Mar 1998 19:27:23 -0500 (EST) Message-Id: <3.0.1.32.19980316162536.00a409d0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 16 Mar 1998 16:25:36 PST To: "Puru Bish" From: Tom Hastings Subject: Re: IPP> Re: IPP- Printer state Cc: ipp@pwg.org In-Reply-To: <19980312200457.1307.qmail@hotmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk At 12:04 03/12/1998 PST, Puru Bish wrote: > >Thanks, Tom for clarifying the issue. > >I still have a question - should an IPP server behave the same >way even when it does not spool any job? You mean what should an IPP Printer object implemented in a server that does not spool jobs, but forwards jobs onto a single device directly (perhaps using IPP or some other device protocol), but the device to which it forwards jobs is shutdown? I would think that the following response might be the best: The server would reject the Create-Job and return the error code: 'server-error-service-unavailable'. Then the client could query the Printer's "printer-state" and see 'stopped' and the Printer's "printer-state-reasons" and see 'error-shutdown'. Do others agree? Tom > >-PB > >>From hastings@cp10.es.xerox.com Wed Mar 11 17:57:09 1998 > >>Yes, the Printer object implemented in a server object does accept the >>job even though the device is powered down. >> >>And the requester MAY get an indication that there is a problem, >because >>the job's OPTIONAL "job-state-reason" attribute that MAY be returned in >the >>Print-Job response containing the value: 'printer-stopped' >>(or 'printer-stopped-partly' in the case that only some of the fan-out >>printers are stopped). Unfortunately, the requeseter will NOT get this >>indication in the response, if the IPP Printer object does not >implement >>the OPTIONAL "job-state-reasons" attribute. >> >>The client can then query the Printer's "printer-state" >>and "printer-state-reasons" attribute and see that the "printer-state" >>is 'stopped' and the "printer-state-reasons" is 'error-shutdown' >>('warning-shutdown' if only some of the fan-out printers are shutdown). >> >> >>The explanation of the 'stopped' state on page 89 of the Model document >>says (in its entirity of two paragraphs): >> >>'5' 'stopped': If a Printer receives a job (whose required resources >are >>ready) while in this state, such a job SHALL transit into the pending >state >>immediately. Such a job SHALL transit into the processing state only >after >>some human fixes the problem that stopped the printer and after jobs >ahead >>of it complete printing. The "printer-state-reasons" attribute SHALL >>contain at least one reason, e.g. media-jam, which prevents it from >either >>processing the current job or transitioning a pending job to the >processing >>state. >> >>Note: if a Printer controls more than one output device, the above >>definition implies that a Printer is stopped only if all output devices >are >>stopped. Also, it is tempting to define stopped as when a sufficient >>number of output devices are stopped and leave it to an implementation >to >>define the sufficient number. But such a rule complicates the >definition >>of stopped and processing. For example, with this alternate definition >of >>stopped, a job can move from idle to processing without human >intervention, >>even though the Printer is stopped. >> >> >> >>Does the Model document need any futher clarification? >> >>Tom > > > > >______________________________________________________ >Get Your Private, Free Email at http://www.hotmail.com > > From ipp-archive Mon Mar 16 21:00:09 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA10159 for ipp-outgoing; Mon, 16 Mar 1998 20:50:43 -0500 (EST) Message-ID: <350DD604.8093BAD4@underscore.com> Date: Mon, 16 Mar 1998 20:46:44 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Tom Hastings CC: Puru Bish , ipp@pwg.org Subject: Re: IPP> Re: IPP- Printer state References: <3.0.1.32.19980316162536.00a409d0@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Yes, I suppose your summary is correct, Tom. However, I get the feeling Puru is asking about an embedded server implementation, one in which the IPP server is embedded within the printer. If this is true, then the error return should be the infamous "too busy" error code, the one that Randy is working on (I believe). ...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 -- ---------------------------------------------------------------------- Tom Hastings wrote: > > At 12:04 03/12/1998 PST, Puru Bish wrote: > > > >Thanks, Tom for clarifying the issue. > > > >I still have a question - should an IPP server behave the same > >way even when it does not spool any job? > > You mean what should an IPP Printer object implemented in a server > that does not spool jobs, but forwards jobs onto a single device directly > (perhaps using IPP or some other device protocol), but the device > to which it forwards jobs is shutdown? > > I would think that the following response might be the best: > > The server would reject the Create-Job and return the error code: > 'server-error-service-unavailable'. > Then the client could query the Printer's "printer-state" and see 'stopped' > and the Printer's "printer-state-reasons" and see 'error-shutdown'. > > Do others agree? > > Tom > > > > >-PB > > > >>From hastings@cp10.es.xerox.com Wed Mar 11 17:57:09 1998 > > > >>Yes, the Printer object implemented in a server object does accept the > >>job even though the device is powered down. > >> > >>And the requester MAY get an indication that there is a problem, > >because > >>the job's OPTIONAL "job-state-reason" attribute that MAY be returned in > >the > >>Print-Job response containing the value: 'printer-stopped' > >>(or 'printer-stopped-partly' in the case that only some of the fan-out > >>printers are stopped). Unfortunately, the requeseter will NOT get this > >>indication in the response, if the IPP Printer object does not > >implement > >>the OPTIONAL "job-state-reasons" attribute. > >> > >>The client can then query the Printer's "printer-state" > >>and "printer-state-reasons" attribute and see that the "printer-state" > >>is 'stopped' and the "printer-state-reasons" is 'error-shutdown' > >>('warning-shutdown' if only some of the fan-out printers are shutdown). > >> > >> > >>The explanation of the 'stopped' state on page 89 of the Model document > >>says (in its entirity of two paragraphs): > >> > >>'5' 'stopped': If a Printer receives a job (whose required resources > >are > >>ready) while in this state, such a job SHALL transit into the pending > >state > >>immediately. Such a job SHALL transit into the processing state only > >after > >>some human fixes the problem that stopped the printer and after jobs > >ahead > >>of it complete printing. The "printer-state-reasons" attribute SHALL > >>contain at least one reason, e.g. media-jam, which prevents it from > >either > >>processing the current job or transitioning a pending job to the > >processing > >>state. > >> > >>Note: if a Printer controls more than one output device, the above > >>definition implies that a Printer is stopped only if all output devices > >are > >>stopped. Also, it is tempting to define stopped as when a sufficient > >>number of output devices are stopped and leave it to an implementation > >to > >>define the sufficient number. But such a rule complicates the > >definition > >>of stopped and processing. For example, with this alternate definition > >of > >>stopped, a job can move from idle to processing without human > >intervention, > >>even though the Printer is stopped. > >> > >> > >> > >>Does the Model document need any futher clarification? > >> > >>Tom > > > > > > > > > >______________________________________________________ > >Get Your Private, Free Email at http://www.hotmail.com > > > > From ipp-archive Tue Mar 17 12:35:13 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA25869 for ipp-outgoing; Tue, 17 Mar 1998 12:32:45 -0500 (EST) Message-ID: <350EB3B6.D12B459C@underscore.com> Date: Tue, 17 Mar 1998 12:32:38 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: IPP Mailing List Subject: IPP> [Fwd: I-D ACTION:draft-ietf-disman-notif-log-mib-02.txt] Content-Type: multipart/mixed; boundary="------------CD32AB3A5ED4F392253A206D" Sender: ipp-owner@pwg.org Precedence: bulk This is a multi-part message in MIME format. --------------CD32AB3A5ED4F392253A206D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit FYI... --------------CD32AB3A5ED4F392253A206D Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by uscore.underscore.com (8.8.4/8.7.2) with ESMTP id KAA16919 for ; Tue, 17 Mar 1998 10:56:44 -0500 (EST) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id KAA22764; Tue, 17 Mar 1998 10:53:18 -0500 (EST) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id KAA13430 for ; Tue, 17 Mar 1998 10:53:02 -0500 (EST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id KAA10005 for ; Tue, 17 Mar 1998 10:53:00 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA03783; Tue, 17 Mar 1998 10:52:55 -0500 (EST) Message-Id: <199803171552.KAA03783@ns.ietf.org> Mime-Version: 1.0 To: IETF-Announce: ; Cc: disman@nexen.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-disman-notif-log-mib-02.txt Date: Tue, 17 Mar 1998 10:52:53 -0500 Sender: cclark@cnri.reston.va.us Content-Type: Multipart/Mixed; Boundary="NextPart" --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Management Working Group of the IETF. Title : Notification MIB Author(s) : B. Stewart Filename : draft-ietf-disman-notif-log-mib-02.txt Pages : 15 Date : 13-Mar-98 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing SNMP notifications. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-disman-notif-log-mib-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-disman-notif-log-mib-02.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@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-disman-notif-log-mib-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980316082325.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-notif-log-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-notif-log-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980316082325.I-D@ietf.org> --OtherAccess-- --NextPart-- --------------CD32AB3A5ED4F392253A206D-- From ipp-archive Tue Mar 17 13:25:11 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA26543 for ipp-outgoing; Tue, 17 Mar 1998 13:23:02 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'imcdonal@eso.mc.xerox.com'" , Joe_Filion@mc.xerox.com, ipp@pwg.org, jmp@pwg.org Subject: RE: IPP> SNMPv3 unsuited for IPP/JMP Notifications Date: Tue, 17 Mar 1998 10:23:01 -0800 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 I am not sure what the dissenting opinion is, whether SNMPv3 is not the correct solution? Or, is the proposed notification MIB not the right solution? If SNMP is the wrong solution, then any SNMP-accessed MIB would be the wrong solution, including the JAM MIB. I will try and address the concerns outlined below, with matching numbers. 1) Scopes of interest are still supported by OID subtree specifications; it's the intended notification recipients that are identified and matched by the UTF-8 tag. 2) Registration lifetimes would be a good idea. It's quite possible for an IPP MIB to augment the notification table with objects that represent registration lifetimes. No need to throw the baby out with the bath water on this one. Since it is an explicit augmentation, the indices would be the same. 3) Indices that appear as SnmpAdminString types are labeled as NOT-ACCESSIBLE, so they should not appear in the response packet of a GET, or GET-BULK. 4) I'm not sure if a brute force search would be required or not (yet). It appears from reading the RFC that this might be the case and I understand how this conclusion could be made. However, I'm not sure that duplicate registrations could be identified solely on the basis of "transport" and "transport-address" matching. This particular scenario would require more study. 5) This rationale does not exist for SNMPv3. This held true only for V2 (and derivatives). All the text about "dual-role entities" from V2 has been removed from the V3 doc set. The V3 specs now generically identify "notification senders" and "notification recipients". The idea of specific functionality being reserved for a "mid-level" manager entity no longer exists. Implementors are free to instrument whatever feature they need, depending upon the type of management (or managed) entity is being constructed. 6) Again, this idea is a V2 idea, the restrictions on "how" a feature is used has been removed from the V3 specifications. See #5 above. Also, I have it on good authority from Jeff Case at SNMP Research, that the effort required to take the V1 trap code base and move it to V3 trap/inform is no great task. A lot of code reuse is possible. Also, V3 informs are as reliable as any other notification mechanism. 7) Again, I have it on first hand communication from Bob Stewart(Cisco), Jeff Case and David Levi(SNMP Research) that their "intent" was never to disallow the type of functionality I have proposed. Rather, it seems like a prudent reuse of all vendors' existing agent code base. This reuse of technology (both in design and existing code) is what I am trying to take advantage of. Given the speed at which SNMPv3 is being adopted, I feel like a lot of vendors are going to want to implement V3 agents anyway. Also, after looking at Ira's proposal for the JAM MIB, there are some ideas present in the JAM MIB that were not included in the standard notification/target MIBs specified in RFC 2273. I think we should include these ideas in whatever we come up with. I don't think we should completely reinvent the wheel here, rather, I think we should come up with a suitable set of additional (non-overlapping) notification features and AUGMENT the standard set. This is because, for a lot of reasons, I think vendors will eventually have to support them anyway to be "V3 compliant" at some point in the future. By the way, I have no SNMP religious affiliation, just a desire to reuse technology. If we find out that our requirements exceed the boundaries of what SNMPv3 and related technology can deliver, then I would be just as happy to pursue another path. But I think we need to study this stuff a little more before taking any radical direction change. Randy -----Original Message----- From: imcdonal@eso.mc.xerox.com [SMTP:imcdonal@eso.mc.xerox.com] Sent: Sunday, March 15, 1998 4:35 PM To: Joe_Filion@mc.xerox.com; ipp@pwg.org; jmp@pwg.org Subject: IPP> SNMPv3 unsuited for IPP/JMP Notifications Copies To: ipp@pwg.org jmp_pwg.org Hi folks, Sunday (15 March 1998) Extracted below (with line numbers) is summary information from the five SNMPv3 documents (RFC 2271 to RFC 2275, January 1998). As Randy Turner has argued, it IS possible to use a small subset (Target and Notification MIBs in RFC 2273) of the SNMPv3 MIB modules (there are a total of 7 SNMPv3 MIB modules) to achieve a simple (security-free) SNMP trap registration mechanism (see the 'snmpNotifyBasicCompliance' declaration at line 2773 of RFC 2273). But, the functionality provided is INFERIOR in important ways to that provided by the JAM (Job Async Monitor) MIB that Joe Filion and I posted on Wednesday (4 March 1998) or to my informal understanding of the IBM method presented by Harry Lewis during last week's PWG monthly meeting in Austin, TX. 1) The JAM MIB and Historic SNMP Party MIB (RFC 1447) support scope (traps of 'interest') specified as object identifier subtrees. The SNMPv3 Target/Notification MIBs support scope only by short (32 character) UTF-8 tags, which are NOT standardized by SNMPv3 and (due to their length) are NOT amenable to standardization. 2) The JAM MIB supports automatic trap deregistration specified as 'DateAndTime'. The SNMPv3 Target/Notification MIBs do NOT support automatic trap deregistration at all! 3) The JAM MIB supports simple integer indices for all 'read-create' object groups (written by a remote client). The SNMPv3 Target/Notification MIBs support indices ONLY as (32 character) UTF-8 'SnmpAdminString' values, seriously restricting the number of SNMP objects which can be transferred in a single packet. Since SNMP runs over UDP (in the Internet suite) and there is no 'chunking' for SNMP requests, this limitation is significant! 4) The JAM MIB supports a 'read-only' lookup table (maintained by the SNMP agent on the device) which provides direct lookup from SNMP transport domain and transport address to a client (target) trap registration entry (to avoid duplicate registrations). But, the SNMPv3 Target/Notification MIBs support only brute force (ie, read the entire Target table) for this important functionality! 5) The JAM MIB scales well to a very large number of (end-user) trap client (target) registrations. But, the SNMPv3 Target/Notification MIBs do not scale well. They are intended ONLY for use by network management stations! 6) Randy has suggested that SNMPv2/SNMPv3 'Inform' requests/responses could be used for (questionably) 'reliable' event notification. But, 'Inform' is intended by the SNMPv3 developers to be used ONLY for reporting up a hierarchy of network management stations! Also, 'Inform' is not defined in SNMPv1, so the huge installed base of SNMP agents which (almost exclusively) speak SNMPv1 cannot use 'Inform'. 7) Lastly, as SNMP agent toolkits become available from software tool vendors, any 'local' use of SNMPv3 Target/Notification MIBs by the printer industry vendors will inevitably conflict with the very different intent of the SNMPv3 developers. Recall why the Job Mon MIB is a PWG standard and NOT an IETF standard! As I hope most of you know, I'm dedicated to the use of standards where available and applicable. But the SNMPv3 MIBs were never intended to be used by many clients. They simply aren't appropriate to the problem of trap registration for PWG Job Mon MIB and IETF/PWG Printer MIB traps. Cheers, - Ira McDonald (High North, outside consultant at Xerox) ------------------------------------------------------------------------ **** SNMPv3 Documents **** rfc2271.txt: Architecture for Describing SNMP Management Frameworks - 38-44: This document describes an architecture for describing SNMP Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. The major portions of the architecture are an SNMP engine containing a Message Processing Subsystem, a Security Subsystem and an Access Control Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data. - 1913: SNMP-FRAMEWORK-MIB DEFINITIONS ::= BEGIN - 2420: snmpFrameworkMIBCompliance MODULE-COMPLIANCE rfc2272.txt: Message Processing and Dispatching for SNMP - 41-46: This document describes the Message Processing and Dispatching for SNMP messages within the SNMP architecture [RFC2271]. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. - 810: SNMP-MPD-MIB DEFINITIONS ::= BEGIN - 936: snmpMPDCompliance MODULE-COMPLIANCE - 976: SNMPv3MessageSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN rfc2273.txt: SNMPv3 Applications - 37-44: This memo describes five types of SNMP applications which make use of an SNMP engine as described in [RFC2271]. The types of application described are Command Generators, Command Responders, Notification Originators, Notification Receivers, and Proxy Forwarders. This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. - 1561: SNMP-TARGET-MIB DEFINITIONS ::= BEGIN - 2209: snmpTargetCommandResponderCompliance MODULE-COMPLIANCE - 2305: SNMP-NOTIFICATION-MIB DEFINITIONS ::= BEGIN - 2773: snmpNotifyBasicCompliance MODULE-COMPLIANCE - 2881: snmpNotifyBasicFiltersCompliance MODULE-COMPLIANCE - 2894: snmpNotifyFullCompliance MODULE-COMPLIANCE - 2960: SNMP-PROXY-MIB DEFINITIONS ::= BEGIN - 3242: snmpProxyCompliance MODULE-COMPLIANCE rfc2274.txt: User-based Security Model (USM) for SNMPv3 - 37-41: This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFC2271]. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model. - 861: USMSecurityParametersSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN - 1701: SNMP-USER-BASED-SM-MIB DEFINITIONS ::= BEGIN - 2439: usmMIBCompliance MODULE-COMPLIANCE rfc2275.txt: View-based Access Control Model (VACM) for SNMPv3 - 38-42: This document describes the View-based Access Control Model for use in the SNMP architecture [RFC2271]. It defines the Elements of Procedure for controlling access to management information. This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model. - 541: SNMP-VIEW-BASED-ACM-MIB DEFINITIONS ::= BEGIN - 1356: vacmMIBCompliance MODULE-COMPLIANCE ------------------------------------------------------------------------ From ipp-archive Tue Mar 17 16:20:14 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA28000 for ipp-outgoing; Tue, 17 Mar 1998 16:17:31 -0500 (EST) Message-Id: <3.0.1.32.19980317131137.00ca3660@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 17 Mar 1998 13:11:37 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> I-D ACTION:draft-iesg-iana-considerations-03.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk FYI, Carl-Uno -- >To: IETF-Announce:; >Cc: iesg@ns.ietf.org >From: Internet-Drafts@ns.ietf.org >Reply-to: Internet-Drafts@ns.ietf.org >Subject: I-D ACTION:draft-iesg-iana-considerations-03.txt >Date: Mon, 16 Mar 1998 05:43:25 PST >Sender: cclark@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the IETF Steering Group Working Group of the IETF. > > Title : Guidelines for Writing an IANA Considerations Section in RFCs > Author(s) : H. Alvestrand, T. Narten > Filename : draft-iesg-iana-considerations-03.txt > Pages : 10 > Date : 13-Mar-98 > > Many protocols make use of identifiers consisting of constants and > other well-known values. Even after a protocol has been defined and > deployment has begun, new values may need to be assigned (e.g., for a > new option type in DHCP, or a new authentication algorithm). To > insure that such quantities have unique values, their assignment must > be administered by a central authority. In the Internet, that role is > provided by the Internet Assigned Numbers Authority (IANA). > > In order for the IANA to manage a given numbering space prudently, it > needs guidelines describing the conditions under which new values can > be assigned. If the IANA is expected to play a role in the management > of a numbering space, the IANA must be given clear and concise > instructions describing that role. This document discusses issues > that should be considered in formulating an identifier assignment > policy and provides guidelines to document authors on the specific > text that must be included in documents that place demands on the > IANA. > >Internet-Drafts are available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-iesg-iana-considerations-03.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-iesg-iana-considerations-03.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@ietf.org. In the body type: > "FILE /internet-drafts/draft-iesg-iana-considerations-03.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > > 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 Mar 17 16:30:13 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA28612 for ipp-outgoing; Tue, 17 Mar 1998 16:28:54 -0500 (EST) Message-Id: <3.0.1.32.19980317132250.00ca9b30@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 17 Mar 1998 13:22:50 PST To: ipp@pwg.org From: Daniel Manchala (by way of Carl-Uno Manros ) Subject: IPP> Draft available from Rohit Khare. Upgrading to TLS within HTTP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk FYI, this should also show up as an I-D shortly. Carl-Uno -- >Subject: Repost: Upgrading to TLS within HTTP >Date: Mon, 16 Mar 1998 15:50:05 PST >From: Rohit Khare > > >Upgrading to TLS Within HTTP > > _Rohit Khare_, UC Irvine, March 16, 1998 > > _________________________________________________________________ > > 0. Motivation > > At the [1]Washington DC IETF meeting last year, the Applications Area > Directors indicated they would like to see a mechanism for applying > Transport Layer Security [TLS] within an [2]HTTP connection, at the > same port, instead of only being able to recommend a distinct port > (443) and scheme (https). The TLS working group has moved forward with > an extensive draft on properly implementing https > ([3]draft-ietf-tls-https-00), but there is alternate precedent in SMTP > and other applications of TLS ([4]draft-hoffman-smtp-ssl, > [5]draft-newman-tls-imappop-03, [6]murray-auth-ftp-ssl-00). > > There has already been extensive debate on the [7]http-wg , > [8]ietf-tls and [9]ietf-apps-tls mailing lists about the advisability > of permitting optional 'upgrades' to secure connections within the > same channel, primarily focusing on the thread of man-in-the-middle > attacks. Our intent here is not to engage in this debate, but merely > to document a proposed mechanism for doing either with HTTP. Several > applications being built upon HTTP might use this mechanism, such as > the [10]Internet Printing Protocol; we look to them for implementation > guidance. > > 1. Introduction > > TLS, a/k/a SSL (Secure Sockets Layer) establishes a private end-to-end > connection, optionally including strong mutual authentication, using a > variety of cryptosystems. Initially, a handshake phase uses three > subprotocols to set up a record layer, authenticate endpoints, set > parameters, as well as report errors. Then, there is an ongoing > layered record protocol that handles encryption, compression, and > reassembly for the remainder of the connection. The latter is intended > to be completely transparent. For example, there is no dependency > between TLS's record markers and or certificates and HTTP/1.1's > chunked encoding or authentication. > > The need to 'secure' running connections is not merely 'running SSL > over port 80', an early challenge for firewall developers answered by > Ari Luotonen's [11]ssl-tunneling-02 draft in 1995. The HTTP/1.1 spec > reserves CONNECT for future use, deferring to the more recent > [12]draft-luotonen-web-proxy-tunneling-00 proposal. This technique > perpetuates the concept that security is indicated by a magic port > number -- CONNECT establishes a generic TCP tunnel, so port number is > the only way to specify the layering of TLS with HTTP (https) or with > NTTP (snews). > > Instead, the preferred mechanism to initiate and insert TLS in an > HTTP/1.1 session should be the Upgrade: header, as defined in section > 14.42 of rev-03. Ideally, TLS-capable clients should add "Upgrade: > TLS/1.0" to their initial request, and TLS-capable servers may reply > with "101 Switching Protocol", complete the handshake, and continue > with the "normal" response to the original request. However, the > specification quoth: > > "The Upgrade header field only applies to switching > application-layer protocols upon the existing transport-layer > connection." > > Aside from this minor semantic difference -- invoking TLS indeed > changes the existing transport-layer connection -- this is an ideal > application of Upgrade. This technique overlays the TLS-request on an > HTTP method; requires client-initiation, and allows servers to choose > whether or not to make the switch. Like the other examples of > TLS-enabled application protocols, the original session is preserved > across the TLS handshake; secured communications resumes with a > servers' reply. > > The potential for a man-in-the-middle attack (wherein the "TLS/1.0" > upgrade token is stripped out) is precisely the same as for mixed > http/https use: > > 1. Removing the token is similar to rewriting web pages to change > https:// links to http:// links. > 2. The risk is only present if the server is willing to vend that > information over an insecure channel in the first place > 3. If the client knows for a fact that a server is TLS-compliant, it > can insist on it by only connecting as https:// or by only sending > an upgrade request on a no-op method like OPTIONS. > > Furthermore, for clients which do not actively try to invoke TLS, > servers can use Upgrade: to advertise TLS compliance, too. Since > TLS-compliance should be considered a feature of the server and not > the resource at hand, it should be sufficient to send it once, and let > clients cache that fact. > > 2. Potential Solution > > Define "TLS/x.y" as a reference to the TLS specification > ([13]draft-ietf-tls-protocol-03), with x and y bound to its major and > minor version numbers. Section 6.2.1 of the current draft explains why > the TLS version would currently be defined as 1.0, not the actual > parameters on the wire (which is "3.1" for backwards compatibility > with SSL3). > > An HTTP client may initiate an upgrade by sending "TLS/x.y" as one of > the field-values of the Upgrade: header. The origin-server MAY respond > with "101 Switching Protocols"; if so it MUST include the header > "Upgrade: TLS/x.y" to indicate what it is switching to. > > Servers which can upgrade to TLS MAY include the header "TLS/x.y" in > an Upgrade response header to inform the client; servers SHOULD > include such indication in response to any OPTIONS request. > > Similarly, servers MAY require clients to switch to TLS first by > responding with a new error code "418: Upgrade Required", which MUST > specify the protocol to be supported. @@ This is a change to 'core' > HTTP; if, processwise, it's too difficult to slip in a general-purpose > error code, we may have to fall-back to "418: TLS Required". > > Upgrade is a hop-by-hop header (Section 13.5.1), so each intervening > proxy which supports TLS MUST also request the same version of TLS/x.y > on its subsequent request. Furthermore, any caching proxy which > supports TLS MUST NOT reply from its cache when TLS/x.y has been > requested (although clients are still recommended to explicitly > include "Cache-control: no-cache"). > > Note: proxy servers may be able to request or initiate a TLS-secured > connection, e.g. the outgoing or incoming firewall of a trusted > subnetwork. > > 3. Next Steps > > I could proceed by formalizing Section 2 as an Internet-Draft, but > under the jurisdiction of which IETF working group? Furthermore, I do > not have access nor personal interest in a TLS-capable client/server > pair to experiment with. > > N.B. I believe this work is completely separate from HTTP-extension > work proceeding in the web evolution / http-extension working group. > This uses Upgrade for its stated purpose -- to switch to an entirely > different protocol -- not to define or modify HTTP methods and > semantics. > > Please watch [14]http://www.ics.uci.edu/~rohit/http-tls for updates of > this document and any Internet-Drafts relating to this proposal. > > 4. Acknowledgments > > Thanks to Paul Hoffman for his work on the STARTTLS command extension > for ESMTP. Thanks to Roy Fielding for assistance with the rationale > behind Upgrade: and OPTIONS. > > 5. References > >References > > 1. http://www.ics.uci.edu/pub/ietf/http/hypermail/1997q4/0495.html > 2. http://www.w3.org/Protocols/HTTP/1.1/draft-ietf-http-v11-spec-rev-03.txt > 3. http://ds.internic.net/internet-drafts/draft-ietf-tls-https-00.txt > 4. http://www.imc.org/ietf-apps-tls/draft-hoffman-smtp-ssl > 5. http://ds.internic.net/internet-drafts/draft-newman-tls-imappop-03.txt > 6. http://www.consensus.com/ietf-tls/murray-auth-ftp-ssl-00.txt > 7. http://www.ics.uci.edu/pub/ietf/http/ > 8. http://www.consensus.com/ietf-tls/ > 9. http://www.imc.org/ietf-apps-tls/ > 10. http://www.pwg.org/ipp/index.html > 11. http://www.consensus.com/ietf-tls/ssl-tunneling-02.txt > 12. http://ds.internic.net/internet-drafts/draft-luotonen-web-proxy-tunneling-00 .txt > 13. http://www.consensus.com/ietf-tls/tls-protocol-03.txt > 14. http://www.ics.uci.edu/~rohit/http-tls > > From ipp-archive Tue Mar 17 17:37:22 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA29620 for ipp-outgoing; Tue, 17 Mar 1998 17:28:14 -0500 (EST) Message-Id: <3.0.1.32.19980317142120.0122eea0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 17 Mar 1998 14:21:20 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> I-D ACTION:draft-ietf-svrloc-printer-scheme-02.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk FYI, Scott Isaacson is co-author on this one. Carl-Uno -- >To: IETF-Announce:; >Cc: srvloc@srvloc.org >From: Internet-Drafts@ns.ietf.org >Reply-to: Internet-Drafts@ns.ietf.org >Subject: I-D ACTION:draft-ietf-svrloc-printer-scheme-02.txt >Date: Tue, 17 Mar 1998 07:13:47 PST >Sender: cclark@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Service Location Protocol Working Group of the IETF. > > Title : Definition of printer: URLs for use with > Service Location > Author(s) : S. Isaacson, P. St. Pierre > Filename : draft-ietf-svrloc-printer-scheme-02.txt > Pages : 11 > Date : 16-Mar-98 > > This document defines the printer service type and the attributes > associated with it. This template is designed to be used in > conjuction with the Service Location Protocol [1], but may be > used with any directory service supporting attribute/value pair > registration. > > The printer service type is designed as an abstract service type. It > is expected that printers advertised with the printer type may be > accessible by one or more protocols. IPP and lpr are a two examples > of printing protocols that may be used to perform the actual printing > function. > >Internet-Drafts are available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-svrloc-printer-scheme-02.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-svrloc-printer-scheme-02.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@ietf.org. In the body type: > "FILE /internet-drafts/draft-ietf-svrloc-printer-scheme-02.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > > 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 Mar 17 19:25:23 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA00968 for ipp-outgoing; Tue, 17 Mar 1998 19:19:01 -0500 (EST) Message-Id: <3.0.1.32.19980317161311.0125d100@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 17 Mar 1998 16:13:11 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> I-D ACTION:draft-ietf-disman-event-mib-03.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk FYI, Event MIB anyone? Carl-Uno --- >Cc: disman@nexen.com >From: Internet-Drafts@ns.ietf.org >Reply-to: Internet-Drafts@ns.ietf.org >Subject: I-D ACTION:draft-ietf-disman-event-mib-03.txt >Date: Tue, 17 Mar 1998 07:15:19 PST >Sender: cclark@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Distributed Management Working Group of the IETF. > > Title : Event MIB > Author(s) : B. Stewart > Filename : draft-ietf-disman-event-mib-03.txt > Pages : 23 > Date : 16-Mar-98 > >This memo defines an experimental portion of the Management Information >Base (MIB) for use with network management protocols in the Internet >community. In particular, it describes managed objects used for >managing monitoring of MIB objects and taking action through events. > >Internet-Drafts are available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-disman-event-mib-03.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-disman-event-mib-03.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@ietf.org. In the body type: > "FILE /internet-drafts/draft-ietf-disman-event-mib-03.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > > 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 Mar 17 19:25:24 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA01399 for ipp-outgoing; Tue, 17 Mar 1998 19:22:28 -0500 (EST) Message-Id: <3.0.1.32.19980317161636.00cef100@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 17 Mar 1998 16:16:36 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> I-D ACTION:draft-ietf-applmib-mib-07.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk FYI, They keep coming in.. Carl-Uno -- >To: IETF-Announce:; >Cc: applmib@emi-summit.com >From: Internet-Drafts@ns.ietf.org >Reply-to: Internet-Drafts@ns.ietf.org >Subject: I-D ACTION:draft-ietf-applmib-mib-07.txt >Date: Tue, 17 Mar 1998 07:56:24 PST >Sender: cclark@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Application MIB Working Group of the IETF. > > Title : Application Management MIB > Author(s) : J. Saperia, C. Krupczak, R. Presuhn, C. Kalbfleisch > Filename : draft-ietf-applmib-mib-07.txt > Pages : 62 > Date : 16-Mar-98 > > This memo defines an experimental portion of the Management > Information Base (MIB) for use with network management protocols in > the Internet Community. In particular, it defines objects used for > the management of applications. This MIB complements the System > Application MIB, providing for the management of applications' common > attributes which could not typically be observed without the > cooperation of the software being managed. > >Internet-Drafts are available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-applmib-mib-07.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-applmib-mib-07.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@ietf.org. In the body type: > "FILE /internet-drafts/draft-ietf-applmib-mib-07.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > > 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 Mar 17 20:00:18 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA02224 for ipp-outgoing; Tue, 17 Mar 1998 19:56:49 -0500 (EST) Message-Id: <3.0.1.32.19980317165100.009b0970@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 17 Mar 1998 16:51:00 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - "IPP Job Openings" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk All, In last week's phone conference we discussed the need for additional volonteers to take on new tasks within the WG. In particular, we are looking to fill the following vacancies: 1) Somebody to take over the secretary job for the PWG IPP phone conferences, as Don Wright has said that he has too many other commitments to keep up this task. Means that you need to regularly attend the phone conferences. 2) A champion and preferably editor (sounds better than the earlier WHIP title) for the IPP Notification task. 3) A champion and preferably editor for a new IPP MIB task. 4) A champion for the host-to-device task (this is currently outside the scope of the IETF WG). Please respond to the DL or to me personally, new faces are obviously welcome. If we cannot find people prepared to take on these tasks, we are in trouble! (Curious to see if this goes through the spam filters) 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 Mar 17 21:00:15 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA03355 for ipp-outgoing; Tue, 17 Mar 1998 21:00:01 -0500 (EST) Message-Id: <3.0.1.32.19980317175827.010a5a30@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 17 Mar 1998 17:58:27 PST To: Robert Herriot , Carl Kugler From: Tom Hastings Subject: Re: IPP> MOD Need Clarification re: Type4 keywords [input fo Cc: In-Reply-To: <199803070031.QAA18149@woden.eng.sun.com> References: <5030100018210342000002L022*@MHS> 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 disagree that we should get rid of one of the implementor choices for the 'type4 keyword | name' syntaxes of several attributes that administrators are likely to define additional values, such as "media", "job-hold-until",=20 and "job-sheets", so maybe we need to clarify the Model document. I agree that the difference between a name and a keyword, is that the name is not localized by the client, while a keyword should be. If the client doesn't find the keyword in its table of keywords to localized names, then the client just displays the keyword as is (and hopes that the user understands English, which is widely understood). I also agree that initially, administrators will defines new values as names, not keywords, since there currently isn't a way for clients to discover new localized names for keywords that the client was not built with. On the other hand, we need to specify a way in the future for a client to discover localized names for keywords in the server that that client doesn't have a localized name for. =20 When such a discovery mechanism is provided, then an IPP object could even support an ambituous multi-lingual administrator to be able to define new keyword values and several localized names in different languages that the client could query. So having attributes specified as 'type4 keyword | name' allows for this future possibility. But it would help to clarify that until an IPP object supports querying the name of a keyword in a specified human language, the implementors SHOULD support allowing administrators to add new attribute values by defining additional names, not keywords, to the IPP object. Tom At 16:34 03/06/1998 PST, Robert Herriot wrote: >I agree with you that there is some confusion here, particularly where the= =20 >document says "An administrator MAY define additional values using the=20 >'name' or 'keyword' attribute syntax, depending on implementation." [ line= =20 >2248, section 4.2.3]. > >Our intent was to allow an administrator to add new values locally. I have= =20 >always assumed that a GUI would convert the standard keywords into some=20 >localized word or phrase, but that a GUI would display values created by an= =20 >administrator as is (to keep things simple). Attributes that allow new=20 >administator values need to distinguish between those values that should be= =20 >converted and those that should not. > >But the statement in the model document leaves me confused because it says= =20 >that an administrator can call a new value a keyword or a name, and that=20 >some implementation may not support both ways. This makes me think that= one=20 >of these choices needs to be removed from the standard. The solution= should=20 >be one of the two below. > > o We eliminate the concept of type 4 keywords, and let "name" be the way= =20 > administrators make extensions. We should encourage GUIs to localize= =20 > keywords and display names as is. All attributes whose values are type= 4=20 > keywords currently have "name" as an alternate type. So we change >their > > type to "type 3 keyword | name" > > o We eliminate "name" from the attributes that are "type 4 keyword |=20 > name" and let a language be associated with keywords. We encourage= GUIs >to=20 > leave keywords as is if they aren't in the localization table. >=20 >I like the first option best. It still leaves two data types for some=20 >attributes, but it is better than allowing a language with keywords when=20 >most have no language associated with them. > > >Bob Herriot > >At 01:46 PM 3/5/98 , Carl Kugler wrote: >>Tom- >> >>> Why are there attributes that have both 'type4 keyword' and 'name' >>> (and hence 'nameWithLanguage) data types? >> >>I think that this is a new, different question, and a good one.=A0 Aren't these >>the only attributes for which a multi-valued attribute instance may have a >>mixture of its defined attribute syntaxes? >> >>If true, collapsing the redundant '(type4 keyword | name)' to 'name',= would >>allow one attribute syntax tag to apply to a whole attribute, even a >>multi-valued one. It would also make life easier for implementers trying= to >use >>strong typing. >> >>=A0 -Carl >> >> >> >>hastings@cp10.es.xerox.com on 02/09/98 04:46:51 PM >>Please respond to hastings@cp10.es.xerox.com @ internet >>To: ipp@pwg.org @ internet, Carl Kugler/Boulder/IBM@ibmus >>cc: >>Subject: Re: IPP> MOD Need Clarification re: Type4 keywords [input fo >> >> >>At 14:06 02/02/1998 PST, Carl Kugler wrote: >>>Attributes with type 4 keywords also allow the 'name' attribute syntax= for >>>administrator defined names.=A0 Keywords SHALL be in U.S. English, but >>attributes >>>that are indicated to have the 'name' attribute syntax also automatically >>have >>>the 'nameWithLanguage' attribute syntax. >>> >>>So in general, attributes with type 4 keywords can use the Language Override >>>Mechanism? >> >>Correct, but because the 13 attributes that have 'type 4 keyword' data= type, >>also have the 'name' data type: >> >>=A0 +-------------------+----------------------+----------------------+ >>=A0 | job-hold-until=A0=A0=A0 | job-hold-until-=A0=A0=A0=A0=A0= |job-hold-until-=A0=A0=A0=A0=A0=A0 | >>=A0 | (type4 keyword |=A0 |=A0 default=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= | supported=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | >>=A0 |=A0=A0=A0 name)=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 (type4 keyword |=A0= =A0=A0 |(1setOf=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | >>=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0= name)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | type4 keyword | name)| >>=A0 +-------------------+----------------------+----------------------+ >>=A0 | job-sheets=A0=A0=A0=A0=A0=A0=A0 | job-sheets-default=A0=A0= |job-sheets-supported=A0 | >>=A0 | (type4 keyword |=A0 | (type4 keyword |=A0=A0=A0=A0= |(1setOf=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | >>=A0 |=A0=A0=A0 name)=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0= name)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | type4 keyword | name)| >>=A0 +-------------------+----------------------+----------------------+ >> >>=A0 +-------------------+----------------------+----------------------+ >>=A0 | media=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | media-default=A0=A0=A0= =A0=A0=A0=A0 | media-supported=A0=A0=A0=A0=A0 | >>=A0 | (type4 keyword |=A0 | (type4 keyword |=A0=A0=A0=A0= |(1setOf=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | >>=A0 |=A0=A0=A0 name)=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0= name)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | type4 keyword | name)| >>=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | >>=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |= media-ready=A0=A0=A0=A0=A0=A0=A0=A0=A0 | >>=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= |(1setOf=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | >>=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | type4= keyword | name)| >>=A0 +-------------------+----------------------+----------------------+ >> >>not just because they have the 'type 4 keyword' data type.=A0 But we >>thought that if an administrator is making up names (which is what >>type 4 keywords are), that an implementation may want to be simple >>and treat them as names in the language that the administrator is >>using or may want to be more complex and allow the administrator to >>define keywords that clients can localize into various languages. >> >>Sounds like something for the FAQ: >> >>Why are there attributes that have both 'type4 keyword' and 'name' >>(and hence 'nameWithLanguage) data types? >> >>Tom >> >>> >>>=A0 -Carl >>> >>> >>=20 > > > From ipp-archive Wed Mar 18 09:15:24 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA15475 for ipp-outgoing; Wed, 18 Mar 1998 09:12:59 -0500 (EST) Message-Id: <350FD595.ABBDCE2@dazel.com> Date: Wed, 18 Mar 1998 08:09:25 -0600 From: James Walker Reply-To: walker@dazel.com Organization: DAZEL Corporation X-Mailer: Mozilla 4.04 [en] (WinNT; I) Mime-Version: 1.0 To: ipp@pwg.org Subject: IPP> [Fwd: I-D ACTION:draft-day-envy-00.txt] Content-Type: multipart/mixed; boundary="------------0E3CD8909EEE3C45E31A750C" Sender: ipp-owner@pwg.org Precedence: bulk This is a multi-part message in MIME format. --------------0E3CD8909EEE3C45E31A750C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit As long as others are forwarding IETF announcements ;-)... Here is yet another view on using HTTP for another protocol (presence information, in this case). And, yes, this one is a negative view of HTTP as a general protocol carrier, for some of the same reasons that we have heard from others. One thing is obvious about this whole subject... people seem to be strongly on one side of the fence or the other. enjoy... ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX --------------0E3CD8909EEE3C45E31A750C Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: Received: from support.dazel.com by dazel.com (4.1/SMI-4.1) id AA16550; Tue, 17 Mar 98 12:42:15 CST Received: from ns.ietf.org by support.dazel.com (8.8.7/dazel) id MAA04200 for ; Tue, 17 Mar 1998 12:42:10 -0600 (CST) Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id NAA11289 for ietf-123-outbound.02@ietf.org; Tue, 17 Mar 1998 13:05:00 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA02444 for ; Tue, 17 Mar 1998 10:15:41 -0500 (EST) Message-Id: <199803171515.KAA02444@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@ns.ietf.org From: Internet-Drafts@ns.ietf.org Reply-To: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-day-envy-00.txt Date: Tue, 17 Mar 1998 10:15:41 -0500 Sender: cclark@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : ''HTTP Envy'' and Presence Information Protocols Author(s) : M. Day Filename : draft-day-envy-00.txt Pages : 3 Date : 16-Mar-98 There are a variety of proposals [Calsyn, Mohr] for building a presence information protocol as a variant or version of HTTP. This document summarizes why I believe that is not a good idea. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-day-envy-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-day-envy-00.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@ietf.org. In the body type: "FILE /internet-drafts/draft-day-envy-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980316143229.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-day-envy-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-day-envy-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980316143229.I-D@ietf.org> --OtherAccess-- --NextPart-- --------------0E3CD8909EEE3C45E31A750C-- From ipp-archive Wed Mar 18 13:18:24 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA16367 for ipp-outgoing; Wed, 18 Mar 1998 13:13:15 -0500 (EST) Message-ID: <35100DC9.321E5501@underscore.com> Date: Wed, 18 Mar 1998 13:09:13 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Carl-Uno Manros CC: ipp@pwg.org, upd@pwg.org Subject: IPP> ADM - Concerns regarding the scopes of the IPP and UPD projects References: <3.0.1.32.19980317165100.009b0970@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Carl-Uno, In your message titled "ADM - 'IPP Job Openings'" (attached below) you listed this item: 4) A champion for the host-to-device task (this is currently outside the scope of the IETF WG). Seems we keep crossing on this particular path, namely, whether the IPP project (of which the IETF IPP WG is part of that project) is supposed to take on the requirements for a true host-to-device protocol. I have stated many, many times in the past that the IPP project should NOT attempt to address the "host-to-device" protocol issue. Instead, the UPD project was formed (by me, back in May '97) for *expressly* this kind of work. IPP is for printing over the Internet. UPD addresses the more critical needs of the intranet, with requirements that far surpass those of the IPP. Let's let UPD take its own course, without placing unnecessary constraints on it from the outstart. Comments from others? ...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: > > All, > > In last week's phone conference we discussed the need for additional > volonteers to take on new tasks within the WG. > > In particular, we are looking to fill the following vacancies: > > 1) Somebody to take over the secretary job for the PWG IPP phone > conferences, as Don Wright has said that he has too many other commitments > to keep up this task. Means that you need to regularly attend the phone > conferences. > > 2) A champion and preferably editor (sounds better than the earlier WHIP > title) for the IPP Notification task. > > 3) A champion and preferably editor for a new IPP MIB task. > > 4) A champion for the host-to-device task (this is currently outside the > scope of the IETF WG). > > Please respond to the DL or to me personally, new faces are obviously welcome. > > If we cannot find people prepared to take on these tasks, we are in trouble! > > (Curious to see if this goes through the spam filters) > > 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 Mar 18 13:30:30 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA17563 for ipp-outgoing; Wed, 18 Mar 1998 13:27:07 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" , "'upd@pwg.org'" Subject: RE: IPP> ADM - Concerns regarding the scopes of the IPP and UPD p rojects Date: Wed, 18 Mar 1998 10:27:03 -0800 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 thought the UPD study group was formed to talk about print drivers (extending the concept of the GPD concept to the next evel, etc..), and not a host-to-device protocol. I don't recall wire protocols ever brought up in the last couple of meetings. If there is both an application model (GPD, etc) and a wire protocol developed, I would hope there would be two study groups involved, since the expertise on either topic is largely orthogonal. Randy -----Original Message----- From: Jay Martin [SMTP:jkm@underscore.com] Sent: Wednesday, March 18, 1998 10:09 AM To: Carl-Uno Manros Cc: ipp@pwg.org; upd@pwg.org Subject: IPP> ADM - Concerns regarding the scopes of the IPP and UPD projects Carl-Uno, In your message titled "ADM - 'IPP Job Openings'" (attached below) you listed this item: 4) A champion for the host-to-device task (this is currently outside the scope of the IETF WG). Seems we keep crossing on this particular path, namely, whether the IPP project (of which the IETF IPP WG is part of that project) is supposed to take on the requirements for a true host-to-device protocol. I have stated many, many times in the past that the IPP project should NOT attempt to address the "host-to-device" protocol issue. Instead, the UPD project was formed (by me, back in May '97) for *expressly* this kind of work. IPP is for printing over the Internet. UPD addresses the more critical needs of the intranet, with requirements that far surpass those of the IPP. Let's let UPD take its own course, without placing unnecessary constraints on it from the outstart. Comments from others? ...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: > > All, > > In last week's phone conference we discussed the need for additional > volonteers to take on new tasks within the WG. > > In particular, we are looking to fill the following vacancies: > > 1) Somebody to take over the secretary job for the PWG IPP phone > conferences, as Don Wright has said that he has too many other commitments > to keep up this task. Means that you need to regularly attend the phone > conferences. > > 2) A champion and preferably editor (sounds better than the earlier WHIP > title) for the IPP Notification task. > > 3) A champion and preferably editor for a new IPP MIB task. > > 4) A champion for the host-to-device task (this is currently outside the > scope of the IETF WG). > > Please respond to the DL or to me personally, new faces are obviously welcome. > > If we cannot find people prepared to take on these tasks, we are in trouble! > > (Curious to see if this goes through the spam filters) > > 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 Mar 18 13:53:15 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA18399 for ipp-outgoing; Wed, 18 Mar 1998 13:46:14 -0500 (EST) From: don@lexmark.com Message-Id: <199803181846.AA27930@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: rturner@sharplabs.com, jkm@underscore.com Cc: Ipp@Pwg.Org, Upd@Pwg.Org Date: Wed, 18 Mar 1998 13:45:26 -0500 Subject: IPP> Concerns regarding the scopes of the IPP and UPD projects Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@Pwg.Org Precedence: bulk Randy's right on this matter. In fact at the UPD meeting and in the UPD minutes we explicitly excluded protocols from the discussion. The UPD effort is focused generally on generating print PDL not on the means by which it is delivered to the printer. As everyone expects, I don't see the need to create a host-to-printer protocol. I will be posting a draft on using TIP/SI to deliver IPP content from the server (acting as an IPP printer) to the marking device in the next day or so. ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From ipp-archive Wed Mar 18 17:13:56 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA19870 for ipp-outgoing; Wed, 18 Mar 1998 17:06:19 -0500 (EST) Message-Id: <3.0.1.32.19980318140018.00ccde70@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 18 Mar 1998 14:00:18 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Minutes from PWG IPP Phone Conference 980318 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Minutes from PWG IPP Phone Conference 980318 ============================================ Notes taken by Lee Farrell Attendees: Ron Bergman Dataproducts Lee Farrell Canon Information Systems Tom Hastings Xerox Daniel Manchala Xerox Carl-Uno Manros Xerox Larry Masinter Xerox Ira Mcdonald High North Randy Turner Sharp Don Wright Lexmark Steve Zilles Adobe Carl-Uno Manros led the meeting. For today's agenda topic, he said that he would like to review some of the new Internet-Drafts from other IETF Working Groups that might impact the implementation of IPP. We should decide if we need to comment on some of these drafts in the IETF LA meeting. He also hoped to have discussion about the IPP test suite, but Peter Zehler did not join the teleconference. Harlequin has announced that they be showing a preliminary IPP server for their ScriptWorks product at Seybold this week. If somebody is visiting Seybold in NY this week, please give feedback in next week's phone conference. We still have no feedback from IESG. As far as Carl-Uno can tell, Keith Moore (IETF Area Director) is still reading the documents and thinking about comments. Because the IESG is not meeting again until after the LA IETF meeting, we might not have any official statement on the status of the documents at the LA meeting, but we might get some preliminary feedback in time for LA. The group then discussed comments on any of the Internet-Drafts that have recently surfaced? HTTP - draft-ietf-http-v11-spec-rev-03.txt: Page 144-146 list the updates to the HTTP/1.1 document RFC 2068. It didn't seem that anyone had read the document - or at least no one had comments on it. Steve Zilles said that the HTTP Working Group is not planning to have any more meetings, but they are not yet complete with their interoperability testing. draft-ietf-http-ext-mandatory-00.txt: Another document that Carl-Uno discovered is called "Mandatory Extensions to HTTP" lists some additions to HTTP/1.1. Should this be called HTTP/1.2? Carl-Uno will investigate this apparent oxymoron. It appears that the document discusses methods for extending HTTP (similar to PEP-Protocol Extension Protocol.) Carl-Uno believes that the document is not relevant to IPP. Larry Masinter explained that there will be a separate Working Group formed to address HTTP extensions. The document will be updated as part of the new Working Group activity. draft-ietf-http-authentication-01.txt: This is an update of RFC 2069, and only a few minor elements have changed. Daniel does not believe that the changes are significant enough to affect IPP activity. A few changes have been made to the Digest authentication scheme. Daniel will examine this further to see what changes to an implementation are necessary. TLS - draft-ietf-tls-https-01.txt: This is the TLS profile for HTTP 1.1. Can we apply this for IPP as is? It is much more detailed than the two-page reference to TLS currently in the IPP documents. Daniel described the method proposed for upgrading from an "insecure" to a secure HTTP connection. He says there are still doubts about the degree of security it really offers-especially with regard to "man in the middle" attacks. According to Daniel, the document is only 70% complete, and further testing is still required. The group will need to watch this document as it progresses, and evaluate its (potential) impact on IPP. Daniel also called attention to a document named "Upgrading to TLS within HTTP", which is not yet out as an I-D, suggests a solution how TLS can be combined with applications, such as HTTP, to share the same port number. This is in response to requirements from Keith Moore in the previous IETF meeting. It is complementary to the HTTP over TLS document. CONNEG - draft-ietf-conneg-media-features-00.txt: This document is from the newly formed CONNEG (Content Negotiation) Working Group and partly overlaps with IPP. Carl-Uno wants to make sure that this document does not conflict with the IPP printing model and features. According to Carl-Uno, it is more aligned with the Printer MIB than with IPP. Larry Masinter says that this is more due to historical reasons rather than anything else. Larry suggests that the IPP group review the document and submit any proposed changes-especially for the printer section. Why is there only a single token for media type? Is this sufficient? This issue will be raised at the next IPP meeting. draft-ietf-conneg-feature-reg-00.txt: Carl-Uno wants the group to consider if we should adopt the registration methods proposed in this document. Are they appropriate for IPP? Larry Masinter mentioned that there is a CONNEG document describing an algebra for specifying combinations of features. This algebra might be useful for consideration in a future version of IPP. The algerbra seems to allow for combinations, which makes the question about single token for media type redundant. MIB - A couple of new MIB drafts for Events and Applications were mentioned. It was suggested to look further at those drafts in the work on IPP Notifications. HTTP Envy - One Internet-Draft titled "HTTP Envy" has been submitted that suggests that people should not be using HTTP for protocols. However, there are no alternatives suggested in the document. Carl-Uno says that the document might be an interesting read, but he does not think it contains anything new that should cause us to change our decision to use HTTP for IPP. Server Location - draft-ietf-svrloc-printer-scheme-02.txt: SLP is being promoted by the IESG as the "correct" method for locating services. According to Ira, they feel that LDAP is too heavyweight. Scott Isaacson, Randy Turner and Ira McDonald reviewed the SLP draft with the editor (P. St. Pierre), and the document has been updated to incorporate many of the comments that are relevant to the IPP Working Group requirements. Meeting adjourned at 12:00 noon. The next teleconference will be held on March 25 at 10:00am PST. 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 Mar 18 17:58:54 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA20580 for ipp-outgoing; Wed, 18 Mar 1998 17:51:06 -0500 (EST) From: don@lexmark.com Message-Id: <199803182250.AA12953@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA To: ipp@pwg.org Date: Wed, 18 Mar 1998 17:49:42 -0500 Subject: IPP> IPP over TIPSI Mapping Proposal 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 have posted a PWG-DRAFT to the ftp server in PDF and PostScript forma= t. The URLs are: ftp://ftp.pwg.org/pub/pwg/ipp/drafts/draft-pwg-ipp-tipsi-mapping-01.pdf= ftp://ftp.pwg.org/pub/pwg/ipp/drafts/draft-pwg-ipp-tipsi-mapping-01.ps This is NOT an IETF draft and therefore I have chosen NOT to limit my content and writing style to that which can be conveyed in 72 column= lines with monospaced Courier font. The .PS file is formated for an Apple LaserWriter and should therefore print on almost any PostScript printer. If you can't read .PDF or print .PS then I am sorry, but I do= n't have time to make everything "TEXT-ONLY PRETTY." Here's the introduction which explains what the document is and what I'm attempting to communication: ------------------------- The Internet Printing Protocol (IPP) is an application level protocol t= hat can provide distributed printing using Internet tools and technologies.= IPP version 1.0 (IPP/1.0) focuses only on end user functionality. Anyone reading this document for the first time is strongly encouraged to read the IPP document set. The IPP V1.0 model describes a print environment with only an IPP Client and an IPP Printer. It is important, however, to understand tha= t in many real system implementations (which lie underneath the abstracte= d model), there are other components of a print service which are not explicitly defined in the IPP/1.0 model. The following figure illustrat= es where IPP/1.0 fits with respect to these other components. Note that in the figure, the communications means between the IPP Printer?s Print Service and the actual output device is undefined. In some implementations, it is expected that the IPP Server, the Print Service,= and the output device will be contained in one physical entity in which case the communications means among them is unimportant. In what is expected to be a common implementation, the IPP Server and the IPP Print Service are implemented on a general purpose computing platform and the output device is a separate device which marks on the media. In this case, there are many advantages to a standard communications means or protocol to be defined. IEEE Standard 1284.1-1997 defines a robust, general purpose protocol for communications between a "system" and a "printer." This document will describe the application of IEEE Std. 1284.1-1997 to the IPP environment. --------------------- Comments welcome! ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** = From ipp-archive Wed Mar 18 18:43:56 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA21298 for ipp-outgoing; Wed, 18 Mar 1998 18:36:14 -0500 (EST) Message-Id: <199803182334.PAA01641@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 18 Mar 1998 15:38:05 -0800 To: ipp@pwg.org From: Robert Herriot Subject: IPP>MOD Suggest dropping type 4 keyword to simplify implementations Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Tom and I discussed this issue and I agreed to write it up. Summary In the model document, all attributes whose values include "type 4 keyword"s are actually "type 4 keyword | name". Name and type 4 provide two nearly identical mechanisms that will burden IPP implementations and confuse administrators. I propose that we drop type 4 keywords and state that the "name" provides the sole mechanism for an administrator to add new values. If we want to support multiple languages for administrator created names, we can allow name values to stand for a collection of names, each in a different language. But this is not a protocol issue -- it is a server implementation and administrator issue. It becomes a hint to implementors and does not change the protocol. Details The current model document has four levels of keywords from type1 to type 4. We intended that type 4 keywords would be created locally by administrators, and that type 1 through type 3 would be registered with IANA making them publicly known. We intended that a client would map a keyword to some human-readable localized string. For type1 through type 3, the mapping can be canned because the keywords are all known at implementation time. Mapping of type 4 keywords require some ADDITIONAL mapping mechanism that an administrator can configure and clients can download. This idea was proposed in ISO DPA and then removed from DPA. It has never been completed or implemented. I don't think any of us really wants to implement this mechanism. We intended that a client would display a name as is. So a client doesn't have to do anything special when an administor adds a new name. Currently we think of a name as existing in a single language on the server. From the clients standpoint name and text values have a single language associated with them. But from an administrative and server standpoint, we could allow a name value to stand for a collection of name values each in a different language. When a client requests and attributes with a name value, the client would receive the name in the language requested or, if not available, the one in the server's configured language. The same rule could apply to text. For IPP version 1.0, we don't have to deal with the server end of this. All we have to say is that attributes whose values are of "type 4 keyword | name" become "type 3 keyword | name" and we abolish "type 3 keywords". We show indicate that the "name" exists for administrator to add values that are not supported by the implementation. Bob Herriot From ipp-archive Wed Mar 18 21:20:36 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA22676 for ipp-outgoing; Wed, 18 Mar 1998 21:19:35 -0500 (EST) Message-ID: <19980319021924.28425.qmail@hotmail.com> X-Originating-IP: [156.153.255.194] From: "Puru Bish" To: ipp@pwg.org Subject: IPP> Clarification: printer-uri, job-uri Content-Type: text/plain Date: Wed, 18 Mar 1998 18:19:24 PST Sender: ipp-owner@pwg.org Precedence: bulk Hi all, In the IPP Model document, there is no specification for the value-tags of "printer-uri" and "job-uri" in a IPP request. Should these 2 attriubtes have "name" or "uri" value tag? The response may contain a "job-uri" in the Job Object Attributes group (15.3.4.3), and this "job-uri" is defined to have "uri" value-tag (4.3), but can the "job-uri" in a request be the same as that in a response or should they be the same? The second point that needs clarification is that in the "Note:" section of 3.2.1.1 in the IPP Model document, it was mentioned that "The simplest Print-Job Request consists of just the Document Content, the "attributes- charset" and "attributes-natural-language" operation attributes, and nothing else." However, in the description of Print-Job Request of section 15.3.4.3, the "printer-uri" attribute is specified as a MUST (indicated by (M)). Which rule takes precedence here? -PB ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From ipp-archive Thu Mar 19 11:30:43 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA05682 for ipp-outgoing; Thu, 19 Mar 1998 11:26:08 -0500 (EST) From: Carl Kugler To: Subject: Re: IPP>MOD Suggest dropping type 4 keyword to simplify impl Message-ID: <5030100018711512000002L022*@MHS> Date: Thu, 19 Mar 1998 11:25:23 -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 don't understand this sentence: > All > we have to say is that attributes whose values are of "type 4 keywor= d | > name" become "type 3 keyword | name" and we abolish "type 3 keywords= ". -Carl ipp-owner@pwg.org on 03/18/98 04:38:55 PM Please respond to ipp-owner@pwg.org @ internet To: ipp@pwg.org @ internet cc: Subject: IPP>MOD Suggest dropping type 4 keyword to simplify implemen Tom and I discussed this issue and I agreed to write it up. Summary In the model document, all attributes whose values include "type 4 keyw= ord"s are actually "type 4 keyword | name". Name and type 4 provide two near= ly identical mechanisms that will burden IPP implementations and confuse administrators. I propose that we drop type 4 keywords and state that the "name" provi= des the sole mechanism for an administrator to add new values. If we want = to support multiple languages for administrator created names, we can allo= w name values to stand for a collection of names, each in a different language. But this is not a protocol issue -- it is a server implementa= tion and administrator issue. It becomes a hint to implementors and does no= t change the protocol. Details The current model document has four levels of keywords from type1 to ty= pe 4. We intended that type 4 keywords would be created locally by administrators, and that type 1 through type 3 would be registered with= IANA making them publicly known. We intended that a client would map a keyword to some human-readable localized string. For type1 through type 3, the mapping can be canned because the keywords are all known at implementation time. Mapping of = type 4 keywords require some ADDITIONAL mapping mechanism that an administra= tor can configure and clients can download. This idea was proposed in ISO D= PA and then removed from DPA. It has never been completed or implemented. = I don't think any of us really wants to implement this mechanism. We intended that a client would display a name as is. So a client does= n't have to do anything special when an administor adds a new name. Current= ly we think of a name as existing in a single language on the server. From t= he clients standpoint name and text values have a single language associat= ed with them. But from an administrative and server standpoint, we could = allow a name value to stand for a collection of name values each in a differe= nt language. When a client requests and attributes with a name value, the= client would receive the name in the language requested or, if not available, the one in the server's configured language. The same rule c= ould apply to text. For IPP version 1.0, we don't have to deal with the server end of this.= All we have to say is that attributes whose values are of "type 4 keyword = | name" become "type 3 keyword | name" and we abolish "type 3 keywords".= We show indicate that the "name" exists for administrator to add values th= at are not supported by the implementation. Bob Herriot = From ipp-archive Thu Mar 19 15:26:14 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA09928 for ipp-outgoing; Thu, 19 Mar 1998 15:25:17 -0500 (EST) Message-Id: <199803192022.MAA02483@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Thu, 19 Mar 1998 12:26:33 -0800 To: Carl Kugler , From: Robert Herriot Subject: Re: IPP>MOD Suggest dropping type 4 keyword to simplify impl In-Reply-To: <5030100018711512000002L022*@MHS> 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 made a typo. Change the last 3 to a 4. This sentence was repeating what I had said in the second paragraph correctly. The corrected sentence is. All we have to say is that attributes whose values are of=A0 "type 4= keyword | name" become=A0 "type 3 keyword | name" and we abolish "type 4 keywords". At 08:25 AM 3/19/98 , Carl Kugler wrote: >I don't understand this sentence: > >> All >> we have to say is that attributes whose values are of=A0 "type 4 keyword= | >> name" become=A0 "type 3 keyword | name" and we abolish "type 3 keywords". > >=A0 -Carl > > > > >ipp-owner@pwg.org on 03/18/98 04:38:55 PM >Please respond to ipp-owner@pwg.org @ internet >To: ipp@pwg.org @ internet >cc: >Subject: IPP>MOD Suggest dropping type 4 keyword to simplify implemen > > >Tom and I discussed this issue and I agreed to write it up. > >Summary > >In the model document, all attributes whose values include "type 4= keyword"s >are actually "type 4 keyword | name".=A0 Name and type 4 provide two nearly >identical mechanisms that will burden IPP implementations and confuse >administrators. > >I propose that we drop type 4 keywords and state that the "name"=A0= provides >the sole mechanism for an administrator to add new values.=A0 If we want to >support multiple languages for administrator created names, we can allow >name values to stand for a collection of names, each in a different >language. But this is not a protocol issue -- it is a server implementation >and administrator issue.=A0 It becomes a hint to implementors and does not >change the protocol. > >Details > >The current model document has four levels of keywords from type1 to type= 4. > We intended that type 4 keywords would be created locally by >administrators, and that type 1 through type 3 would be registered with= IANA >making them publicly known. > >We intended that a client would map a keyword to some human-readable >localized string.=A0 For type1 through type 3, the mapping can be canned >because the keywords are all known at implementation time.=A0 Mapping of= type >4 keywords require some ADDITIONAL mapping mechanism that an administrator >can configure and clients can download. This idea was proposed in ISO DPA >and then removed from DPA. It has never been completed or implemented. I >don't think any of us really wants to implement this mechanism. > >We intended that a client would display a name as is.=A0 So a client= doesn't >have to do anything special when an administor adds a new name. Currently= we >think of a name as existing in a single language on the server.=A0 From the >clients standpoint name and text values have a single language associated >with them.=A0 But from an administrative and server standpoint, we could= allow >a name value to stand for a collection of name values each in a different >language.=A0 When a client requests and attributes with a name value, the >client would receive the name in the language requested or, if not >available, the one in the server's configured language. The same rule could >apply to text. > >For IPP version 1.0, we don't have to deal with the server end of this. All >we have to say is that attributes whose values are of=A0 "type 4 keyword | >name" become=A0 "type 3 keyword | name" and we abolish "type 3 keywords".= =A0 We >show indicate that the "name" exists for administrator to add values that >are not supported by the implementation. > >Bob Herriot >=20 From ipp-archive Fri Mar 20 21:01:04 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA24661 for ipp-outgoing; Fri, 20 Mar 1998 21:00:42 -0500 (EST) Message-Id: <199803210158.RAA03881@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 20 Mar 1998 18:02:24 -0800 To: ipp@pwg.org From: Robert Herriot Subject: IPP>MOD: Problem in IPP encoding with "attributes-charset" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk I have found a problem that relates to the "attributes-charset" and "attributes-natural-language" attributes. They must be in the first group of attributes (the operation attributes), but they need not be first in the operation attributes group because the IPP model document states that attributes in groups such as "operation attributes" are unordered. Except for this case, that is good. But the charset and natural language are special because they determine how name and text values of all attributes should be interpreted. Such a text or name attribute may precede the occurrence of "attributes-charset" and "attributes-natural-language". This makes an implementation more difficult because it cannot convert the octet string of the protocol to an internal String until it has found the "attributes-charset" value which could come many attributes later. We need to change the documents to state that two attributes need to be first in the operations group, even though attributes in groups are otherwise unordered. How are you other implementors coping with this? By the way, XML doesn't have this problem because the charset comes at a specific place at the very beginning and the language specification always precedes the text which it applies to. Bob Herriot From ipp-archive Sat Mar 21 18:21:21 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA06101 for ipp-outgoing; Sat, 21 Mar 1998 18:19:21 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: RE: IPP>MOD: Problem in IPP encoding with "attributes-charset" Date: Sat, 21 Mar 1998 15:19:16 -0800 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 I believe we have found some other hidden dependencies that are similar to this, but we just reorder the logic of our attribute processing in order to "do the right thing". While doing in this in the protocol specification may help some implementations, it hasn't hindered our efforts too much. But then again our server is only a proof-of-concept implementation with limited capability. But even with our prototype, taking the attributes in a particular order hasn't been too difficult. If the WG agrees to make this change to the documents, I would have no problem with it. Randy -----Original Message----- From: Robert Herriot [SMTP:robert.herriot@Eng.Sun.COM] Sent: Friday, March 20, 1998 6:02 PM To: ipp@pwg.org Subject: IPP>MOD: Problem in IPP encoding with "attributes-charset" I have found a problem that relates to the "attributes-charset" and "attributes-natural-language" attributes. They must be in the first group of attributes (the operation attributes), but they need not be first in the operation attributes group because the IPP model document states that attributes in groups such as "operation attributes" are unordered. Except for this case, that is good. But the charset and natural language are special because they determine how name and text values of all attributes should be interpreted. Such a text or name attribute may precede the occurrence of "attributes-charset" and "attributes-natural-language". This makes an implementation more difficult because it cannot convert the octet string of the protocol to an internal String until it has found the "attributes-charset" value which could come many attributes later. We need to change the documents to state that two attributes need to be first in the operations group, even though attributes in groups are otherwise unordered. How are you other implementors coping with this? By the way, XML doesn't have this problem because the charset comes at a specific place at the very beginning and the language specification always precedes the text which it applies to. Bob Herriot From ipp-archive Sun Mar 22 11:46:31 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA17335 for ipp-outgoing; Sun, 22 Mar 1998 11:42:10 -0500 (EST) Date: Sun, 22 Mar 1998 08:47:45 PST From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9803221647.AA15780@snorkel.eso.mc.xerox.com> To: ipp@pwg.org, robert.herriot@Eng.Sun.COM Subject: Re: IPP>MOD: Problem in IPP encoding with "attributes-charset" Sender: ipp-owner@pwg.org Precedence: bulk Hi Bob, Yes, you're right that the charset and natural language attributes must appear first. That rule is near universal in modern protocols. Cheers, - Ira McDonald High North Inc ---------------------------------------------------------------------- >From ipp-owner@pwg.org Fri Mar 20 21:15:39 1998 Return-Path: Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA15628; Fri, 20 Mar 98 21:15:38 EST Received: from alpha.xerox.com by zombi (4.1/SMI-4.1) id AA10061; Fri, 20 Mar 98 21:09:42 EST Received: from lists.underscore.com ([199.125.85.30]) by alpha.xerox.com with SMTP id <52148(4)>; Fri, 20 Mar 1998 18:09:39 PST Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA25039 for ; Fri, 20 Mar 1998 21:06:15 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 20 Mar 1998 21:00:53 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA24661 for ipp-outgoing; Fri, 20 Mar 1998 21:00:42 -0500 (EST) Message-Id: <199803210158.RAA03881@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 20 Mar 1998 18:02:24 PST To: ipp@pwg.org From: Robert Herriot Subject: IPP>MOD: Problem in IPP encoding with "attributes-charset" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Status: R I have found a problem that relates to the "attributes-charset" and "attributes-natural-language" attributes. They must be in the first group of attributes (the operation attributes), but they need not be first in the operation attributes group because the IPP model document states that attributes in groups such as "operation attributes" are unordered. Except for this case, that is good. But the charset and natural language are special because they determine how name and text values of all attributes should be interpreted. Such a text or name attribute may precede the occurrence of "attributes-charset" and "attributes-natural-language". This makes an implementation more difficult because it cannot convert the octet string of the protocol to an internal String until it has found the "attributes-charset" value which could come many attributes later. We need to change the documents to state that two attributes need to be first in the operations group, even though attributes in groups are otherwise unordered. How are you other implementors coping with this? By the way, XML doesn't have this problem because the charset comes at a specific place at the very beginning and the language specification always precedes the text which it applies to. Bob Herriot From ipp-archive Sun Mar 22 12:31:28 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA17976 for ipp-outgoing; Sun, 22 Mar 1998 12:30:58 -0500 (EST) Date: Sun, 22 Mar 1998 09:36:47 PST From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9803221736.AA15842@snorkel.eso.mc.xerox.com> To: Joe_Filion@mc.xerox.com, ipp@pwg.org, jmp@pwg.org Subject: IPP> Re: SNMPv3 unsuited for IPP/JMP Notificiations Sender: ipp-owner@pwg.org Precedence: bulk Copies To: ipp@pwg.org, jmp@pwg.org, Joe_Filion@mc.xerox.com Hi Randy, Sunday (22 March 1998) I think you misunderstood several of my comments. My replies are in your note below, preceded by 'IEM>'. Cheers, - Ira McDonald (High North) >----------------------------------------------------------------------< >From: "Turner, Randy" >To: "'imcdonal@eso.mc.xerox.com'" , > Joe_Filion@mc.xerox.com, ipp@pwg.org, jmp@pwg.org >Subject: RE: IPP> SNMPv3 unsuited for IPP/JMP Notifications >Date: Tue, 17 Mar 1998 10:23:01 PST > >I am not sure what the dissenting opinion is, whether SNMPv3 is not the >correct solution? Or, is the proposed notification MIB not the right >solution? > >If SNMP is the wrong solution, then any SNMP-accessed MIB would be the >wrong solution, including the JAM MIB. IEM> The entire SNMPv3 MIB suite is unsuited to supporting very many end-user clients registered for notifications. But, the SNMPv1 suite is QUITE appropriate (and ubiquitously deployed) for basic monitoring (and sometimes active management) of networked systems and devices. >I will try and address the concerns outlined below, with matching >numbers. > >1) Scopes of interest are still supported by OID subtree >specifications; it's the intended notification recipients that are >identified and matched by the UTF-8 tag. IEM> No, OID subtrees are NOT in the SNMPv3 Notification or Target MIBs. Only local-scope tags (non-standardized names for groups of attributes) are specified in the Notification MIB. OID subtrees are in the SNMPv3 View-based Access Control Model MIB (RFC 2275), but ONLY with additional support of the user ('principal') security identifications accomplished via the User-based Security Model MIB (RFC 2274). That is, it takes the whole ball-of-wax of SNMPv3 MIBs to get to OID subtree views and they STILL aren't designed for fine-grained control (like individual traps, which are ONLY intended to be controlled via the Notification MIB). >2) Registration lifetimes would be a good idea. It's quite possible >for an IPP MIB to augment the notification table with objects that >represent registration lifetimes. No need to throw the baby out with the >bath water on this one. Since it is an explicit augmentation, the >indices would be the same. IEM> Augmenting an inappropriate scheme (SNMPv3) won't help. >3) Indices that appear as SnmpAdminString types are labeled as >NOT-ACCESSIBLE, so they should not appear in the response packet of a >GET, or GET-BULK. IEM> There is much confusion about 'not-accessible' indices. In ALL versions of SNMP (and OSI CMIP), the so-called 'variable bindings' are lists of full MIB object OIDs with SUFFIXED 'instance qualifiers', which are the VALUES of all the indices (so non-integer indices greatly reduce the efficiency of SNMP protocol exchanges). >4) I'm not sure if a brute force search would be required or not >(yet). It appears from reading the RFC that this might be the case and I >understand how this conclusion could be made. However, I'm not sure that >duplicate registrations could be identified solely on the basis of >"transport" and "transport-address" matching. This particular scenario >would require more study. IEM> In ALL versions of SNMP trap registration, duplicate registrations are determined solely on the basis of 'transport domain' and 'transport address' matching (all the way back to the Historic SNMPv1 Party MIB, RFC 1353). Because SNMPv3 is too heavyweight for a given low-level device to have many registered 'notification targets', the brute force search doesn't matter much, but for the printer industry scenarios of (potentially) hundreds of registered trap clients, the results would be catastrophic. >5) This rationale does not exist for SNMPv3. This held true only >for V2 (and derivatives). All the text about "dual-role entities" from >V2 has been removed from the V3 doc set. The V3 specs now generically >identify "notification senders" and "notification recipients". The idea >of specific functionality being reserved for a "mid-level" manager >entity no longer exists. Implementors are free to instrument whatever >feature they need, depending upon the type of management (or managed) >entity is being constructed. IEM> The SNMPv3 specs do NOT clarify appropriate use of 'Inform', as David Perkins has repeatedly criticized. The use of 'Inform' PDUs for directly acknowledgemed notifications to/from a EACH printer device to (potentially) hundreds of registered clients would fail utterly to scale in an enterprise network environment. >6) Again, this idea is a V2 idea, the restrictions on "how" a >feature is used has been removed from the V3 specifications. See #5 >above. Also, I have it on good authority from Jeff Case at SNMP >Research, that the effort required to take the V1 trap code base and >move it to V3 trap/inform is no great task. A lot of code reuse is >possible. Also, V3 informs are as reliable as any other notification >mechanism. IEM> See my comment below. >7) Again, I have it on first hand communication from Bob >Stewart(Cisco), Jeff Case and David Levi(SNMP Research) that their >"intent" was never to disallow the type of functionality I have >proposed. Rather, it seems like a prudent reuse of all vendors' existing >agent code base. IEM> The new PDUs for SNMPv2 were first published five years ago (1993). Nonetheless, almost ALL installed products speak SNMPv1 ONLY. A small minority support SNMPv1/SNMPv2 'hybrid agents'. Many of those became obsolete when the original SNMPv2 specifications (RFC 144x series) were abandoned and replaced with the (incompatible) current SNMPv2 specs (RFC 190x series) in January 1996. Many of the 'big names' in open management stations STILL only support SNMPv1 protocol. Quite a few STILL won't compile an SMIv2 dialect MIB (remember the SMI dialect is INDEPENDENT of the version of 'over-the-wire' SNMP protocol). It is inconceivable that customers will upgrade their open management control centers just to get at (newly incompatible) SNMPv3-based printers! >This reuse of technology (both in design and existing code) is what I am >trying to take advantage of. Given the speed at which SNMPv3 is being >adopted, I feel like a lot of vendors are going to want to implement V3 >agents anyway. Also, after looking at Ira's proposal for the JAM MIB, >there are some ideas present in the JAM MIB that were not included in >the standard notification/target MIBs specified in RFC 2273. I think we >should include these ideas in whatever we come up with. I don't think we >should completely reinvent the wheel here, rather, I think we should >come up with a suitable set of additional (non-overlapping) notification >features and AUGMENT the standard set. This is because, for a lot of >reasons, I think vendors will eventually have to support them anyway to >be "V3 compliant" at some point in the future. > >By the way, I have no SNMP religious affiliation, just a desire to reuse >technology. If we find out that our requirements exceed the boundaries >of what SNMPv3 and related technology can deliver, then I would be just >as happy to pursue another path. But I think we need to study this stuff >a little more before taking any radical direction change. > >Randy >----------------------------------------------------------------------< From ipp-archive Sun Mar 22 17:56:29 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA18990 for ipp-outgoing; Sun, 22 Mar 1998 17:56:20 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" , "'jmp@pwg.org'" Subject: RE: IPP> Re: SNMPv3 unsuited for IPP/JMP Notificiations Date: Sun, 22 Mar 1998 14:56:06 -0800 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 There two questions that have yet to be answered. You've repeatedly stated that SNMPv3 is not intended for "very many notification clients". I would like to hear a technical analysis of why you think this is the case. Also, I think its VERY unrealistic that an embedded device will have to manage "several hundred" client notification requests. If every client can specify a totally different object set to be sent along with each notification, then I don't think this is realistic for embedded devices. If you have a defined trap/notification, with a specific list of objects that are returned, then a notification originator only has to keep track of transport domains and addresses, not every combination of object sets that "possibly hundreds of notification clients" might want to know about. I don't think SNMPv3 is heavyweight. It's designed be implemented in everything from $300 managed 100Mbit hubs, all the way to enterprise ATM switches. And I think whatever solution we come up with will have to have the capability to support a distributed event notification system, similar to the way SENSE and other distributed notification mechanisms remove the burden from individual embedded printers from having to keep up with the entire world of notifications. Randy -----Original Message----- From: imcdonal@eso.mc.xerox.com [SMTP:imcdonal@eso.mc.xerox.com] Sent: Sunday, March 22, 1998 9:37 AM To: Joe_Filion@mc.xerox.com; ipp@pwg.org; jmp@pwg.org Subject: IPP> Re: SNMPv3 unsuited for IPP/JMP Notificiations Copies To: ipp@pwg.org, jmp@pwg.org, Joe_Filion@mc.xerox.com Hi Randy, Sunday (22 March 1998) I think you misunderstood several of my comments. My replies are in your note below, preceded by 'IEM>'. Cheers, - Ira McDonald (High North) >----------------------------------------------------------------------< >From: "Turner, Randy" >To: "'imcdonal@eso.mc.xerox.com'" , > Joe_Filion@mc.xerox.com, ipp@pwg.org, jmp@pwg.org >Subject: RE: IPP> SNMPv3 unsuited for IPP/JMP Notifications >Date: Tue, 17 Mar 1998 10:23:01 PST > >I am not sure what the dissenting opinion is, whether SNMPv3 is not the >correct solution? Or, is the proposed notification MIB not the right >solution? > >If SNMP is the wrong solution, then any SNMP-accessed MIB would be the >wrong solution, including the JAM MIB. IEM> The entire SNMPv3 MIB suite is unsuited to supporting very many end-user clients registered for notifications. But, the SNMPv1 suite is QUITE appropriate (and ubiquitously deployed) for basic monitoring (and sometimes active management) of networked systems and devices. >I will try and address the concerns outlined below, with matching >numbers. > >1) Scopes of interest are still supported by OID subtree >specifications; it's the intended notification recipients that are >identified and matched by the UTF-8 tag. IEM> No, OID subtrees are NOT in the SNMPv3 Notification or Target MIBs. Only local-scope tags (non-standardized names for groups of attributes) are specified in the Notification MIB. OID subtrees are in the SNMPv3 View-based Access Control Model MIB (RFC 2275), but ONLY with additional support of the user ('principal') security identifications accomplished via the User-based Security Model MIB (RFC 2274). That is, it takes the whole ball-of-wax of SNMPv3 MIBs to get to OID subtree views and they STILL aren't designed for fine-grained control (like individual traps, which are ONLY intended to be controlled via the Notification MIB). >2) Registration lifetimes would be a good idea. It's quite possible >for an IPP MIB to augment the notification table with objects that >represent registration lifetimes. No need to throw the baby out with the >bath water on this one. Since it is an explicit augmentation, the >indices would be the same. IEM> Augmenting an inappropriate scheme (SNMPv3) won't help. >3) Indices that appear as SnmpAdminString types are labeled as >NOT-ACCESSIBLE, so they should not appear in the response packet of a >GET, or GET-BULK. IEM> There is much confusion about 'not-accessible' indices. In ALL versions of SNMP (and OSI CMIP), the so-called 'variable bindings' are lists of full MIB object OIDs with SUFFIXED 'instance qualifiers', which are the VALUES of all the indices (so non-integer indices greatly reduce the efficiency of SNMP protocol exchanges). >4) I'm not sure if a brute force search would be required or not >(yet). It appears from reading the RFC that this might be the case and I >understand how this conclusion could be made. However, I'm not sure that >duplicate registrations could be identified solely on the basis of >"transport" and "transport-address" matching. This particular scenario >would require more study. IEM> In ALL versions of SNMP trap registration, duplicate registrations are determined solely on the basis of 'transport domain' and 'transport address' matching (all the way back to the Historic SNMPv1 Party MIB, RFC 1353). Because SNMPv3 is too heavyweight for a given low-level device to have many registered 'notification targets', the brute force search doesn't matter much, but for the printer industry scenarios of (potentially) hundreds of registered trap clients, the results would be catastrophic. >5) This rationale does not exist for SNMPv3. This held true only >for V2 (and derivatives). All the text about "dual-role entities" from >V2 has been removed from the V3 doc set. The V3 specs now generically >identify "notification senders" and "notification recipients". The idea >of specific functionality being reserved for a "mid-level" manager >entity no longer exists. Implementors are free to instrument whatever >feature they need, depending upon the type of management (or managed) >entity is being constructed. IEM> The SNMPv3 specs do NOT clarify appropriate use of 'Inform', as David Perkins has repeatedly criticized. The use of 'Inform' PDUs for directly acknowledgemed notifications to/from a EACH printer device to (potentially) hundreds of registered clients would fail utterly to scale in an enterprise network environment. >6) Again, this idea is a V2 idea, the restrictions on "how" a >feature is used has been removed from the V3 specifications. See #5 >above. Also, I have it on good authority from Jeff Case at SNMP >Research, that the effort required to take the V1 trap code base and >move it to V3 trap/inform is no great task. A lot of code reuse is >possible. Also, V3 informs are as reliable as any other notification >mechanism. IEM> See my comment below. >7) Again, I have it on first hand communication from Bob >Stewart(Cisco), Jeff Case and David Levi(SNMP Research) that their >"intent" was never to disallow the type of functionality I have >proposed. Rather, it seems like a prudent reuse of all vendors' existing >agent code base. IEM> The new PDUs for SNMPv2 were first published five years ago (1993). Nonetheless, almost ALL installed products speak SNMPv1 ONLY. A small minority support SNMPv1/SNMPv2 'hybrid agents'. Many of those became obsolete when the original SNMPv2 specifications (RFC 144x series) were abandoned and replaced with the (incompatible) current SNMPv2 specs (RFC 190x series) in January 1996. Many of the 'big names' in open management stations STILL only support SNMPv1 protocol. Quite a few STILL won't compile an SMIv2 dialect MIB (remember the SMI dialect is INDEPENDENT of the version of 'over-the-wire' SNMP protocol). It is inconceivable that customers will upgrade their open management control centers just to get at (newly incompatible) SNMPv3-based printers! >This reuse of technology (both in design and existing code) is what I am >trying to take advantage of. Given the speed at which SNMPv3 is being >adopted, I feel like a lot of vendors are going to want to implement V3 >agents anyway. Also, after looking at Ira's proposal for the JAM MIB, >there are some ideas present in the JAM MIB that were not included in >the standard notification/target MIBs specified in RFC 2273. I think we >should include these ideas in whatever we come up with. I don't think we >should completely reinvent the wheel here, rather, I think we should >come up with a suitable set of additional (non-overlapping) notification >features and AUGMENT the standard set. This is because, for a lot of >reasons, I think vendors will eventually have to support them anyway to >be "V3 compliant" at some point in the future. > >By the way, I have no SNMP religious affiliation, just a desire to reuse >technology. If we find out that our requirements exceed the boundaries >of what SNMPv3 and related technology can deliver, then I would be just >as happy to pursue another path. But I think we need to study this stuff >a little more before taking any radical direction change. > >Randy >----------------------------------------------------------------------< From ipp-archive Sun Mar 22 19:31:31 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA19857 for ipp-outgoing; Sun, 22 Mar 1998 19:31:25 -0500 (EST) Date: Sun, 22 Mar 1998 16:37:08 PST From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9803230037.AA15969@snorkel.eso.mc.xerox.com> To: Joe_Filion@mc.xerox.com, ipp@pwg.org, jmp@pwg.org Subject: IPP> Re: SNMPv3 unsuited for IPP/JMP Notifications Sender: ipp-owner@pwg.org Precedence: bulk Copies To: ipp@pwg.org, jmp@pwg.org, Joe_Filion@mc.xerox.com Hi Randy, Sunday (22 March 1998) My replies are imbedded in your note below, preceded by 'IEM>'. I tried to answer each of your questions. Cheers, - Ira McDonald (High North) >----------------------------------------------------------------------< >From: "Turner, Randy" >To: "'ipp@pwg.org'" , "'jmp@pwg.org'" >Subject: RE: IPP> Re: SNMPv3 unsuited for IPP/JMP Notificiations >Date: Sun, 22 Mar 1998 14:56:06 PST > >There two questions that have yet to be answered. > >You've repeatedly stated that SNMPv3 is not intended for "very many >notification clients". I would like to hear a technical analysis of why >you think this is the case. IEM> Because the SNMPv3 security depends on the distribution of shared secrets to EVERY managed system, but does NOT specify a Key Management Protocol. Because the SNMPv3 Target and Notification MIBs have highly inefficient string indices, placing a significant burden on ALL managed systems. For ACTIVE management (not just passive monitoring) of key infrastructure (routers, switches, hubs, etc), SNMPv3 may turn out to be quite successful in the marketplace, but deployment will undoubtedly be sporadic and interworking problems will be common. >Also, I think its VERY unrealistic that an embedded device will have to >manage "several hundred" client notification requests. If every client >can specify a totally different object set to be sent along with each >notification, then I don't think this is realistic for embedded devices. >If you have a defined trap/notification, with a specific list of objects >that are returned, then a notification originator only has to keep track >of transport domains and addresses, not every combination of object sets >that "possibly hundreds of notification clients" might want to know >about. IEM> Xerox (like IBM, and various other printer vendors) builds VERY big production printing systems (which may cost over a million dollars each). The SNMPv1 framework defines 6 different important traps; each interface MIB (Ethernet, TokenRing, etc) defines several more traps; the Printer MIB defines one trap; the PWG Job Monitoring MIB will (hopefully) define one or several (job- vs document-level) traps; the XCMI (Xerox Common Mgmt Interface) suite of 14 MIBs defines 16 different traps. Xerox clients do NOT register promiscuously for ALL traps - they pick and choose, according to their end-user preferences or roles (operators and system administrators have different interests and needs, for example). VERY lightweight trap registration is a necessity for the printer industry! >I don't think SNMPv3 is heavyweight. It's designed be implemented in >everything from $300 managed 100Mbit hubs, all the way to enterprise ATM >switches. And I think whatever solution we come up with will have to >have the capability to support a distributed event notification system, >similar to the way SENSE and other distributed notification mechanisms >remove the burden from individual embedded printers from having to keep >up with the entire world of notifications. IEM> But, your examples are all of infrastructure (intermediate-systems), not printers, scanners, and other end-systems. Managing a hub or router has essentially nothing in common with managing end-systems, except that they use a common protocol - SNMPv1, NOT SNMPv3, which is unlikely to be widely deployed for at least the next three years - look at the deployment track record of SNMPv2! No vendor can tell their customers that they can't manage their printers until they deploy (largely non-existant) new enterprise open management systems (CA Unicenter, Tivoli TME, HP OpenView, Sun Solstice, etc) that have support for SNMPv3 (some of those that I just mentioned don't have support for SNMPv2, yet). Xerox research has found that many customers HATE to be told that "this product just requires a few little server applications." Elegant distributed event notification schemes like SENSE are very unpopular with Xerox product planners and marketers (and customers). Perhaps your customers haven't been bitten by unstable NetWare NLMs or NT server applications? [Jay, I personally think SENSE is good stuff - but technical excellence isn't the only or even major factor in the deployment of technology.] >----------------------------------------------------------------------< From ipp-archive Sun Mar 22 20:11:37 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA20697 for ipp-outgoing; Sun, 22 Mar 1998 20:06:48 -0500 (EST) Message-ID: From: "Turner, Randy" To: ipp@pwg.org, jmp@pwg.org Subject: RE: IPP> Re: SNMPv3 unsuited for IPP/JMP Notifications Date: Sun, 22 Mar 1998 17:04:26 -0800 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 Your scalability rationale essentially boils down to string indices, since not all SNMPv3 implementations have to implement security via shared secrets. I don't think this single rationale is enough to dismiss on a scalability question. All along we've been talking about how to scale things down enough to make things "simple, lightweight", including talk about a much lighter weight protocol for host-to-device communication, where a notification protocol might be used. For you to bring up the fact that Xerox and other vendors have up to 1 million dollar printers is an argument for many notifications, but doesn't make much sense in the context of our heretofore previous discussions. You even talk about "1 million dollar printers" and "VERY lightweight" in the same paragraph ;) ;) I will reiterate my belief that I don't think its realistic for a simple embedded device to maintain notification info for hundreds of clients. I don't think its in the notification requirements document...maybe we should talk about the number of notifications that an embedded device should minimally support? And include the outcome of that discussion in the requirements doc. Also, I used my managed device examples (small hub to enterprise switch) to illustrate low-cost to high-cost devices with very wide variances in burden cost for manufacturing (memory, power, cpu, etc.). Maybe what we are actually debating is semantics in how we define "lightweight" and "heavyweight" Does lightweight mean simple to build (overall)? Simple to code? Lightweight in terms of CPU cycles? Other? It sometimes sounds like we are defining terms differently. Randy -----Original Message----- From: imcdonal@eso.mc.xerox.com [SMTP:imcdonal@eso.mc.xerox.com] Sent: Sunday, March 22, 1998 4:37 PM To: Joe_Filion@mc.xerox.com; ipp@pwg.org; jmp@pwg.org Subject: IPP> Re: SNMPv3 unsuited for IPP/JMP Notifications Copies To: ipp@pwg.org, jmp@pwg.org, Joe_Filion@mc.xerox.com Hi Randy, Sunday (22 March 1998) My replies are imbedded in your note below, preceded by 'IEM>'. I tried to answer each of your questions. Cheers, - Ira McDonald (High North) >----------------------------------------------------------------------< >From: "Turner, Randy" >To: "'ipp@pwg.org'" , "'jmp@pwg.org'" >Subject: RE: IPP> Re: SNMPv3 unsuited for IPP/JMP Notificiations >Date: Sun, 22 Mar 1998 14:56:06 PST > >There two questions that have yet to be answered. > >You've repeatedly stated that SNMPv3 is not intended for "very many >notification clients". I would like to hear a technical analysis of why >you think this is the case. IEM> Because the SNMPv3 security depends on the distribution of shared secrets to EVERY managed system, but does NOT specify a Key Management Protocol. Because the SNMPv3 Target and Notification MIBs have highly inefficient string indices, placing a significant burden on ALL managed systems. For ACTIVE management (not just passive monitoring) of key infrastructure (routers, switches, hubs, etc), SNMPv3 may turn out to be quite successful in the marketplace, but deployment will undoubtedly be sporadic and interworking problems will be common. >Also, I think its VERY unrealistic that an embedded device will have to >manage "several hundred" client notification requests. If every client >can specify a totally different object set to be sent along with each >notification, then I don't think this is realistic for embedded devices. >If you have a defined trap/notification, with a specific list of objects >that are returned, then a notification originator only has to keep track >of transport domains and addresses, not every combination of object sets >that "possibly hundreds of notification clients" might want to know >about. IEM> Xerox (like IBM, and various other printer vendors) builds VERY big production printing systems (which may cost over a million dollars each). The SNMPv1 framework defines 6 different important traps; each interface MIB (Ethernet, TokenRing, etc) defines several more traps; the Printer MIB defines one trap; the PWG Job Monitoring MIB will (hopefully) define one or several (job- vs document-level) traps; the XCMI (Xerox Common Mgmt Interface) suite of 14 MIBs defines 16 different traps. Xerox clients do NOT register promiscuously for ALL traps - they pick and choose, according to their end-user preferences or roles (operators and system administrators have different interests and needs, for example). VERY lightweight trap registration is a necessity for the printer industry! >I don't think SNMPv3 is heavyweight. It's designed be implemented in >everything from $300 managed 100Mbit hubs, all the way to enterprise ATM >switches. And I think whatever solution we come up with will have to >have the capability to support a distributed event notification system, >similar to the way SENSE and other distributed notification mechanisms >remove the burden from individual embedded printers from having to keep >up with the entire world of notifications. IEM> But, your examples are all of infrastructure (intermediate-systems), not printers, scanners, and other end-systems. Managing a hub or router has essentially nothing in common with managing end-systems, except that they use a common protocol - SNMPv1, NOT SNMPv3, which is unlikely to be widely deployed for at least the next three years - look at the deployment track record of SNMPv2! No vendor can tell their customers that they can't manage their printers until they deploy (largely non-existant) new enterprise open management systems (CA Unicenter, Tivoli TME, HP OpenView, Sun Solstice, etc) that have support for SNMPv3 (some of those that I just mentioned don't have support for SNMPv2, yet). Xerox research has found that many customers HATE to be told that "this product just requires a few little server applications." Elegant distributed event notification schemes like SENSE are very unpopular with Xerox product planners and marketers (and customers). Perhaps your customers haven't been bitten by unstable NetWare NLMs or NT server applications? [Jay, I personally think SENSE is good stuff - but technical excellence isn't the only or even major factor in the deployment of technology.] >----------------------------------------------------------------------< From ipp-archive Mon Mar 23 10:27:00 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA02527 for ipp-outgoing; Mon, 23 Mar 1998 10:23:12 -0500 (EST) Message-ID: <35167E4B.2EEBA340@underscore.com> Date: Mon, 23 Mar 1998 10:22:51 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org CC: Ira Mcdonald x10962 , Sense mailing list Subject: Re: IPP> Re: SNMPv3 unsuited for IPP/JMP Notifications References: <9803230037.AA15969@snorkel.eso.mc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk This is a *great* thread. Hopefully everyone is reading the exchanges between Randy and Ira so as to quickly come up to speed on the applicability (or not) of SNMPv3 to the network printer universe. One comment Ira wrote to Randy is particularly notable: > >I don't think SNMPv3 is heavyweight. It's designed be implemented in > >everything from $300 managed 100Mbit hubs, all the way to enterprise ATM > >switches. And I think whatever solution we come up with will have to > >have the capability to support a distributed event notification system, > >similar to the way SENSE and other distributed notification mechanisms > >remove the burden from individual embedded printers from having to keep > >up with the entire world of notifications. > > IEM> But, your examples are all of infrastructure (intermediate-systems), > not printers, scanners, and other end-systems. Managing a hub or router > has essentially nothing in common with managing end-systems, except that > they use a common protocol - SNMPv1, NOT SNMPv3, which is unlikely to be > widely deployed for at least the next three years - look at the deployment > track record of SNMPv2! In essence, all things are *not* necessarily equal under SNMP in terms of scale and functionality. I have been trying to get people in the PWG to understand this essential fact for years now. SNMP was designed for "network elements" (what Ira calls "infrastructure elements", another good name). That was the sole problem domain for which SNMP was designed. Can SNMP be used for other applications? Of course. Must we necessarily constrain our product designs around the limitations of SNMP? (That is, if SNMP can't do it, then either can/should we.) That's silly. Just because you can, doesn't mean you should... > No vendor can tell their customers that they can't manage their printers > until they deploy (largely non-existant) new enterprise open management > systems (CA Unicenter, Tivoli TME, HP OpenView, Sun Solstice, etc) that > have support for SNMPv3 (some of those that I just mentioned don't have > support for SNMPv2, yet). Xerox research has found that many customers > HATE to be told that "this product just requires a few little server > applications." Elegant distributed event notification schemes like > SENSE are very unpopular with Xerox product planners and marketers > (and customers). Perhaps your customers haven't been bitten by unstable > NetWare NLMs or NT server applications? Amen, brother. We at Underscore constantly wrestle with the plain fact that customers ABHORE the need to install/maintain/operate additional components required to make your product work. That cold, hard fact became painfully obvious with our work on designing a product-oriented implementation of SENSE. For example, we needed a very, very lightweight directory service. No problem. How about LDAP? What about SLP? Hey, even NDS may be possible. And yet the continual problem we faced was: Which lightweight directory is ubiquitously available across all major server platforms today? The answer, of course, is: None. So we had to (quickly) design/implement the very, very lightweight directory service directly inside SENSE. It was no big deal, and we do not have any external dependencies that customers abhore. > [Jay, I personally think SENSE is good stuff - but technical excellence > isn't the only or even major factor in the deployment of technology.] Again, amen. I would never consider the current SENSE design as "technically excellent". That was NEVER the goal. The goals? Simple. Very lightweight. Eminently portable. Easy to use. Easy to understand. Easy to extend. Low resource requirements. ...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 -- ---------------------------------------------------------------------- From ipp-archive Mon Mar 23 10:31:50 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA02721 for ipp-outgoing; Mon, 23 Mar 1998 10:27:17 -0500 (EST) Message-ID: <35167F33.3D332CAF@underscore.com> Date: Mon, 23 Mar 1998 10:26:43 -0500 From: Jay Martin Organization: Underscore, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: "Turner, Randy" CC: ipp@pwg.org, jmp@pwg.org, Sense mailing list Subject: Re: IPP> Re: SNMPv3 unsuited for IPP/JMP Notifications References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Turner, Randy wrote: > I will reiterate my belief that I don't think its realistic for a simple > embedded device to maintain notification info for hundreds of clients. I agree 110%. That fundamental belief is one of the most critical assumptions for which SENSE was designed. Namely, require the managed entity (ie, a printer) to provide minimal scalability for key services (ie, just a few simultaneous client accesses), then route that information into a generalized client/server system with a very high degree of scalability. ...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 -- ---------------------------------------------------------------------- From ipp-archive Mon Mar 23 13:46:45 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA04831 for ipp-outgoing; Mon, 23 Mar 1998 13:44:43 -0500 (EST) Message-Id: <3.0.1.32.19980323103827.009c1280@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 23 Mar 1998 10:38:27 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> NOT - Is SNMPv3 suitable for IPP Notifications? Cc: jmp@pwg.org, sense@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk All, We have had a rather intensive debate between Randy, who first proposed that we might want to use SNMPv3 traps or informs for IPP notifications, and Ira, who thinks that the whole idea is wrong. With the exception of Jay's comments earlier today, it has been very quiet from the rest of the group on this subject. Are there any other views on the subject? Do you support one or the other combattants' views? If all we will be hearing is arguments between mainly two people with diametrically opposite views, we are not going to archieve anything. We are supposed to discuss this next week in the IETF in LA and it would be nice to have a little better understanding of where the group stands in this debate by then. Should we abandon SNMPv3 as a candidate for IPP notifications and concentrate our efforts on a new or different solution? Please give more feedback to the DL. 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 Mar 23 13:51:59 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA05084 for ipp-outgoing; Mon, 23 Mar 1998 13:47:40 -0500 (EST) From: Harry Lewis To: Cc: , , Subject: Re: SENSE> Re: IPP> Re: SNMPv3 unsuited for IPP/JMP Notifica Message-ID: <5030300019257914000002L042*@MHS> Date: Mon, 23 Mar 1998 13:54:01 -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 response to Ira' comment... > IEM> But, your examples are all of infrastructure (intermediate-syste= ms), > not printers, scanners, and other end-systems. Managing a hub or rou= ter > has essentially nothing in common with managing end-systems, except t= hat > they use a common protocol - SNMPv1, NOT SNMPv3, which is unlikely to= be > widely deployed for at least the next three years - look at the deplo= yment We (PWG) crossed the "using SNMP to manage printers" question long ago.= Some people have never been comfortable with it but no one can deny we did. = To some degree, one can argue that every network element is part of it's infrastructure. That's pretty much how I believe we got where we are. I= 'm not saying it's right or wrong. I've just been trying to make good use of i= t rather than judge it or wish for something different. Also, I don't believe we can predict SNMPv3 rollout based on V2 lag. SN= MPv2 had a goory history - so bad that many chose not to implement. I view SNMPv= 3 as the answer to the v2 problem, not a repeat of it. Harry Lewis - IBM Printing Systems = From ipp-archive Mon Mar 23 14:11:49 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA06806 for ipp-outgoing; Mon, 23 Mar 1998 14:09:56 -0500 (EST) From: Harry Lewis To: Cc: , , , Subject: Re: SENSE> Re: IPP> Re: SNMPv3 unsuited for IPP/JMP Notifica Message-ID: <5030300019257048000002L082*@MHS> Date: Mon, 23 Mar 1998 14:15:11 -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 also agree... (its not realistic for a simple embedded device to mai= ntain notification info for hundreds of clients). But, this does not mean tha= t the embedded Device should never be able to handle notification to multiple= clients. There may be more than one "notification server", or some smal= ler scale networks using peer-to-peer printing without a notification serve= r. Yes, the embedded device will ultimately limit the number of notificati= on hosts it can service, but (as I presented in Austin) I feel 16 - 32 is not unreasonable for many "network printers". Harry Lewis - IBM Printing Systems owner-sense@pwg.org on 03/23/98 08:33:19 AM Please respond to owner-sense@pwg.org To: rturner@sharplabs.com cc: sense@pwg.org, jmp@pwg.org, ipp@pwg.org Subject: SENSE> Re: IPP> Re: SNMPv3 unsuited for IPP/JMP Notification Turner, Randy wrote: > I will reiterate my belief that I don't think its realistic for a sim= ple > embedded device to maintain notification info for hundreds of clients= From ipp-archive Mon Mar 23 14:46:49 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA07843 for ipp-outgoing; Mon, 23 Mar 1998 14:43:27 -0500 (EST) Message-ID: <5CEA8663F24DD111A96100805FFE6587030BC3B2@red-msg-51.dns.microsoft.com> From: Paul Moore To: "'Carl-Uno Manros'" , ipp@pwg.org Cc: jmp@pwg.org, sense@pwg.org Subject: RE: IPP> NOT - Is SNMPv3 suitable for IPP Notifications? Date: Mon, 23 Mar 1998 11:42:56 -0800 X-Mailer: Internet Mail Service (5.5.2166.0) Sender: ipp-owner@pwg.org Precedence: bulk Some time since I aired my views on this. I think we should make IPP notifications a mechanism whereby a client can request that a notification be sent to it via any mechanism. That is to say - the notification itself is sent any way you like and is not part of IPP. IPP merely provides the means for the client to request that this be done. We might want to define some standard optional mechanisms (email being the obvious one). All notifications are optional. The IPP Model also needs to define what events are notification candidates and what they mean. The IPP request indicates which events it wants notification on, what mechanism to use, any parameters associated with that mechanism (email address) and maybe message content. The mechanisms available should be something that is queryable (get printer attributes). There is a separate thing that deals with device level alerts and events - along with robust data transmission, etc. etc. My thoughts on that topic have already been aired! > -----Original Message----- > From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] > Sent: Monday, March 23, 1998 10:38 AM > To: ipp@pwg.org > Cc: jmp@pwg.org; sense@pwg.org > Subject: IPP> NOT - Is SNMPv3 suitable for IPP Notifications? > > All, > > We have had a rather intensive debate between Randy, who first > proposed that we might want to use SNMPv3 traps or informs for > IPP notifications, and Ira, who thinks that the whole idea is > wrong. > > With the exception of Jay's comments earlier today, it has been > very quiet from the rest of the group on this subject. Are there > any other views on the subject? Do you support one or the other > combattants' views? > > If all we will be hearing is arguments between mainly two people > with diametrically opposite views, we are not going to archieve > anything. > > We are supposed to discuss this next week in the IETF in LA and > it would be nice to have a little better understanding of where > the group stands in this debate by then. Should we abandon SNMPv3 > as a candidate for IPP notifications and concentrate our efforts > on a new or different solution? > > Please give more feedback to the DL. > > 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 Mar 23 16:16:46 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA08922 for ipp-outgoing; Mon, 23 Mar 1998 16:16:15 -0500 (EST) Message-Id: <3.0.1.32.19980323131002.00ceac30@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 23 Mar 1998 13:10:02 PST To: Paul Moore , ipp@pwg.org From: Carl-Uno Manros Subject: RE: IPP> NOT - Is SNMPv3 suitable for IPP Notifications? Cc: jmp@pwg.org, sense@pwg.org In-Reply-To: <5CEA8663F24DD111A96100805FFE6587030BC3B2@red-msg-51.dns.mi crosoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Paul, As far as I am aware, we seem to have agreements on most of the points in your message. The area in which there is still debate is for a delivery mechanism, that can send out notifications more quickly than with email. There has been some interesting discussion lately in the IFAX group about their intended use of MDNs for notifications over email. Those seem to indicate that implementation and actual use of MDNs in email is likely to be a very slow process... Carl-Uno At 11:42 AM 3/23/98 PST, Paul Moore wrote: >Some time since I aired my views on this. > >I think we should make IPP notifications a mechanism whereby a client can >request that a notification be sent to it via any mechanism. > >That is to say - the notification itself is sent any way you like and is not >part of IPP. IPP merely provides the means for the client to request that >this be done. > >We might want to define some standard optional mechanisms (email being the >obvious one). All notifications are optional. > >The IPP Model also needs to define what events are notification candidates >and what they mean. > >The IPP request indicates which events it wants notification on, what >mechanism to use, any parameters associated with that mechanism (email >address) and maybe message content. > >The mechanisms available should be something that is queryable (get printer >attributes). > >There is a separate thing that deals with device level alerts and events - >along with robust data transmission, etc. etc. My thoughts on that topic >have already been aired! > >> -----Original Message----- >> From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] >> Sent: Monday, March 23, 1998 10:38 AM >> To: ipp@pwg.org >> Cc: jmp@pwg.org; sense@pwg.org >> Subject: IPP> NOT - Is SNMPv3 suitable for IPP Notifications? >> >> All, >> >> We have had a rather intensive debate between Randy, who first >> proposed that we might want to use SNMPv3 traps or informs for >> IPP notifications, and Ira, who thinks that the whole idea is >> wrong. >> >> With the exception of Jay's comments earlier today, it has been >> very quiet from the rest of the group on this subject. Are there >> any other views on the subject? Do you support one or the other >> combattants' views? >> >> If all we will be hearing is arguments between mainly two people >> with diametrically opposite views, we are not going to archieve >> anything. >> >> We are supposed to discuss this next week in the IETF in LA and >> it would be nice to have a little better understanding of where >> the group stands in this debate by then. Should we abandon SNMPv3 >> as a candidate for IPP notifications and concentrate our efforts >> on a new or different solution? >> >> Please give more feedback to the DL. >> >> 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 > > 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 Mar 23 16:31:50 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA09907 for ipp-outgoing; Mon, 23 Mar 1998 16:29:45 -0500 (EST) Message-ID: <5CEA8663F24DD111A96100805FFE6587030BC3B4@red-msg-51.dns.microsoft.com> From: Paul Moore To: "'Carl-Uno Manros'" , Paul Moore , ipp@pwg.org Cc: jmp@pwg.org, sense@pwg.org Subject: RE: IPP> NOT - Is SNMPv3 suitable for IPP Notifications? Date: Mon, 23 Mar 1998 13:29:20 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: ipp-owner@pwg.org Precedence: bulk If this is the case "As far as I am aware, we seem to have agreements on most of the points in your message. The area in which there is still debate is for a delivery mechanism, that can send out notifications more quickly than with email." Then why is there a discussion? I can use anything I like for notifications. I cannot see why SNMP appears in this discussion. If a system wants to use SNMP to get events from a device then this is already possible - it has nothing to do with IPP. What IPP needs is end user focussed stuff (pagers, email, etc.). Faster than email would be the network native messenger service (SMB Net Send for example). > -----Original Message----- > From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] > Sent: Monday, March 23, 1998 1:10 PM > To: Paul Moore; ipp@pwg.org > Cc: jmp@pwg.org; sense@pwg.org > Subject: RE: IPP> NOT - Is SNMPv3 suitable for IPP Notifications? > > Paul, > > As far as I am aware, we seem to have agreements on most of the points in > your message. The area in which there is still debate is for a delivery > mechanism, that can send out notifications more quickly than with email. > > There has been some interesting discussion lately in the IFAX group about > their intended use of MDNs for notifications over email. Those seem to > indicate that implementation and actual use of MDNs in email is likely to > be a very slow process... > > Carl-Uno > > > At 11:42 AM 3/23/98 PST, Paul Moore wrote: > >Some time since I aired my views on this. > > > >I think we should make IPP notifications a mechanism whereby a client can > >request that a notification be sent to it via any mechanism. > > > >That is to say - the notification itself is sent any way you like and is > not > >part of IPP. IPP merely provides the means for the client to request that > >this be done. > > > >We might want to define some standard optional mechanisms (email being > the > >obvious one). All notifications are optional. > > > >The IPP Model also needs to define what events are notification > candidates > >and what they mean. > > > >The IPP request indicates which events it wants notification on, what > >mechanism to use, any parameters associated with that mechanism (email > >address) and maybe message content. > > > >The mechanisms available should be something that is queryable (get > printer > >attributes). > > > >There is a separate thing that deals with device level alerts and events > - > >along with robust data transmission, etc. etc. My thoughts on that topic > >have already been aired! > > > >> -----Original Message----- > >> From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] > >> Sent: Monday, March 23, 1998 10:38 AM > >> To: ipp@pwg.org > >> Cc: jmp@pwg.org; sense@pwg.org > >> Subject: IPP> NOT - Is SNMPv3 suitable for IPP Notifications? > >> > >> All, > >> > >> We have had a rather intensive debate between Randy, who first > >> proposed that we might want to use SNMPv3 traps or informs for > >> IPP notifications, and Ira, who thinks that the whole idea is > >> wrong. > >> > >> With the exception of Jay's comments earlier today, it has been > >> very quiet from the rest of the group on this subject. Are there > >> any other views on the subject? Do you support one or the other > >> combattants' views? > >> > >> If all we will be hearing is arguments between mainly two people > >> with diametrically opposite views, we are not going to archieve > >> anything. > >> > >> We are supposed to discuss this next week in the IETF in LA and > >> it would be nice to have a little better understanding of where > >> the group stands in this debate by then. Should we abandon SNMPv3 > >> as a candidate for IPP notifications and concentrate our efforts > >> on a new or different solution? > >> > >> Please give more feedback to the DL. > >> > >> 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 > > > > > 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 Mar 23 21:26:51 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA11659 for ipp-outgoing; Mon, 23 Mar 1998 21:25:02 -0500 (EST) Date: Mon, 23 Mar 1998 18:30:49 PST From: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962) Message-Id: <9803240230.AA16432@snorkel.eso.mc.xerox.com> To: ipp@pwg.org, jmp@pwg.org Subject: IPP> Re: NOT - Is SNMPv3 suitable for IPP Notifications? Sender: ipp-owner@pwg.org Precedence: bulk Hi Randy, Harry, Paul, Jay, et al, I concede all points. I got dragooned into stating my technical objections to the scalability of the SNMPv3 trap registration mechanisms. The discussion has wandered off completely into the merits of the SNMPv3 protocol itself, which is irrelevant. I never wanted to start this thread. I hereby withdraw from it. I'll watch with interest what you folks decide on. Cheers, - Ira McDonald (High North) PS - In a few weeks, my wife Nancy and I fly off to Scotland for five weeks of walking and visiting gardens (MUCH more rewarding than computer industry standards work). We'll be back on our farm in Grand Marais, Michigan around Wednesday (20 May). Good luck with the IESG on IPP/1.0. From ipp-archive Mon Mar 23 23:37:17 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA12601 for ipp-outgoing; Mon, 23 Mar 1998 23:34:27 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'imcdonal@eso.mc.xerox.com'" , ipp@pwg.org, jmp@pwg.org Subject: RE: IPP> Re: NOT - Is SNMPv3 suitable for IPP Notifications? Date: Mon, 23 Mar 1998 20:34:02 -0800 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 ..snip.. PS - In a few weeks, my wife Nancy and I fly off to Scotland for five weeks of walking and visiting gardens (MUCH more rewarding than computer industry standards work). We'll be back on our farm in Grand Marais, Michigan around Wednesday (20 May). Good luck with the IESG on IPP/1.0. Need someone to carry your luggage? Randy From ipp-archive Tue Mar 24 10:17:02 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA24325 for ipp-outgoing; Tue, 24 Mar 1998 10:16:32 -0500 (EST) Message-Id: <3517CD57.28B24665@dazel.com> Date: Tue, 24 Mar 1998 09:12:23 -0600 From: James Walker Reply-To: walker@dazel.com Organization: DAZEL Corporation X-Mailer: Mozilla 4.04 [en] (WinNT; I) Mime-Version: 1.0 To: Jay Martin Cc: ipp@pwg.org, jmp@pwg.org, sense@pwg.org Subject: Re: IPP> Re: SNMPv3 unsuited for IPP/JMP Notifications References: <35167F33.3D332CAF@underscore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Jay Martin wrote: > > Turner, Randy wrote: > > > I will reiterate my belief that I don't think its realistic for a simple > > embedded device to maintain notification info for hundreds of clients. > > I agree 110%. That fundamental belief is one of the most critical > assumptions for which SENSE was designed. Namely, require the > managed entity (ie, a printer) to provide minimal scalability for > key services (ie, just a few simultaneous client accesses), then > route that information into a generalized client/server system > with a very high degree of scalability. Well, here we go again... Is it just me, or are we running into the embedded printer requirements versus the print server requirements. If we are talking about IPP, the host to device protocol, then I agree that the device need only support a limited number of notification clients. If we are talking about IPP, the print client to server protocol, then I believe that print server ought to be able to scale to 100's, even 1000's, of clients. ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX From ipp-archive Tue Mar 24 11:32:08 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA25321 for ipp-outgoing; Tue, 24 Mar 1998 11:27:58 -0500 (EST) From: Harry Lewis To: Cc: , Subject: Re: IPP> Re: SNMPv3 unsuited for IPP/JMP Notifications Message-ID: <5030300019296298000002L082*@MHS> Date: Tue, 24 Mar 1998 11:34:05 -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 Well, yes, it gets pretty confusing... >Well, here we go again... > >Is it just me, or are we running into the embedded printer requirement= s >versus the print server requirements. If we are talking about IPP, th= e >host to device protocol, then I agree that the device need only suppor= t >a limited number of notification clients. If we are talking about IPP= , >the print client to server protocol, then I believe that print server >ought to be able to scale to 100's, even 1000's, of clients. > >...walker Because we're talking less about IPP and more about a notification serv= ice where, as a potential ubiquitous print submission protocol, IPP needs a= mechanism for registering clients for notifications, regardless of the scalability of the notification server I think we need to look at notification services both from the limitati= ons of an embedded device (where most notifications will originate), AND from = the point of view of a robust server implementation (like SENSE). The devic= e is not likely to accept the notion of give me e-mail on this message, pager fr= om noon-2pm and fog horn after dark. Oh, and I'd like specifically, and ON= LY, the following content with that notice. But, I'm hearing that we wish to co= nsider all this flexibility (and more) in our design. If we break notification into "stages"... the "device originated notifi= cation" and the "server based notification"... I think it is likely that typica= l client-server-device breakpoints will result in several registered host= s at the device. It is also possible to create a limited peer-to-peer printing s= ystem with no notification server where print clients register directly with = the device. It is also possible to create a notification server that simply= polls the device, eliminating the need for a device notification protocol or registration scheme. Since, as Jim points out, we really are talking about (at least) two st= ages of notification, we should be careful to indicate which part of the proble= m our recommendation is addressing. Harry Lewis - IBM Printing Systems = From ipp-archive Tue Mar 24 12:22:09 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA26174 for ipp-outgoing; Tue, 24 Mar 1998 12:18:53 -0500 (EST) Message-Id: <3.0.1.32.19980324091036.01204330@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 24 Mar 1998 09:10:36 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - PWG IPP Phone Conference 980325 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk PWG IPP Phone Conference Agenda for 980325 Latests news from Keith Moore is that we will NOT get any feedback from him or the IESG worth discussing in LA. This leaves IPP Notifications as the main agenda item for the IPP LA meeting. I would like to concentrate our discussions this week on the different aspects of notifications and try to straighten out where we think that we have agreements and where we need to do more work, so that we can identify the things worth spending time on in LA. We have the discussions from the Austin meeting as a basis. It seems to me that we could start working on the IPP part of the solution right away, and keep up the discussion about how to actually deliver the notifications. Tom's recent proposal on a dictionary attribute is one option for how we could express things like requesting notifications to more than one destination. If we have sufficient time we should also move on to the subject of host-to-device. Out of the home work assignments from Austin, Don has produced a strawaman for how TIPSI could be used. Randy is also working on a proposal on how to modify IPP to serve as a host-to-device protocol, but we are still waiting for that to show up. The phone-in information is: Date and Time: March 25, 10:00-12:00 am PST (remember the earlier time slot) Phone number: 212-547-0304 (For Xerox participants 8*535-5000) Pass code: cmanros Please note that the phone number is different from last 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 Tue Mar 24 16:37:06 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA27877 for ipp-outgoing; Tue, 24 Mar 1998 16:35:32 -0500 (EST) Message-Id: <3.0.1.32.19980324131914.01211100@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 24 Mar 1998 13:19:14 PST To: agenda@ns.ietf.org, moore+iesg@cs.utk.edu, Harald.Alvestrand@maxware.no From: Carl-Uno Manros Subject: IPP> Agenda for IPP WG in LA Cc: ipp@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk IPP WG Agenda - Wednesday March 1, 1998 1300 - 1500 =================================================== 1) Review and discuss proposed requirements for IPP Notifications and entertain proposals for possible existing standarization efforts on which IPP Notifications could be built. o Requirements for IPP Notifications 2) Discuss how to make sure that the generic directory attributes from the IPP Model & Semantics documents gets mapped to SLP and LDAP. o Internet Printing Protocol/1.0: Model and Semantics o Definition of printer: URLs for use with Service Location 3) Discuss any other future work on IPP. 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 Mar 24 16:57:09 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA28581 for ipp-outgoing; Tue, 24 Mar 1998 16:55:39 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: IPP> new proposal Date: Tue, 24 Mar 1998 13:55:27 -0800 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 Hi everyone, I will be placing a proposal for a new transport mapping on the FTP server sometime this evening. The conference call tomorrow is at 10 AM. It is a relatively short proposal (downsized from 15 pages to 10 pages recently). If you have time tomorrow morning, you might want to pull it down and glance at it before the phone conference. I will send another mail message to the DL when it is posted, hopefully by 7:00 PM PST. Sorry for the delay, I was bogged down again with "products" this week. "Man! The bottom line sure gets in the way sometimes..." R. From ipp-archive Tue Mar 24 16:57:10 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA28500 for ipp-outgoing; Tue, 24 Mar 1998 16:54:53 -0500 (EST) Message-Id: <3.0.1.32.19980324134847.00ce9450@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 24 Mar 1998 13:48:47 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Sessions of interest to IPP in LA Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_890804927==_" Sender: ipp-owner@pwg.org Precedence: bulk --=====================_890804927==_ Content-Type: text/plain; charset="us-ascii" Hi all, On request, I have put together a "condenced" version of the overall IETF41 Agenda only keeping the sessions that I believe to be of interest to IPPers. This is obviously just my own personal stab at identifying things based on our earlier or ongoing discussion subjects from the IPP DL. You should consult the full official IETF41 Agenda for other subjects, as well as for any last minute updates. Attached in HTML format. Regards, Carl-Uno --=====================_890804927==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="IPP-special.html" DRAFT Agenda of the Forty-first IETF
Agenda of the Forty-first IETF
March 30 - April 3, 1998
   
MONDAY, March 30, 1998
 
0900-0930 Opening Plenary - San Francisco/Sacramento Room

0930-1130 Morning Sessions
 
 NONE

1300-1500 Afternoon Sessions I
 
San Diego              APP    httpext     HTTP Extensibility BOF
  
1530-1730 Afternoon Sessions II
 
Santa Barbara A      SEC    tls            Transport Layer Security WG
 
1930-2200 Evening Sessions
 
Santa Anita C         OPS   disman    Distributed Management WG
 
TUESDAY, March 31, 1998
 
0900-1000 Morning Sessions I
 
Emeral Bay             OPS   snmpv3   SNMP Version 3 WG
 
1015-1115 Morning Sessions II
 
Santa Barbara A     INT    svrloc       Service Location Protocol WG
Emerald Bay           OPS   snmpv3    SNMP Version 3 WG

1300-1400 Afternoon Sessions I
 
Santa Anita AB       INT    ip1394       IP Over IEEE 1394 WG

1415-1515 Afternoon Sessions II
 
Santa Anita AB       INT    ip1394      IP Over IEEE 1394 WG
 
1545-1645 Afternoon Sessions III
 
Santa Barabara A    APP   acap        Application Configuration Access Protocol WG
 
1700-1800 Afternoon Sessions IV
 
Santa Anita C          APP    mhtml     MIME Encapsulation of Aggregate HTML Doc. WG
 
WEDNESDAY, April 1, 1998
 
0900-1130 Morning Sessions
 
Emerald Bay           APP   fax            Internet Fax WG
Avalon                    APP   ldapext     LDAP Extensions WG
 
1300-1500 Afternoon Sessions I
 
Santa Anita C         APP   ipp            Internet Printing Protocol WG
 
1530-1730 Afternoon Sessions II
 
NONE
 
1930-2200 Evening Sessions
 
San Diego              APP   dasl           DAV Searching and Locating BOF
 
THURSDAY, April 2, 1998
 
0900-1130 Morning Sessions
 
Emeral Bay            APP    fax          Internet Fax WG

1300-1500 Afternoon Sessions I
 
Santa Anita AB      APP     webdav    WWW Distributed Authoring and Versioning WG

1530-1730 Afternoon Sessions II
 
Santa Anita AB       APP    conneg     Content Negotiation WG
 
FRIDAY, April 3, 1998
 
1000-1130 IAB Open Plenary - San Francisco/Sacramento Room

          o    General Comments - Fred Baker
          o    Nominations Committee Report - Michael St. Johns
          o    IAB Open Plenary Session
          o    IESG Open Plenary Session
===========================================================================
Key to Abbreviations

APP   Applications                          Harald Alvestrand/Maxware and
                                                       Keith Moore/UTK
GEN   General Interest                    Fred Baker/Cisco Systems
INT    Internet                                 Jeffrey Burgan @Home Network and
                                                       Thomas Narten/IBM Corporation
OPS    Operations & Management   John Curran/BBN Corporation and
                                                       Michael O'Dell/UUNET Technologies
RTG     Routing                                Joel Halpern/Newbridge Networks
SEC     Security                                Jeff Schiller/MIT
TSV     Transport                             Scott Bradner/Harvard University and
                                                        Allyn Romanow/MCI Corporation
USV     User Services                      Joyce K. Reynolds/ISI
 
  --=====================_890804927==_ Content-Type: text/plain; charset="us-ascii" 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 --=====================_890804927==_-- From ipp-archive Tue Mar 24 18:38:47 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA29788 for ipp-outgoing; Tue, 24 Mar 1998 18:32:41 -0500 (EST) Message-Id: <3.0.1.32.19980324152613.009bc990@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 24 Mar 1998 15:26:13 PST To: agenda@ns.ietf.org, moore+iesg@cs.utk.edu, Harald.Alvestrand@maxware.no From: Carl-Uno Manros Subject: IPP> Agenda for Internet Printing Protocol (ipp) WG in IETF41 (corrected) Cc: ipp@pwg.org, szilles@adobe.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk OOPS, Got the wrong month on the previous version. Here is the corrected one: IPP WG Agenda - Wednesday April 1, 1998 1300 - 1500 =================================================== 1) Review and discuss proposed requirements for IPP Notifications and entertain proposals for possible existing standarization efforts on which IPP Notifications could be built. o Requirements for IPP Notifications 2) Discuss how to make sure that the generic directory attributes from the IPP Model & Semantics documents gets mapped to SLP and LDAP. o Internet Printing Protocol/1.0: Model and Semantics o Definition of printer: URLs for use with Service Location 3) Discuss any other future work on IPP. 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 Tue Mar 24 19:29:00 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA00233 for ipp-outgoing; Tue, 24 Mar 1998 18:37:45 -0500 (EST) Message-Id: <3.0.1.32.19980324153634.01213b10@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 24 Mar 1998 15:36:34 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD/PRO - simple proposal for providing dictionary-like capability Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk For the IPP telecon, Wed, 3/25: Roger, Bob, and I have been working on various dictionary proposals. Last Friday, we had a teleconference on version 0.8. After Roger hung up, Bob and I came up with yet another simpler proposal which is version 0.9. I edited the document, but neither Bob nor Roger have had the time to send me comments, since they are both away at meetings this week. However, Carl-Uno thought it would be good to at least discuss this work in progress. Send any comments before hand and/or I'll present the ideas on the telecon. I've posted: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-dict-1setOf-1setOf.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-dict-1setof-1setof.pdf Briefly, the scheme isn't really a dictionary at all (previous versions were). Other earlier versions were adding a new addressing mechanism for attributes in dictionaries. This proposal adds no new addressing mechanisms, but justs add a new out-of-band value to encode the new Model attribute syntax of 1setOf 1setOf (doubly nested values). Instead, we use the idea of attributes with parallel values, like we already have for "printer-uri-supported" and "uri-security-supported". I fleshed out a real world example for "job-notify", "job-notify-default", and "job-notify-supported" to show how it works, along with a simpler "printer-resolution", "printer-resolution-default" and "printer-resolution-supported" example. I've left the rejected example that uses the 'dictionary' attribute syntax in the document. I've also listed the alternatives that we considered and the reasons for rejecting them. There are two issues remaining: ISSUE 1: If a 1setOf 1setOf value is a single value, does the sender need to include the double nesting or not? It would be nice if our encoding would allow a single value, i.e.,: "job-notify-method-supported" 'mailto', { 'sense', 'tcp/ip-socket' } for representing: job-notify-method-supported (1setOf 1setOf type2 keyword) where the "{" indicates the begin and the "}" indicates the end. Thus the new begin and end construct is not needed for every use of 1setOf 1SetOf, only when there are actually more than one value for the second 1setOf. Here is what I have for the encoding: 5 Encoding In order to allow the 1setOf 1setOf to be represented as merely 1setOf when there is only one value in a set of parallel attributes, we need a begin and end indication of a set of values that are to be grouped together into a 1setOf 1setOf. The simplest and most compatible way to add simple begin and end markers that can be ignored by existing parsers is to use an attribute to mean begin of a 1setOf 1setOf and another attribute to flag the end of a 1setOf 1SetOf value. Since the begin and end flags don't need any values, it is simplest to add a single out-of-band value, say, 'value-marker' and then introduce two new attributes that use it: "begin-set-of-set" and "end-set-of-set". ISSUE 2: Ok to use the same "out-of-band" with different attributes to get the begin and end? Tom From ipp-archive Wed Mar 25 12:42:19 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA14171 for ipp-outgoing; Wed, 25 Mar 1998 12:40:57 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'ipp@pwg.org'" Subject: IPP> new proposal Date: Wed, 25 Mar 1998 09:40:44 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BD57D2.16DEA2C0" Sender: ipp-owner@pwg.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_000_01BD57D2.16DEA2C0 Content-Type: text/plain Sorry for the delay, but our internet connection was up and down last night and I "gave up the ghost". The document is ready this morning as of 9:00 AM in the new_PRO directory on the IPP FTP directory. The document is "Ipptcp.doc". It is a word95 document. I am also included a copy as an attachment to speed things up for those people that can handle attachments. Randy ------ =_NextPart_000_01BD57D2.16DEA2C0 Content-Type: application/msword; name="ipptcp.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ipptcp.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAMgAAAAAAAAAA EAAALwAAAAEAAAD+////AAAAADMAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////c pWgAY+AJBAAAAABlAAAAAAAAAAAAAAAAAwAAKEkAAPpZAAAAAAAAAAAAAAAAAAAAAAAAKEYAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAAKQAAAAAWAAApAAAAKRYAAAAAAAApFgA AAAAAACkWAAAAAAAAKRYAAAAAAAApFgAABQAAAC4WAAAAAAAALhYAAAAAAAAuFgAAAAAAAC4WAAA AAAAALhYAAAAAAAAuFgAAAoAAADCWAAAKAAAALhYAAAAAAAA7FgAAEMAAADqWAAAAAAAAOpYAAAA AAAA6lgAAAAAAADqWAAAAAAAAOpYAAAAAAAA6lgAAAAAAADqWAAAAAAAAOpYAAAAAAAA6lgAAAIA AADsWAAAAAAAAOxYAAAAAAAA7FgAAAAAAADsWAAAAAAAAOxYAAAAAAAA7FgAAAAAAAAvWQAAWAAA AIdZAABzAAAA7FgAAAAAAAAAAAAAAAAAAAAAAAAAAAAApFgAAAAAAADqWAAAAAAAAAAAJQAmAAEA BgDqWAAAAAAAAOpYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOpYAAAAAAAA6lgAAAAAAADsWAAAAAAA AOpYAAAAAAAApFgAAAAAAACkWAAAAAAAAOpYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOpYAAAAAAAA 6lgAAAAAAADqWAAAAAAAAOpYAAAAAAAA6lgAAAAAAACkWAAAAAAAAOpYAAAAAAAApFgAAAAAAADq WAAAAAAAAOpYAAAAAAAAAAAAAAAAAABgku8AFVi9AbhYAAAAAAAAuFgAAAAAAACkWAAAAAAAAKRY AAAAAAAApFgAAAAAAACkWAAAAAAAAOpYAAAAAAAA6lgAAAAAAADqWAAAAAAAAOpYAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJhbmR5IFR1cm5lcg1FeHBpcmVzOiBTZXB0ZW1i ZXIgMTk5OCAgICAgICAgICAgICAgICAgICAgICAgICAgIFNoYXJwIExhYnMgb2YgQW1lcmljYQ0N DSAgICAgICAgICAgICAgSW50ZXJuZXQgUHJpbnRpbmcgUHJvdG9jb2wgb3ZlciBUQ1AvSVANDQ1T dGF0dXMgb2YgdGhpcyBNZW1vDQ1UaGlzIGRvY3VtZW50IGlzIGFuIEludGVybmV0LURyYWZ0LiAg SW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nDWRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5n aW5lZXJpbmcgVGFzayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywNYW5kIGl0cyB3b3JraW5nIGdy b3Vwcy4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZQ13b3JraW5n IGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuDQ1JbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0 IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMgYW5kIG1heSBiZSB1 cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkg dGltZS4gSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVy ZW5jZSBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAnJ3dvcmsgaW4gcHJv Z3Jlc3MnJw0NVG8gbGVhcm4gdGhlIGN1cnJlbnQgc3RhdHVzIG9mIGFueSBJbnRlcm5ldC1EcmFm dCwgcGxlYXNlIGNoZWNrIHRoZQ1gYDFpZC1hYnN0cmFjdHMudHh0JycgbGlzdGluZyBjb250YWlu ZWQgaW4gdGhlIEludGVybmV0LURyYWZ0cyBTaGFkb3cNRGlyZWN0b3JpZXMgb24gZnRwLmlzLmNv LnphIChBZnJpY2EpLCBuaWMubm9yZHUubmV0IChFdXJvcGUpLA1tdW5uYXJpLm96LmF1IChQYWNp ZmljIFJpbSksIGRzLmludGVybmljLm5ldCAoVVMgRWFzdCBDb2FzdCksIG9yDWZ0cC5pc2kuZWR1 IChVUyBXZXN0IENvYXN0KS4NDQ0xIEFic3RyYWN0DQ1UaGUgSW50ZXJuZXQgUHJpbnRpbmcgUHJv dG9jb2wgKElQUCkgaXMgZnVuZGFtZW50YWxseSBkZWZpbmVkIGJ5IHRoZSBJUFAgTW9kZWwgJiBT ZW1hbnRpY3MvMS4wIERvY3VtZW50IFsxXS4gVGhlIElQUCBtb2RlbCB3YXMgZGVzaWduZWQgdG8g YmUgdHJhbnNwb3J0LWluZGVwZW5kZW50LiBUaGVyZSBjdXJyZW50bHkgZXhpc3RzIGEgZG9jdW1l bnQgdGhhdCBkZXNjcmliZXMgdXNpbmcgSHlwZXJ0ZXh0IFRyYW5zZmVyIFByb3RvY29sIChIVFRQ KSAxLjEgYXMgYSB0cmFuc3BvcnQgbGF5ZXIgZm9yIElQUCBbSVBQUFJPVF0uIEJlY2F1c2UgdGhl IElQUCBtb2RlbCBkb2N1bWVudCBpcyBub3QgdHJhbnNwb3J0LXNwZWNpZmljLCBpdCB3YXMgZW52 aXNpb25lZCB0aGF0IHBvc3NpYmx5IG11bHRpcGxlIHRyYW5zcG9ydCBzcGVjaWZpY2F0aW9ucyB3 b3VsZCBiZSBhdXRob3JlZCBmb3IgSVBQLiBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBzdWNoIGFu IGFsdGVybmF0ZSB0cmFuc3BvcnQgZm9yIElQUCBtZXNzYWdlcywgYW5kIGF0dGVtcHRzIHRvIGNs YXJpZnkgdGhlIHRyYW5zcG9ydC1pbmRlcGVuZGVuY2UgaW1wbGllZCBieSB0aGUgSVBQIG1vZGVs IGFuZCBzZW1hbnRpY3MgZG9jdW1lbnQuDQ0yIE92ZXJ2aWV3DQ1UaGlzIGRvY3VtZW50IGRlc2Ny aWJlcyBhIG5ldyB0cmFuc3BvcnQgbWFwcGluZyBmb3IgdGhlIElQUCBwcm90b2NvbC4gIFRoZSBl eGlzdGluZyBzZXQgb2YgZG9jdW1lbnRzIGRlc2NyaWJpbmcgSVBQIGRlZmluZSBhIG1vZGVsIGFu ZCBhYnN0cmFjdCBwcm90b2NvbCBmb3IgcHJpbnRpbmcsIGFuZCBhbiBleHBsaWNpdCBlbmNvZGlu ZyBhbmQgdHJhbnNwb3J0IG92ZXIgSFRUUCAxLjEuIFRoaXMgZG9jdW1lbnQgaXMgYSB0cmFuc3Bv cnQgZG9jdW1lbnQgdGhhdCBleHBsaWNpdCBkZWZpbmVzIGhvdyB0aGUgZXhpc3RpbmcgSVBQIGVu Y29kaW5nIGlzIHRyYW5zcG9ydGVkIGRpcmVjdGx5IG92ZXIgVENQLg0NVGhpcyBkb2N1bWVudCBt YWtlcyBleHBsaWNpdCByZWZlcmVuY2VzIHRvIGJvdGggdGhlIElQUCBtb2RlbCBkb2N1bWVudCBb SVBQTU9EXSBhbmQgdGhlIGV4aXN0aW5nIElQUCBQcm90b2NvbC9FbmNvZGluZyBkb2N1bWVudCBb SVBQUFJPVF0uIFRoaXMgcHJvcG9zYWwgaW1wbGllcyBubyBzZW1hbnRpYyBjaGFuZ2VzIHRvIHRo ZSBJUFAgbW9kZWwgZG9jdW1lbnQuIEZ1cnRoZXIsIGl0IHJldXNlcyB0aGUgZW5jb2Rpbmcgc3Bl Y2lmaWVkIGluIFtJUFBQUk9UXSBpbiBpdHMgZW50aXJldHkuIE9ubHkgdGhlIG1lY2hhbmlzbSBm b3IgdHJhbnNwb3J0aW5nIHRoZSBleGlzdGluZyBlbmNvZGluZyBpcyBtb2RpZmllZCBieSB0aGlz IHByb3Bvc2FsLg0NMyBJUFAgb3ZlciBUQ1AvSVAgliBSYXRpb25hbGUgU3RhdGVtZW50DQ1UaGVy ZSBpcyBhIHBlcmNlaXZlZCBub3Rpb24gdGhhdCB0aGUgY3VycmVudCBJUFAtb3Zlci1IVFRQIHNw ZWNpZmljYXRpb24gaW1wb3NlcyBhICJoZWF2eXdlaWdodCIgcmVxdWlyZW1lbnQgb24gbG93LWNv c3QsIGVtYmVkZGVkIGRldmljZXMsIGluIHRlcm1zIG9mIHJlc291cmNlcyBhbmQgaW1wbGVtZW50 YXRpb24gZWZmb3J0LiBJbml0aWFsIGltcGxlbWVudGF0aW9ucyBvZiBJUFAtb3Zlci1IVFRQIHdp bGwgYmUgdGFyZ2V0ZWQgdG93YXJkcyBzZXJ2ZXItYmFzZWQgc3lzdGVtcywgd2l0aCBsb2NhbCBz dG9yYWdlIGNhcGFjaXR5IGZvciBzcG9vbGluZyBhbmQgb3RoZXIgam9iIG1hbmFnZW1lbnQgZmVh dHVyZXMuIFRoZSB1c2Ugb2YgSFRUUCBhcyBhIHRyYW5zcG9ydCB3aWxsIGFsbG93IHF1aWNrIGRl cGxveW1lbnQgb2YgaW50ZXJuZXQgY2FwYWJpbGl0eSBmb3IgcHJpbnRpbmcgdGhyb3VnaCBzdGFu ZGFyZCBIVFRQIHNlcnZlciBleHRlbnNpb24gbWVjaGFuaXNtcyAoQ0dJLCBOU0FQSSwgSVNBUEks IEphdmEgc2VydmxldHMsIGV0Yy4pLiBCZWNhdXNlIHRoZSBjb3JlIElQUCBwcm90b2NvbCBtb2Rl bCBjb250YWlucyBubyBIVFRQLXNwZWNpZmljIHJlcXVpcmVtZW50cyBvciBzZW1hbnRpY3MsIHRo aXMgZG9jdW1lbnQgc3VnZ2VzdHMgYW4gYWx0ZXJuYXRlIHRyYW5zcG9ydCBmb3IgdGhlIElQUCBh YnN0cmFjdCBwcm90b2NvbCB1dGlsaXppbmcgc2ltcGxlciB0cmFuc3BvcnQgc2VtYW50aWNzLCBh cyB3ZWxsIGFzIHByb3ZpZGluZyBzbGlnaHQgY2hhbmdlcyB0byBJUFAgY2xpZW50L3NlcnZlciBp bnRlcmFjdGlvbi4gVGhlIGNoYW5nZXMgYXJlIG1pbm9yIGFuZCBhbGxvdyB0aWdodGVyIGludGVn cmF0aW9uIG9mIGNsaWVudCBhbmQgcHJpbnRlciBmb3Igbm90aWZpY2F0aW9ucyBhbmQgc3RhdHVz IGluZm9ybWF0aW9uLg0NVGhlIGZvbGxvd2luZyBkaWFncmFtIHNob3dzIG9uZSBJUFAgdG9wb2xv Z3kgZm9yIHdoaWNoIHRoZSBwcm9wb3NlZCBUQ1AvSVAgdHJhbnNwb3J0IHdvdWxkIGJlIHV0aWxp emVkDQ1JUFAvSFRUUCBjbGllbnRzICAgICAgICAgICAgIElQUCBTZXJ2ZXIgICAgICAgICAgICBJ UFAgUHJpbnRlcnMNDSAgLS0tLS0tLS0tICAgICAgICAgICAgIHwtLS0tLS0tLS0tLS0tLS0tLS18 DSAgfCAgIEMxICB8ICAgSFRUUCAgICAgIHwgICAgICAgICArICAgICAgICB8ICAgVENQICAgfC0t LS0tLXwNICB8ICAgICAgIHw9PT09PT09PT09PT09fCAgICAgICAgICsgICAgICAgIHw9PT09PT09 PT18ICBQMSAgfA0gIC0tLS0tLS0tLSAgICAgICAgICAgICB8ICAgIEggICAgKyAgICAgICAgfCAg ICAgICAgIHwtLS0tLS18DSAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICArICAgVCAg ICB8DSAgLS0tLS0tLS0tICAgICAgICAgICAgIHwgICAgVCAgICArICAgICAgICB8DSAgfCAgIEMy ICB8ICAgSFRUUCAgICAgIHwgICAgICAgICArICAgQyAgICB8ICAgVENQICAgfC0tLS0tLXwNICB8 ICAgICAgIHw9PT09PT09PT09PT09fCAgICBUICAgICsgICAgICAgIHw9PT09PT09PT18ICBQMiAg fA0gIC0tLS0tLS0tLSAgICAgICAgICAgICB8ICAgICAgICAgKyAgIFAgICAgfCAgICAgICAgIHwt LS0tLS18DSAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgUCAgICArICAgICAgICB8DSAgLS0t LS0tLS0tICAgICAgICAgICAgIHwgICAgICAgICArICAgICAgICB8ICAgVENQICAgfC0tLS0tLXwN ICB8ICAgQzMgIHwgICBIVFRQICAgICAgfCAgICAgICAgICsgICAgICAgIHw9PT09PT09PT18ICBQ MyAgfA0gIHwgICAgICAgfD09PT09PT09PT09PT18ICAgICAgICAgKyAgICAgICAgfCAgICAgICAg IHwtLS0tLS18DSAgLS0tLS0tLS0tICAgICAgICAgICAgIHwtLS0tLS0tLS0tLS0tLS0tLS18DQ0N ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDENDQ1FeGlzdGluZyBJUFAvMS4w LW92ZXItSFRUUCBjbGllbnRzIHdvdWxkIHN1Ym1pdCBqb2JzIHRvIElQUCBzZXJ2ZXJzLiBUaGUg c2VydmVycyB3b3VsZCByZWxheSB0aGUgSVBQIHJlcXVlc3RzIHRvIHBoeXNpY2FsIHByaW50ZXJz IHVzaW5nIHRoZSBwcm9wb3NlZCBUQ1AvSVAgdHJhbnNwb3J0LiBUaGUgdHJhbnNwb3J0IGdhdGV3 YXkgaXMganVzdCB0aGF0LCBhIHRyYW5zcG9ydCBnYXRld2F5LCBub3QgYW4gYXBwbGljYXRpb24t bGV2ZWwgZ2F0ZXdheS4gVGhlcmVmb3JlLCB0aGVyZSB3b3VsZCBiZSBubyBsb3NzIGluIGFwcGxp Y2F0aW9uIGluZm9ybWF0aW9uIGZyb20gY2xpZW50IHRvIGV2ZW50dWFsIHBoeXNpY2FsIHByaW50 ZXIuIA0NT2YgY291cnNlLCB0aGlzIHVzZSBvZiB0aGUgcHJvcG9zZWQgc2ltcGxlIHRyYW5zcG9y dCBpcyBidXQgb25lIHBvc3NpYmxlIHRvcG9sb2d5LiBUaGUgZGlhZ3JhbSBhYm92ZSBjb3VsZCBi ZSBjaGFuZ2VkIHNvIHRoYXQgYm90aCBJUFAgc2VydmVycyBhbmQgSVBQIGNsaWVudHMgQk9USCBj b25uZWN0IHRvIElQUCBwaHlzaWNhbCBwcmludGVycywgaWYgYm90aCBzZXJ2ZXJzIGFuZCBjbGll bnRzIHdpc2ggdG8gdGFrZSBhZHZhbnRhZ2Ugb2YgdGhlIGZlYXR1cmVzIG9mIHRoZSBwcm9wb3Nl ZCB0cmFuc3BvcnQuIEFsc28sIHNjZW5hcmlvcyB3aGVyZWluIG11bHRpcGxlIGxldmVscyBvZiBz ZXJ2ZXJzIGNvbW11bmljYXRpbmcgd2l0aCBzZXJ2ZXJzIHdoaWNoIGV2ZW50dWFsbHkgY29tbXVu aWNhdGUgd2l0aCBhIHBoeXNpY2FsIHByaW50ZXIgY291bGQgYmUgc3VwcG9ydGVkIGFzIHdlbGwu DQ1JUFAgc2VjdXJpdHkgaXMgYWxzbyBhZGRyZXNzZWQgYnkgdGhpcyBtZW1vLCBhbmQgYSBzaW1w bGVyIG1lY2hhbmlzbSBmb3Igc3VwcG9ydCBvZiBpbi1iYW5kIHNlY3VyaXR5IG5lZ290aWF0aW9u IGlzIGluY2x1ZGVkIGluIHRoZSBwcm9wb3NlZCB0cmFuc3BvcnQuDQ00IElQUCBQcm90b2NvbCBQ cm9jZXNzaW5nDQ1UaGlzIGRyYWZ0IHByb3Bvc2VzIGEgbW9kZWwgZm9yIElQUCBwcm90b2NvbCBv cGVyYXRpb24gdGhhdCBmb2xsb3dzIG90aGVyIGFwcGxpY2F0aW9uIHByb3RvY29scyB0aGF0IHN1 cHBvcnQgbXVsdGlwbGUgdHJhbnNwb3J0cywgaW5jbHVkaW5nIFNOTVAgVmVyc2lvbiAzIFtSRkMy MjczXS4gVGhlIG9wZXJhdGlvbiBtb2RlbCBkZXNjcmliZWQgaGVyZWluIHNwZWNpZmllcyB0d28g aW5kZXBlbmRlbnRseSBvcGVyYXRpbmcgImxheWVycyI6IFRoZSBJUFAgcHJvY2Vzc2luZyBsYXll ciBhbmQgb25lIG9yIG1vcmUgdHJhbnNwb3J0IGxheWVycy4NDVRoZSBJUFAgcHJvY2Vzc2luZyBs YXllciBpcyB0aGUgY29yZSBwcm90b2NvbCBlbmdpbmUgdGhhdCB1bmRlcnN0YW5kcyB0aGUgc2Vt YW50aWNzIG9mIHByb3RvY29sIG9wZXJhdGlvbnMsIHN1Y2ggYXMgcmVxdWVzdHMgYW5kIHJlc3Bv bnNlcy4gVGhlIGNvcmUgSVBQIHByb3RvY29sIGVuZ2luZSBvcGVyYXRlcyBpbmRlcGVuZGVudGx5 IG9mIHRyYW5zcG9ydC4gVGhlIGluZGVwZW5kZW5jZSBpcyBhY2hpZXZlZCB0aHJvdWdoIGFkaGVy ZW5jZSB0byBzcGVjaWZpYyBpbnRlcmZhY2VzLiBUaGUgbmV4dCBzZWN0aW9uIGRlc2NyaWJlcyB0 aGUgYWJzdHJhY3QgaW50ZXJmYWNlKHMpIGVtcGxveWVkIHRvIGFjaGlldmUgdGhlIG11bHRpcGxl LXRyYW5zcG9ydCBtb2RlbC4gVGhlIGRpc2N1c3Npb24gb2YgYWJzdHJhY3QgdHJhbnNwb3J0IGlu dGVyZmFjZXMgYW5kIHN1YnNlcXVlbnQgc3RhdHVzIGNvZGVzIGlzIG1lcmVseSB0byBlbXBoYXNp emUgYW5kIGNsYXJpZnkgaG93IGEgcGFydGljdWxhciBJUFAgaW1wbGVtZW50YXRpb24gbWlnaHQg YmUgYXJjaGl0ZWN0ZWQgdG8gc3VwcG9ydCBtdWx0aXBsZSB0cmFuc3BvcnRzLiBJdCBhbHNvIGls bHVzdHJhdGVzIGhvdyBJUFAgInRyYW5zcG9ydC1nYXRld2F5cyIgY2FuIGJlIGNvbnN0cnVjdGVk LiBUaGUgaW5jbHVzaW9uIG9mIHRoaXMgYWJzdHJhY3QgbW9kZWwgZG9lcyBub3QgaW1wbHkgdGhh dCBhIHBhcnRpY3VsYXIgaW1wbGVtZW50YXRpb24gb2YgdGhpcyBwcm90b2NvbCBtYXBwaW5nIFNI T1VMRCBvciBNVVNUIGJlIGNvbnN0cnVjdGVkIHVzaW5nIHRoZXNlIGFic3RyYWN0IHNlbWFudGlj cy4NDTQuMSBJUFAgVHJhbnNwb3J0IEludGVyZmFjZQ0NVGhlIGZvbGxvd2luZyBhYnN0cmFjdCBp bnRlcmZhY2UgaXMgdXNlZCBieSBhbiBJUFAgcHJvY2Vzc2luZyBlbmdpbmUgdG8gdHJhbnNtaXQg YSBQRFUsIGFjcm9zcyBhIHBhcnRpY3VsYXIgdHJhbnNwb3J0LCB0byBhbm90aGVyIElQUCBwcm90 b2NvbCBwcm9jZXNzaW5nIGVuZ2luZS4gVGhlIG1vZGVsIGFuZCBmb3JtYXQgaXMgdGFrZW4gZnJv bSBbUkZDMjI3M10gYXMgYW4gZXhhbXBsZSBhYnN0cmFjdCBpbnRlcmZhY2UsIHdpdGggc2ltaWxh ciBmZWF0dXJlczoNDXBkdUhhbmRsZSA9IHNlbmRQZHUoDSAgICAgICAgIElOICAgdHJhbnNwb3J0 RG9tYWluICAgICAgICAgICAtLSB0cmFuc3BvcnQgZG9tYWluIHRvIGJlIHVzZWQNICAgICAgICAg SU4gICB0cmFuc3BvcnRBZGRyZXNzICAgICAgICAgIC0tIGRlc3RpbmF0aW9uIG5ldHdvcmsgYWRk cmVzcw0gICAgICAgICBJTiAgIG1lc3NhZ2VQcm9jZXNzaW5nTW9kZWwgICAgLS0gSVBQIFZlcnNp b24gTnVtYmVyDSAgICAgICAgIElOICAgc2VjdXJpdHlNb2RlbCAgICAgICAgICAgICAtLSBTZWN1 cml0eSBNb2RlbCB0byB1c2UNICAgICAgICAgSU4gICBzZWN1cml0eU5hbWUgICAgICAgICAgICAg IC0tIG9uIGJlaGFsZiBvZiB0aGlzIHByaW5jaXBhbA0gICAgICAgICBJTiAgIHNlY3VyaXR5TGV2 ZWwgICAgICAgICAgICAgLS0gTGV2ZWwgb2YgU2VjdXJpdHkgcmVxdWVzdGVkDSAgICAgICAgIElO ICAgcGR1VmVyc2lvbiAgICAgICAgICAgICAgICAtLSBFbmNvZGluZyBtb2RlbCB1c2VkDSAgICAg ICAgIElOICAgUERVICAgICAgICAgICAgICAgICAgICAgICAtLSBJUFAgUHJvdG9jb2wgRGF0YSBV bml0DSAgICAgICAgIElOICAgZXhwZWN0UmVzcG9uc2UgICAgICAgICAgICAtLSBUUlVFIG9yIEZB TFNFDSAgICAgICAgICAgICAgKQ0NV2hlcmUsDQ0idHJhbnNwb3J0RG9tYWluIiBpcyB0aGUgcGFy dGljdWxhciB0cmFuc3BvcnQgb3ZlciB3aGljaCB0aGUgSVBQIFBEVSBpcyBiZWluZyBkZWxpdmVy ZWQuDQ0idHJhbnNwb3J0QWRkcmVzcyIgaXMgdGhlIHBhcnRpY3VsYXIgYWRkcmVzcyB3aXRoaW4g dGhlIHRyYW5zcG9ydERvbWFpbiB0aGF0IHNob3VsZCByZWNlaXZlIHRoZSBQRFUuDQ0ibWVzc2Fn ZVByb2Nlc3NpbmdNb2RlbCIgaXMgdGhlIHBhcnRpY3VsYXIgSVBQIHZlcnNpb24gbnVtYmVyIGZv ciB3aGljaCB0aGUgcHJvY2Vzc2luZyBhbmQgc2VtYW50aWNzIG9mIHRoZSBQRFUgYXJlIHRvIGJl IGFwcGxpZWQuIFNpbmNlIHRoZSBJUFAgY29yZSBwcm9jZXNzaW5nIGVuZ2luZSBhbmQgdGhlIHRy YW5zcG9ydCBsYXllciBtYXkgYmUgaW5kZXBlbmRlbnRseSBpbXBsZW1lbnRlZCwgdGhlcmUgbWln aHQgYmUgdmVyc2lvbiBjb25mbGljdHMgd2hlcmVpbiBhIHBhcnRpY3VsYXIgdHJhbnNwb3J0IGxh eWVyIGNhbm5vdCBzdXBwb3J0IGEgcGFydGljdWxhciB2ZXJzaW9uIG9mIHRoZSBJUFAgbW9kZWwu DQ0ic2VjdXJpdHlNb2RlbCIgaXMgdGhlIHBhcnRpY3VsYXIgc2VjdXJpdHkgbWVjaGFuaXNtIGJl aW5nIGVtcGxveWVkIGZvciBwcm90ZWN0aW5nIHRoZSBQRFUuDQ0ic2VjdXJpdHlMZXZlbCIgaXMg dGhlIHBhcnRpY3VsYXIgbGV2ZWwgb3IgZGVncmVlIG9mIHNlY3VyaXR5IHdpdGhpbiB0aGUgInNl Y3VyaXR5TW9kZWwiIHVzZWQgdG8gY29udmV5IHRoaXMgUERVLg0NInNlY3VyaXR5TmFtZSIgaXMg YSBwYXJ0aWN1bGFyIGVuZC11c2VyIGlkZW50aWZpZXIgKGlmIGtub3duKSB0aGF0IHNob3VsZCBi ZSB1c2VkIGR1cmluZyB0aGUgZ2VuZXJhdGlvbiBvZiBhdXRoZW50aWNhdGlvbiBpbmZvcm1hdGlv biBmb3IgYSBwYXJ0aWN1bGFyIHNlY3VyaXR5IG1lY2hhbmlzbS4NDSJwZHVWZXJzaW9uIiBpcyB0 aGUgcGFydGljdWxhciBlbmNvZGluZyBydWxlcyB1c2VkIHRvIGVuY29kZSB0aGUgUERVLiBUaGlz IHBhcmFtZXRlciBpcyBwYXNzZWQgdG8gdGhlIHRyYW5zcG9ydCBsYXllciBiZWNhdXNlIHRoZSBw YXJ0aWN1bGFyIHRyYW5zcG9ydCBsYXllciBtaWdodCBub3QgYmUgYWJsZSB0byByZWxpYWJsZSBl bmNhcHN1bGF0ZSBjZXJ0YWluIGVuY29kaW5ncyBhbmQgZ3VhcmFudGVlIHRoZWlyIGRlbGl2ZXJ5 Lg0NInNlbmRQZHVIYW5kbGUiIGlzIGFuIG9wYXF1ZSAidHJhbnNhY3Rpb24taWQiIGdlbmVyYXRl ZCBieSB0aGUgc3BlY2lmaWMgdHJhbnNwb3J0IGxheWVyIGZvciB0aGlzIFBEVS4NDQ1UaGUgY29y ZSBJUFAgcHJvY2Vzc2luZyBlbmdpbmUgd291bGQgZm9ybXVsYXRlIElQUCBtZXNzYWdlcyB2aWEg c29tZSBlbmNvZGluZywgYW5kIHRoZW4gc3Vic2VxdWVudGx5IHBhc3MgdGhlc2UgZW5jb2RlZCBQ RFVzIHRvIHRoZSBhcHByb3ByaWF0ZSB0cmFuc3BvcnQgbGF5ZXIgaWRlbnRpZmllZCBieSB0cmFu c3BvcnREb21haW4gYW5kIGVuZHBvaW50IGlkZW50aWZpZWQgYnkgdHJhbnNwb3J0QWRkcmVzcy4g SW4gYWN0dWFsIGNsaWVudCBpbXBsZW1lbnRhdGlvbnMsIHRoZXNlIHR3byBwYXJhbWV0ZXJzIHdv dWxkIGJlIGRlcml2ZWQgZnJvbSB0aGUgInNjaGVtZSIgYW5kICJob3N0IiBwYXJ0cyBvZiBhIFVS SS4NDQ0gcGR1TGVuZ3RoID0gcmVjZWl2ZVBkdSggICAgICAgICAgICAgIC0tIHByb2Nlc3MgUmVz cG9uc2UgUERVDSAgICAgICAgIElOICAgdHJhbnNwb3J0RG9tYWluDSAgICAgICAgIElOICAgdHJh bnNwb3J0QWRkcmVzcw0gICAgICAgICBJTiAgIG1lc3NhZ2VQcm9jZXNzaW5nTW9kZWwgICAgLS0g SVBQIHZlcnNpb24gbnVtYmVyDSAgICAgICAgIElOICAgc2VjdXJpdHlNb2RlbCAgICAgICAgICAg ICAtLSBTZWN1cml0eSBNb2RlbCBpbiB1c2UNICAgICAgICAgSU4gICBzZWN1cml0eUxldmVsICAg ICAgICAgICAgIC0tIExldmVsIG9mIHNlY3VyaXR5DSAgICAgICAgIElOICAgc2VjdXJpdHlOYW1l ICAgICAgICAgICAgICAtLSBvbiBiZWhhbGYgb2YgdGhpcyBwcmluY2lwYWwNICAgICAgICAgSU4g ICBwZHVWZXJzaW9uICAgICAgICAgICAgICAgIC0tIGVuY29kaW5nIG1ldGhvZCB1c2VkDSAgICAg ICAgIElOICAgUERVICAgICAgICAgICAgICAgICAgICAgICAtLSBJUFAgUHJvdG9jb2wgRGF0YSBV bml0DSAgICAgICAgIElOICAgc2VuZFBkdUhhbmRsZSAgICAgICAgICAgICAtLSBoYW5kbGUgZnJv bSBzZW5kUERVDSAgICAgICAgICAgICAgKQ0NV2hlcmUsDQ0icGR1TGVuZ3RoIiBpcyB0aGUgbGVu Z3RoLCBpbiBvY3RldHMsIG9mIHRoZSByZWNlaXZlZCBQRFUuIElmIHRoZSANDSJ0cmFuc3BvcnRE b21haW4iIGlzIHRoZSBwYXJ0aWN1bGFyIHRyYW5zcG9ydCBvdmVyIHdoaWNoIHRoZSBJUFAgUERV IGlzIHJlY2VpdmVkLg0NInRyYW5zcG9ydEFkZHJlc3MiIGlzIHRoZSBwYXJ0aWN1bGFyIGFkZHJl c3Mgd2l0aGluIHRoZSB0cmFuc3BvcnREb21haW4gdGhhdCBvcmlnaW5hdGVkIHRoZSByZWNlaXZl ZCBQRFUuDQ0ibWVzc2FnZVByb2Nlc3NpbmdNb2RlbCIgaXMgdGhlIHBhcnRpY3VsYXIgSVBQIHZl cnNpb24gbnVtYmVyIGZvciB3aGljaCB0aGUgcHJvY2Vzc2luZyBhbmQgc2VtYW50aWNzIG9mIHRo ZSBQRFUgYXJlIHRvIGJlIGFwcGxpZWQuDQ0ic2VjdXJpdHlNb2RlbCIgaXMgdGhlIHBhcnRpY3Vs YXIgc2VjdXJpdHkgbWVjaGFuaXNtIGJlaW5nIGVtcGxveWVkIGZvciBwcm90ZWN0aW5nIHRoZSBy ZWNlaXZlZCBQRFUuDQ0ic2VjdXJpdHlMZXZlbCIgaXMgdGhlIHBhcnRpY3VsYXIgbGV2ZWwgb3Ig ZGVncmVlIG9mIHNlY3VyaXR5IHdpdGhpbiB0aGUgInNlY3VyaXR5TW9kZWwiIHVzZWQgdG8gY29u dmV5IHRoaXMgUERVLg0NInNlY3VyaXR5TmFtZSIgaXMgYSBwYXJ0aWN1bGFyIGVuZC11c2VyIGlk ZW50aWZpZXIgKGlmIGtub3duKSB0aGF0IHdhcyB0cmFuc2xhdGVkIGZyb20gdGhlIHBhcnRpY3Vs YXIgc2VjdXJpdHkgbWVjaGFuaXNtLg0NInBkdVZlcnNpb24iIGlzIHRoZSBwYXJ0aWN1bGFyIGVu Y29kaW5nIHJ1bGVzIHVzZWQgdG8gZW5jb2RlIHRoZSByZWNlaXZlZCBQRFUuDQ0ic2VuZFBkdUhh bmRsZSIgaXMgYW4gb3BhcXVlICJ0cmFuc2FjdGlvbi1pZCIgZ2VuZXJhdGVkIGJ5IHRoZSBvcmln aW5hdG9yIG9mIHRoaXMgUERVLg0NVGhpcyBwcm9wb3NhbCBzcGVjaWZpZXMgdGhlIHVzZSBvZiB0 aGUgZW5jb2RpbmcgYXMgc3BlY2lmaWVkIGluIFtJUFAtUFJPVF0uIE9uZSBwYXJ0aWN1bGFyIHVz ZSBvZiB0aGlzIHRyYW5zcG9ydCBzcGVjaWZpY2F0aW9uIHdvdWxkIGJlIHRvIGltcGxlbWVudCBh IGdhdGV3YXkgZnVuY3Rpb24gYXMgaWxsdXN0cmF0ZWQgaW4gRmlndXJlIDEuIA0NSW4gdGhlIGlk ZWFsIGdhdGV3YXkgc2NlbmFyaW8sIGEgY29yZSBJUFAgcHJvY2Vzc2luZyBlbmdpbmUgd291bGQg c2ltcGx5IHJlbGF5IHJlcXVlc3RzIGZyb20gb25lIHRyYW5zcG9ydCAoSFRUUCkgdG8gYW5vdGhl ciB0cmFuc3BvcnQgKFRDUC9JUCksIG9ubHkgdmFyeWluZyB0aGUgdHJhbnNwb3J0RG9tYWluIGFu ZCB0cmFuc3BvcnRBZGRyZXNzIHBhcmFtZXRlcnMgYXMgbmVjZXNzYXJ5LiANDVRoZSBwcmltYXJ5 IG1vdGl2YXRpb24gYnkgY3JlYXRpbmcgdGhlc2UgYWJzdHJhY3QgaW50ZXJmYWNlcyBpcyB0byBh bGxvdyBtYXhpbXVtIHJldXNlIG9mIHRyYW5zcG9ydCwgZW5jb2RpbmcgbG9naWMsIGFuZCBjb3Jl IHByb3RvY29sIHByb2Nlc3NpbmcuIFVzaW5nIHRoaXMgZ2F0ZXdheSBzY2VuYXJpbywgbm8gbG9z cyBvZiBJUFAgc2VtYW50aWMgaW5mb3JtYXRpb24gaXMgaW5jdXJyZWQgZnJvbSBlbmQtdXNlciB0 byBJUFAgcHJpbnRlciBlbmRwb2ludC4gSW4gdGhlb3J5LCBpdCBtaWdodCBldmVuIGJlIHBvc3Np YmxlIHRvIGNvbnN0cnVjdCBnYXRld2F5cyB1c2luZyB0aGlzIG1vZGVsIHRoYXQgYXJlIGltbXVu ZSB0byBkaWZmZXJpbmcgSVBQIHZlcnNpb24gbnVtYmVycyBmcm9tIGNsaWVudCBlbmRwb2ludCB0 byBwcmludGVyIGVuZHBvaW50LiBUaGlzIGlzIGJlY2F1c2UgaW4gdGhpcyBleGFtcGxlLCBubyBt b2RpZmljYXRpb24gb2YgdGhlIElQUCBQRFUgaXRzZWxmIGlzIHBlcmZvcm1lZCB3aGVuIHJlbGF5 aW5nIGZyb20gdHJhbnNwb3J0IHRvIHRyYW5zcG9ydC4gVGhpcyBhc3N1bXB0aW9uIHdvdWxkIG9m IGNvdXJzZSBoYXZlIHRvIHVuZGVyZ28gdmFsaWRhdGlvbi4NDTQuMiBUcmFuc3BvcnQtc3BlY2lm aWMgSGVhZGVyDQ1UaGlzIHByb3Bvc2FsIGFsbG93cyBzb21lIHRyYW5zcG9ydC1zcGVjaWZpYyBj YXBhYmlsaXRpZXMgbm90IGV4cGxpY2l0bHkgYWxsb3dlZCAob3IgZ3VhcmFudGVlZCkgYnkgW0lQ UFBST1RdLiBUaGlzIHRyYW5zcG9ydCBzcGVjaWZpY2F0aW9uIHV0aWxpemVzIGEgSVBQLXNwZWNp ZmljIHRyYW5zcG9ydCBoZWFkZXIgdGhhdCBpcyByZXF1aXJlZCB0byBzdXBwb3J0IG1hbmRhdG9y eSBmZWF0dXJlcyBkaXNjdXNzZWQgaW4gW0lQUE1PRF0uIFRoaXMgdHJhbnNwb3J0IGhlYWRlciBj YW4gYWxzbyBwcm92aWRlIGNhcGFiaWxpdGllcyBub3QgZXhwbGljaXRseSBwcm92aWRlZCBieSBb SVBQTU9EXS4gDQ1UaGUgdHJhbnNwb3J0IGhlYWRlciBpbmNsdWRlcyBmb3VyIGZpZWxkcywgQSBw ZHVMZW5ndGggZmllbGQgYW5kIGEgcGR1U3RhdHVzIGZpZWxkLiBUaGUgcGR1TGVuZ3RoIGZpZWxk IGRlbm90ZXMgdGhlIGxlbmd0aCwgaW4gb2N0ZXRzLCBvZiB0aGUgUERVLiBUaGUgcGR1U3RhdHVz IGZpZWxkIGluZGljYXRlcyB0aGUgc3RhdHVzIG9mIHRoZSBwYXJ0aWN1bGFyIFBEVSBiZWluZyBw cm9jZXNzZWQuIEEgbGlzdCBvZiBwb3NzaWJsZSBzdGF0dXMgY29kZXMgaXMgZGlzY3Vzc2VkIGlu IHNlY3Rpb24gNSBvZiB0aGlzIHByb3Bvc2FsLiBUaGUgaGVhZGVyIGl0c2VsZiBpcyBjb21wb3Nl ZCBvZiBBU0NJSSB0ZXh0IHdpdGggdGhlIHN5bnRheCBkZXNjcmliZWQgYnkgdGhlIGZvbGxvd2lu ZyBBQk5GOg0NWHB0LUhlYWRlciA9IHBkdVN0YXR1cyBTRVAgcGR1TGVuZ3RoIFNFUCBwZHUNDXBk dVN0YXR1cyA9IDEqRElHSVQNDXBkdUxlbmd0aCA9IDEqRElHSVQNDXBkdSA9IE9DVEVULVNUUklO Rw0NU0VQID0gMHgxM3gxMA0NT0NURVQtU1RSSU5HID0gKkJZVEUNDUJZVEUgPSAweDAwLi4weDI1 NQ0NVGhpcyBzcGVjaWZpY2F0aW9uIGFsc28gcmVxdWlyZXMgcmVnaXN0cmF0aW9uIG9mIGEgbmV3 IFVSSSBzY2hlbWUsICJJUFAiLCB0aGF0IGRlc2lnbmF0ZXMgYSBwYXJ0aWN1bGFyIGRlZmF1bHQg cG9ydCBudW1iZXIgZm9yIGNvbm5lY3RpbmcgdG8gSVBQIHNlcnZpY2VzIHVzaW5nIHRoZSB0cmFu c3BvcnQgc3BlY2lmaWVkIGJ5IHRoaXMgZG9jdW1lbnQuIE5vdGUgdGhhdCB0aGUgcmVnaXN0cmF0 aW9uIG9ubHkgc3BlY2lmaWVzIGEgZGVmYXVsdCBwb3J0IG51bWJlci4gQXBwZW5kaXggQSBvZiB0 aGlzIGRvY3VtZW50IGlzIHRoZSBjb21wbGV0ZSB0ZXh0IG9mIHRoZSBVUkwgcmVnaXN0cmF0aW9u LiBUaGUgcHJvcG9zZWQgVVJMIHN5bnRheCBpbmNsdWRlcyBhIGZpZWxkIGZvciBzcGVjaWZ5aW5n IHNvbWUgb3RoZXIgVENQIHBvcnQgbnVtYmVyIG90aGVyIHRoYW4gdGhlIGRlZmF1bHQuDQ01LiBU cmFuc3BvcnQgTGF5ZXIgU3RhdHVzIENvZGVzDQ1UaGUgZm9sbG93aW5nIHRyYW5zcG9ydC1zcGVj aWZpYyBlcnJvciBjb2RlcyBhcmUgZ3JvdXBlZCBpbnRvIHRocmVlIGRpZmZlcmVudCBjYXRlZ29y aWVzIG9mIHNldmVyaXR5OiBOb3JtYWwsIEVycm9yLCBhbmQgV2FybmluZy4gVGhlc2Ugc3RhdHVz IGNvZGVzIHdvdWxkIGJlIGFzc29jaWF0ZWQgd2l0aCB0aGUgYWJzdHJhY3QgdHJhbnNwb3J0IGlu dGVyZmFjZSBwcmV2aW91c2x5IGRlc2NyaWJlZC4NDU5vcm1hbA0NU1VDQ0VTUyAtIHRyYW5zcG9y dCBsYXllciByZXF1ZXN0IGNvbXBsZXRlZCBzdWNjZXNzZnVsbHkNDUVycm9ycw0NRVJSLVBST1RP Q09MIC0gbWFsZm9ybWVkIHRyYW5zcG9ydCBsYXllciBwYWNrZXQgd2FzIHJlY2VpdmVkDUVSUi1U SU1FT1VUIC0gdGltZW91dCB3YWl0aW5nIGZvciByZXNwb25zZQ1FUlItRElTQ09OIC0gc2Vzc2lv biBhYm5vcm1hbGx5IGRpc2Nvbm5lY3RlZA1FUlItQkFEVkVSIC0gSVBQIHZlcnNpb24gbm90IHN1 cHBvcnRlZA1FUlItQkFEUERVIC0gSVBQIHByb3RvY29sIGVuY29kaW5nIG5vdCBzdXBwb3J0ZWQN RVJSLVdPVUxEQkxPQ0sgLSBJbml0aWF0aW5nIHRoaXMgb3BlcmF0aW9uIHdvdWxkIGNhdXNlIGFu IGluZGVmaW5pdGUgYmxvY2tpbmcgc3RhdGUgdG8gb2NjdXIuDUVSUi1JTlRFUk5BTCAtIEFuIGlu dGVybmFsIHRyYW5zcG9ydCBlcnJvciBvY2N1cnJlZC4NDVdhcm5pbmdzDQ1XQVJOLU1PUkUtREFU QSAtIE1vcmUgZGF0YSBpcyBhdmFpbGFibGUgZnJvbSB0aGUgdHJhbnNwb3J0IGxheWVyIGZvciB0 aGlzIHBhcnRpY3VsYXIgcmVxdWVzdC4gVGhpcyBpcyBhbiBpbmRpY2F0aW9uIHRoYXQgbW9yZSB0 aGFuIG9uZSBpbmRpdmlkdWFsIHRyYW5zcG9ydCBsYXllciBwYWNrZXQgd2FzIG5lY2Vzc2FyeSB0 byBjb250YWluIGEgcGFydGljdWxhciBJUFAgbWVzc2FnZS4NDTYuIFNlY3VyaXR5IENvbnNpZGVy YXRpb25zDQ1UaGUgcHJvcG9zZWQgdHJhbnNwb3J0IHNwZWNpZmllcyB0aGUgdXNlIG9mIG9uZSBv ciBtb3JlIG9mIHRoZSBmb2xsb3dpbmcgU2ltcGxlIEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cml0 eSBMYXllciAoU0FTTCkgW1JGQzIyMjJdIHByb2ZpbGVzOg0NU1RBUlRUTFMgW1NUQVJUVExTXQ1B Tk9OWU1PVVMgW1JGQzIyNDVdDUNSQU0tTUQ1ICBbUkZDMjE5NV0NDVNBU0wgYWxsb3dzIHRoZSBw dWJsaWNhdGlvbiBvZiBvbmx5IG9uZSBVUkkgZm9yIHNlcnZpY2UgZGlzY292ZXJ5IG1lY2hhbmlz bXMgKGRpcmVjdG9yeSBzZXJ2aWNlcywgREhDUCwgZXRjKS4gVGhlIGV4aXN0aW5nIElQUC1vdmVy LUhUVFAgc3BlY2lmaWNhdGlvbiByZXF1aXJlcyB0aGUgdXNlIG9mIGRpZmZlcmVudCBVUkkgcHVi bGljYXRpb25zIGZvciBzZWN1cmUgYW5kIG5vbi1zZWN1cmUgSVBQIHNlcnZpY2VzLiBTQVNMIG5l Z290aWF0aW9uIGlzIHBlcmZvcm1lZCAiaW4tYmFuZCIsIG92ZXIgYSBzaW5nbGUgY29ubmVjdGlv biwgdGhlcmVieSBlbGltaW5hdGluZyB0aGUgbmVlZCBmb3IgZGlmZmVyZW50IFVSSXMgZm9yIGRp ZmZlcmVudCBzZWN1cml0eSBtZWNoYW5pc21zLiBPZiB0aGUgdGhyZWUgcHJvZmlsZXMgc3BlY2lm aWVkIGFib3ZlLCBhbGwgYnV0IHRoZSBTVEFSVFRMUyBwcm9maWxlIGlzIGF2YWlsYWJsZSBmb3Ig cmVmZXJlbmNpbmcgYXMgYW4gUkZDLiBHaXZlbiB0aGF0IHRoaXMgbWVtbyAoSVBQIG92ZXIgVENQ L0lQKSBpcyBkYXRlZCBNYXJjaCAxOTk4LCB0aGUgZHJhZnQgdGhhdCBkZXNjcmliZXMgdGhlIFNU QVJUVExTIHByb2ZpbGUgaXMgc2NoZWR1bGVkIGZvciBsYXN0IGNhbGwgYXQgdGhlIGJlZ2lubmlu ZyBvZiBBcHJpbCAxOTk4LiBBbnRpY2lwYXRlZCBSRkMgc3RhdHVzIGZvciB0aGlzIGRyYWZ0IGZh bGxzIHdpdGhpbiBhIHJlYXNvbmFibGUgdGltZSBwZXJpb2QgZm9yIGluY2x1c2lvbiBpbiB0aGlz IHByb3Bvc2FsLg0NVGhpcyBkb2N1bWVudCBzdWdnZXN0cyB0aGUgdXNlIG9mIGJvdGggQU5PTllN T1VTIGFuZCBDUkFNLU1ENSBhcyBNQU5EQVRPUlkgc2VjdXJpdHkgbWVjaGFuaXNtcy4gQm90aCBv ZiB0aGVzZSBtZWNoYW5pc21zIG9ubHkgcHJvdmlkZSBhdXRoZW50aWNhdGlvbiwgbm90IHByaXZh Y3kuIElmIHByaXZhY3kgaXMgcmVxdWlyZWQsIHRoZW4sIGxpa2UgdGhlIElQUCBtb2RlbCBkb2N1 bWVudCBzcGVjaWZpZXMsIFRMUyBzaG91bGQgYmUgbmVnb3RpYXRlZCB1c2luZyB0aGUgU1RBUlRU TFMgU0FTTCBwcm9maWxlLg0NVGhlIEFOT05ZTU9VUyBtZWNoYW5pc20gYWxsb3dzIHNpbWlsYXIg YWNjZXNzIHNlbWFudGljcyBhcyAiYW5vbnltb3VzIEZUUCIsIHVzaW5nIGp1c3QgYSBzaW1wbGUg Y2xlYXIgdGV4dCBpZCBzdHJpbmcgc3VjaCBhcyBhbiBlbWFpbCBhZGRyZXNzIG9yIG90aGVyIHNp bXBsZSBBU0NJSSBzdHJpbmcuDQ1DUkFNLU1ENSBpcyBhIHZlcnkgc2ltcGxlIG1lY2hhbmlzbSBm b3IgYXV0aGVudGljYXRpb24gdXNpbmcgaW5mb3JtYXRpb24gdGhhdCBpcyBub3QgcGFzc2VkIGFz IGNsZWFyIHRleHQuIENSQU0tTUQ1IGxpa2Ugb3RoZXIgTUQ1LWJhc2VkIGF1dGhlbnRpY2F0aW9u IHNjaGVtZXMsIHJlcXVpcmVzIHRoZSBrbm93bGVkZ2Ugb2YgYSBzaGFyZWQgc2VjcmV0IGJldHdl ZW4gY2xpZW50IGFuZCBwcmludGVyLiBTaGFyZWQgc2VjcmV0cyBkbyBub3QgbmVlZCB0byBiZSBr ZXB0IGZvciBhbGwgcG9zc2libGUgZW5kLXVzZXJzLiBSYXRoZXIsIGFkbWluaXN0cmF0b3JzIG1h eSB3YW50IHRvIHByb3ZpZGUgc2VjcmV0IGtleXMgdGhhdCBtYXAgdG8gZWl0aGVyIHNtYWxsIGdy b3Vwcywgb3IgZGVwYXJ0bWVudGFsIGFjY2VzcyBrZXlzLiBIb3dldmVyLCB0aGUgdXNlIG9mIGFn Z3JlZ2F0ZWQga2V5cyBkb2VzIGFsbG93IGEgZ3JlYXRlciBwb3NzaWJpbGl0eSBmb3Iga2V5cyB0 byBiZSByZXZlYWxlZCB0byBub24tYXV0aG9yaXplZCBwYXJ0aWVzLiBPbiB0aGUgb3RoZXIgaGFu ZCwgdGhpcyB0eXBlIG9mIHNlY3VyaXR5IG1heSBiZSBhY2NlcHRhYmxlIGZvciBjZXJ0YWluIGVu dmlyb25tZW50cyB0aGF0IGRvIG5vdCB3YW50IG9wZW4gYWNjZXNzIHRvIHNlcnZpY2VzKEFOT05Z TU9VUyksIGJ1dCBkbyBub3Qgd2FudCB0byBkZWFsIHdpdGggVExTLWJhc2VkIHNlY3VyaXR5LiBb UkZDMjEwNF0gY29udGFpbnMgYSBkZXRhaWxlZCBkZXNjcmlwdGlvbiBvZiB0aGUga2V5ZWQtTUQ1 IG1ldGhvZCBlbXBsb3llZCBieSBDUkFNLU1ENSwgYXMgd2VsbCBhcyBleGFtcGxlIGNvZGUgdGhh dCBpbXBsZW1lbnRzIHRoZSBhbGdvcml0aG0uDQ0NNi4gUmVmZXJlbmNlcw0NW0lQUE1PRF0gRGVC cnkgUi4sIEhhc3RpbmdzIFQuLCBIZXJyaW90IFIuLCBJc2FhY3NvbiBTLiwgUG93ZWxsIFAuLCAi SW50ZXJuZXQgUHJpbnRpbmcgUHJvdG9jb2wvMS4wOiBNb2RlbCBhbmQgU2VtYW50aWNzIiwgSW50 ZXJuZXQtRHJhZnQgZHJhZnQtaWV0Zi1pcHAtbW9kZWwtMDksIEphbnVhcnkgMTk5OA0NW0lQUFBS T1RdIEhlcnJpb3QgUi4sIEJ1dGxlciBTLiwgTW9vcmUgUC4sIFR1cm5lciBSLiwgIkludGVybmV0 IFByaW50aW5nIFByb3RvY29sLzEuMDogUHJvdG9jb2wgU3BlY2lmaWNhdGlvbiIsIEludGVybmV0 LURyYWZ0IGRyYWZ0LWlldGYtaXBwLXByb3RvY29sLTA1LCBKYW51YXJ5IDE5OTgNDVtSRkMxNzU5 XSBTbWl0aCBSLiwgV3JpZ2h0IEYuLCBIYXN0aW5ncyBULiwgWmlsbGVzIFMuLCBHeWxsZW5za29n IEouLCAiUHJpbnRlciBNSUIiLCBSRkMgMTc1OSwgTWFyY2ggMTk5NQ0NW1JGQzIyNzNdIExldmkg RC4sIE1leWVyIFAuLCBTdGV3YXJ0IEIuLCAiU05NUHYzIEFwcGxpY2F0aW9ucyIsIFJGQyAyMjcz LCBKYW51YXJ5IDE5OTgNDVtSRkMyMDY4XSBGaWVsZGluZyBSLiwgR2V0dHlzIEouLCBNb2d1bCBK LiwgRnJ5c3R5ayBILiwgQmVybmVycy1MZWUgVC4sICJIeXBlcnRleHQgVHJhbnNmZXIgUHJvdG9j b2wgliBIVFRQLzEuMSIsIFJGQyAyMDY4LCBKYW51YXJ5IDE5OTcNDVtSRkMyMTE5XSBCcmFkbmVy IFMuLCAiS2V5d29yZHMgZm9yIFVzZSBpbiBSRkNzIHRvIEluZGljYXRlIFJlcXVpcmVtZW50IExl dmVscyIsIFJGQyAyMjE5LCBNYXJjaCAxOTk3DQ1bUkZDMjIyMl0gTXllcnMgSi4sICJTaW1wbGUg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyaXR5IExheWVyIChTQVNMKSIsIFJGQyAyMjIyLCBPY3Rv YmVyIDE5OTcNDVtSRkMyMjQ1XSBOZXdtYW4gQy4sICJBbm9ueW1vdXMgU0FTTCBNZWNoYW5pc20i LCBSRkMgMjI0NSwgTm92ZW1iZXIgMTk5Nw0NW1JGQy0yMTA0XSBLcmF5Y3p5ayBILiwgQmVsbGFy ZSBNLiwgQ2FuZXR0aSBSLiwgIkhNQUM6IEtleWVkLUhhc2hpbmcgZm9yIE1lc3NhZ2UgQXV0aGVu dGljYXRpb24iLCBSRkMgMjEwNCwgRmVicnVhcnkgMTk5Nw0NW1JGQy0yMTk1XSBLbGVuc2luIEou LCBDYXRvZSBSLiwgS3J1bXZpZWRlIFAuLCAiSU1BUC9QT1AgQVVUSG9yaXplIEV4dGVuc2lvbiBm b3IgU2ltcGxlIENoYWxsZW5nZS9SZXNwb25zZSIsIFJGQyAyMTk1LCBTZXB0ZW1iZXIgMTk5Nw0N W1NUQVJUVExTXSBOZXdtYW4gQy4sICJVc2luZyBUTFMgd2l0aCBJTUFQNCwgUE9QMywgYW5kIEFD QVAiLCBJbnRlcm5ldC1EcmFmdCBkcmFmdC1uZXdtYW4tdGxzLWltYXBwb3AtMDMsIE1hcmNoIDE5 OTgNDQ1BcHBlbmRpeCBBIJYgIklQUCIgU2NoZW1lIFJlZ2lzdHJhdGlvbg0NVGhlIGZvbGxvd2lu ZyBJUFAgc2NoZW1lIHByb3Bvc2FsIGlzIG1lYW50IHRvIHN0YXJ0IGRlYmF0ZSBvbiBJUFAgc2No ZW1lZCBVUkxzLiBUaGUgc2NoZW1lIHN1Z2dlc3RlZCBiZWxvdyB3b3VsZCBiZSBhZHZlcnRpc2Vk IGJ5IHNlcnZlcnMgdG8gcG90ZW50aWFsIGNsaWVudHMuDQ1JUFA6Ly9ob3N0LmRvbWFpbls6cG9y dF0NDQ1DbGllbnRzIGF0dGVtcHRpbmcgYWNjZXNzIHRvIGEgcmVzb3VyY2UgaWRlbnRpZmllZCBi eSB0aGUgIklQUCIgc2NoZW1lIE1VU1QgdXRpbGl6ZSB0aGUgSVBQIHRyYW5zcG9ydCBtYXBwaW5n IHNwZWNpZmllZCBieSB0aGlzIGRvY3VtZW50Lg0NDRgAoQEApNAvpeA9pggHpwgHqKAFqaAFqgAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAADAAByHQAA7B8AAPAkAABQJgAAUiYAAKEoAAA5QwAA4UMAAChJ AABCSQAAAP0A/QD9AP0A+wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAACdQEAA10DAAAKAAMAAEgDAACQAwAAkQMAAJIDAADHAwAAyAMAAMkDAADdAwAA3gMA AB8EAABjBAAApwQAAM0EAADOBAAA0wUAANQFAAAYBgAAXgYAAJwGAADdBgAA+gYAAPsGAAD8BgAA BwcAAAgHAAB0CQAAdQkAAIAJAACBCQAA2goAANsKAABLDAAATAwAAHQMAAB1DAAAFxAAABgQAAB/ EAAAgBAAAMAQAADBEAAA7hAAACwRAABqEQAAqBEAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAA AAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAA AP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA /gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+ AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4A AAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAA AAAAAAAAAAAAAAAAAAEPAC2oEQAA1REAAAISAABAEgAAfhIAALwSAADpEgAAJxMAAGUTAACjEwAA 0BMAANETAADSEwAA+RMAAPoTAAD7EwAAZhUAAGcVAAAqFwAAKxcAAMMXAADEFwAA3hcAAN8XAAAV GQAAFhkAAEscAABMHAAAaBwAAGkcAABxHQAAch0AAIcdAADOHQAAFR4AAFMeAACUHgAA2x4AACIf AABhHwAAox8AANwfAADsHwAA7R8AAPQfAAD1HwAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAA AP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA /gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+ AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4A AAAAAAD+AAAAAAAA/gAAAAAAAPwAAAAAAAD8AAAAAAAA/AAAAAAAAPwAAAAAAAD8AAAAAAAA/AAA AAAAAPwAAAAAAAD8AAAAAAAA/AAAAAAAAPwAAAAAAAD8AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAA AAAAAAAAAAABAAAAAQ8ALfUfAABOIAAATyAAALQgAAC1IAAAEyIAABQiAABwIgAAcSIAAOMiAADk IgAAjyMAAJAjAACHJAAAiCQAAO4kAADvJAAA8CQAAFAmAABRJgAAUiYAAJAmAACuJgAAzSYAAAsn AABMJwAAiScAANAnAAAQKAAAUigAAJEoAAChKAAAoigAAKkoAACqKAAA7SgAAO4oAABAKQAAQSkA AKspAACsKQAALyoAADAqAACVKgAAlioAAAgrAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA /gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+ AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAPwAAAAAAAD+AAAAAAAA/AAAAAAAAPwA AAAAAAD8AAAAAAAA/AAAAAAAAPwAAAAAAAD8AAAAAAAA/AAAAAAAAPwAAAAAAAD8AAAAAAAA/AAA AAAAAPwAAAAAAAD8AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAA AAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAA AAAAAAAAAAEAAAABDwAtCCsAAAkrAACDKwAAhCsAANMrAADUKwAAKywAACwsAADxLAAA8iwAANMt AADULQAAPTAAAD4wAABcMAAAXTAAALIxAACzMQAAPzMAAEAzAABtMwAAbjMAAIIzAACDMwAAlzMA AJgzAACrMwAArDMAALozAAC7MwAA0DMAANEzAADkMwAA5TMAAKU1AACmNQAAxjUAAMc1AACsNgAA rTYAALQ2AAC1NgAA7jYAAO82AAD2NgAA9zYAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+ AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4A AAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAA AAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAA AAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAA AAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAA AAAAAAAAAAAAAAEPAC33NgAANDcAAF83AACMNwAAszcAAOQ3AABCOAAAdzgAAHg4AACBOAAAgjgA AF45AABfOQAAejkAAHs5AAAIOgAACToAAB06AAAxOgAARToAAEY6AABHPQAASD0AAGo+AABrPgAA Fz8AABg/AAB3QgAAeEIAAHlCAACHQgAAiEIAADhDAAA5QwAA4UMAAOJDAABMRAAATUQAAKREAAD+ AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4A AAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA2QAA AAAAANkAAAAAAADZAAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAA AAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAA AADXAAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAAAAAAAAAAAAAQAAACQPAA0LETgE E5j+DDT/AQAIAAABgAAAAAA4BAAAAAAAAC0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA DwUAATgEAAAAAQ8AJqREAAClRAAALkUAAC9FAACVRQAAlkUAAPRFAAD1RQAAPkYAAD9GAAC5RgAA ukYAAEBHAABBRwAAtkcAALdHAAC4RwAA30cAAOBHAACASAAAgUgAAJpIAACbSAAAnEgAACZJAAAn SQAAKEkAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+ AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAAAAAAAP4A AAAAAAD+AAAAAAAA/gAAAAAAAP4AAAAAAAD+AAAAAAAA+gAAAAAAAP4AAAAAAAD+AAAAAAAA/gAA AAAAAP4AAAAAAAD+AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA Aw8AEdACAAABDwAaDgARAAgAAQBLAA8AAAAAABoAAEDx/wIAGgAGTm9ybWFsAAIAAAADAGEJBAAA AAAAAAAAAAAAAAAAAAAAAAAiAEFA8v+hACIAFkRlZmF1bHQgUGFyYWdyYXBoIEZvbnQAAAAAAAAA AAAAAB4A/k8BAPIAHgAKUGxhaW4gVGV4dAACAA8AAwBdAwAAGAD+T/EAAgEYAARJRVRGAAUAEAAQ OAQAAAAAAAAAKEYAAAMAKEkAAAEA/////wADAABCSQAAJQAAAwAAqBEAAPUfAAAIKwAA9zYAAKRE AAAoSQAAJgAnACgAKQAqACsA/0BDABUSkAEAAFRpbWVzIE5ldyBSb21hbgAMEJABAgBTeW1ib2wA CyKQAQAAQXJpYWwAETGQAQAAQ291cmllciBOZXcAIgAEAAAAgBgAANACAABoAQAAAABnyiNmZ8oj ZgnDI0YBAAAAAAAmCgAA2TkAAAEAHQAAAAQAgxB7AAAAAAAAAAAAAAABAAEAAAABAAAAAAAAAAAA AAAAAHMAAABHSU5URVJORVQtRFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBSYW5keSBUdXJuZXIAAAAMUmFuZHkgVHVybmVyDFJhbmR5IFR1cm5lcgAAAAAA AAAAAAAAAAAAAAABAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABGGAAAAE1pY3Jvc29mdCBXb3Jk IERvY3VtZW50AAoAAABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAA AAAAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAA KQAAACoAAAArAAAALAAAAP7////9////MQAAAP7///85AAAA/v////////////////////////// ///////////////+//////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////1IAbwBvAHQAIABFAG4AdAByAHkAAABCAAAAAACQBAAAAAAAAAAAAAAAAAAA//// /wAAAAAAAAAAAQAAAOEuRQ0WAAUB//////////8BAAAAAAkCAAAAAADAAAAAAAAARgAAAAA0ADQA LQA0AGCS7wAVWL0BMAAAAAAEAAAtADgAVwBvAHIAZABEAG8AYwB1AG0AZQBuAHQAAAAwADAAMAB9 ACMAMgAuADAAIwAwACMAQwA6AFwAVwBJAE4ARABPABoAAgECAAAAAwAAAP////9WAEIARQBcAE0A UwBGAG8AcgBtAHMALgBFAFgARAAjAE0AaQAAAAAA+lkAAG8AZgABAEMAbwBtAHAATwBiAGoAAAAu ADAAIABPAGIAagBlAGMAdAAgAEwAaQBiAHIAYQByAHkAAAAAAGMAMwA1ADEAEgACAf////////// /////yoARAABAAAAVABoAGkAcwBEAG8AAAAAAAAAAAAAAAAAAAAAAAAAAABqAAAAQwBOAAUAUwB1 AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAABAAAAAAAAAP////9oAAAAAAAAAAAA AAAoAAIB/////wQAAAD/////sGBKAAAA/f///wAAAAAAACAAAGAAAAAAAAAAAAAAAAAAAAAAAgAA AAgCAAAAAAAAAQAAAP7///8DAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAP7///8MAAAA DQAAAA4AAAAPAAAA/v////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////8BAP7/AwoAAP////8ACQIAAAAAAMAAAAAAAABGGAAAAE1pY3Jvc29mdCBXb3JkIERv Y3VtZW50AAoAAABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuNgD0ObJxAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAEAAIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9o EKuRCAArJ7PZMAAAANgBAAASAAAAAQAAAJgAAAACAAAAoAAAAAMAAADwAAAABAAAAPwAAAAFAAAA FAEAAAYAAAAgAQAABwAAACwBAAAIAAAAPAEAAAkAAABUAQAAEgAAAGABAAAKAAAAiAEAAAsAAACU AQAADAAAAKABAAANAAAArAEAAA4AAAC4AQAADwAAAMABAAAQAAAAyAEAABMAAADQAQAAAgAAAOQE AAAeAAAASAAAAElOVEVSTkVULURSQUZUICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgUmFuZHkgVHVybmVyAB4AAAABAAAAAAA1AB4AAAANAAAAUmFuZHkgVHVybmVy AAAPAB4AAAABAAAAAA8AAB4AAAABAAAAAAAAAB4AAAAHAAAATm9ybWFsAAAeAAAADQAAAFJhbmR5 IFR1cm5lcgUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkA bwBuAAAAAAAAAAAAAAA4AAIA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAACwAAACABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP////////////// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAUgBvAG8AdAAgAEUAbgB0AHIAeQAAAEIAAAAAAJAEAAAAAAAAAAAAAAAAAAD/////AAAA AAAAAAABAAAA4S5FDRYABQH//////////wEAAAAACQIAAAAAAMAAAAAAAABGAAAAAOB36QAVWL0B AJ1eABVYvQEwAAAAAAQAAC0AOABXAG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAAADAAMAAwAH0AIwAy AC4AMAAjADAAIwBDADoAXABXAEkATgBEAE8AGgACAQIAAAADAAAA/////1YAQgBFAFwATQBTAEYA bwByAG0AcwAuAEUAWABEACMATQBpAAAAAAD6WQAAbwBmAAEAQwBvAG0AcABPAGIAagAAAC4AMAAg AE8AYgBqAGUAYwB0ACAATABpAGIAcgBhAHIAeQAAAAAAYwAzADUAMQASAAIB//////////////// KgBEAAEAAABUAGgAaQBzAEQAbwAAAAAAAAAAAAAAAAAAAAAAAAAAAGoAAABDAE4ABQBTAHUAbQBt AGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAEAAAAAAAAA/////2gAAAAAAAAAAAAAACgA AgH/////BAAAAP////+wYEoAAAD9////AAAAAAAAIAAAYAAAAAAAAAAAAAAAAAAAAAACAAAACAIA AAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAA DgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAc AAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoA AAArAAAALAAAAP7///////////////7///85AAAA/v///zEAAAD9//////////////////////// ///////+//////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAHgAAAAIAAAAxAEoAHgAAAB4AAABNaWNyb3NvZnQgV29yZCBmb3IgV2luZG93cyA5NQBKAEAA AAAAAAAAAAAAAEAAAAAA1vSuYFe9AUAAAAAAkvPkFFi9AUAAAAAAkvPkFFi9AQMAAAABAAAAAwAA ACYKAAADAAAA2TkAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAACAAAAAAAAAAAAAAAAAAAAAAABAAAAAtXN1ZwuGxCT lwgAKyz5rjAAAADwAAAABwAAAAEAAABAAAAADwAAAEgAAAAFAAAAcAAAAAYAAAB4AAAACwAAAIAA AAAQAAAAiAAAAAwAAACQAAAAAgAAAOQEAAAeAAAAHgAAAFNoYXJwIExhYm9yYXRvcmllcyBvZiBB bWVyaWNhAEoAAwAAAHsAAAADAAAAHQAAAAsAAAAAAAAACwAAAAAAAAAMEAAAAgAAAB4AAABIAAAA SU5URVJORVQtRFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBSYW5keSBUdXJuZXIAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== ------ =_NextPart_000_01BD57D2.16DEA2C0-- From ipp-archive Wed Mar 25 16:22:36 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA14930 for ipp-outgoing; Wed, 25 Mar 1998 16:20:36 -0500 (EST) Message-Id: <3519741C.A50232BC@dazel.com> Date: Wed, 25 Mar 1998 15:16:12 -0600 From: James Walker Reply-To: walker@dazel.com Organization: DAZEL Corporation X-Mailer: Mozilla 4.04 [en] (WinNT; I) Mime-Version: 1.0 To: Tom Hastings Cc: ipp@pwg.org Subject: Re: IPP> MOD/PRO - simple proposal for providing dictionary-like capability References: <3.0.1.32.19980324153634.01213b10@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Tom Hastings wrote: > > For the IPP telecon, Wed, 3/25: > > Roger, Bob, and I have been working on various dictionary proposals. > > ... > > Briefly, the scheme isn't really a dictionary at all (previous > versions were). Other earlier versions were adding a new addressing > mechanism for attributes in dictionaries. > > This proposal adds no new addressing mechanisms, > but justs add a new out-of-band value to encode the new Model attribute > syntax of 1setOf 1setOf (doubly nested values). Instead, we use the > idea of attributes with parallel values, like we already have for > "printer-uri-supported" and "uri-security-supported". As discussed in the telecon today, I think that the parallel attribute idea is a bad one... it does not scale well, it is difficult for users to understand and get right, it is error-prone, etc. Our experience from the implementation of parallel attributes in DPA has not been a good one. All in all, I believe that data structures are a good idea, but trying to describe data structures using parallel attributes does not work. > ... > > I've left the rejected example that uses the 'dictionary' attribute syntax > in the document. I've also listed the alternatives that we considered > and the reasons for rejecting them. > > ... I simply do not understand why the original concept of a dictionary value tag (with its associated value length) would not work well. This is the example that is shown in Tom's document. ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX From ipp-archive Wed Mar 25 21:06:32 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA15903 for ipp-outgoing; Wed, 25 Mar 1998 20:58:52 -0500 (EST) Message-Id: <3.0.1.32.19980325175745.031e6d90@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 25 Mar 1998 17:57:45 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> ADM - Minutes from PWG IPP phone conference, 3/25/98 Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Minutes from PWG IPP Phone Conference 980325 ============================================ Notes taken by Carl-Uno Manros and Tom Hastings. Attendees: Ron Bergman Dataproducts Tom Hastings Xerox Carl-Uno Manros Xerox Ira Mcdonald High North Randy Turner Sharp Don Wright Lexmark Jim Walker DAZEL Peter Zehler Xerox Harry Lewis IBM Jay Martin Underscore Agenda: Carl-Uno Manros led the meeting. For today's agenda topics, he said that he would like to revisit the IPP notification and the host-to-device home work assignments and DL discussions. Status of IPP in the IESG and IPP LA Agenda: Carl-Uno reported that contacts with Keith Moore make it clear that we will not see any feedback from him or the IESG in time for IETF41 next week, and probably not before the PWG IPP meeting in Portland either. The IETF41 IPP agenda is therefore limited to the discussion of IPP notifications and mapping of directory attributes to SLP and LDAP. Carl-Uno then made a quick review of other sessions in IETF41 that might be of interest to IPP WG members coming to LA. Notifications: Then the discussion of IPP notifications started. Carl-Uno suggested that we already have a number of inputs that could be used to work out a solution for the simple kind of user notifications intended in the IETF IPP work item. It was clear from the following discussion that the PWG needs to view notifications in a wider scenario that takes into account host-to-device, administrator etc. requirements, but that this work could be done in parallel to developing a simple notification solution for IPP 1.0. The notification specification is expected to take the form of a standards track IETF RFC, which specifies additional attributes to what is in the Model document. Although the notification specification will be optional to implement, we should aim for it to become a standards track document. Discussions were held around how much flexibility the user needs to have in specifying what should be returned in a notification. Some suggested that standardized packages should be enough, but there were also requirements to have full flexibility to specify the exact attributes (including private attribute extensions) to be returned. Unless the solution gets too complex, it looks like we should expect a few standard packages to be specified and supported, but that implementations could optionally support attribute level specification. There was also discussion about the format of the notification. Everybody seemed to agree that it should be in the form of a MIME type, which is identical or very similar to the application/ipp Mime type and should look more or less identical to the List-Job-Attribute response format. There also seemed to be agreement that the life cycle of a notification request is the same as for the print job. As part of this discussion, Tom Hastings introduced the DL draft on how a directory attribute syntax could be defined. Bob Herriot and Roger deBry had worked with Tom on this, but had not yet seen the current version, when had been written by Tom. There was opposition from Jim Walker and others about the parallel attribute value approach taken in the proposal and Tom undertook to work out a full proposal based on the original idea of introducing a new syntax for comparison. Carl-Uno when summing up the discussion about notifications asked for volunteers to write up a proposal based on the earlier text in the model document, the current requirements document, Tom's revised proposal for the directory attribute, and today's discussion. Tom Hastings and Harry Lewis will try to have a draft ready for discussion in Portland (April 8-9) with Jim Walker's review, if there is time. PWG Host-to-Device protocol discussion: The next agenda item was the alternative approaches to arrive at a suitable solution for a host-to-device protocol (which is not intended as an IETF standard). Don Wright introduced his PWG draft called "IPP to IEEE 1284.1 Mapping". This describes how IEEE 1284.1, a.k.a. TIP/SI, could be used to transfer IPP attributes and document data from a print server to a print device. A few minor extensions would be needed to the IEEE TIP/SI standard itself to support the proposal. In addition, the PWG would develop a PWG standard for a IPP Logical Unit (LU) that works with TIP/SI that accepts IPP attributes directly. Areas for further study would be internationalization and security, plus an explicit mapping of TIP/SI to TCP/IP. Don wanted to have further discussion of the document in the Portland IPP meeting before investing more work in refining the draft. Randy Turner then introduced his proposal on how to map IPP directly on TCP/IP, which he claimed would solve most of the problems that have been stated against using IPP as a host-to-device protocol. The following discussion indicated that people wanted the two channel approach that is used in TIP/SI and CPAP (one for bi-directional control information and one for data) to be added to Randy's proposal. Randy undertook to have a revised version of the proposal ready for discussion in Portland. It will introduce a second pull-only data channel and rewrite some of the proposal for a new URI scheme. Meeting adjourned at 12:30 PM. There will not be any phone conferences for the next two weeks due to the IETF41 and PWG IPP meetings. The next teleconference will be held on April 15 at 10:00am PST. From ipp-archive Thu Mar 26 19:02:44 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA28150 for ipp-outgoing; Thu, 26 Mar 1998 18:58:26 -0500 (EST) Message-Id: <3.0.1.32.19980326153352.009279b0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 26 Mar 1998 15:33:52 PST To: ipp@pwg.org From: Dan Wing (by way of Carl-Uno Manros ) Subject: IPP> ADM - BOF announcement: WASRV (Wide Area Service Location) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk This was announced to the IFAX group. It might also be of interest to the IPP group. Carl-Uno --- FYI, There will be a BOF at IETF 41 concerning Wide Area Service Location - There has been recent interest in mechanisms for discovery of services across the global internet. Such interest has manifested itself in numerous papers, standards proposals, and commercial tools. However, what is meant by wide area service location seems to vary in all cases. The organizers of the WASRV BOF will advocate a set of architectural principals for a successful wide area service location system. In brief, discovery should not require a priori knowledge or configuration to perform, should be based on attribute based search criteria and allow rapid, scalable access to service information. Services should be discoverable only when they are actually available and ideally advertise themselves automatically. These principals will be discussed and proposals for solutions to the wide area service location problem will be presented. The goal of the BOF is to determine whether there is sufficient interest in the problem, as we agree to define it, and whether the technical proposals presented will arrive at a feasible technical solution. Please see http://www.bell-labs.com/mailing-lists/wasrv/ for a list of documents including "WASRV Architectural Principles" which describe in detail the issues believe a chartered WASRV WG in the Internet area should address. My apologies if you receive this announcement more than once. The BOF is currently scheduled for 1530-1730 Thursday in the Avalon room (but check your schedules when you arrive for changes :-) Erik Guttman WASRV BOF Cochair ----------------------------------------------------------------------- Erik Guttman http://www.neato.org/~femur/eg.html Sun Microsystems Erik.Guttman@sun.com SMCC Advanced Network Development +49 7263 911 700 From ipp-archive Fri Mar 27 14:57:46 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA09690 for ipp-outgoing; Fri, 27 Mar 1998 14:57:41 -0500 (EST) From: Carl Kugler To: Subject: Re: IPP>MOD: Problem in IPP encoding with "attributes-charse Message-ID: <5030100019004296000002L062*@MHS> Date: Fri, 27 Mar 1998 14:56:41 -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 found it rather easy to implement when I did it. "ipp-attribute-fidelity" is another special attribute because it, too, determines how all attributes should be interpreted. I think there's no getting around saving some state during initial attr= ibute processing which is later used to evaluate the operation as a whole. Certainly you could save the raw form of any 'text' or 'name' strings d= uring a first pass over the attributes, then interpret them using the supplied "attributes-charset" and "attributes-natural-language" in a later phase= From ipp-archive Mon Mar 30 17:23:39 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA13300 for ipp-outgoing; Mon, 30 Mar 1998 17:21:15 -0500 (EST) Message-Id: <199803302218.OAA11801@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 30 Mar 1998 14:22:40 -0800 To: Carl Kugler , From: Robert Herriot Subject: Re: IPP>MOD: Problem in IPP encoding with "attributes-charse In-Reply-To: <5030100019004296000002L062*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Yes, I realize that there is a work-around, but none of us should have to deal with this mess in our implementations. Instead, we need to change the spec so that the implementations will be simpler. The lack of ordering with regard to charset and language has no value. "ipp-attribute-fidelity" is not the same problem because its value applies to the following group. That is, the ordering rules work in this case. Bob Herriot At 11:56 AM 3/27/98 , Carl Kugler wrote: >I found it rather easy to implement when I did it. > >"ipp-attribute-fidelity" is another special attribute because it, too, >determines how all attributes should be interpreted. > >I think there's no getting around saving some state during initial attribute >processing which is later used to evaluate the operation as a whole. > >Certainly you could save the raw form of any 'text' or 'name' strings during a >first pass over the attributes, then interpret them using the supplied >"attributes-charset" and "attributes-natural-language" in a later phase > From ipp-archive Mon Mar 30 20:53:42 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA14074 for ipp-outgoing; Mon, 30 Mar 1998 20:53:15 -0500 (EST) Message-Id: <199803310147.RAA12009@woden.eng.sun.com> X-Sender: rherriot@woden.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 30 Mar 1998 17:51:25 -0800 To: walker@dazel.com, Tom Hastings From: Robert Herriot Subject: Re: IPP> MOD/PRO - simple proposal for providing dictionary-like capability Cc: ipp@pwg.org In-Reply-To: <3519741C.A50232BC@dazel.com> References: <3.0.1.32.19980324153634.01213b10@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 Jim, I have similar concerns about the use of attributes with parallel values. I have this nagging feeling that we are going to regret this direction. But thus far it has been the least bad solution that we have found. We have arrived at this unfortunate point because the current binary encoding has painted us into a corner. An XML encoding would=20 allow a very simple solution for dictionaries. We considered having dictionary members appear as normal attributes surrounded by begin-dictionary and end-dictionary "values", but this= solution would potentially create name conflicts with names at the top level for parsers that don't know about dictionaries. This solution works if we force a= version change or all existing parsers add support for it. We considered having a dictionary structure which would be a new type whose values are nested in an existing value. For small dictionaries, this is the obvious and simple solution, but if we kept the existing limit of 1023 octets per value, some dictionaries would be impossible. Picking=20 a value that is large enough for all likely dictionaries but doesn't burden small implementations was difficult and didn't seem to solve the problem. We looked at ways to keep the 1023 limit and instead chunk the dictionary into multiple values. I had a reasonable but very ugly solution which=20 concatenated the chunks together and use "begin-dictionary" and=20 "end-dictionary" "values" to indicate the structure. By turning the dictionary problem into a naming problem, we seem to have side stepped all of these issues, but as you point out data structures were invented for a reason. Do you have any suggestions for what we should do? Bob Herriot At 01:16 PM 3/25/98 , James Walker wrote: >Tom Hastings wrote: >>=20 >> For the IPP telecon, Wed, 3/25: >>=20 >> Roger, Bob, and I have been working on various dictionary proposals. >>=20 >> ... >>=20 >> Briefly, the scheme isn't really a dictionary at all (previous >> versions were).=A0 Other earlier versions were adding a new addressing >> mechanism for attributes in dictionaries. >>=20 >> This proposal adds no new addressing mechanisms, >> but justs add a new out-of-band value to encode the new Model attribute >> syntax of 1setOf 1setOf (doubly nested values).=A0 Instead, we use the >> idea of attributes with parallel values, like we already have for >> "printer-uri-supported" and "uri-security-supported". > >As discussed in the telecon today, I think that the parallel attribute >idea is a bad one... it does not scale well, it is difficult for users >to understand and get right, it is error-prone, etc.=A0 Our experience >from the implementation of parallel attributes in DPA has not been a >good one.=A0 All in all, I believe that data structures are a good idea, >but trying to describe data structures using parallel attributes does >not work. > >> ... >>=20 >> I've left the rejected example that uses the 'dictionary' attribute= syntax >> in the document.=A0 I've also listed the alternatives that we considered >> and the reasons for rejecting them. >>=20 >> ... > >I simply do not understand why the original concept of a dictionary >value tag (with its associated value length) would not work well. >This is the example that is shown in Tom's document. > >...walker > >-- >Jim Walker >System Architect/DAZEL Wizard >DAZEL Corporation, Austin, TX >=20 From ipp-archive Mon Mar 30 23:13:45 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA14814 for ipp-outgoing; Mon, 30 Mar 1998 23:11:13 -0500 (EST) From: duff@field.com Date: Mon, 30 Mar 1998 23:10:41 -0500 (EST) Message-Id: <199803310410.XAA08446@mail.interhop.net> To: Subject: IPP> about filedudes Sender: ipp-owner@pwg.org Precedence: bulk hey, found this real fast download site www.filedudes.com, check it out! From ipp-archive Tue Mar 31 12:56:42 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA27487 for ipp-outgoing; Tue, 31 Mar 1998 12:49:53 -0500 (EST) Message-ID: <5CEA8663F24DD111A96100805FFE6587030BC41B@red-msg-51.dns.microsoft.com> From: Paul Moore To: "'Robert Herriot'" , walker@dazel.com, Tom Hastings Cc: ipp@pwg.org Subject: RE: IPP> MOD/PRO - simple proposal for providing dictionary-like capability Date: Tue, 31 Mar 1998 09:49:29 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: ipp-owner@pwg.org Precedence: bulk I agree - this is one of the areas where we all agreed that XML won with no debate whatsoever. We all know the history of this debate (XML or not XML). We decided to keep the current protocol for IPP1. The informal consensus in maui was that IPP2 (which I think the dictionary discussion is aimed at) must be XML-based. If we dont make that change then we will regret it for ever and ever. > -----Original Message----- > From: Robert Herriot [SMTP:robert.herriot@Eng.Sun.COM] > Sent: Monday, March 30, 1998 5:51 PM > To: walker@dazel.com; Tom Hastings > Cc: ipp@pwg.org > Subject: Re: IPP> MOD/PRO - simple proposal for providing > dictionary-like capability > > Jim, > > I have similar concerns about the use of attributes with parallel values. > I have this nagging feeling that we are going to regret this direction. > But thus far it has been the least bad solution that we have found. > > We have arrived at this unfortunate point because the current binary > encoding has painted us into a corner. An XML encoding would > allow a very simple solution for dictionaries. > > We considered having dictionary members appear as normal attributes > surrounded by begin-dictionary and end-dictionary "values", but this > solution > would potentially create name conflicts with names at the top level for > parsers > > that don't know about dictionaries. This solution works if we force a > version > change or all existing parsers add support for it. > > We considered having a dictionary structure which would be a new type > whose values are nested in an existing value. For small dictionaries, this > is the obvious and simple solution, but if we kept the existing limit > of 1023 octets per value, some dictionaries would be impossible. Picking > a value that is large enough for all likely dictionaries but doesn't > burden > small implementations was difficult and didn't seem to solve the problem. > We looked at ways to keep the 1023 limit and instead chunk the dictionary > into multiple values. I had a reasonable but very ugly solution which > concatenated the chunks together and use "begin-dictionary" and > "end-dictionary" "values" to indicate the structure. > > By turning the dictionary problem into a naming problem, we seem to have > side stepped all of these issues, but as you point out data structures > were > invented for a reason. > > Do you have any suggestions for what we should do? > > Bob Herriot > > > > > At 01:16 PM 3/25/98 , James Walker wrote: > >Tom Hastings wrote: > >> > >> For the IPP telecon, Wed, 3/25: > >> > >> Roger, Bob, and I have been working on various dictionary proposals. > >> > >> ... > >> > >> Briefly, the scheme isn't really a dictionary at all (previous > >> versions were).  Other earlier versions were adding a new addressing > >> mechanism for attributes in dictionaries. > >> > >> This proposal adds no new addressing mechanisms, > >> but justs add a new out-of-band value to encode the new Model attribute > >> syntax of 1setOf 1setOf (doubly nested values).  Instead, we use the > >> idea of attributes with parallel values, like we already have for > >> "printer-uri-supported" and "uri-security-supported". > > > >As discussed in the telecon today, I think that the parallel attribute > >idea is a bad one... it does not scale well, it is difficult for users > >to understand and get right, it is error-prone, etc.  Our experience > >from the implementation of parallel attributes in DPA has not been a > >good one.  All in all, I believe that data structures are a good idea, > >but trying to describe data structures using parallel attributes does > >not work. > > > >> ... > >> > >> I've left the rejected example that uses the 'dictionary' attribute > syntax > >> in the document.  I've also listed the alternatives that we considered > >> and the reasons for rejecting them. > >> > >> ... > > > >I simply do not understand why the original concept of a dictionary > >value tag (with its associated value length) would not work well. > >This is the example that is shown in Tom's document. > > > >...walker > > > >-- > >Jim Walker > >System Architect/DAZEL Wizard > >DAZEL Corporation, Austin, TX > > From ipp-archive Tue Mar 31 17:08:55 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA29114 for ipp-outgoing; Tue, 31 Mar 1998 17:01:04 -0500 (EST) Message-Id: <3.0.1.32.19980331135443.009917f0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 31 Mar 1998 13:54:43 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - REMINDER - IETF41 IPP meeting April 1 at 1 pm Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk Hope to see at least a few faces from the IPP group :-) 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 Mar 31 18:29:14 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA29932 for ipp-outgoing; Tue, 31 Mar 1998 18:26:29 -0500 (EST) Message-ID: <19980331232607.16368.qmail@hotmail.com> X-Originating-IP: [156.153.255.194] From: "Puru Bish" To: ipp@pwg.org Subject: IPP> printer-uri and job-uri Content-Type: text/plain Date: Tue, 31 Mar 1998 15:26:07 PST Sender: ipp-owner@pwg.org Precedence: bulk Greetings. There are two issues related to printer-uri and job-uri that need some clarifications. Issue1: In the IPP Model document, there is no specification for the value-tags of "printer-uri" and "job-uri" attributes in a IPP request. According to the IPP Model document, section 3.1.3, the "printer-uri" attribute contains the Printer object's URIs which is one of the values in the Printer object's "printer- uri-supported" attribute. This implies that the value-tag of "printer-uri" attribute must be of type "uri". Similarly, the value-tag of "job-uri" attribute should be "uri" as well. Issue 2: In the "Note:" section of 3.2.1.1 in the IPP Model document, it was mentioned that "The simplest Print-Job Request consists of just the Document Content, the "attributes- charset" and "attributes-natural-language" operation attributes, and nothing else." However, in the description of Print-Job Request of section 15.3.4.3, the "printer-uri" attribute is specified as a MUST (indicated by (M)) and also in section 3.1.3 of the same document, it was indicated that either "printer-uri" or "job-uri" MUST appear in every operation request. There seems to be some inconsistency here. Please send your remarks/comments to the mailing list. -PB ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From ipp-archive Wed Apr 1 03:39:02 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id DAA09174 for ipp-outgoing; Wed, 1 Apr 1998 03:34:32 -0500 (EST) Message-Id: <3.0.1.32.19980401003250.011cd8d0@garfield> X-Sender: hastings@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 1 Apr 1998 00:32:50 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> MOD - Updated 'dictionary' attribute syntax proposal posted Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk I've posted an updated proposal for a new 'dictionary' attribute syntax. As agreed at last weeks telecon, I've gone back to the original proposal that introduces a new 'dictionary' attribute syntax. There was implementation experience that parallel attributes is difficult for clients and servers. The consensus was that with the 'dictionary' attribute syntax that some maximum length, like 2047 octets, would be sufficient and there there was no need to have a way to provide for bigger dictionaries. We agreed that we are not trying to solve the dictionary problem for all applications, only for printing. I've also used "job-notify" examples of a dictionary that needs multiple valued attributes in the dictionary. This is only an example, not Harry's and my action item on notification. But it does show how the 'dictionary' mechanism will be useful for specifying notification when submitting a job. The files are at: ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-dict-attr-syntax-v092.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-dict-attr-syntax-v092.pdf The PDF has line numbers. I'd like to put review of this proposal on the agenda for next week. Also lets start the discussion via e-mail. Thanks, Tom From ipp-archive Wed Apr 1 03:59:01 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id DAA10873 for ipp-outgoing; Wed, 1 Apr 1998 03:56:37 -0500 (EST) From: henrik.holst@i-data.com X-Lotus-FromDomain: I-DATA To: ipp@pwg.org Message-Id: Date: Wed, 1 Apr 1998 09:56:26 +0100 Subject: IPP> IPP: Job template attributes MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Precedence: bulk I am wondering, are the job template attributes only for information and administration? E.g. if an IPP Server recieves the job template attribute 'copies n' must the IPP Server make the n copies, or does the attribute only tell that the following job will me maked in n copies. Henrik Holst ___________________________________________________________ Henrik Holst Software engineer - developing embedded Printservers i-data International Vadstrupvej 35-43, 2880 Bagsvaerd, Denmark Voice: (+45) 44366271 Fax: (+45) 44366111 Email: henrik.holst@i-data.com WEB: www.i-data.com