From dhall at hp.com Mon Jan 6 16:23:44 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:08 2009 Subject: PS> 0.94b Spec available Message-ID: <77261E830267D411BD4D00902740AC250DB4C3E0@xvan01.vcd.hp.com> Hey All... The 0.94b specification is available. I have split out the relevant sections into a separate developers guide. Also, we have created a usage overview document. ftp://ftp.pwg.org/pub/pwg/ps/psi-spec-latest.pdf ftp://ftp.pwg.org/pub/pwg/ps/psi-devl-latest.pdf ftp://ftp.pwg.org/pub/pwg/ps/psi-interface-usage-latest.pdf We have a goal of having 0.95 complete by Monday the 13th, so please review and provide comments and feedback. Dave From dhall at hp.com Tue Jan 7 18:34:56 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:08 2009 Subject: PS> Union construct for 0.95 Message-ID: <77261E830267D411BD4D00902740AC250DB4C400@xvan01.vcd.hp.com> Hey All During todays PSI meeting, the issue of toolkit support for the union construct in schema definitions came up. In general, one of our goals for the PSI spec is to provide a specification that has a high probability of interoperatibility between different vendors. There are three options available to address the union construct: 1) Leave it as it is, and deal with the toolkits lack of support on a case by case basis. This has the advantage of keeping the specification "pure", but has the dis-advantage of near term interop problems. 2) For the interim, modify the Common Semantic Model to not utilize the union construct. As the toolkits add support, eventually roll the union construct back into the semantic model. This gets us better interop in the near term, but may add turmoil when we re-introduce the union construce. 3) In PSI, duplicate the object defnintions that contain the element refences to the types that are defined by union, and define them directly as an NMTOKEN. In otherwords, create a PSI_DocumentDescription.xsd that has: instead of: This has the advantage of keeping the semantic model "pure", but has the dis-advantage of duplicated container object definitions.. Thoughts / Opinions? Dave From imcdonald at sharplabs.com Tue Jan 7 18:38:51 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:08 2009 Subject: PS> RE: LDAP Printer Schema - lost in the woods? Message-ID: <116DB56CD7DED511BC7800508B2CA53735CE72@mailsrvnt02.enet.sharplabs.com> Hi folks, OK - our concensus is that Pat Fleming and I should work with Tom Hastings and convert the latest IETF Internet-Draft of the IETF Informative LDAP Printer Schema (not IETF 'standards track') to an IEEE/ISTO PWG draft of a PWG Proposed Standard LDAP Printer Schema (PWG 'standards track'). As we discussed during our weekly PWG PSI telecon this morning, PSI needs to eventually make NORMATIVE references to both the IANA-registered SLP Printer Template v2.0 and our semantically equivalent LDAP Printer Schema for service discovery. Cheers, - Ira McDonald, co-editor of LDAP Printer Schema High North Inc PS - I've copied the open PWG PSI list, since we've reached concensus among the document editors and IETF IPP (Carl-Uno Manros) and IEEE/ISTO PWG (Harry Lewis) officers. -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, January 07, 2003 10:27 AM To: Pat Fleming Cc: 'carl@manros.com'; 'Hastings, Tom N'; McDonald, Ira Subject: RE: LDAP Printer Schema - lost in the woods? Sorry I'm still catching up from the holiday. I agree... let's quit dragging out feet with the IETF. Unfortunate... but reality. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- Pat Fleming 01/02/2003 09:19 AM To: "McDonald, Ira" cc: "'carl@manros.com'" , Harry Lewis/Boulder/IBM@IBMUS, "'Hastings, Tom N'" , "McDonald, Ira" From: Pat Fleming/Rochester/IBM@IBMUS Subject: RE: LDAP Printer Schema - lost in the woods?Link Ira, I'm ok with your suggestion. Pat Fleming, STSM, WebSphere Architecture, Directory and Web Services, Websphere Technology CEM for iSeries Phone: 507-253-7583 (T/L 553-7583) Dept 45E/Bldg 015-2 / F111 flemingp@us.ibm.com "McDonald, Ira" 01/01/2003 01:27 PM To: "'carl@manros.com'" , "McDonald, Ira" cc: Pat Fleming/Rochester/IBM@IBMUS, "'Hastings, Tom N'" , Harry Lewis/Boulder/IBM@IBMUS Subject: RE: LDAP Printer Schema - lost in the woods? Hi Carl-Uno, Thanks - your suggestion (some future Informational RFC that points to the IEEE/ISTO PWG 510x.y standard LDAP Printer Schema) makes perfect sense to me. Harry and Pat - comments? opinions? I suggest that Pat and I publish one FINAL I-D version (to replace the existing one at ftp.ietf.org), with an empty body and an Abstract that says (something like): "Work on this LDAP Printer Schema has been withdrawn from the IETF process. See IEEE/ISTO Printer Working Group 'work-in-progress' on this topic at 'http://www.pwg.org'." Then we send your suggested note to RFC Editor (the documents in the RFC queue), IETF Secretary, and IETF Applications ADs. Cheers, - Ira PS - At least the PSI and FSG folks are quite happy to make MUST requirements for implementations that elect to support LDAP and/or SLP service discovery - the problem of options is getting more attention in the next generation of printing protocol standards. -----Original Message----- From: Carl [mailto:carl@manros.com] Sent: Tuesday, December 31, 2002 8:36 PM To: McDonald, Ira Cc: Carl-Uno Manros; 'Pat Fleming'; 'Hastings, Tom N'; 'Harry Lewis' Subject: RE: LDAP Printer Schema - lost in the woods? Ira, This is such a long and sad story. As you might remember, the original idea was to have this informatiuon as an appendix to the IPP Model document, but then we decided to break it out and make it into a separate document, etc. etc. and then it has been going on for several years... I think you are right. I suggest that you and Pat as authors of the latest draft write to the IETF Editor and Patrik, informing them that you want to withdraw the current version of the document. Once it has been published by the PWG, you can still re-enter an updated version as an Informational RFC in the IETF, but then with the remark that it is a published standard in the PWG and is only offered to the IETF for pure information. Does this make sense? Carl-Uno Carl-Uno Manros 10701 S Eastern Ave #1117 Henderson, NV 89052, USA Tel +1-702-617-9414 Fax +1-702-617-9417 Mob +1-702-525-0727 Email carl@manros.com > -----Original Message----- > From: McDonald, Ira [mailto:imcdonald@sharplabs.com] > Sent: Tuesday, December 31, 2002 12:25 PM > To: 'carl@manros.com'; McDonald, Ira > Cc: 'Harry Lewis'; 'Hastings, Tom N'; 'Pat Fleming' > Subject: RE: LDAP Printer Schema - lost in the woods? > > > Hi Carl-Uno, > > My mistake - this LDAP Printer Schema was for IETF Informational > status. The fact that a non-IETF standard (in fact quite a few of > them) will make a Normative reference is perhaps the BEST reason > to just withdraw the document and publish it from the PWG. > > Background: > > We agreed (at Harry Lewis' urging) to try and get it published as > an RFC - but two more years have gone past, and a lot of products > have shipped with this LDAP Printer Schema (from IBM, Sun, and > others). > > So let's just withdraw this document as an IETF product and > publish it as IEEE/ISTO PWG Proposed Standard, OK? > > Cheers, > - Ira McDonald > > > > -----Original Message----- > From: Carl [mailto:carl@manros.com] > Sent: Saturday, December 28, 2002 2:04 AM > To: McDonald, Ira > Cc: Carl-Uno Manros > Subject: RE: LDAP Printer Schema - lost in the woods? > > > Ira, > > Before I ping Patrik, can you remind me what status this document > will have > in the IETF? > > If it is not standards track, it will be politically incorrect to > talk about > other standads documents as referencing it as a normative reference, just > trying to not word this wrongly. > > Carl-Uno > > Carl-Uno Manros > 10701 S Eastern Ave #1117 > Henderson, NV 89052, USA > Tel +1-702-617-9414 > Fax +1-702-617-9417 > Mob +1-702-525-0727 > Email carl@manros.com > > > -----Original Message----- > > From: McDonald, Ira [mailto:imcdonald@sharplabs.com] > > Sent: Friday, December 27, 2002 4:33 PM > > To: 'Carl'; 'Harry Lewis'; 'Hastings, Tom N'; 'Pat Fleming'; McDonald, > > Ira > > Subject: LDAP Printer Schema - lost in the woods? > > Importance: High > > > > > > Hi Carl-Uno, > > > > Would you please ping Patrik Faltstrom about the status of this > > document? > > > > The soon-to-be-completed IEEE/ISTO PWG Print Systems Interface > > (PSI, printer over WSDL/SOAP) will have a Normative section on > > print server and target device service discovery via: > > (1) Multicast DNS -- vis SRV record search > > (2) SLPv2 -- via IANA-registered SLP Printer Template v2.0 > > (3) LDAPv3 -- draft-fleming-ldap-printer-schema-02.txt, June 2002 > > > > Patrik has never answered any of the notes that Pat Fleming (my > > co-author) and I have sent since July 2002. The IETF DataTracker > > shows that this item was last updated in July -- when it was first > > _added_ to the IESG DataTracker. > > > > If this document is not published quite soon as an RFC (Q1 2003), > > for PSI we need to: > > (1) _withdraw_ it as an IETF document -- via a new I-D version > > (2) _adopt_ it as a stable IEEE/ISTO PWG Proposed Standard > > > > Free Software Group (FSG) Open Printing standards for Linux will > > also have several Normative references to this LDAP Printer Schema. > > > > Cheers, > > - Ira McDonald, co-author of LDAP Printer Schema > > High North Inc > > > From PZehler at crt.xerox.com Wed Jan 8 07:44:25 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:02:08 2009 Subject: PS> SLP (srvloc) discussion on sourceforge Message-ID: All, Here is one of the notes from the SLP conversation on co-resident services. At the end is the URL to where you can join or look through the archive. Pete Peter Zehler XEROX Xerox Architecture Center Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 265-8871 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-30E Webster NY, 14580-9701 -----Original Message----- From: Erik Guttman [mailto:Erik.Guttman@Sun.COM] Sent: Wednesday, January 08, 2003 5:34 AM To: Mayer, Jim Cc: 'Erik Guttman'; Dan Nuffer; mdday@us.ibm.com; srvloc-discuss@lists.sourceforge.net; Matt Peterson Subject: RE: [Srvloc-discuss] Re: your view on draft-guttman-svrloc-servic eid-02.txt On Mon, 6 Jan 2003, Mayer, Jim wrote: > One of the issues that the serviceid scheme was (I thought) going to help > address was the proliferation of service advertisements. For folks using SLP to contact management devices, it was simpler to group attributes by the access point. The only thing they required was to know, definitively, that a set of service access points were in fact accessing the same service, over time, irrespective of change in address and independent of access mechanism. Once we start down the path of a general service record, we have to seriously bend the text based SLP attribute mechanism. Either we should *break AttrRply* and allow record based attributes, or I believe we should stick with the simpler approach of adding a serviceid attribute for collating different service replies. > The multiplexing is necessary because the URI, transport, and security > protocol may all be tightly associated with each other. Either by (a) separate responses (my current proposal) Simple to explain and use, a bit heavy on the network (b) complex attribute lists embedded in attributes (serviceid-02) Which is really nasty to explain and use (c) breaking attribute lists, changing SLP itself, etc Will take a long time to get adopted, if it gets adopted. > I would really like to avoid having to make a seperate advertisement for > every possible combination of transport and access security, which is where > the proposal seems to be going. I understand that, but there is a trade-off of complexity given SLP's constraints and verbosity. > Things I'd like to be discoverable for a multi-function device include: > > 1) Find me the adminstration service for the device that supports this > printer (or scanner, etc.) > 2) Find me the services supported by this device. > 3) Find me the printer(s) (scanner(s), etc.) supported by this device. > > Perhaps "device" should be generalized to multple "groups"? Just a thought. A fruitful direction would be to define a device advertisement. One could list device characteristics, even serviceids of services the device supports. Anyone want to take a stab at that template? Some will view this as going pretty far down the road of using SLP as a management protocol, but so what. Erik ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Srvloc-discuss mailing list Srvloc-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/srvloc-discuss From alan.berkema at hp.com Wed Jan 8 12:33:09 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:08 2009 Subject: PS> [PSI]: minutes 01/07/03 Message-ID: <499DC368E25AD411B3F100902740AD650E6AD55C@xrose03.rose.hp.com> PSI Working Group: *Alan Berkema *Dave Hall Gail Songer *Jerry Thasher *Harry Lewis Ted Tronson *Peter Mierau *Peter Zehler Paul Tykodi Bob Taylor Don Levinstone Lee Farrell Don Wright Kirk Ocke *Ira Mcdonald Amir Shahindoust * = attendance 01/07/03 Agenda 1) Discovery - Finalize: SLPv2 and LDAPv3 examples for spec, SSDP examples for spec. 2) Look at mDNS-SD examples 3) Spec review topics 01/07/03 Minutes: 0) Rev 0.94x (candidate for 0.95) will be delivered on the morning of January 13 2003. This gives us a week to review before the start of the week of PWG F2F meetings. Planning page turner review at PSI F2F January 24 2003. Ideally, at the F2F we will identify what needs to be fixed to have a last call for comments before we promote the spec to revision 0.95 At 0.95 the spec will be theoretically frozen. Changes to the spec will be conducted via an errata process. One exception is the WSDL itself. The WSDL will evolve through versioning since an errata process does not really make sense for WSDL, we really want an entire latest greatest version of the WSDL which includes all bug fixes. Need all input by Thursday afternoon 01/09/03 for inclusion in 01/13/03 rev 0.95 candidate. 1) Re visit SSDP examples Decided that psi:rootdevice, is needed for compatibility for a device that uses SSDP for both PSI and UPnP. Action: Send SSDP example to Dave Owner: Alan Status: Open Action: Investigate what needs to be done for UPnP-dev device description via UPnP Print Device documentation. Owner: Alan Status: Open Action: Send latest SLPv2 LDAPv3 examples to Dave Owner: Ira Status: Open Action: Send new proposals for Reference and Target Device by afternoon of 01/09/03 Owner: Ira Status: Open Action: e-mail discussion of state of current tool kit issues Owner: Dave Status: Done Action: Determine if Web Sphere tools have similar limitations Owner: Alan Status: Open General spec discussion: Need some Normative statements on authentication: Discovery? Normative part of spec or developer's guide? I think discovery is what Bluetooth calls "process mandatory" This means that, if a feature (such as a discovery protocol) is used, it is used in the specified manner. Interop events? As soon as we have a few companies that are ready HP will host an event, off cycle from PWG meetings. How many devices do we need? Need interop test criteria such as what features will be supported what discovery is used etc. From imcdonald at sharplabs.com Thu Jan 9 12:32:55 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:08 2009 Subject: PS> Final SLP and LDAP examples for PSI spec Message-ID: <116DB56CD7DED511BC7800508B2CA53735CE79@mailsrvnt02.enet.sharplabs.com> Hi Dave and Alan, Thursday (9 January 2003) Per my action item from this week's PSI Telecon (7 January 2003), below are revised examples and details for PSI discovery via SLPv2 (RFC 2608) and LDAPv3 (RFC 2251). Standard PSI URL scheme names (defined below) are REQUIRED for PSI discovery via SLPv2 and LDAPv3. But, new attributes do NOT need to be added to the existing standard printer schema for PSI discovery. URL scheme registration in the IETF tree (without embedded hyphen '-') is very slow - currently several _years_ before acceptance and RFC publication. We should register an alternate tree with "pwg-" prefix for use with PSI and (probably) also IPPFAX. Cheers, - Ira McDonald, co-editor of SLPv2 and LDAPv3 Printer Schemas High North Inc imcdonald@sharplabs.com ------------------------------------------------------------------------ PSI URL Schemes --------------- Conformant to "Registration Procedures for URL Scheme Names" (RFC 2717), the PSI standard URL schemes are: pwg-psips: - PSI Print Service pwg-psitd: - PSI Target Device Conforming PSI Clients MUST convert PSI standard URLs to session-level HTTP URLs by: (a) Replacing the PSI scheme name with "http:"; (b) Adding explicitly the IANA-registered PSI standard port. Conforming PSI Print Services and PSI Target Devices: (a) MUST only use the (future) IANA-registered PSI port; (b) MUST NOT use "http:" port 80 for their WSDL/SOAP interface; (c) MUST advertise using PSI standard URL schemes. Printer Schema Locations ------------------------ The IANA-registered SLPv2 Printer Template v2.0 is in the directory: ftp://ftp.iana.org/assignments/svrloc-templates/ in the file: printer.2.0.en (8 March 2000) The latest draft of the LDAPv3 Printer Schema is in the directory: ftp://ftp.pwg.org/pub/pwg/ipp/new_LDAP in the file: draft-fleming-ldap-printer-schema-02.txt (30 June 2002) Note: The LDAP Printer Schema has been withdrawn from the IETF process and will be published in a future IEEE/ISTO PWG Proposed Standard. The content of the LDAP Printer Schema has been stable for two years, with the ASN.1 OIDs assigned in the IBM namespace, NOT in the IETF namespace. SLPv2 Discovery --------------- A conforming PSI Print Service or PSI Target Device that supports SLPv2 (RFC 2608) MUST advertise using the IANA-registered standard SLPv2 Printer Template v2.0. ABNF for PSI standard SLPv2 service URLs is: service:printer:pwg-psips://hostport[abs_path] service:printer:pwg-psitd://hostport[abs_path] hostport = host [ ":" port ] host = IPv6reference / IPv4address / hostname port = *DIGIT abs_path = "/" path_segments SLPv2 Service Request --------------------- A conforming PSI Client that supports SLPv2 (RFC 2608) MUST discover available PSI Print Services or PSI Target Devices, acting in the role of an SLPv2 User Agent (UA), by sending an SLPv2 Service Request (see section 8.1 of RFC 2608) of the form: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Location header (function = SrvRqst = 1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of | String \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of | String \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of | String \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of predicate string | Service Request \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of string | String \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The MUST be either "service:printer:pwg-psips" or "service:printer:pwg-psitd". Note that the final ":" MUST NOT be included in the value. The (without prior administrative configuration) MUST be "DEFAULT" (the standard SLPv2 scope). Note that SLPv2 scopes are case-sensitive, so the value "DEFAULT" MUST be in uppercase. The (optional) MAY specify any LDAPv3 valid search filter (see "The String Representation of LDAP Search Filters", RFC 2254). For example a PSI printer that supports color can be discovered using a value of: "printer-color-supported=true" SLPv2 Service Reply ------------------- The presence or absence of network infrastructure is invisible to the PSI Client - SLPv2 discovery uses identical SLPv2 requests and replies in either case. When operating in a managed environment (with infrastructure), an SLPv2 Directory Agent (DA) will reply to a PSI Client (on behalf of registered PSI Print Services and PSI Target Devices). When operating in a zero configuration environment (no infrastructure), a conforming PSI Print Service or PSI Target Device that supports SLPv2, acting in the role of an SLPv2 Service Agent (UA), MUST reply directly to SLPv2 Service Requests received from a PSI Client, by sending an SLPv2 Service Reply (see section 8.2 of RFC 2608) of the form: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Location header (function = SrvRply = 2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Code | URL Entry count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Each returned PSI Print Service URL MUST specify either an IPv4/IPv6 address (directly usable) or a hostname (which must be resolved by DNS or mDNS lookup). SLPv2 DA Discovery ------------------ The DHCP option (decimal) 78 may be used, to find an SLPv2 Directory Agent (DA), per "DHCP Options for Service Location Protocol" (RFC 2610). LDAPv3 Discovery ---------------- Conforming PSI Clients that support LDAPv3 (RFC 2251) MUST use the (future) IEEE/ISTO PWG Proposed Standard LDAPv3 Printer Schema to search for the LDAPv3 object class "printerService" (a base class) or "printerServiceAuxClass" (may be attached, for example, to a DMTF CIM printer object class - same content as "printerService") to discover PSI standard URLs (values of the "printer-uri" attribute) of the form: pwg-psips://hostport[abs_path] pwg-psitd://hostport[abs_path] Also, an LDAPv3 search filter may be used (as with SLPv2) to find the substring "pwg-psips" or "pwg-psitd" in the "printer-xri-supported" attribute. LDAPv3 Search Request --------------------- A conforming PSI Client that supports LDAPv3 (RFC 2251) MUST discover available PSI Print Services or PSI Target Devices by sending an LDAPv3 Search Request (see section 4.5.1 of RFC 2251) of the form: SearchRequest ::= [APPLICATION 3] SEQUENCE { baseObject LDAPDN, scope ENUMERATED { baseObject (0), singleLevel (1), wholeSubtree (2) }, derefAliases ENUMERATED { neverDerefAliases (0), derefInSearching (1), derefFindingBaseObj (2), derefAlways (3) }, sizeLimit INTEGER (0 .. maxInt), timeLimit INTEGER (0 .. maxInt), typesOnly BOOLEAN, filter Filter, attributes AttributeDescriptionList } Filter ::= CHOICE { and [0] SET OF Filter, or [1] SET OF Filter, not [2] Filter, equalityMatch [3] AttributeValueAssertion, substrings [4] SubstringFilter, greaterOrEqual [5] AttributeValueAssertion, lessOrEqual [6] AttributeValueAssertion, present [7] AttributeDescription, approxMatch [8] AttributeValueAssertion, extensibleMatch [9] MatchingRuleAssertion } SubstringFilter ::= SEQUENCE { type AttributeDescription, -- at least one must be present substrings SEQUENCE OF CHOICE { initial [0] LDAPString, any [1] LDAPString, final [2] LDAPString } } MatchingRuleAssertion ::= SEQUENCE { matchingRule [1] MatchingRuleId OPTIONAL, type [2] AttributeDescription OPTIONAL, matchValue [3] AssertionValue, matchValue [3] AssertionValue, LDAPv3 Search Result -------------------- When operating in a managed environment (with infrastructure), an LDAPv3 Server will reply to a PSI Client (on behalf of registered PSI Print Services and PSI Target Devices), by sending an LDAPv3 Search Result (see section 4.5.2 of RFC 2251) of the form: SearchResultEntry ::= [APPLICATION 4] SEQUENCE { objectName LDAPDN, attributes PartialAttributeList } PartialAttributeList ::= SEQUENCE OF SEQUENCE { type AttributeDescription, vals SET OF AttributeValue } -- implementors should note that the PartialAttributeList may -- have zero elements (if none of the attributes of that entry -- were requested, or could be returned), and that the vals set -- may also have zero elements (if types only was requested, or -- all values were excluded from the result.) SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL -- at least one LDAPURL element must be present SearchResultDone ::= [APPLICATION 5] LDAPResult LDAPv3 Server Discovery ----------------------- The DHCP option (decimal) 95 may be used, to find an LDAPv3 Server. See the definition in the directory: ftp://ftp.iana.org/assignments/bootp-dhcp-extensions/ DNS Server Discovery -------------------- The DHCP option (decimal) 6 may be used to find a DNS server address. See "DHCP Options and BOOTP Vendor Extensions" (RFC 2132). The DHCP option (decimal) 117 may also be used to find a DNS server. See "The Name Service Search Option for DHCP" (RFC 2937). From imcdonald at sharplabs.com Thu Jan 9 18:02:30 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:08 2009 Subject: PS> Protocol Stack and 'targetDevice.xsd' to simple URLs Message-ID: <116DB56CD7DED511BC7800508B2CA53735CE7C@mailsrvnt02.enet.sharplabs.com> Hi Dave, Thursday (9 January 2003) Below is a a PSI protocol stack diagram to disambiguate our terminology and my best effort to replace the PSI-specific 'targetDevice.xsd' with simple URLs (with examples and notes). Cheers, - Ira McDonald High North Inc ---------------------------------------- * PSI Protocol Stack |-------------------------| |7 - Application Layer | |PSI Client or PSI Server | |-------------------------| |6 - Presentation Layer | |WSDL/SOAP | |-------------------------| |5 - Session Layer | |HTTP | |-------------------------| |4 - Transport Layer | |[TLS] | |TCP | |-------------------------| |3 - Network Layer | |IP | |-------------------------| |2 - Datalink Layer | |Ethernet, Bluetooth, etc.| |-------------------------| |1 - Physical Layer | |Wire, light, radio, etc. | |-------------------------| ---------------------------------------- * Replace 'targetDevice.xsd' with simple URLs TCP Port -------- Example: raw-tcp://somehost.com:9100 Notes: (1) REQUIRED 'host' or 'ip-addr' MUST be specified (1) REQUIRED 'port' MUST be specified (cannot be defaulted) Background: See the "raw-tcp:" URL scheme defined in the IANA-registered SLPv2 "direct print" template in the directory: ftp://ftp.iana.org/assignments/svrloc-templates in the file: printer_raw-tcp.1.0.en which extends the base SLPv2 Printer Template v2.0 Fax --- Example: fax:+358.555.1234567 Background: See "fax:" URL scheme defined in "URLs for Telephone Calls" (RFC 2806). UNC --- Example: pwg-unc:\\myprintserver\myprinter Notes: (1) Proposed new PWG standard URL scheme for UNC encapsulation (2) ALL printable ASCII characters are legal in the UNC, including the BACKSLASH (0x5C) Background: Microsoft uses UNC identifiers in Windows environments. PSI Service Endpoint -------------------- Example: pwg-psitd://mypsitarget.mydomain.com:3700/psitd Notes: (1) REQUIRED 'host' or 'ip-addr' MUST be specified (2) OPTIONAL 'port' MUST default to IANA-assigned value (example assumes port '3700') Background: PSI standard URL schemes are defined elsewhere in this PSI spec. From imcdonald at sharplabs.com Thu Jan 9 18:04:10 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:08 2009 Subject: PS> 'reference.xsd' to simple URLs Message-ID: <116DB56CD7DED511BC7800508B2CA53735CE7D@mailsrvnt02.enet.sharplabs.com> Hi Dave, Thursday (9 January 2003) Below is my best effort to replace the PSI 'reference.xsd' with simple URLs (with a few query part parameters). More work is still needed on the RFC 2822 (SMTP) format for references to specific messages and body parts and attachments of those messages, for POP3 (see IMAP4 below). Cheers, - Ira McDonald High North Inc ---------------------------------------- * Convert current "reference.xsd" to use _only_ URLs URL --- Background: See "Uniform Resource Identifiers (URI): Generic Syntax" (RFC 2396). FTP --- Example: ftp://joe:blues@myhost.com:21/somefile.txt?passive=true;mode=binary Notes: (1) OPTIONAL 'user' here is 'joe' (2) OPTIONAL 'password' here is 'blues' (3) REQUIRED 'host' here is 'myhost.com' (4) OPTIONAL 'port' here is '21' (the default for FTP) (5) OPTIONAL 'fpath' here is 'somefile.txt' (6) PSI-defined query extension 'passive' here is 'true' (7) PSI-defined query extension 'mode' here is 'binary' (as opposed to 'text') Background: >From section 5 of "Uniform Resource Locators (URL)" (RFC 1738): ftpurl = "ftp://" login [ "/" fpath [ ";type=" ftptype ]] fpath = fsegment *[ "/" fsegment ] fsegment = *[ uchar | "?" | ":" | "@" | "&" | "=" ] ftptype = "A" | "I" | "D" | "a" | "i" | "d" login = [ user [ ":" password ] "@" ] hostport hostport = host [ ":" port ] FILE ---- Example: file://myhost.com/myreference.pdf Notes: (1) OPTIONAL 'host' can be empty of "localhost" (but this is not a safe reference to pass over the network) (2) REQUIRED 'path' MUST specify a specific file Background: >From section 3.10 of "Uniform Resource Locators (URL)" (RFC 1738): The file URL scheme is used to designate files accessible on a particular host computer. This scheme, unlike most other URL schemes, does not designate a resource that is universally accessible over the Internet. A file URL takes the form: file:/// where is the fully qualified domain name of the system on which the is accessible, and is a hierarchical directory path of the form //.../. POP3 ---- Example: pop://joe;auth=@mailhost.com:110 (1) (2) (3) (4) Notes: (1) OPTIONAL 'user' parameter MUST be specified for PSI usage (2) OPTIONAL 'auth' parameter MAY be specified for APOP or SASL info (3) REQUIRED 'host' parameter SHOULD NOT be for PSI usage (4) OPTIONAL 'port' parameter defaults to 110 Background: >From section 3 of "POP URL Scheme", RFC 2384, August 1998: "The POP URL scheme designates a POP server, and optionally a port number, authentication mechanism, authentication ID, and/or authorization ID. The POP URL follows the common Internet scheme syntax as defined in RFC 1738 [BASIC-URL] except that clear text passwords are not permitted. If : is omitted, the port defaults to 110. The POP URL is described using [ABNF] in Section 8. A POP URL is of the general form: pop://;auth=@: Where , , and are as defined in RFC 1738, and some or all of the elements, except "pop://" and , may be omitted." >From section 8 of "POP URL Scheme", RFC 2384, August 1998: "The POP URL scheme is described using [ABNF]: achar = uchar / "&" / "=" / "~" ; see [BASIC-URL] for "uchar" definition auth = ";AUTH=" ( "*" / enc-auth-type ) enc-auth-type = enc-sasl / enc-ext enc-ext = "+" ("APOP" / 1*achar) ;APOP or encoded extension mechanism name enc-sasl = 1*achar ;encoded version of [SASL] "auth_type" enc-user = 1*achar ;encoded version of [POP3] mailbox pop-url = "pop://" server server = [user-auth "@"] hostport ;See [BASIC-URL] for "hostport" definition user-auth = enc-user [auth] IMAP4 ----- Example: >From section 10 of "IMAP URL Scheme", RFC 2192, September 1997: The IMAP URL: Results in the following client commands: C: A001 LOGIN ANONYMOUS sheridan@babylon5.org C: A002 SELECT gray-council C: A003 UID FETCH 20 BODY.PEEK[] Notes: Background: >From section 2 of "IMAP URL Scheme", RFC 2192, September 1997: "The IMAP URL scheme is used to designate IMAP servers, mailboxes, messages, MIME bodies [MIME], and search programs on Internet hosts accessible using the IMAP protocol. The IMAP URL follows the common Internet scheme syntax as defined in RFC 1738 [BASIC-URL] except that clear text passwords are not permitted. If : is omitted, the port defaults to 143. An IMAP URL takes one of the following forms: imap:/// imap:///;TYPE= imap:///[uidvalidity][?] imap:///[uidvalidity][isection] The first form is used to refer to an IMAP server, the second form refers to a list of mailboxes, the third form refers to the contents of a mailbox or a set of messages resulting from a search, and the final form refers to a specific message or message part. Note that the syntax here is informal. The authoritative formal syntax for IMAP URLs is defined in section 11." >From section 12 of "IMAP URL Scheme", RFC 2192, September 1997: "This uses ABNF as defined in RFC 822 [IMAIL]. Terminals from the BNF for IMAP [IMAP4] and URLs [BASIC-URL] are also used. Strings are not case sensitive and free insertion of linear-white-space is not permitted. achar = uchar / "&" / "=" / "~" ; see [BASIC-URL] for "uchar" definition bchar = achar / ":" / "@" / "/" enc_auth_type = 1*achar ; encoded version of [IMAP-AUTH] "auth_type" enc_list_mailbox = 1*bchar ; encoded version of [IMAP4] "list_mailbox" enc_mailbox = 1*bchar ; encoded version of [IMAP4] "mailbox" enc_search = 1*bchar ; encoded version of search_program below enc_section = 1*bchar ; encoded version of section below enc_user = 1*achar ; encoded version of [IMAP4] "userid" imapurl = "imap://" iserver "/" [ icommand ] iauth = ";AUTH=" ( "*" / enc_auth_type ) icommand = imailboxlist / imessagelist / imessagepart imailboxlist = [enc_list_mailbox] ";TYPE=" list_type imessagelist = enc_mailbox [ "?" enc_search ] [uidvalidity] imessagepart = enc_mailbox [uidvalidity] iuid [isection] isection = "/;SECTION=" enc_section iserver = [iuserauth "@"] hostport ; See [BASIC-URL] for "hostport" definition iuid = "/;UID=" nz_number ; See [IMAP4] for "nz_number" definition iuserauth = enc_user [iauth] / [enc_user] iauth list_type = "LIST" / "LSUB" search_program = ["CHARSET" SPACE astring SPACE] search_key *(SPACE search_key) ; IMAP4 literals may not be used ; See [IMAP4] for "astring" and "search_key" section = section_text / (nz_number *["." nz_number] ["." (section_text / "MIME")]) ; See [IMAP4] for "section_text" and "nz_number" uidvalidity = ";UIDVALIDITY=" nz_number ; See [IMAP4] for "nz_number" definition UNC --- Example: pwg-unc:\\myprintserver\myprinter Notes: (1) Proposed new PWG standard URL scheme for UNC encapsulation (2) ALL printable ASCII characters are legal in the UNC, including the BACKSLASH (0x5C) Background: Microsoft uses UNC identifiers in Windows environments. From alan.berkema at hp.com Fri Jan 10 14:13:51 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:08 2009 Subject: PS> [PSI]: Spec contributors Message-ID: <499DC368E25AD411B3F100902740AD650E6AD56A@xrose03.rose.hp.com> Please let me know if you would like you name included as a contributor, if you are not already on the list. Thanks, Alan From alan.berkema at hp.com Fri Jan 10 20:08:41 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:08 2009 Subject: PS> [PSI]: next call 01/14/03 Message-ID: <499DC368E25AD411B3F100902740AD650E6AD57A@xrose03.rose.hp.com> Teleconference details: NEXT: Tuesday January 14 2003 (USA) NO CALL: - Tuesday January 21 NEXT: Tuesday January 28 2003 USA) Time: 8 AM (US PST) Number: 404-774-4112(T774-4112) ID: 55605 Agenda: 1) Discovery - upnp-dev 2) Look at mDNS-SD examples 3) Spec review topics WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 21643883 Meeting Password: newpsi Host: Alan Berkema 1(916)7855605 From dhall at hp.com Mon Jan 13 12:28:23 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:08 2009 Subject: PS> Latest PSI Documents (95a) Message-ID: <77261E830267D411BD4D00902740AC250DB4C466@xvan01.vcd.hp.com> Hi All.. I have them ready, but the FTP server is down! Sorry about blasting the list, but I'm not sure exactly who to notify. As soon as it is up, I will publish documents and re-notify the list. Dave From dhall at hp.com Mon Jan 13 13:47:16 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:08 2009 Subject: PS> 0.95 PSI Specifcation available for Review Message-ID: <77261E830267D411BD4D00902740AC250DB4C46A@xvan01.vcd.hp.com> Hi All.. The 0.95a PSI Specification is available for review at: ftp://ftp.pwg.org/pub/pwg/ps/psi-spec95a.pdf and ftp://ftp.pwg.org/pub/pwg/ps/psi-spec95a.doc This is the specification that we will perform a page-turner at the Jan PWG meeting. Thanks! Dave From dhall at hp.com Tue Jan 14 10:59:40 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:08 2009 Subject: PS> New WebEx Info for 1/14 Message-ID: <77261E830267D411BD4D00902740AC250DB4C47C@xvan01.vcd.hp.com> New meeting info: Meeting ID: 24004938 Password: newpsi Dave From imcdonald at sharplabs.com Tue Jan 14 13:00:10 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:08 2009 Subject: PS> SSL/3.0 and TLS/1.0 details and references Message-ID: <116DB56CD7DED511BC7800508B2CA53735CE80@mailsrvnt02.enet.sharplabs.com> Hi folks, Tuesday (14 January 2003) At today's PSI Telecon, we agreed that a conforming PSI Client, Print Service, or Target Device that claims to support secure operation MUST support either: (a) Netscape SSL 3.0; or (b) IETF TLS 1.0 (version "3.1" over-the-wire). I further propose that a conforming PSI Client, Print Service, or Target Device that claims to support secure operation MUST NOT negotiate down to Netscape SSL 2.0 (to avoid compromised session security). Per my action item from today's PSI Telecon, below are some details from the IETF TLS 1.0 spec (RFC 2246) about fallback to Netscape SSL 3.0. Cheers, - Ira McDonald High North Inc ------------------------------------------------------------------------ References for SSL and TLS specs: [SSL2] Hickman, Kipp, "The SSL Protocol", Netscape Communications Corp., Feb 9, 1995. [SSL3] Frier, Karlton, Kocher, "The SSL 3.0 Protocol", Netscape Communications Corp., Nov 18, 1996. [TLS10] Dierks, Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. - version "3.1" over-the-wire ftp://ftp.isi.edu/in-notes/rfc2246.txt [TLS11] Dierks, Rescorla, "The TLS Protocol Version 1.1", work-in-progress, October 2002. - version "3.2" over-the-wire ftp://ftp.ietf.org/internet-drafts/ draft-ietf-tls-rfc2246-bis-02.txt ------------------------------------------------------------------------ Excerpt from "The TLS Protocol Version 1.0" (RFC 2246, January 1999): E. Backward Compatibility With SSL For historical reasons and in order to avoid a profligate consumption of reserved port numbers, application protocols which are secured by TLS 1.0, SSL 3.0, and SSL 2.0 all frequently share the same connection port: for example, the https protocol (HTTP secured by SSL or TLS) uses port 443 regardless of which security protocol it is using. Thus, some mechanism must be determined to distinguish and negotiate among the various protocols. TLS version 1.0 and SSL 3.0 are very similar; thus, supporting both is easy. TLS clients who wish to negotiate with SSL 3.0 servers should send client hello messages using the SSL 3.0 record format and client hello structure, sending {3, 1} for the version field to note that they support TLS 1.0. If the server supports only SSL 3.0, it will respond with an SSL 3.0 server hello; if it supports TLS, with a TLS server hello. The negotiation then proceeds as appropriate for the negotiated protocol. Similarly, a TLS server which wishes to interoperate with SSL 3.0 clients should accept SSL 3.0 client hello messages and respond with an SSL 3.0 server hello if an SSL 3.0 client hello is received which has a version field of {3, 0}, denoting that this client does not support TLS. Whenever a client already knows the highest protocol known to a server (for example, when resuming a session), it should initiate the connection in that native protocol. TLS 1.0 clients that support SSL Version 2.0 servers must send SSL Version 2.0 client hello messages [SSL2]. TLS servers should accept either client hello format if they wish to support SSL 2.0 clients on the same connection port. The only deviations from the Version 2.0 specification are the ability to specify a version with a value of three and the support for more ciphering types in the CipherSpec. Warning: The ability to send Version 2.0 client hello messages will be phased out with all due haste. Implementors should make every effort to move forward as quickly as possible. Version 3.0 provides better mechanisms for moving to newer versions. The following cipher specifications are carryovers from SSL Version 2.0. These are assumed to use RSA for key exchange and authentication. V2CipherSpec TLS_RC4_128_WITH_MD5 = { 0x01,0x00,0x80 }; V2CipherSpec TLS_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 }; V2CipherSpec TLS_RC2_CBC_128_CBC_WITH_MD5 = { 0x03,0x00,0x80 }; V2CipherSpec TLS_RC2_CBC_128_CBC_EXPORT40_WITH_MD5 = { 0x04,0x00,0x80 }; V2CipherSpec TLS_IDEA_128_CBC_WITH_MD5 = { 0x05,0x00,0x80 }; V2CipherSpec TLS_DES_64_CBC_WITH_MD5 = { 0x06,0x00,0x40 }; V2CipherSpec TLS_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 }; Cipher specifications native to TLS can be included in Version 2.0 client hello messages using the syntax below. Any V2CipherSpec element with its first byte equal to zero will be ignored by Version 2.0 servers. Clients sending any of the above V2CipherSpecs should also include the TLS equivalent (see Appendix A.5): V2CipherSpec (see TLS name) = { 0x00, CipherSuite }; From alan.berkema at hp.com Tue Jan 14 23:22:37 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:08 2009 Subject: PS> [PSI]: minutes 01/14/03 Message-ID: <499DC368E25AD411B3F100902740AD65163FAA7D@xrose03.rose.hp.com> PSI Working Group: *Alan Berkema *Dave Hall Gail Songer Jerry Thasher *Harry Lewis *Ted Tronson *Peter Mierau Peter Zehler Paul Tykodi Bob Taylor Don Levinstone Lee Farrell Don Wright Kirk Ocke *Ira Mcdonald Amir Shahindoust *Alain Regnier * = attendance 01/14/03 Agenda 1) Discovery - upnp-dev 2) Look at mDNS-SD examples 3) Spec review topics 01/14/03 Minutes: 0) Rev 0.95a (candidate for 0.95) was posted on the morning of January 13 2003. This gives us a week to review before the start of the week of PWG F2F meetings. Page turner review at PSI F2F January 24 2003. When reviewing this spec for the F2F please think about practical implementation details such as how many Jobs a Target Device should be able to support concurrently. Ideally, at the F2F we will identify what needs to be fixed to have a last call for comments before we promote the spec to revision 0.95 At 0.95 the spec will be theoretically frozen. Changes to the spec will be conducted via an errata process. One exception is the WSDL itself. The WSDL will evolve through versioning since an errata process does not really make sense for WSDL, we really want an entire latest greatest version of the WSDL which includes all bug fixes. 1) Looked at the upnp-dev from: http://www.upnp.org/download/Printer_Definition_v1_020808.pdfII.pdf The Device Description is described in section 3. We need to define the mandatory fields for both upnp-dev and for LDAPv3. 2) mDNS-Sd examples at F2F 3) What do we need for the HTTPS port? psi-port+1 is no longer being approved by the IESG. A different path is recommended. Dave captured the ideas as proposed changes to psi-spec rev 0.95a (in a separate document). Part of this approach uses an HTTP layer header for security "upgrade" need more details here. ---------------------------- Action: Status from 01/07/03 Action: Send SSDP example to Dave Owner: Alan Status: Done Action: Investigate what needs to be done for UPnP-dev device description via UPnP Print Device documentation. Owner: Alan Status: Done Action: Send latest SLPv2 LDAPv3 examples to Dave Owner: Ira Status: Done Action: Send new proposals for Reference and Target Device by afternoon of 01/09/03 Owner: Ira Status: Done Action: e-mail discussion of state of current tool kit issues Owner: Dave Status: Done Action: Determine if Web Sphere tools have similar limitations Owner: Alan Status: Open >From 01/07/03 General spec discussion: Need some Normative statements on authentication: Discovery? Normative part of spec or developer's guide? I think discovery is what Bluetooth calls "process mandatory" This means that, if a feature (such as a discovery protocol) is used, it is used in the specified manner. Interop events? As soon as we have a few companies that are ready HP will host an event, off cycle from PWG meetings. How many devices do we need? Need interop test criteria such as what features will be supported what discovery is used etc. From alan.berkema at hp.com Thu Jan 16 18:07:41 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:08 2009 Subject: PS> [PSI]: Process Change Proposal Message-ID: <499DC368E25AD411B3F100902740AD650E6AD591@xrose03.rose.hp.com> all, Please see attached for discussion at F2F Mahalo, Alan <> -------------- next part -------------- A non-text attachment was scrubbed... Name: agenda_012403.pdf Type: application/octet-stream Size: 92974 bytes Desc: not available Url : http://www.pwg.org/archives/ps/attachments/20030116/2754c5a8/agenda_012403.obj From imcdonald at sharplabs.com Thu Jan 23 16:22:58 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:08 2009 Subject: PS> RFC 3470 (BCP 70) Guidelines for use of XML in IETF Protocols Message-ID: <116DB56CD7DED511BC7800508B2CA53735CE91@mailsrvnt02.enet.sharplabs.com> Hi folks, Excellent reading. ftp://ftp.isi.edu/in-notes/rfc3470.txt I particularly enjoyed the discussion of XML validation using ISO SGML DTD, W3C XML Schema, and OASIS RELAX-NG in section 4.7. Cheers, - Ira McDonald High North Inc ---------------------------------- [excerpts from RFC 3470] Abstract The Extensible Markup Language (XML) is a framework for structuring data. While it evolved from Standard Generalized Markup Language (SGML) -- a markup language primarily focused on structuring documents -- XML has evolved to be a widely-used mechanism for representing structured data. There are a wide variety of Internet protocols being developed; many have need for a representation for structured data relevant to their application. There has been much interest in the use of XML as a representation method. This document describes basic XML concepts, analyzes various alternatives in the use of XML, and provides guidelines for the use of XML within IETF standards-track protocols. Table of Contents Conventions Used In This Document . . . . . . . . . . . . . . . . 2 1. Introduction and Overview . . . . . . . . . . . . . . . . . 2 1.1 Intended Audience. . . . . . . . . . . . . . . . . . . 3 1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 XML Evolution . . . . . . . . . . . . . . . . . . . . 3 1.4 XML Users, Support Groups, and Additional Information. . . . . . . . . . . . . . . . . . . . . . 4 2. XML Selection Considerations . . . . . . . . . . . . . . . . 4 3. XML Alternatives . . . . . . . . . . . . . . . . . . . . . . 5 4. XML Use Considerations and Recommendations . . . . . . . . . 7 4.1 XML Syntax and Well-Formedness . . . . . . . . . . . . 7 4.2 XML Information Set . . . . . . . . . . . . . . . . . 7 4.3 Syntactic Restrictions . . . . . . . . . . . . . . . . 8 4.4 XML Declarations . . . . . . . . . . . . . . . . . . . 9 4.5 XML Processing Instructions . . . . . . . . . . . . . 9 4.6 XML Comments . . . . . . . . . . . . . . . . . . . . . 10 4.7 Validity and Extensibility . . . . . . . . . . . . . . 10 4.8 Semantics as Well as Syntax. . . . . . . . . . . . . . 12 4.9 Namespaces . . . . . . . . . . . . . . . . . . . . . . 12 4.9.1 Namespaces and Attributes. . . . . . . . . . . . 13 4.10 Element and Attribute Design Considerations. . . . . . 14 4.11 Binary Data and Text with Control Characters . . . . . 16 4.12 Incremental Processing . . . . . . . . . . . . . . . . 16 4.13 Entity Declarations and Entity References . . . . . . 16 4.14 External References . . . . . . . . . . . . . . . . . 17 4.15 URI Processing . . . . . . . . . . . . . . . . . . . . 17 4.16 White Space . . . . . . . . . . . . . . . . . . . . . 18 4.17 Interaction with the IANA . . . . . . . . . . . . . . 19 5. Internationalization Considerations . . . . . . . . . . . . 19 5.1 Character Sets and Encodings . . . . . . . . . . . . . 19 5.2 Language Declaration . . . . . . . . . . . . . . . . . 20 5.3 Other Internationalization Considerations . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21 7. Security Considerations . . . . . . . . . . . . . . . . . . 21 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 9. Normative References . . . . . . . . . . . . . . . . . . . . 22 10. Informative References . . . . . . . . . . . . . . . . . . . 23 11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 27 12. Full Copyright Statement . . . . . . . . . . . . . . . . . . 28 From imcdonald at sharplabs.com Sat Jan 25 14:29:54 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:08 2009 Subject: PS> FW: Secure / Unsecure on one port. Message-ID: <116DB56CD7DED511BC7800508B2CA53735CE96@mailsrvnt02.enet.sharplabs.com> Hi folks, See below for clarification of how a single port works just fine (with HTTP/1.1 or any other session protocol) for upgrade in the same connection to TLS mode (always secure, optionally encrypted). Cheers, - Ira McDonald High North Inc -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Friday, January 24, 2003 4:04 PM To: McDonald, Ira Subject: RE: Secure / Unsecure on one port. Ira, thanks for the response. We just reviewed it at the f2f and switched our position which, earlier today, was 2 ports. OK if I forward your note to the PSI reflector as it captures the topic better than anything I'v seen. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "McDonald, Ira" 01/24/2003 01:22 PM To: Harry Lewis/Boulder/IBM@IBMUS, "McDonald, Ira" cc: Subject: RE: Secure / Unsecure on one port. Hi Harry, Works exactly like shipping 'ipp:' implementations today. You come in on the standard PSI port (e.g., '3700' - some port that is NOT a kernel-mode port less than '1024' decimal) with an HTTP request (e.g., read capabilities of PSI service) and the server replies with '426 Upgrade Required' (see below). The client then MUST initiate the TLS upgrade (see below). The details for all generic HTTP applications are spelled out in the 'standards track' RFC 2817 "Upgrading to TLS Within HTTP/1.1". See section 3 'Client Requested Upgrade to HTTP over TLS' and section 4 'Server Requested Upgrade to HTTP over TLS' and section 5 'Upgrade across Proxies' of RFC 2817. Cheers, - Ira ------------------------------------------ [excerpts from RFC 2817] 1. Motivation The historical practice of deploying HTTP over SSL3 [3] has distinguished the combination from HTTP alone by a unique URI scheme and the TCP port number. The scheme 'http' meant the HTTP protocol alone on port 80, while 'https' meant the HTTP protocol over SSL on port 443. Parallel well-known port numbers have similarly been requested -- and in some cases, granted -- to distinguish between secured and unsecured use of other application protocols (e.g. snews, ftps). This approach effectively halves the number of available well known ports. At the Washington DC IETF meeting in December 1997, the Applications Area Directors and the IESG reaffirmed that the practice of issuing parallel "secure" port numbers should be deprecated. The HTTP/1.1 Upgrade mechanism can apply Transport Layer Security [6] to an open HTTP connection. In the nearly two years since, there has been broad acceptance of the concept behind this proposal, but little interest in implementing alternatives to port 443 for generic Web browsing. In fact, nothing in this memo affects the current interpretation of https: URIs. However, new application protocols built atop HTTP, such as the Internet Printing Protocol [7], call for just such a mechanism in order to move ahead in the IETF standards process. The Upgrade mechanism also solves the "virtual hosting" problem. Rather than allocating multiple IP addresses to a single host, an HTTP/1.1 server will use the Host: header to disambiguate the intended web service. As HTTP/1.1 usage has grown more prevalent, more ISPs are offering name-based virtual hosting, thus delaying IP address space exhaustion. TLS (and SSL) have been hobbled by the same limitation as earlier versions of HTTP: the initial handshake does not specify the intended hostname, relying exclusively on the IP address. Using a cleartext HTTP/1.1 Upgrade: preamble to the TLS handshake -- choosing the certificates based on the initial Host: header -- will allow ISPs to provide secure name-based virtual hosting as well. ... 4.2 Mandatory Advertisement A server MAY indicate that a client request can not be completed without TLS using the "426 Upgrade Required" status code, which MUST include an an Upgrade header field specifying the token of the required TLS version. HTTP/1.1 426 Upgrade Required Upgrade: TLS/1.0, HTTP/1.1 Connection: Upgrade The server SHOULD include a message body in the 426 response which indicates in human readable form the reason for the error and describes any alternative courses which may be available to the user. Note that even if a client is willing to use TLS, it must use the operations in Section 3 to proceed; the TLS handshake cannot begin immediately after the 426 response. -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Friday, January 24, 2003 1:29 PM To: McDonald, Ira Subject: Secure / Unsecure on one port. Ira, we're having difficulty in the f2f discussions with the concept of 1 vs 2 ports for secure and unsecure connections. I recall, in a phone conv, that you described a method for coming in on (port 3700 ex.) unsecure and negotiating, immediately, to secure. Don't think anyone here knows how this works. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- From alan.berkema at hp.com Mon Jan 27 12:29:34 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:08 2009 Subject: PS> [PSI]: ?? next call 01/28/03 Message-ID: <499DC368E25AD411B3F100902740AD650E6AD5B0@xrose03.rose.hp.com> Hey all, This is a place holder for tomorrow's call. I can't get at the web sites to confirm the call info though I think it is still accurate. Seems web access is being affected by that worm thing. I'll update when I can. Also, I may have jury duty :) Thanks, Alan ---- Teleconference details: NEXT: Tuesday January 28 2003 (USA) Time: 8 AM (US PST) Number: 404-774-4112(T774-4112) ID: 55605 Agenda: 1) TBD WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 21643883 Meeting Password: newpsi Host: Alan Berkema 1(916)7855605 From harryl at us.ibm.com Mon Jan 27 16:01:29 2003 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:02:08 2009 Subject: PS> Possible Interop Timeframes Message-ID: I'm getting my constraints in as early as possible into the interop scheduling equation. After returning from Maui and talking with my team we would prefer f2f Inerop dates in the following priority August Late June Early May April We would strongly like to avoid Late May, Early June. Key developers who will participate in interop event will be unavailable. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/ps/attachments/20030127/fc1319d3/attachment.html From alan.berkema at hp.com Mon Jan 27 18:21:39 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:08 2009 Subject: PS> [PSI]:next call 01/28/03 info OK Message-ID: <499DC368E25AD411B3F100902740AD650E6AD5BE@xrose03.rose.hp.com> I'm back on the web info is correct. Just got to worry about jury duty. Alan > > Hey all, > > This is a place holder for tomorrow's call. > I can't get at the web sites to confirm > the call info though I think it is still > accurate. Seems web access is being affected > by that worm thing. I'll update when I can. > > Also, I may have jury duty :) > > Thanks, > Alan > ---- > > Teleconference details: > > NEXT: Tuesday January 28 2003 (USA) > > Time: 8 AM (US PST) > Number: 404-774-4112(T774-4112) > ID: 55605 > > Agenda: > 1) TBD > > WebEx info: > ------------------------- > FIRST TIME USERS > ------------------------- > For fully interactive meetings, including the ability > to present your documents and applications, a one-time > setup takes less than 10 minutes. Click this URL to set up now: > https://hp.webex.com/join/ > Then click New User. > ------------------------- > MEETING SUMMARY > ------------------------- > Name: PSI > Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada > Meeting Number: 21643883 > Meeting Password: newpsi > Host: Alan Berkema > 1(916)7855605 > From dhall at hp.com Mon Jan 27 18:31:23 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:08 2009 Subject: PS> Tomorrow's PSI Meeting Agenda Message-ID: <77261E830267D411BD4D00902740AC250DB4C66C@xvan01.vcd.hp.com> Hey All.. I would like to review the following two things at tomorrows conference call. We missed reviewing them on Friday... Thanks! Dave Section 6.1 TargetDeviceIdentifier - Change the introductory paragraph to be: The Target Device Identifier allows for Clients to specify legacy Target Devices as well as new PSI capable Target Devices. It is up to the Print Service to provide the proxy support for that legacy device if it so chooses. The TargetDeviceIdentifier is specified by a URL. The client is allowed to specify any existing, or yet to be defined URL schemes that refer to a potential Target Device. Below is a list of existing URL schemes that should be taken into consideration when implementing a Print Service. A Print Service must support the PSI Service Root URL Target Device Identifier. <-- do we need a statement to this effect? Section 6.1.4: Should be named psiServiceRootURL Examples: pwg-psips://MyPsiServiceTarget.mydomain.com:psi-port/psi/ pwg-psitd://MyPsiTargetDeviceTarget.mydomain.com:psi-port/psi/ Notes: (1) REQUIRED 'host' or 'ip-addr' MUST be specified (2) REQUIRED 'port' MUST default to PWG PSI IANA-assigned value (example assumes port 'psi-port') If a Print Services whishes to expose a proxy PSI TargetDevice for a legacy Target Device, it may do so by adding appropriate query parameters to the psiServiceRootURL which would allow the Print Service to identify that the client has discovered, and is wishing to utilize the legacy Target Device. This query parameter is: * LegacyTargetDeviceID Example: pwg-psitd://mypsitarget.mydomain.com:psi-port/psi/?LegacyTargetDevi ceID=132452523 From alan.berkema at hp.com Fri Jan 31 13:44:18 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:08 2009 Subject: PS> [PSI]: next call 02/04/03 Message-ID: <499DC368E25AD411B3F100902740AD650E6AD5FE@xrose03.rose.hp.com> Teleconference details: NEXT: Tuesday February 04 2003 (USA) Time: 8 AM (US PST) Number: 404-774-4112(T774-4112) ID: 55605 Agenda: 1) TBD WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 21643883 Meeting Password: newpsi Host: Alan Berkema 1(916)7855605 From imcdonald at sharplabs.com Mon Feb 3 19:43:58 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:08 2009 Subject: PS> [PSI]: next call 02/04/03 [versions] Message-ID: <116DB56CD7DED511BC7800508B2CA53735CEA6@mailsrvnt02.enet.sharplabs.com> Hi Alan, An obvious agenda topic is a discussion of: (a) concrete protocol versions over-the-wire (in protocol operations and envelopes) (b) concrete WSDL interface versions (in URLs of component schemas) (c) abstract protocol spec versions (on cover pages and in the URLs of spec documents) See Dave Hall's note today on the pwg@pwg.org mailing list. Cheers, - Ira McDonald High North Inc -----Original Message----- From: BERKEMA,ALAN C (HP-Roseville,ex1) [mailto:alan.berkema@hp.com] Sent: Friday, January 31, 2003 12:44 PM To: 'a PSI pwg.org' Subject: PS> [PSI]: next call 02/04/03 Teleconference details: NEXT: Tuesday February 04 2003 (USA) Time: 8 AM (US PST) Number: 404-774-4112(T774-4112) ID: 55605 Agenda: 1) TBD WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 21643883 Meeting Password: newpsi Host: Alan Berkema 1(916)7855605 From dhall at hp.com Tue Feb 4 10:50:09 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:08 2009 Subject: PS> PSI WebEx Info and Versioning Discussion Material Message-ID: <77261E830267D411BD4D00902740AC250DB4C779@xvan01.vcd.hp.com> ------------------------- MEETING SUMMARY ------------------------- Name: psi Date: 2/4/2003 Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 21865515 Meeting Password: newpsi Things we need to track: Specification Document Version - (IPP 1.0, IPP 1.1, PSI 1.0, PSI 1.1, etc) Specification Document Revision - (Date?) Specification Goodness - (3 states, with ability to differentiate a document that has just been published from one that has been accepted) - States: (a) Draft, (b) Proposal, (c) Standard - Acceptance: (1) Working, (2) Accepted Individual Interface Version - (0.01 - 0.99, 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.1.0, 1.1.1, 1.1.2, etc) Individual Interface Revision - (1, 2, 3, 4, 5...) Individual Interface Namespace - (?) Schema Revision - (0.01 - 0.99, 1.0.0, 1.0.1, 1.0.2, etc) Schema Namespace - (?) Requirements: Published WSDL and Schema needs to remain accessible. A Specification Document should be able to refer to different Interface Revisions. (i.e. 1.1 of the PSI Specification should be able to reference QueryEndPointsInterface v1.0.5 if we don't need to change it for 1.1) Reference: Versioning Everyone who developed COM applications: How many of you remember the golden rules of versioning? Okay, hands down. As a quick review, here are the rules: 1. Always increment the version number. 2. Freeze the interface on the previous version. All new features should go into a new interface. 3. Freeze all structures used on the previous version. Any enhancements to those structures should show up in new structures. WSDL version indication is done via the targetNamespace attribute of the definitions element. This namespace gives the SOAP messages meaning by relating the messages to a specific bit of code implemented somewhere on the server. The targetNamespace attribute has an XSD type of anyURI. This attribute could be used in a large number of ways to indicate the version. For a service named Foo that was hosted at msdn.microsoft.com, a few options exist for the first version. Option 1: The targetNamespace could be named http://msdn.microsoft.com/foo. This works by giving the interface a unique namespace name. This option does not fit our needs, however, because it does not include an obvious mechanism for indicating whether one version is earlier or later than another. I suppose you could follow up later versions of the interface with namespaces such as http://msdn.microsoft.com/foo1 and http://msdn.microsoft.com/foo2, but that seems silly. Option 2: The targetNamespace could be named http://msdn.microsoft.com/1.0/foo. Again, this gives the interface a unique namespace identifier. This option fits our needs, because it gives us an obvious indicator of version as well as a place to increment that version in a way people are used to seeing. As we are dealing with an XML-centric world, however, we might do well to follow the lead of the newer XML specifications, such as SOAP 1.2, XML Schema, and XSLT. While this option is viable, it does not follow this lead. Option 3: Call the targetNamespace http://msdn.microsoft.com/2002/04/foo. This has a few small advantages over option 2. For one, this is the versioning scheme employed by the newer XML specifications. People who are used to looking at XML will find versioning by date more familiar. As an added bonus, versioning by date allows a person or machine to easily figure out when the version was released. You can increase the resolution of the version to reflect the frequency of releases. A resolution down to the hour would indicate that releases are coming out far too frequently. If your team does nightly builds, extend the interim granularity of the version to the date of the build. Regardless of what you do, don't be cute and use zero-based month and day-of-month numbers. It's counterintuitive. Of the above options, both 2 and 3 fit the bill, with 3 being the versioning option that many XML users I have talked to like the best. An added advantage of date-based versioning is that you will know how long the interface has been available. When changing an XSD type, create a brand new type in a brand new namespace. This new namespace should still stick with your versioning model. If the first version was in a namespace such as http://foo.org/bar/2001/11/20/types, the new namespace should only change the date information. That new type, if published on April 5, 2002, should be in the namespace http://foo.org/bar/2002/04/05/types. Any related sub-types should remain in the old namespace and simply get imported into the new one. Here, no wishy-washy answers. To sum things up, here are the guidelines to use when updating an interface: * The changes always go into a new namespace. * The new interface should be a superset of the old one. * It is a good idea to keep the data model the same when versioning the interface. * Never revise data structures. Instead, add new ones as needed. From imcdonald at sharplabs.com Tue Feb 4 10:56:26 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:08 2009 Subject: PS> PSI WebEx Info and Versioning Discussion Material Message-ID: <116DB56CD7DED511BC7800508B2CA53735CEA8@mailsrvnt02.enet.sharplabs.com> Hi Dave, You've just shown an example of why I urged that we reduce the PWG 'standards track' to two states last Thursday. The IETF (and current PWG) 'standards track' states are: (a) Proposed (b) Draft (c) Standard. The overloading of 'draft' in both Working-Draft and the MIDDLE state of the 'standards track' is a bad problem. Also, the IETF actually VERY rarely advances a document all the way to 'Standard'. Mostly, they struggle to get to 'Draft Standard'. Cheers, - Ira McDonald High North Inc -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Tuesday, February 04, 2003 9:50 AM To: 'ps@pwg.org' Subject: PS> PSI WebEx Info and Versioning Discussion Material ------------------------- MEETING SUMMARY ------------------------- Name: psi Date: 2/4/2003 Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 21865515 Meeting Password: newpsi Things we need to track: Specification Document Version - (IPP 1.0, IPP 1.1, PSI 1.0, PSI 1.1, etc) Specification Document Revision - (Date?) Specification Goodness - (3 states, with ability to differentiate a document that has just been published from one that has been accepted) - States: (a) Draft, (b) Proposal, (c) Standard - Acceptance: (1) Working, (2) Accepted Individual Interface Version - (0.01 - 0.99, 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.1.0, 1.1.1, 1.1.2, etc) Individual Interface Revision - (1, 2, 3, 4, 5...) Individual Interface Namespace - (?) Schema Revision - (0.01 - 0.99, 1.0.0, 1.0.1, 1.0.2, etc) Schema Namespace - (?) Requirements: Published WSDL and Schema needs to remain accessible. A Specification Document should be able to refer to different Interface Revisions. (i.e. 1.1 of the PSI Specification should be able to reference QueryEndPointsInterface v1.0.5 if we don't need to change it for 1.1) Reference: Versioning Everyone who developed COM applications: How many of you remember the golden rules of versioning? Okay, hands down. As a quick review, here are the rules: 1. Always increment the version number. 2. Freeze the interface on the previous version. All new features should go into a new interface. 3. Freeze all structures used on the previous version. Any enhancements to those structures should show up in new structures. WSDL version indication is done via the targetNamespace attribute of the definitions element. This namespace gives the SOAP messages meaning by relating the messages to a specific bit of code implemented somewhere on the server. The targetNamespace attribute has an XSD type of anyURI. This attribute could be used in a large number of ways to indicate the version. For a service named Foo that was hosted at msdn.microsoft.com, a few options exist for the first version. Option 1: The targetNamespace could be named http://msdn.microsoft.com/foo. This works by giving the interface a unique namespace name. This option does not fit our needs, however, because it does not include an obvious mechanism for indicating whether one version is earlier or later than another. I suppose you could follow up later versions of the interface with namespaces such as http://msdn.microsoft.com/foo1 and http://msdn.microsoft.com/foo2, but that seems silly. Option 2: The targetNamespace could be named http://msdn.microsoft.com/1.0/foo. Again, this gives the interface a unique namespace identifier. This option fits our needs, because it gives us an obvious indicator of version as well as a place to increment that version in a way people are used to seeing. As we are dealing with an XML-centric world, however, we might do well to follow the lead of the newer XML specifications, such as SOAP 1.2, XML Schema, and XSLT. While this option is viable, it does not follow this lead. Option 3: Call the targetNamespace http://msdn.microsoft.com/2002/04/foo. This has a few small advantages over option 2. For one, this is the versioning scheme employed by the newer XML specifications. People who are used to looking at XML will find versioning by date more familiar. As an added bonus, versioning by date allows a person or machine to easily figure out when the version was released. You can increase the resolution of the version to reflect the frequency of releases. A resolution down to the hour would indicate that releases are coming out far too frequently. If your team does nightly builds, extend the interim granularity of the version to the date of the build. Regardless of what you do, don't be cute and use zero-based month and day-of-month numbers. It's counterintuitive. Of the above options, both 2 and 3 fit the bill, with 3 being the versioning option that many XML users I have talked to like the best. An added advantage of date-based versioning is that you will know how long the interface has been available. When changing an XSD type, create a brand new type in a brand new namespace. This new namespace should still stick with your versioning model. If the first version was in a namespace such as http://foo.org/bar/2001/11/20/types, the new namespace should only change the date information. That new type, if published on April 5, 2002, should be in the namespace http://foo.org/bar/2002/04/05/types. Any related sub-types should remain in the old namespace and simply get imported into the new one. Here, no wishy-washy answers. To sum things up, here are the guidelines to use when updating an interface: * The changes always go into a new namespace. * The new interface should be a superset of the old one. * It is a good idea to keep the data model the same when versioning the interface. * Never revise data structures. Instead, add new ones as needed. From don at lexmark.com Tue Feb 4 11:19:26 2003 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:02:08 2009 Subject: PS> PSI WebEx Info and Versioning Discussion Material Message-ID: Gee, I wonder if a "Working Draft" is different from a "Draft Standard" ??????? Of course, I have trouble telling a "Surf Board" from a "School Board" because they both have the word "Board" in them. Maybe it's just me. Perhaps if we skip the short cuts and called a working draft a working draft (and not a draft) we wouldn't have this confusion. ********************************************** Don Wright don@lexmark.com Chair, IEEE SA Standards Board Member, IEEE-ISTO Board of Directors f.wright@ieee.org / f.wright@computer.org Director, Alliances & Standards Lexmark International 740 New Circle Rd Lexington, Ky 40550 859-825-4808 (phone) 603-963-8352 (fax) ********************************************** "McDonald, Ira" @pwg.org on 02/04/2003 10:56:26 AM Sent by: owner-ps@pwg.org To: "'HALL,DAVID (HP-Vancouver,ex1)'" , "'ps@pwg.org'" cc: Subject: RE: PS> PSI WebEx Info and Versioning Discussion Material Hi Dave, You've just shown an example of why I urged that we reduce the PWG 'standards track' to two states last Thursday. The IETF (and current PWG) 'standards track' states are: (a) Proposed (b) Draft (c) Standard. The overloading of 'draft' in both Working-Draft and the MIDDLE state of the 'standards track' is a bad problem. Also, the IETF actually VERY rarely advances a document all the way to 'Standard'. Mostly, they struggle to get to 'Draft Standard'. Cheers, - Ira McDonald High North Inc -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Tuesday, February 04, 2003 9:50 AM To: 'ps@pwg.org' Subject: PS> PSI WebEx Info and Versioning Discussion Material ------------------------- MEETING SUMMARY ------------------------- Name: psi Date: 2/4/2003 Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 21865515 Meeting Password: newpsi Things we need to track: Specification Document Version - (IPP 1.0, IPP 1.1, PSI 1.0, PSI 1.1, etc) Specification Document Revision - (Date?) Specification Goodness - (3 states, with ability to differentiate a document that has just been published from one that has been accepted) - States: (a) Draft, (b) Proposal, (c) Standard - Acceptance: (1) Working, (2) Accepted Individual Interface Version - (0.01 - 0.99, 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.1.0, 1.1.1, 1.1.2, etc) Individual Interface Revision - (1, 2, 3, 4, 5...) Individual Interface Namespace - (?) Schema Revision - (0.01 - 0.99, 1.0.0, 1.0.1, 1.0.2, etc) Schema Namespace - (?) Requirements: Published WSDL and Schema needs to remain accessible. A Specification Document should be able to refer to different Interface Revisions. (i.e. 1.1 of the PSI Specification should be able to reference QueryEndPointsInterface v1.0.5 if we don't need to change it for 1.1) Reference: < http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnservice/ html/service04032002.asp> Versioning Everyone who developed COM applications: How many of you remember the golden rules of versioning? Okay, hands down. As a quick review, here are the rules: 1. Always increment the version number. 2. Freeze the interface on the previous version. All new features should go into a new interface. 3. Freeze all structures used on the previous version. Any enhancements to those structures should show up in new structures. WSDL version indication is done via the targetNamespace attribute of the definitions element. This namespace gives the SOAP messages meaning by relating the messages to a specific bit of code implemented somewhere on the server. The targetNamespace attribute has an XSD type of anyURI. This attribute could be used in a large number of ways to indicate the version. For a service named Foo that was hosted at msdn.microsoft.com, a few options exist for the first version. Option 1: The targetNamespace could be named http://msdn.microsoft.com/foo. This works by giving the interface a unique namespace name. This option does not fit our needs, however, because it does not include an obvious mechanism for indicating whether one version is earlier or later than another. I suppose you could follow up later versions of the interface with namespaces such as http://msdn.microsoft.com/foo1 and http://msdn.microsoft.com/foo2, but that seems silly. Option 2: The targetNamespace could be named http://msdn.microsoft.com/1.0/foo. Again, this gives the interface a unique namespace identifier. This option fits our needs, because it gives us an obvious indicator of version as well as a place to increment that version in a way people are used to seeing. As we are dealing with an XML-centric world, however, we might do well to follow the lead of the newer XML specifications, such as SOAP 1.2, XML Schema, and XSLT. While this option is viable, it does not follow this lead. Option 3: Call the targetNamespace http://msdn.microsoft.com/2002/04/foo. This has a few small advantages over option 2. For one, this is the versioning scheme employed by the newer XML specifications. People who are used to looking at XML will find versioning by date more familiar. As an added bonus, versioning by date allows a person or machine to easily figure out when the version was released. You can increase the resolution of the version to reflect the frequency of releases. A resolution down to the hour would indicate that releases are coming out far too frequently. If your team does nightly builds, extend the interim granularity of the version to the date of the build. Regardless of what you do, don't be cute and use zero-based month and day-of-month numbers. It's counterintuitive. Of the above options, both 2 and 3 fit the bill, with 3 being the versioning option that many XML users I have talked to like the best. An added advantage of date-based versioning is that you will know how long the interface has been available. When changing an XSD type, create a brand new type in a brand new namespace. This new namespace should still stick with your versioning model. If the first version was in a namespace such as http://foo.org/bar/2001/11/20/types, the new namespace should only change the date information. That new type, if published on April 5, 2002, should be in the namespace http://foo.org/bar/2002/04/05/types. Any related sub-types should remain in the old namespace and simply get imported into the new one. Here, no wishy-washy answers. To sum things up, here are the guidelines to use when updating an interface: * The changes always go into a new namespace. * The new interface should be a superset of the old one. * It is a good idea to keep the data model the same when versioning the interface. * Never revise data structures. Instead, add new ones as needed. From dhall at hp.com Tue Feb 4 13:06:32 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:08 2009 Subject: PS> PSI WebEx Info and Versioning Discussion Material Message-ID: <77261E830267D411BD4D00902740AC250DB4C783@xvan01.vcd.hp.com> Hehehe.. :) Actually, that is were we ended up... Working Draft, Candidate Standard, Standard... Look for a document shortly that describes this in detail.. Dave -----Original Message----- From: don@lexmark.com [mailto:don@lexmark.com] Sent: Tuesday, February 04, 2003 8:19 AM To: McDonald, Ira Cc: 'HALL,DAVID (HP-Vancouver,ex1)'; 'ps@pwg.org' Subject: RE: PS> PSI WebEx Info and Versioning Discussion Material Gee, I wonder if a "Working Draft" is different from a "Draft Standard" ??????? Of course, I have trouble telling a "Surf Board" from a "School Board" because they both have the word "Board" in them. Maybe it's just me. Perhaps if we skip the short cuts and called a working draft a working draft (and not a draft) we wouldn't have this confusion. ********************************************** Don Wright don@lexmark.com Chair, IEEE SA Standards Board Member, IEEE-ISTO Board of Directors f.wright@ieee.org / f.wright@computer.org Director, Alliances & Standards Lexmark International 740 New Circle Rd Lexington, Ky 40550 859-825-4808 (phone) 603-963-8352 (fax) ********************************************** "McDonald, Ira" @pwg.org on 02/04/2003 10:56:26 AM Sent by: owner-ps@pwg.org To: "'HALL,DAVID (HP-Vancouver,ex1)'" , "'ps@pwg.org'" cc: Subject: RE: PS> PSI WebEx Info and Versioning Discussion Material Hi Dave, You've just shown an example of why I urged that we reduce the PWG 'standards track' to two states last Thursday. The IETF (and current PWG) 'standards track' states are: (a) Proposed (b) Draft (c) Standard. The overloading of 'draft' in both Working-Draft and the MIDDLE state of the 'standards track' is a bad problem. Also, the IETF actually VERY rarely advances a document all the way to 'Standard'. Mostly, they struggle to get to 'Draft Standard'. Cheers, - Ira McDonald High North Inc -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Tuesday, February 04, 2003 9:50 AM To: 'ps@pwg.org' Subject: PS> PSI WebEx Info and Versioning Discussion Material ------------------------- MEETING SUMMARY ------------------------- Name: psi Date: 2/4/2003 Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 21865515 Meeting Password: newpsi Things we need to track: Specification Document Version - (IPP 1.0, IPP 1.1, PSI 1.0, PSI 1.1, etc) Specification Document Revision - (Date?) Specification Goodness - (3 states, with ability to differentiate a document that has just been published from one that has been accepted) - States: (a) Draft, (b) Proposal, (c) Standard - Acceptance: (1) Working, (2) Accepted Individual Interface Version - (0.01 - 0.99, 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.1.0, 1.1.1, 1.1.2, etc) Individual Interface Revision - (1, 2, 3, 4, 5...) Individual Interface Namespace - (?) Schema Revision - (0.01 - 0.99, 1.0.0, 1.0.1, 1.0.2, etc) Schema Namespace - (?) Requirements: Published WSDL and Schema needs to remain accessible. A Specification Document should be able to refer to different Interface Revisions. (i.e. 1.1 of the PSI Specification should be able to reference QueryEndPointsInterface v1.0.5 if we don't need to change it for 1.1) Reference: < http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnservice/ html/service04032002.asp> Versioning Everyone who developed COM applications: How many of you remember the golden rules of versioning? Okay, hands down. As a quick review, here are the rules: 1. Always increment the version number. 2. Freeze the interface on the previous version. All new features should go into a new interface. 3. Freeze all structures used on the previous version. Any enhancements to those structures should show up in new structures. WSDL version indication is done via the targetNamespace attribute of the definitions element. This namespace gives the SOAP messages meaning by relating the messages to a specific bit of code implemented somewhere on the server. The targetNamespace attribute has an XSD type of anyURI. This attribute could be used in a large number of ways to indicate the version. For a service named Foo that was hosted at msdn.microsoft.com, a few options exist for the first version. Option 1: The targetNamespace could be named http://msdn.microsoft.com/foo. This works by giving the interface a unique namespace name. This option does not fit our needs, however, because it does not include an obvious mechanism for indicating whether one version is earlier or later than another. I suppose you could follow up later versions of the interface with namespaces such as http://msdn.microsoft.com/foo1 and http://msdn.microsoft.com/foo2, but that seems silly. Option 2: The targetNamespace could be named http://msdn.microsoft.com/1.0/foo. Again, this gives the interface a unique namespace identifier. This option fits our needs, because it gives us an obvious indicator of version as well as a place to increment that version in a way people are used to seeing. As we are dealing with an XML-centric world, however, we might do well to follow the lead of the newer XML specifications, such as SOAP 1.2, XML Schema, and XSLT. While this option is viable, it does not follow this lead. Option 3: Call the targetNamespace http://msdn.microsoft.com/2002/04/foo. This has a few small advantages over option 2. For one, this is the versioning scheme employed by the newer XML specifications. People who are used to looking at XML will find versioning by date more familiar. As an added bonus, versioning by date allows a person or machine to easily figure out when the version was released. You can increase the resolution of the version to reflect the frequency of releases. A resolution down to the hour would indicate that releases are coming out far too frequently. If your team does nightly builds, extend the interim granularity of the version to the date of the build. Regardless of what you do, don't be cute and use zero-based month and day-of-month numbers. It's counterintuitive. Of the above options, both 2 and 3 fit the bill, with 3 being the versioning option that many XML users I have talked to like the best. An added advantage of date-based versioning is that you will know how long the interface has been available. When changing an XSD type, create a brand new type in a brand new namespace. This new namespace should still stick with your versioning model. If the first version was in a namespace such as http://foo.org/bar/2001/11/20/types, the new namespace should only change the date information. That new type, if published on April 5, 2002, should be in the namespace http://foo.org/bar/2002/04/05/types. Any related sub-types should remain in the old namespace and simply get imported into the new one. Here, no wishy-washy answers. To sum things up, here are the guidelines to use when updating an interface: * The changes always go into a new namespace. * The new interface should be a superset of the old one. * It is a good idea to keep the data model the same when versioning the interface. * Never revise data structures. Instead, add new ones as needed. From rseeler at adobe.com Tue Feb 4 13:13:11 2003 From: rseeler at adobe.com (Rick Seeler) Date: Wed May 6 14:02:08 2009 Subject: PS> PSI WebEx Info and Versioning Discussion Material In-Reply-To: <77261E830267D411BD4D00902740AC250DB4C783@xvan01.vcd.hp.com> Message-ID: <003701c2cc79$13e09670$21972099@rseeler1> So, you're saying we have a working draft of a proposal for a standard for proposing working drafts, proposals, and standards? ;-) -Rick > -----Original Message----- > From: owner-ps@pwg.org [mailto:owner-ps@pwg.org] On Behalf Of > HALL,DAVID (HP-Vancouver,ex1) > Sent: Tuesday, February 04, 2003 10:07 AM > To: 'don@lexmark.com'; McDonald, Ira > Cc: HALL,DAVID (HP-Vancouver,ex1); 'ps@pwg.org' > Subject: RE: PS> PSI WebEx Info and Versioning Discussion Material > > > Hehehe.. :) > > Actually, that is were we ended up... > > Working Draft, Candidate Standard, Standard... > > Look for a document shortly that describes this in detail.. > > Dave > > -----Original Message----- > From: don@lexmark.com [mailto:don@lexmark.com] > Sent: Tuesday, February 04, 2003 8:19 AM > To: McDonald, Ira > Cc: 'HALL,DAVID (HP-Vancouver,ex1)'; 'ps@pwg.org' > Subject: RE: PS> PSI WebEx Info and Versioning Discussion Material > > > > > Gee, I wonder if a "Working Draft" is different from a "Draft > Standard" ??????? > > Of course, I have trouble telling a "Surf Board" from a > "School Board" because they both have the word "Board" in them. > > Maybe it's just me. > > > > Perhaps if we skip the short cuts and called a working draft > a working draft (and not a draft) we wouldn't have this confusion. > > ********************************************** > Don Wright don@lexmark.com > > Chair, IEEE SA Standards Board > Member, IEEE-ISTO Board of Directors > f.wright@ieee.org / f.wright@computer.org > > Director, Alliances & Standards > Lexmark International > 740 New Circle Rd > Lexington, Ky 40550 > 859-825-4808 (phone) 603-963-8352 (fax) > ********************************************** > > > > > "McDonald, Ira" @pwg.org on > 02/04/2003 10:56:26 AM > > Sent by: owner-ps@pwg.org > > > To: "'HALL,DAVID (HP-Vancouver,ex1)'" , > "'ps@pwg.org'" > > cc: > Subject: RE: PS> PSI WebEx Info and Versioning Discussion Material > > > Hi Dave, > > You've just shown an example of why I urged that we reduce > the PWG 'standards track' to two states last Thursday. > > The IETF (and current PWG) 'standards track' states are: > (a) Proposed (b) Draft (c) Standard. > > The overloading of 'draft' in both Working-Draft and the > MIDDLE state of the 'standards track' is a bad problem. > > Also, the IETF actually VERY rarely advances a document > all the way to 'Standard'. Mostly, they struggle to > get to 'Draft Standard'. > > Cheers, > - Ira McDonald > High North Inc > > > -----Original Message----- > From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] > Sent: Tuesday, February 04, 2003 9:50 AM > To: 'ps@pwg.org' > Subject: PS> PSI WebEx Info and Versioning Discussion Material > > > ------------------------- > MEETING SUMMARY > ------------------------- > Name: psi > Date: 2/4/2003 > Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada > Meeting Number: 21865515 > Meeting Password: newpsi > > > Things we need to track: > > Specification Document Version - (IPP 1.0, IPP 1.1, PSI 1.0, > PSI 1.1, etc) Specification Document Revision - (Date?) > Specification Goodness - (3 states, with ability to > differentiate a document that has just been published from > one that has been accepted) > - States: (a) Draft, (b) Proposal, (c) Standard > - Acceptance: (1) Working, (2) Accepted > Individual Interface Version - (0.01 - 0.99, 1.0.0, 1.0.1, > 1.0.2, 1.0.3, 1.1.0, 1.1.1, 1.1.2, etc) Individual Interface > Revision - (1, 2, 3, 4, 5...) Individual Interface Namespace > - (?) Schema Revision - (0.01 - 0.99, 1.0.0, 1.0.1, 1.0.2, > etc) Schema Namespace - (?) > > Requirements: > Published WSDL and Schema needs to remain accessible. > A Specification Document should be able to refer to different > Interface Revisions. (i.e. 1.1 of the PSI Specification > should be able to reference QueryEndPointsInterface v1.0.5 if > we don't need to change it for 1.1) > > Reference: > < > http://msdn.microsoft.com/library/default.asp?url=/library/en- > us/dnservice/ > html/service04032002.asp> > > Versioning > Everyone who developed COM applications: How many of you > remember the golden rules of versioning? Okay, hands down. As > a quick review, here are the > rules: > 1. Always increment the version number. > 2. Freeze the interface on the previous version. All new features > should go into a new interface. > 3. Freeze all structures used on the previous version. Any > enhancements > to those structures should show up in new structures. > WSDL version indication is done via the targetNamespace > attribute of the definitions element. This namespace gives > the SOAP messages meaning by relating the messages to a > specific bit of code implemented somewhere on the server. The > targetNamespace attribute has an XSD type of anyURI. This > attribute could be used in a large number of ways to indicate > the version. For a service named Foo that was hosted at > msdn.microsoft.com, a few options exist for the first > version. Option 1: The targetNamespace could be named > http://msdn.microsoft.com/foo. This works by giving the > interface a unique namespace name. This option does not fit > our needs, however, because it does not include an obvious > mechanism for indicating whether one version is earlier or > later than another. I suppose you could follow up later > versions of the interface with namespaces such as > http://msdn.microsoft.com/foo1 and > http://msdn.microsoft.com/foo2, but that seems silly. Option > 2: The targetNamespace could be named > http://msdn.microsoft.com/1.0/foo. > Again, > this gives the interface a unique namespace identifier. This > option fits our needs, because it gives us an obvious > indicator of version as well as a place to increment that > version in a way people are used to seeing. As we are dealing > with an XML-centric world, however, we might do well to > follow the lead of the newer XML specifications, such as SOAP > 1.2, XML Schema, and XSLT. While this option is viable, it > does not follow this lead. Option 3: Call the targetNamespace > http://msdn.microsoft.com/2002/04/foo. > This has a few small > advantages over option 2. For one, this is the versioning > scheme employed by the newer XML specifications. People who > are used to looking at XML will find versioning by date more > familiar. As an added bonus, versioning by date allows a > person or machine to easily figure out when the version was > released. You can increase the resolution of the version to > reflect the frequency of releases. A resolution down to the > hour would indicate that releases are coming out far too > frequently. If your team does nightly builds, extend the > interim granularity of the version to the date of the build. > Regardless of what you do, don't be cute and use zero-based > month and day-of-month numbers. It's counterintuitive. Of the > above options, both 2 and 3 fit the bill, with 3 being the > versioning option that many XML users I have talked to like > the best. An added advantage of date-based versioning is that > you will know how long the interface has been available. When > changing an XSD type, create a brand new type in a brand new > namespace. This new namespace should still stick with your > versioning model. If the first version was in a namespace > such as http://foo.org/bar/2001/11/20/types, the new > namespace should only change the date information. That new > type, if published on April 5, 2002, should be in the > namespace http://foo.org/bar/2002/04/05/types. Any related > sub-types should remain in the old namespace and simply get > imported into the new one. Here, no wishy-washy answers. To > sum things up, here are the guidelines to use when updating an > interface: > > * The changes always go into a new namespace. > * The new interface should be a superset of the old one. > * It is a good idea to keep the data model the same when > versioning > the interface. > * Never revise data structures. Instead, add new ones as needed. > > > > From alan.berkema at hp.com Fri Feb 7 17:07:31 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:08 2009 Subject: PS> [PSI]: next call 02/11/03 Message-ID: <499DC368E25AD411B3F100902740AD650E6AD63E@xrose03.rose.hp.com> Teleconference details: NEXT: Tuesday February 11 2003 (USA) Time: 8 AM (US PST) Number: 650-690-9367(T348-9367) ID: 55605 Agenda: 1) Status code alignment with semantic model 2) New Go Get Print Job Method ideas? Used with Firewall use model when client initiates a print job to a Print Service and then the printer must get the Print Job. Previously this was called "out of band" or Ira's "and then a miracle happens " Dave Hall will send Webex info since I may not have web access, also chance that I will have trouble calling in. Thanks, Alan WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 21643883 Meeting Password: newpsi Host: Alan Berkema 1(916)7855605 From imcdonald at sharplabs.com Mon Feb 10 12:15:54 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:08 2009 Subject: PS> FW: [relax-ng] Topologi Collaborative Markup Editor version 1.1.1 Message-ID: <116DB56CD7DED511BC7800508B2CA53735CEBE@mailsrvnt02.enet.sharplabs.com> Hi folks, Note the XML interactive editing and many schema/DTD validation features of this XML/HTML collaborative editor. Cheers, - Ira McDonald High North Inc -----Original Message----- From: Rick Jelliffe [mailto:ricko@topologi.com] Sent: Monday, February 10, 2003 10:50 AM To: relax-ng-comment@lists.oasis-open.org Subject: [relax-ng-comment] ANN: Topologi Collaborative Markup Editor version 1.1.1 I am happy to announce the release of the latest version of Topologi's Collaborative Markup Editor. Visit http://www.topologi.com/ The editor has been designed to address many of the issues that other editors ignore: * special tools for marking up non-WF document fast and productively * special tools for manipulating whitespace and breaks * immediate feedback on XML syntax makes the editor good for training * immediate feedback on regular expression syntax helps tame even complicated search patterns * documents up to 8 meg * open and start editing any document immediately: does not require configuration * fast search and replace: what one famous competitor takes 16 minutes to do, we take 8 seconds! * extra help for Unicode and encoding problems * clean-up HTML with bundled Tidy * Schematron, RELAX NG, WXS, XML DTD and SGML DTD validation * read and and write to ZIP files * view and sort all validation results * built-in peer-to-peer networking helps teamwork: workers can exchange and annotate screenshots, send messages, and view each other's directory diaries Version 1.1.1 adds support for RELAX NG compact syntax and Examplotron schemas, upgrades some libraries, and has some fixes. The editor has introductory pricing of $59-95 for unsupported individual licenses, and $5,000 for supported-site licenses. A free 30-day evaluation version is available. A free license is available for use in training courses and for charities. The Windows version of 1.1.1 is online now. Versions for other platforms will appear in the next few days. Cheers Rick Jelliffe Topologi Pty. Ltd. ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: From dhall at hp.com Mon Feb 10 15:20:01 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:08 2009 Subject: PS> WebEx Info for 2/11/03 Message-ID: <77261E830267D411BD4D00902740AC250DB4C7EF@xvan01.vcd.hp.com> ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: psi Date: 2/11/2003 Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 21880808 Meeting Password: temppsi Dave From dhall at hp.com Mon Feb 10 16:36:02 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:08 2009 Subject: PS> PSI 1.0 20030210 Available for Review Message-ID: <77261E830267D411BD4D00902740AC250DB4C7F2@xvan01.vcd.hp.com> Hey All.. The latest working draft of the PSI 1.0 Specification is available at: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030210.doc ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030210.pdf This revision is not the document for the Last Call, but really close to it - I need to get the WSDL cleaned up and referenced to from the document, as well as get a few more target device examples incorporated. Dave From dhall at hp.com Tue Feb 11 11:02:31 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:08 2009 Subject: PS> New telecon # Message-ID: <77261E830267D411BD4D00902740AC250DB4C80B@xvan01.vcd.hp.com> 1-866-639-4756 #2124228 From imcdonald at sharplabs.com Sun Feb 16 16:38:09 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:09 2009 Subject: PS> FW: [relax-ng-comment] InstanceToSchema 1.0 Message-ID: <116DB56CD7DED511BC7800508B2CA53735CEDD@mailsrvnt02.enet.sharplabs.com> Hi, Folks now prototyping PSI might want to play with the tool below. Cheers, - Ira McDonald High North Inc -----Original Message----- From: Didier DEMANY [mailto:didier.demany@xmloperator.net] Sent: Thursday, February 13, 2003 3:08 PM To: relax-ng-comment@lists.oasis-open.org Subject: [relax-ng-comment] InstanceToSchema 1.0 Hi, I am pleased to announce InstanceToSchema 1.0 [1] InstanceToSchema is a RELAX NG schema generator from XML instances. It is a command line tool, written in java. It needs J2SE 1.3 or 1.4 and a JAXP compliant SAX parser for running. InstanceToSchema is developed inside the xmloperator project [2] and shares its BSD style license but is packaged and can be used independently from the XML editor. The software is based on pattern categories. A pattern category represents a set of RELAX NG patterns. The tool work consists in building for each element name a pattern category that is compatible with all the input XML instances and is as precise as possible. The following pattern category types are implemented : * An EmptyPatternCategory represents contents with no element. There may be only attributes and/or text. * An (OptionalRepeatable)ElementPatternCategory represents contents with one element or several elements but with the same name. There may also be attributes and/or texts. * A GroupPatternCategory represents ordered contents or choice between ordered contents. There may also be attributes and/or texts. * An InterleavePatternCategory represents unordered contents. Some element names may appear several times, some others may not. There may also be attributes and/or texts. All these pattern categories consider elements and attributes as independent. However the tool framework doesn't require that. New pattern categories could correlate elements and attributes. Another thing the tool does not is inferencing datatypes. The tool is suitable for processing large documents. It uses only one SAX parsing pass. The required memory space depends on the element name count and the complexity of patterns, not the document size. The set of pairs (element name, pattern category) is translated to a RELAX NG simple syntax data model (the same is used by the XML editor), which is converted to a more readable full syntax and writed out with indentation. A typical use case consists to obtain a description of the structure of one or several (combined) XML files. From my point of view, such a schema is not suitable for validating or for guiding editing some document. I hope that this tool can be usefull or incite some developer to do better. I would welcome any comment. Regards, Didier Demany didier.demany@xmloperator.net The_xmloperator_project [1] http://www.xmloperator.net/i2s/ [2] http://www.xmloperator.net/ ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: From imcdonald at sharplabs.com Mon Feb 17 21:34:18 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:09 2009 Subject: PS> FW: [URI, IRI, and Schemes] Message-ID: <116DB56CD7DED511BC7800508B2CA53735CEE4@mailsrvnt02.enet.sharplabs.com> Hi, See below for the latest on revisions and clarifications to RFC 2396 (Generic URI Syntax) and IRI (Internationalized Resource Identifiers - using full Unicode charset) and URI Scheme registration process. Cheers, - Ira McDonald High North Inc -----Original Message----- From: Martin Duerst [mailto:duerst@w3.org] Sent: Monday, February 17, 2003 3:05 PM To: www-international@w3.org Subject: Fwd: (slightly) request for URI BOF scheduling FYI. >From: "Larry Masinter" >To: >Cc: "'Patrik F?tstr?'" ,"'Lisa Dusseault'" >,"Jim Whitehead" ,"'Roy Fielding'" >, ,"Martin J. D?st" >Subject: (slightly) request for URI BOF scheduling >Date: Mon, 17 Feb 2003 12:31:59 -0800 >I've updated the proposed "agenda" to improve the 'goals' >of the various sessions. > >Because of various individual constraints, the request >is for a BOF for URI at the next IETF on Thursday >(preferably in the morning) and also that >WebDAV be scheduled close (the same or adjacent day). > >================================================ >Agenda and goals: > >* 30 minutes (Roy Fielding) > Review plans for revising RFC 3696 (URI) to Standard > http://www.apache.org/?fielding/uri/rev-2002/issues.html > Goal: disseminate information about activity > encourage focus on issues in issue list > create schedule & milestones > >* 15 minutes (Martin Duerst) > Review plans for IRI (as Proposed Standard) > Discussion of current state, IAB concerns > Goal: review IAB issues & coordination with DNS I18N > review process & mailing list > establish schedule & milestones > >* 15 minutes (Patrik F?tstr?) > Discuss "process for registering new URI schemes" > Review mailing list, process, and 'experts' for URI > scheme registration. > Goal: refine process to insure timely and complete feedback > > > > From alan.berkema at hp.com Tue Feb 18 09:25:02 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:09 2009 Subject: PS> [PSI]: next call 02/18/03 Message-ID: <499DC368E25AD411B3F100902740AD650E6AD651@xrose03.rose.hp.com> Teleconference details: NEXT: Tuesday February 18 2003 (USA) Time: 8 AM (US PST) Number: 866-639-4738 Participant PIN: 7855605 Agenda: 1) TBD WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Date: 2/18/2003 Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 27995593 Meeting Password: newpsi Host: Alan Berkema 1(916)7855605 From dhall at hp.com Tue Feb 18 16:05:25 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:09 2009 Subject: PS> FW: Web Services Interoperability guidelines - PSI WSDL Implicati ons Message-ID: <77261E830267D411BD4D00902740AC250DB4C91C@xvan01.vcd.hp.com> > Hey All... > > In developing the WSDL for the PSI specification, we have been running > into many problems trying to implement a multi-parameter document-literal > encoding. > > What the below mentioned WSI interop guideline implies is that we should > NOT have multi-parameter messages. Rather we should have what I've seen > termed "Wrapped" document-literal. > > Essentially, in the WSDL we need to add an additional layer of "wrapping" > of the parameters. So for example, the CreatJob method would have a > CreateJob parameter that has all of our current parameters encapsulated > within it. > > I'll move ahead with this additional layer of encapsulation (wrapping) for > the PSI WSDL unless there is more discussion or comments. > > Comments? > > Dave > > -----Original Message----- > From: REVEL,DAN (HP-Vancouver,ex1) > Sent: Friday, February 14, 2003 3:47 PM > To: HALL,DAVID (HP-Vancouver,ex1) > Subject: Web Services Interoperability guidelines > > Dave, > > Here's a link to an Interoperabilty profile that we should consider when > constructing the WSDL for the PSI interface: > > http://www.ws-i.org/Profiles/Basic/2002-10/BasicProfile-1.0-WGD.htm > > Two things that caught my attention (and which will require changing the > current WSDL) are: > > R1000 When a MESSAGE contains a soap:Fault element, that element MUST NOT > have element children other than faultcode, faultstring, faultactor and > detail. > This seems to go against the inclusion of objects which you told me was > being proposed. > > and: > > R2201 If style="document" and use="literal" at the SOAP binding level, a > DESCRIPTION MUST have zero or one part in a wsdl:message element that > forms the soap:body. > R2204 If the style="document" and use="literal" at the SOAP binding level, > a DESCRIPTION MUST use the element attribute to define the single part in > a message. > This implies the wrapped behavior for the Axis toolkit. > From the Axis WSDL2Java reference guide: > > -W, --noWrapped > This turns off the special treatment of what is called "wrapped" > document/literal style operations. By default, WSDL2Java will recognize > the following conditions: > * If an input message has is a single part. > * The part is an element. > * The element has the same name as the operation > * The element's complex type has no attributes > When it sees this, WSDL2Java will 'unwrap' the top level element, and > treat each of the components of the element as arguments to the operation. > This type of WSDL is the default for Microsoft .NET web services, which > wrap up RPC style arguments in this top level schema element. > > Note the above description places a naming restriction on the single > element included in an input message, essentially the element name maps to > the operation/methed being called... > > Dan > From imcdonald at sharplabs.com Tue Feb 18 17:46:18 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:09 2009 Subject: PS> FW: Web Services Interoperability guidelines - PSI WSDL I mplicati ons Message-ID: <116DB56CD7DED511BC7800508B2CA53735CEEA@mailsrvnt02.enet.sharplabs.com> Hi Dave, I agree that it would be safer and better to add the extra "wrapping". Cheers, - Ira -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Tuesday, February 18, 2003 3:05 PM To: 'ps@pwg.org' Subject: PS> FW: Web Services Interoperability guidelines - PSI WSDL Implicati ons > Hey All... > > In developing the WSDL for the PSI specification, we have been running > into many problems trying to implement a multi-parameter document-literal > encoding. > > What the below mentioned WSI interop guideline implies is that we should > NOT have multi-parameter messages. Rather we should have what I've seen > termed "Wrapped" document-literal. > > Essentially, in the WSDL we need to add an additional layer of "wrapping" > of the parameters. So for example, the CreatJob method would have a > CreateJob parameter that has all of our current parameters encapsulated > within it. > > I'll move ahead with this additional layer of encapsulation (wrapping) for > the PSI WSDL unless there is more discussion or comments. > > Comments? > > Dave > > -----Original Message----- > From: REVEL,DAN (HP-Vancouver,ex1) > Sent: Friday, February 14, 2003 3:47 PM > To: HALL,DAVID (HP-Vancouver,ex1) > Subject: Web Services Interoperability guidelines > > Dave, > > Here's a link to an Interoperabilty profile that we should consider when > constructing the WSDL for the PSI interface: > > http://www.ws-i.org/Profiles/Basic/2002-10/BasicProfile-1.0-WGD.htm > > Two things that caught my attention (and which will require changing the > current WSDL) are: > > R1000 When a MESSAGE contains a soap:Fault element, that element MUST NOT > have element children other than faultcode, faultstring, faultactor and > detail. > This seems to go against the inclusion of objects which you told me was > being proposed. > > and: > > R2201 If style="document" and use="literal" at the SOAP binding level, a > DESCRIPTION MUST have zero or one part in a wsdl:message element that > forms the soap:body. > R2204 If the style="document" and use="literal" at the SOAP binding level, > a DESCRIPTION MUST use the element attribute to define the single part in > a message. > This implies the wrapped behavior for the Axis toolkit. > From the Axis WSDL2Java reference guide: > > -W, --noWrapped > This turns off the special treatment of what is called "wrapped" > document/literal style operations. By default, WSDL2Java will recognize > the following conditions: > * If an input message has is a single part. > * The part is an element. > * The element has the same name as the operation > * The element's complex type has no attributes > When it sees this, WSDL2Java will 'unwrap' the top level element, and > treat each of the components of the element as arguments to the operation. > This type of WSDL is the default for Microsoft .NET web services, which > wrap up RPC style arguments in this top level schema element. > > Note the above description places a naming restriction on the single > element included in an input message, essentially the element name maps to > the operation/methed being called... > > Dan > From alan.berkema at hp.com Wed Feb 19 18:32:40 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:09 2009 Subject: PS> [PSI]: Washington Meeting Message-ID: <499DC368E25AD411B3F100902740AD650E6AD66A@xrose03.rose.hp.com> Hey all, We have had a few requests to finish the PSI meeting by 3:00PM on 4/4/03. So that will be our official stop time. Alan > -----Original Message----- > From: Farrell, Lee [mailto:Lee.Farrell@cda.canon.com] > Sent: Tuesday, February 18, 2003 2:03 PM > To: Alan Berkema (E-mail); HALL,DAVID (HP-Vancouver,ex1) > Subject: Washington meeting > > > Hi Alan, Dave, > > Do you guys have a sense of the meeting duration in Washington? > > I'm trying to arrange flights, and it looks like I'll need to > leave the meeting around 3:00pm if I fly home on Friday. > > But if you think there will be a full day agenda, I should > look into staying until Saturday. > > Any thoughts? > > [Sorry if this was discussed at today's telecon. I had a conflict.] > > lee > =========================== > Lee Farrell > Canon Development Americas > 110 Innovation Drive > Irvine, CA 92612 > (949) 856-7163 - voice > (949) 856-7510 - fax > lee.farrell@cda.canon.com > =========================== > > From alan.berkema at hp.com Thu Feb 20 12:08:41 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:09 2009 Subject: PS> [PSI]: NO CALL 02/25/03 Message-ID: <499DC368E25AD411B3F100902740AD650E6AD66E@xrose03.rose.hp.com> Teleconference details: NEXT: Tuesday March 4 2003 (USA) Time: 8 AM (US PST) Number: 866-639-4738 Participant PIN: 7855605 Agenda: 1) TBD WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Date: 2/18/2003 Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 27995593 Meeting Password: newpsi Host: Alan Berkema 1(916)7855605 From dhall at hp.com Mon Feb 24 12:26:28 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:09 2009 Subject: PS> PSI 1.0 Working Draft 20030221 Available Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAA4A@xvan01.vcd.hp.com> Hi All! The PSI 1.0 Working Draft 20030221 is now available at: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030221.doc ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030221.pdf ftp://ftp.pwg.org/pub/pwg/ps/psi-spec-latest.pdf The PSI WSDL has been updated as well, and includes the new Wrapped Document-Literal encoding, but does not reference the new Semantic Model Schemas yet. http://www.pwg.org/schemas/ps/20030221/QueryEndPointsInterface.wsdl http://www.pwg.org/schemas/ps/20030221/ServiceCapabilitiesInterface.wsdl http://www.pwg.org/schemas/ps/20030221/JobControlInterface.wsdl http://www.pwg.org/schemas/ps/20030221/TargetDeviceSupportInterface.wsdl Dave Hall From WWagner at NetSilicon.com Mon Feb 24 15:56:23 2003 From: WWagner at NetSilicon.com (Wagner,William) Date: Wed May 6 14:02:09 2009 Subject: PS> PSI Port Message-ID: <7F2C5DA4096E9D44B70E967CB54EEEDB0E85A3@mamail.digi.com> In discussing WBMM (which has some similarities to PSI), I advanced the premise that Web Based management would use the infrastructure (access path, proxies etc) that enterprises have established for user web access. I suggested that this was parallel to what PSI was doing, since I thought that that indeed, was the way that PSI would allow deployment without requiring firewall reprogramming, special proxy setups, etc. However, Ira corrected me and observed that: PSI implementations MUST ONLY use the (future) IANA-assigned PSI "registered port" (a number greater than 1024 for a vendor defined protocol). PSI implementations (even by administrator configuration) MUST NOT ever use port 80. and further indicted that to use port 80 for things other than human driven browser clients would violate guidelines being established by IETF/DMTF/W3C. However, this non use of port 80 for PSI is not clear in the specifications. There is a statement relative to URL examples to the effect that the port 80 indicated would be replaced by an IANA to be assigned number; but that does not appear to be a ban on the use of port 80. And the section on firewalls in the Application Guide is empty. I believe that requiring any location that is to support a PSI Client or PSI Target Device create a new path through the firewall will serious affect the potential adoption of PSI. One may observe that assigning port 631 to IPP did very little to allow its use as an Internet Printing Protocol. In presenting PSI to NetSilicon customers, the ability to use the existing port 80 facility is a very important factor. Therefore, I would like some clarification about what the intent in specification really is, and what the position of the working group is. Many thanks. Bill Wagner, NetSilicon/A Digi International Company From imcdonald at sharplabs.com Tue Feb 25 18:43:38 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:09 2009 Subject: PS> RE: PWG-ANNOUNCE> Print Services Web Page Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF01@mailsrvnt02.enet.sharplabs.com> Hi, Actually, PSI is what you want. Several vendors have working PSI prototypes. Products can be expected in the quite near future. PSI itself does not do discovery. But PSI specifies (in some detail) how to do device discovery by wireless (BlueTooth), by SSDP (part of Microsoft's UPnP), by SLPv2 (RFC 2608), by LDAPv3 (RFC 2251), by DNS-SD (RFC 2782), or by UDDI (Web Services) in the "PSI Developers Guide" in section 6 'Print Service Discovery and Deployment'. ftp://ftp.pwg.org/pub/pwg/ps/psi-devl-latest.pdf (most recently v0.95a 13 January 2003) PSI is intended to be (relatively) lightweight. It is a series of WSDL (Web Services Definition Language) SOAP (Simple Object Access Protocol) operations, using the attributes defined in the common XML schema of the IEEE/ISTO PWG Semantic Model. I hope this helps. Cheers, - Ira McDonald, contributing PSI editor High North Inc -----Original Message----- From: Clem McDonald [mailto:cmcdonald@regenstrief.org] Sent: Monday, February 24, 2003 4:18 PM To: imcdonald@sharplabs.com Subject: Re: PS> RE: PWG-ANNOUNCE> Print Services Web Page I have just discovered the PSI working group activity. We have developed a network that includes all of the major hospitals in Indianapolis and captures in a secure way clinical information from all of these institutions. We are working on ways to provide physician access to the data they can properly see, via a wireless PDA (or cell phone) using technology like the Black Berry. For a smallish prespecified list of patients , this system will work very well because the cellular system can push the data to the PDA. The physician will face different issues when he/she wants to look at a broad spectrum of information about a patient that had not been pre-defined. It will likely be slow to load (pull) information on demand about a specific pattient. Furthermore ,even for patients whose data has been pushed to the PDA- some kinds of informatio (E.g EKG tracings and Chest xrays) will not fit very well, and in many cases the physciain would rather review the informaiton on paper. Hence the need for a printer connection. I read the plan for PSI written (I think in 2000). The diagram showing acellular phone or cellular connected PDA sending a URL to a network for printing is exactly what we need. I gather that PSI is just being proposed so there is not likely to be any way for us to take advantage of it. However we don't need the full boat. What we would love to have , would be for a PDA/cellular to be able to discover the Internet address (or URL) of the printer near by. (Ideally this would be by probing it through infrared or blue tooth but doubt that is feasible), and then send a URL from the network to it. Do you know of any implementation of the capabilty that would allow discovery of printer locations and then directing something accross a wider area network to that printer. ( Lots of issues and problemS) Would love to explore anything that was out there that was lightweight Many thanks -- Director, Regenstrief Institute Regenstrief Professor of Medical Informatics Distinguished Professor of Medicine Indiana University School of Medicine 1050 Wishard Blvd RG5 Indianapolis IN 46202-2872 Phone: 317/630-7070 Fax: 317/630-6962 URL: www.regenstrief.org From imcdonald at sharplabs.com Wed Feb 26 17:52:13 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:09 2009 Subject: PS> RE: PWG-ANNOUNCE> Print Services Web Page Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF02@mailsrvnt02.enet.sharplabs.com> Hi folks, Anyone care to respond to Clem's interest in collaborating on a vendor prototype of PSI (see his note below)? Cheers, - Ira McDonald High North Inc -----Original Message----- From: Clem McDonald [mailto:cmcdonald@regenstrief.org] Sent: Wednesday, February 26, 2003 9:28 AM To: McDonald, Ira Subject: Re: PS> RE: PWG-ANNOUNCE> Print Services Web Page wow, that could be just what the doctor ordered. Is there any way to get info on who has these prototypes and how we might be able to get involved. We are working to get federal funding for the second phase of a city wide (indianapolis) linkage of all of the major hospitals. want to be able to request clinical reports via a cellular phone and send the request via cellular to the network and have hte reports print out near the provider. But will need more detaila about the implementation and how it works with blue tooth to sell this. We would be a good demo site. Would love to be ableto contact the folks who are working on prtotypes and understand the context. Does bluetooth sitting on a printer (or the printers internet port) the ability to tell a near by device the internet address of the printer. If so that would be perfect (maybe) Will follow up on the documents you have specified. "McDonald, Ira" wrote: > Hi, > > Actually, PSI is what you want. Several vendors have working PSI > prototypes. Products can be expected in the quite near future. > > PSI itself does not do discovery. > > But PSI specifies (in some detail) how to do device discovery > by wireless (BlueTooth), by SSDP (part of Microsoft's UPnP), > by SLPv2 (RFC 2608), by LDAPv3 (RFC 2251), by DNS-SD (RFC 2782), > or by UDDI (Web Services) in the "PSI Developers Guide" in > section 6 'Print Service Discovery and Deployment'. > > ftp://ftp.pwg.org/pub/pwg/ps/psi-devl-latest.pdf > (most recently v0.95a 13 January 2003) > > PSI is intended to be (relatively) lightweight. It is a series > of WSDL (Web Services Definition Language) SOAP (Simple Object > Access Protocol) operations, using the attributes defined in the > common XML schema of the IEEE/ISTO PWG Semantic Model. > > I hope this helps. > > Cheers, > - Ira McDonald, contributing PSI editor > High North Inc > > -----Original Message----- > From: Clem McDonald [mailto:cmcdonald@regenstrief.org] > Sent: Monday, February 24, 2003 4:18 PM > To: imcdonald@sharplabs.com > Subject: Re: PS> RE: PWG-ANNOUNCE> Print Services Web Page > > I have just discovered the PSI working group activity. We have > developed a network that includes all of the major hospitals in > Indianapolis and captures in a secure way clinical information from all > of these institutions. We are working on ways to provide physician > access to the data they can properly see, via a wireless PDA (or cell > phone) using technology like the Black Berry. > > For a smallish prespecified list of patients , this system will work > very well because the cellular system can push the data to the PDA. The > physician will face different issues when he/she wants to look at a > broad spectrum of information about a patient that had not been > pre-defined. It will likely be slow to load (pull) information on > demand about a specific pattient. Furthermore ,even for patients whose > data has been pushed to the PDA- some kinds of informatio (E.g EKG > tracings and Chest xrays) will not fit very well, and in many cases the > physciain would rather review the informaiton on paper. Hence the need > for a printer connection. I read the plan for PSI written (I think in > 2000). The diagram showing acellular phone or cellular connected PDA > sending a URL to a network for printing is exactly what we need. I > gather that PSI is just being proposed so there is not likely to be any > way for us to take advantage of it. > > However we don't need the full boat. What we would love to have , would > be for a PDA/cellular to be able to discover the Internet address (or > URL) of the printer near by. (Ideally this would be by probing it > through infrared or blue tooth but doubt that is feasible), and then > send a URL from the network to it. > > Do you know of any implementation of the capabilty that would allow > discovery of printer locations and then directing something accross a > wider area network to that printer. ( Lots of issues and problemS) > > Would love to explore anything that was out there that was lightweight > > Many thanks > > -- > Director, Regenstrief Institute > Regenstrief Professor of Medical Informatics > Distinguished Professor of Medicine > Indiana University School of Medicine > 1050 Wishard Blvd RG5 > Indianapolis IN 46202-2872 > Phone: 317/630-7070 > Fax: 317/630-6962 > URL: www.regenstrief.org -- Director, Regenstrief Institute Regenstrief Professor of Medical Informatics Distinguished Professor of Medicine Indiana University School of Medicine 1050 Wishard Blvd RG5 Indianapolis IN 46202-2872 Phone: 317/630-7070 Fax: 317/630-6962 URL: www.regenstrief.org From dhall at hp.com Fri Feb 28 09:50:45 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:09 2009 Subject: PS> PSI and Port 80, and printers traversing the firewall Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAADC@xvan01.vcd.hp.com> Hi Bill... A couple of questions for you... You mentioned the following with regards to PSI and port 80: I am very sad to hear that PSI will not use port 80; I think that will very much handicap the potential of what is an excellent capability. Of course, IPP was assigned port 631, but many implementations still listen on port 80 as well. In consideration of this, Ira and I spent some time looking at PSI, and the use of port 80, and port 3700 (psi-port), and came up with the following proposal: * A Print Service shall implement PSI on psi-port, and port 80 (and thus, the path to ALL psi interfaces must be of the form pwg-psips://server/psi/...) * A Target Device shall implement PSI only on port psi-port * A Client shall always try to communicate with a Print Service on psi-port first, and if that fails, then utilize port 80. We believe that this reasoning enables the following requirements: 1) A company can deploy a PSI Print Service on their normal, publically exposed web-server on port 80. 2) All communication to a Target Device is on port 3700 for network monitoring purposes. 3) Within and enterprise, communication between a client and a Print Service is on 3700 for network monitoring purposes. 4) If an administrator chooses to expose their print service on port 3700, then all traffic to it will be on 3700... Do you feel that this addresses your concerns? (And your customers?) Second: Having been though this at various places. Asking if they would allow a printer that talks to an external server, without adding more restrictions, will get a very quick NO. This model is very important for many of the PSI firewall traversing use models! I do think that implementers of Target Devices should not have their printers come configured "out of the box" with the ability to go and fetch data from an external server. This should probably be something that the administrator needs to enable for particular printers within their enterprise. However, once allowed by the administrator, these "public printers" would then be able to retrieve publically initiated print jobs. Another option is to only allow "authorized users" to initiate these out-bound requests. This would be accomplished by authenticating the user via http, and then the Target Device would need to authorize the user against an acl.. Comments?? Dave From mike.haller at attbi.com Fri Feb 28 10:07:58 2003 From: mike.haller at attbi.com (Mike Haller) Date: Wed May 6 14:02:09 2009 Subject: PS> Difficulty with AddDocumentByPost Message-ID: <002301c2df3b$2dd4f1f0$0200a8c0@boulder.ibm.com> I have an implementation of the job control interface circa last November, and am finally getting around to updating it to something more modern (20030221), but I am finding the new AddDocumentByPost difficult to implement. First, making the option mandatory will make it unnecessarily difficult to support an SMTP-bound SOAP implementation, since it forces an HTTP server implementation. Second, allowing the lastDocument on this call means that heavy-duty coupling must be done between the JCI implementation and whatever implementation receives the SOAP calls, since the lastDocument = true must effectively be deferred until after the post has successfully completed. This implies that whatever receives the post must communicate with the JCI implementation when it has been received successfully. And of course, the JCI implementation already has to know all about whatever receives the post so that it can know how to create a new sink URL and go collect the data when it is done. It is also unclear what the implementation should do if the post fails for some reason, or in what order the implementation can expect to receive the posts. For example, it now seems the client could: 1. CreateJob 2. AddDocumentByPost last = false 3. AddDocumentByPost last = true 4. Post document 2 5. Post document 1 This makes the implementation difficult, without really seeming to buy anything useful for the client. If the lastDocument flag were removed from the AddDocumentByPost call, and if the additional requirement were made that the client could not perform any additional AddDocumentByReference or AddDocumentByPost calls until either the post was complete, or a CancelDocument call were made for the pending document, then the implementation would be much simpler. Then the example above would be: 1. CreateJob 2. AddDocumentByPost 3. Post document 1 4. AddDocumentByPost 5. Post document 2 6. AddDocumentByReference last = true reference = null Though I can't seem to find where AddDocumentByReference with a null reference and attributes is actually allowed (it is, isn't it?) Maybe it's not to late for a completeJob( jobURI ) call? Mike Haller From dhall at hp.com Fri Feb 28 11:48:32 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:09 2009 Subject: PS> Difficulty with AddDocumentByPost Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAAE1@xvan01.vcd.hp.com> Hey Mike... Thanks for the input! See my comments inline... Would you be interested in attending some of our public interop events with your implementation? We plann on having some teleconference interops before a Face 2 Face event as well. Dave -----Original Message----- From: Mike Haller [mailto:mike.haller@attbi.com] Sent: Friday, February 28, 2003 7:08 AM To: ps@pwg.org Subject: PS> Difficulty with AddDocumentByPost I have an implementation of the job control interface circa last November, and am finally getting around to updating it to something more modern (20030221), but I am finding the new AddDocumentByPost difficult to implement. First, making the option mandatory will make it unnecessarily difficult to support an SMTP-bound SOAP implementation, since it forces an HTTP server implementation. Which option in particular are you refering to? Second, allowing the lastDocument on this call means that heavy-duty coupling must be done between the JCI implementation and whatever implementation receives the SOAP calls, since the lastDocument = true must effectively be deferred until after the post has successfully completed. This implies that whatever receives the post must communicate with the JCI implementation when it has been received successfully. And of course, the JCI implementation already has to know all about whatever receives the post so that it can know how to create a new sink URL and go collect the data when it is done. Yep, this is very true, and I can't think of an easy way to decouple the JCI implementation from whatever receives the post. I think inherently that whatever receives the post needs to then add the data to the document that was created in the original AddDocumentByPost SOAP call. - I've managed this my placing a query parameter on the URL that is returned to the client as follows: We have a servlet that is listening on a particular path. The AddDocumentByPost returns the following: http://mypsiserver/axis/servlet/PSIPostServlet/urn:uuid:143832734-2340342-34 34-3 Basically, we encode the DocumentURI on the return path. This allows the servlet that receives the post to make the association with the appropriate internal JCI document as follows: protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { try { String documentURI = req.getPathInfo().substring(1); // Find the appropriate document from our PSIDocument hash PSIDocument doc = PSIDocument.getDocumentByURI(documentURI); InputStream requestInputStream = req.getInputStream(); //Let the document object know about the input stream... doc.post(requestInputStream); // what do we return? resp.setContentLength(0); resp.getWriter().close(); } catch (Exception e) { e.printStackTrace(); throw new ServletException(e); // ??? } } It is also unclear what the implementation should do if the post fails for some reason, or in what order the implementation can expect to receive the posts. For example, it now seems the client could: 1. CreateJob 2. AddDocumentByPost last = false 3. AddDocumentByPost last = true 4. Post document 2 5. Post document 1 This makes the implementation difficult, without really seeming to buy anything useful for the client. This is also true. Right now I have solved this by deferring processing of the job untill all of the document data has been received. There are some gating factors as to what allows a job to be processed: lastDocument == true AllDocumentDataReceived == true If the lastDocument flag were removed from the AddDocumentByPost call, and if the additional requirement were made that the client could not perform any additional AddDocumentByReference or AddDocumentByPost calls until either the post was complete, or a CancelDocument call were made for the pending document, then the implementation would be much simpler. Then the example above would be: 1. CreateJob 2. AddDocumentByPost 3. Post document 1 4. AddDocumentByPost 5. Post document 2 6. AddDocumentByReference last = true reference = null I like the idea of adding the requirement that the data MUST be posted directly after the AddDocumentByPost, and before any other AddDocumentBy* methods are called. I'll add it to the latest rev of the spec, and see if the working group approves. I don't like overloading the AddDocumentByReference to indicate the "I'm Done". Hopefully adding the interleaving requirement is sufficient for you needs. Though I can't seem to find where AddDocumentByReference with a null reference and attributes is actually allowed (it is, isn't it?) Maybe it's not to late for a completeJob( jobURI ) call? Mike Haller From alan.berkema at hp.com Fri Feb 28 12:58:57 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:09 2009 Subject: PS> [PSI]: next call 03/04/03 Message-ID: <499DC368E25AD411B3F100902740AD650E6AD6C9@xrose03.rose.hp.com> Teleconference details: NEXT: Tuesday March 04 2003 (USA) Time: 8 AM (US PST) Number: 866-639-4738 Participant PIN: 7855605 Agenda: 1) PSI Port 2) Difficulty with AddDocumentByPost 3) Ready for Last Call 4) ? WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 27995593 Meeting Password: newpsi Host: Alan Berkema 1(916)7855605 From mhaller at us.ibm.com Fri Feb 28 15:53:25 2003 From: mhaller at us.ibm.com (Mike Haller) Date: Wed May 6 14:02:09 2009 Subject: PS> Difficulty with AddDocumentByPost In-Reply-To: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAAE1@xvan01.vcd.hp.com> Message-ID: <000d01c2df6b$7024a660$0200a8c0@boulder.ibm.com> Dave, Thanks for the speedy reply. Response below. > > Hey Mike... > > Thanks for the input! See my comments inline... > > Would you be interested in attending some of our public > interop events with your implementation? We plann on having > some teleconference interops before a Face 2 Face event as well. > Harry has been talking to us about this, and we are definitely interested. It will mostly be a question of whether we can catch up by then. > First, making the option mandatory will make it unnecessarily > difficult to support an SMTP-bound SOAP implementation, since > it forces an HTTP server implementation. > > > Which option in particular are you refering to? > Well, I guess it's not really an option if it's mandatory :) I was referring to the call AddDocumentByPost, which is listed as mandatory for both a print service and a target device. Since it is required and there is no fault for "operation not supported", then even a non-HTTP SOAP implementation is forced to coordinate with an HTTP server. I understand that the focus was on HTTP implementations, but this seems to effectively preclude anything else. > > Second, allowing the lastDocument on this call means that > heavy-duty coupling must be done between the JCI > implementation and whatever implementation receives the SOAP > calls, since the lastDocument = true must effectively be > deferred until after the post has successfully completed. > This implies that whatever receives the post must communicate > with the JCI implementation when it has been received > successfully. And of course, the JCI implementation already > has to know all about whatever receives the post so that it > can know how to create a new sink URL and go collect the data > when it is done. > > > Yep, this is very true, and I can't think of an easy way to > decouple the JCI implementation from whatever receives the > post. I think inherently that whatever receives the post > needs to then add the data to the document that was created > in the original AddDocumentByPost SOAP call. - I've managed > this my placing a query parameter on the URL that is returned > to the client as > follows: > > We have a servlet that is listening on a particular path. > The AddDocumentByPost returns the following: > http://mypsiserver/axis/servlet/PSIPostServlet/urn:uuid:143832 > 734-2340342-34 > 34-3 > > Basically, we encode the DocumentURI on the return path. > This allows the servlet that receives the post to make the > association with the appropriate internal JCI document as follows: > > protected void doPost(HttpServletRequest req, > HttpServletResponse resp) throws ServletException, IOException { > try > { > String documentURI = req.getPathInfo().substring(1); > // Find the appropriate document from our > PSIDocument hash > PSIDocument doc = > PSIDocument.getDocumentByURI(documentURI); > InputStream requestInputStream = req.getInputStream(); > > //Let the document object know about the input > stream... doc.post(requestInputStream); > > // what do we return? > resp.setContentLength(0); > resp.getWriter().close(); > } > catch (Exception e) > { > e.printStackTrace(); > throw new ServletException(e); // ??? > } > } > > > It is also unclear what the implementation should do if the > post fails for some reason, or in what order the > implementation can expect to receive the posts. For example, > it now seems the client could: > > 1. CreateJob > 2. AddDocumentByPost last = false > 3. AddDocumentByPost last = true > 4. Post document 2 > 5. Post document 1 > > This makes the implementation difficult, without really > seeming to buy anything useful for the client. > > > This is also true. Right now I have solved this by deferring > processing of the job untill all of the document data has > been received. There are some gating factors as to what > allows a job to be processed: lastDocument == true > AllDocumentDataReceived == true Technically this problem has a solution, even in the out-of-order case. I think the real question is whether all the service implementors should be burdened with this additional coupling when it can be fairly easily be avoided without unduly limiting the client implementation (I think). > If the lastDocument flag were removed from the > AddDocumentByPost call, and if the additional requirement > were made that the client could not perform any additional > AddDocumentByReference or AddDocumentByPost calls until > either the post was complete, or a CancelDocument call were > made for the pending document, then the implementation would > be much simpler. Then the example above would be: > > 1. CreateJob > 2. AddDocumentByPost > 3. Post document 1 > 4. AddDocumentByPost > 5. Post document 2 > 6. AddDocumentByReference last = true reference = null > > > I like the idea of adding the requirement that the data MUST > be posted directly after the AddDocumentByPost, and before > any other AddDocumentBy* methods are called. I'll add it to > the latest rev of the spec, and see if the working group approves. > > I don't like overloading the AddDocumentByReference to > indicate the "I'm Done". Hopefully adding the interleaving > requirement is sufficient for you needs. Then such an overloading does not already exist? That would seem to be a problem, since you may not know at the time the last document is started if it is the last document. I had assumed that PSI was similar to IPP in that one of the AddDocumentByPost and AddDocumentByReference was overloaded and could be used to end the job, but I did not find a reference to this. Is there any way to do this, or is it always necessary to know that a job will be complete at the commencement of the last document? Regards, Mike > Though I can't seem to find where AddDocumentByReference with > a null reference and attributes is actually allowed (it is, > isn't it?) Maybe it's not to late for a completeJob( jobURI ) call? > > Mike Haller > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2342 bytes Desc: not available Url : http://www.pwg.org/archives/ps/attachments/20030228/ceef466c/smime.bin From imcdonald at sharplabs.com Fri Feb 28 17:44:44 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:09 2009 Subject: PS> Difficulty with AddDocumentByPost Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF10@mailsrvnt02.enet.sharplabs.com> Hi Mike, The 'last-document' flag in PSI is a legacy of IPP. It's a kludge. A much cleaner solution is a distinct operation "CloseJob" that is sent AFTER the last document is added by Post (by value) or by Reference. I'd much prefer that we corrected this mistake in IPP and (therefore) the PWG Semantic Model. Forcing mandatory support for AddDocumentByPost (and thus an HTTP transport) is a bad mistake. PSI should define clean WSDL/SOAP operations that can use any transport binding of SOAP - SOAP over SMTP, or SOAP over Blocks (RFC 3288), or whatever. Cheers, - Ira McDonald High North Inc PS - When we originally developed IPP/1.0, Microsoft only wanted Print-Job (sends print data by value). Later, Microsoft and many others realized that we SHOULD have made support for Print-URI (sends print data by reference) Mandatory and made Print-Job Optional. -----Original Message----- From: Mike Haller [mailto:mhaller@us.ibm.com] Sent: Friday, February 28, 2003 2:53 PM To: ps@pwg.org Subject: RE: PS> Difficulty with AddDocumentByPost Dave, Thanks for the speedy reply. Response below. > > Hey Mike... > > Thanks for the input! See my comments inline... > > Would you be interested in attending some of our public > interop events with your implementation? We plann on having > some teleconference interops before a Face 2 Face event as well. > Harry has been talking to us about this, and we are definitely interested. It will mostly be a question of whether we can catch up by then. > First, making the option mandatory will make it unnecessarily > difficult to support an SMTP-bound SOAP implementation, since > it forces an HTTP server implementation. > > > Which option in particular are you refering to? > Well, I guess it's not really an option if it's mandatory :) I was referring to the call AddDocumentByPost, which is listed as mandatory for both a print service and a target device. Since it is required and there is no fault for "operation not supported", then even a non-HTTP SOAP implementation is forced to coordinate with an HTTP server. I understand that the focus was on HTTP implementations, but this seems to effectively preclude anything else. > > Second, allowing the lastDocument on this call means that > heavy-duty coupling must be done between the JCI > implementation and whatever implementation receives the SOAP > calls, since the lastDocument = true must effectively be > deferred until after the post has successfully completed. > This implies that whatever receives the post must communicate > with the JCI implementation when it has been received > successfully. And of course, the JCI implementation already > has to know all about whatever receives the post so that it > can know how to create a new sink URL and go collect the data > when it is done. > > > Yep, this is very true, and I can't think of an easy way to > decouple the JCI implementation from whatever receives the > post. I think inherently that whatever receives the post > needs to then add the data to the document that was created > in the original AddDocumentByPost SOAP call. - I've managed > this my placing a query parameter on the URL that is returned > to the client as > follows: > > We have a servlet that is listening on a particular path. > The AddDocumentByPost returns the following: > http://mypsiserver/axis/servlet/PSIPostServlet/urn:uuid:143832 > 734-2340342-34 > 34-3 > > Basically, we encode the DocumentURI on the return path. > This allows the servlet that receives the post to make the > association with the appropriate internal JCI document as follows: > > protected void doPost(HttpServletRequest req, > HttpServletResponse resp) throws ServletException, IOException { > try > { > String documentURI = req.getPathInfo().substring(1); > // Find the appropriate document from our > PSIDocument hash > PSIDocument doc = > PSIDocument.getDocumentByURI(documentURI); > InputStream requestInputStream = req.getInputStream(); > > //Let the document object know about the input > stream... doc.post(requestInputStream); > > // what do we return? > resp.setContentLength(0); > resp.getWriter().close(); > } > catch (Exception e) > { > e.printStackTrace(); > throw new ServletException(e); // ??? > } > } > > > It is also unclear what the implementation should do if the > post fails for some reason, or in what order the > implementation can expect to receive the posts. For example, > it now seems the client could: > > 1. CreateJob > 2. AddDocumentByPost last = false > 3. AddDocumentByPost last = true > 4. Post document 2 > 5. Post document 1 > > This makes the implementation difficult, without really > seeming to buy anything useful for the client. > > > This is also true. Right now I have solved this by deferring > processing of the job untill all of the document data has > been received. There are some gating factors as to what > allows a job to be processed: lastDocument == true > AllDocumentDataReceived == true Technically this problem has a solution, even in the out-of-order case. I think the real question is whether all the service implementors should be burdened with this additional coupling when it can be fairly easily be avoided without unduly limiting the client implementation (I think). > If the lastDocument flag were removed from the > AddDocumentByPost call, and if the additional requirement > were made that the client could not perform any additional > AddDocumentByReference or AddDocumentByPost calls until > either the post was complete, or a CancelDocument call were > made for the pending document, then the implementation would > be much simpler. Then the example above would be: > > 1. CreateJob > 2. AddDocumentByPost > 3. Post document 1 > 4. AddDocumentByPost > 5. Post document 2 > 6. AddDocumentByReference last = true reference = null > > > I like the idea of adding the requirement that the data MUST > be posted directly after the AddDocumentByPost, and before > any other AddDocumentBy* methods are called. I'll add it to > the latest rev of the spec, and see if the working group approves. > > I don't like overloading the AddDocumentByReference to > indicate the "I'm Done". Hopefully adding the interleaving > requirement is sufficient for you needs. Then such an overloading does not already exist? That would seem to be a problem, since you may not know at the time the last document is started if it is the last document. I had assumed that PSI was similar to IPP in that one of the AddDocumentByPost and AddDocumentByReference was overloaded and could be used to end the job, but I did not find a reference to this. Is there any way to do this, or is it always necessary to know that a job will be complete at the commencement of the last document? Regards, Mike > Though I can't seem to find where AddDocumentByReference with > a null reference and attributes is actually allowed (it is, > isn't it?) Maybe it's not to late for a completeJob( jobURI ) call? > > Mike Haller > From mhaller at us.ibm.com Sat Mar 1 12:48:18 2003 From: mhaller at us.ibm.com (Mike Haller) Date: Wed May 6 14:02:09 2009 Subject: PS> Difficulty with AddDocumentByPost In-Reply-To: <116DB56CD7DED511BC7800508B2CA53735CF10@mailsrvnt02.enet.sharplabs.com> Message-ID: <002601c2e01a$be8d54a0$0200a8c0@boulder.ibm.com> Hello Ira, I just can't help but agree with all of your points. Regards, Mike > -----Original Message----- > From: owner-ps@pwg.org [mailto:owner-ps@pwg.org] On Behalf Of > McDonald, Ira > Sent: Friday, February 28, 2003 3:45 PM > To: 'Mike Haller'; ps@pwg.org > Subject: RE: PS> Difficulty with AddDocumentByPost > > > Hi Mike, > > The 'last-document' flag in PSI is a legacy of IPP. It's > a kludge. A much cleaner solution is a distinct operation > "CloseJob" that is sent AFTER the last document is added by > Post (by value) or by Reference. > > I'd much prefer that we corrected this mistake in IPP and > (therefore) the PWG Semantic Model. > > Forcing mandatory support for AddDocumentByPost (and thus > an HTTP transport) is a bad mistake. > > PSI should define clean WSDL/SOAP operations that can use > any transport binding of SOAP - SOAP over SMTP, or SOAP > over Blocks (RFC 3288), or whatever. > > Cheers, > - Ira McDonald > High North Inc > > PS - When we originally developed IPP/1.0, Microsoft only > wanted Print-Job (sends print data by value). Later, > Microsoft and many others realized that we SHOULD have made > support for Print-URI (sends print data by reference) > Mandatory and made Print-Job Optional. > > > -----Original Message----- > From: Mike Haller [mailto:mhaller@us.ibm.com] > Sent: Friday, February 28, 2003 2:53 PM > To: ps@pwg.org > Subject: RE: PS> Difficulty with AddDocumentByPost > > > Dave, > > Thanks for the speedy reply. Response below. > > > > > Hey Mike... > > > > Thanks for the input! See my comments inline... > > > > Would you be interested in attending some of our public > > interop events with your implementation? We plann on having > > some teleconference interops before a Face 2 Face event as well. > > > > Harry has been talking to us about this, and we are > definitely interested. It will mostly be a question of > whether we can catch up by then. > > > First, making the option mandatory will make it unnecessarily > > difficult to support an SMTP-bound SOAP implementation, since > > it forces an HTTP server implementation. > > > > > > Which option in particular are you refering to? > > > > Well, I guess it's not really an option if it's mandatory :) > I was referring to the call AddDocumentByPost, which is > listed as mandatory for both a print service and a target > device. Since it is required and there is no fault for > "operation not supported", then even a non-HTTP SOAP > implementation is forced to coordinate with an HTTP server. > I understand that the focus was on HTTP implementations, but > this seems to effectively preclude anything else. > > > > > Second, allowing the lastDocument on this call means that > > heavy-duty coupling must be done between the JCI > > implementation and whatever implementation receives the SOAP > > calls, since the lastDocument = true must effectively be > > deferred until after the post has successfully completed. > > This implies that whatever receives the post must communicate > > with the JCI implementation when it has been received > > successfully. And of course, the JCI implementation already > > has to know all about whatever receives the post so that it > > can know how to create a new sink URL and go collect the data > > when it is done. > > > > > > Yep, this is very true, and I can't think of an easy way to > > decouple the JCI implementation from whatever receives the > > post. I think inherently that whatever receives the post > > needs to then add the data to the document that was created > > in the original AddDocumentByPost SOAP call. - I've managed > > this my placing a query parameter on the URL that is returned > > to the client as > > follows: > > > > We have a servlet that is listening on a particular path. > > The AddDocumentByPost returns the following: > > http://mypsiserver/axis/servlet/PSIPostServlet/urn:uuid:143832 > > 734-2340342-34 > > 34-3 > > > > Basically, we encode the DocumentURI on the return path. > > This allows the servlet that receives the post to make the > > association with the appropriate internal JCI document as follows: > > > > protected void doPost(HttpServletRequest req, > > HttpServletResponse resp) throws ServletException, IOException { > > try > > { > > String documentURI = req.getPathInfo().substring(1); > > // Find the appropriate document from our > > PSIDocument hash > > PSIDocument doc = > > PSIDocument.getDocumentByURI(documentURI); > > InputStream requestInputStream = req.getInputStream(); > > > > //Let the document object know about the input > > stream... doc.post(requestInputStream); > > > > // what do we return? > > resp.setContentLength(0); > > resp.getWriter().close(); > > } > > catch (Exception e) > > { > > e.printStackTrace(); > > throw new ServletException(e); // ??? > > } > > } > > > > > > It is also unclear what the implementation should do if the > > post fails for some reason, or in what order the > > implementation can expect to receive the posts. For example, > > it now seems the client could: > > > > 1. CreateJob > > 2. AddDocumentByPost last = false > > 3. AddDocumentByPost last = true > > 4. Post document 2 > > 5. Post document 1 > > > > This makes the implementation difficult, without really > > seeming to buy anything useful for the client. > > > > > > This is also true. Right now I have solved this by deferring > > processing of the job untill all of the document data has > > been received. There are some gating factors as to what > > allows a job to be processed: lastDocument == true > > AllDocumentDataReceived == true > > Technically this problem has a solution, even in the > out-of-order case. I think the real question is whether all > the service implementors should be burdened with this > additional coupling when it can be fairly easily be avoided > without unduly limiting the client implementation (I think). > > > If the lastDocument flag were removed from the > > AddDocumentByPost call, and if the additional requirement > > were made that the client could not perform any additional > > AddDocumentByReference or AddDocumentByPost calls until > > either the post was complete, or a CancelDocument call were > > made for the pending document, then the implementation would > > be much simpler. Then the example above would be: > > > > 1. CreateJob > > 2. AddDocumentByPost > > 3. Post document 1 > > 4. AddDocumentByPost > > 5. Post document 2 > > 6. AddDocumentByReference last = true reference = null > > > > > > I like the idea of adding the requirement that the data MUST > > be posted directly after the AddDocumentByPost, and before > > any other AddDocumentBy* methods are called. I'll add it to > > the latest rev of the spec, and see if the working group approves. > > > > I don't like overloading the AddDocumentByReference to > > indicate the "I'm Done". Hopefully adding the interleaving > > requirement is sufficient for you needs. > > Then such an overloading does not already exist? That would > seem to be a problem, since you may not know at the time the > last document is started if it is the last document. I had > assumed that PSI was similar to IPP in that one of the > AddDocumentByPost and AddDocumentByReference was overloaded > and could be used to end the job, but I did not find a > reference to this. Is there any way to do this, or is it > always necessary to know that a job will be complete at the > commencement of the last document? > > Regards, > Mike > > > Though I can't seem to find where AddDocumentByReference with > > a null reference and attributes is actually allowed (it is, > > isn't it?) Maybe it's not to late for a completeJob( jobURI ) call? > > > > Mike Haller > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2342 bytes Desc: not available Url : http://www.pwg.org/archives/ps/attachments/20030301/c9af197b/smime.bin From WWagner at NetSilicon.com Mon Mar 3 11:19:39 2003 From: WWagner at NetSilicon.com (Wagner,William) Date: Wed May 6 14:02:09 2009 Subject: PS> RE: PSI and Port 80, and printers traversing the firewall Message-ID: <7F2C5DA4096E9D44B70E967CB54EEEDB0E85BF@mamail.digi.com> David, Many thanks for the consideration. 1. I may be getting confused with the terminology. PSI defines three types of entities all of which have "Client" capability. From Figure 1 in the Developer's Guide, lets call the user client the "Mobile Device". So one has: Mobile Device - with a client capability Print Service - Client Capability QueryEndpointsInterface ServiceCapabilitiesInterface JobControlInterface TargetDeviceSupportInterface TargetDevice- Client Capability JobControlInterface QueryEndpointsInterface ServiceCapabilitiesInterface a. if there are no firewalls (or all components are inside a common network), there should be no problem using the psi-port communicating from any client to any interface b. in any case involving firewalls, any "server" interface needs special firewall handling, regardless of what port is used. c. a mobile device may very well be trying to communicate to the Print Service through a foreign firewall, which does not support the PSI Port. So allowing the Mobile client a port 80 backup is highly desirable. d. it would seem that a target device might want to operate in only the client mode. (This appears to be in violation of the requirement that the target device support all interfaces, but it is an attractive capability regardless) The target therefore could pull jobs from a internet Print Service to which it subscribed. This would allow "internet printing" without needing special firewall handling for the Target Device. The need to provide special firewall handing is one reason why IPP has not become a widely used "internet" printing protocol. Allowing the target device to pull jobs from a server that can be accessed via the internet would resolve this problem. But from your statement that "A Target Device shall implement PSI only on port psi-port", it is not clear to me that you are allowing the client in the target device to initiate a connection on port 80. I also do not understand your statement that: "If an administrator chooses to expose their print service on port 3700, then all traffic to it will be on 3700." 2. With respect to my comment about MIS not allowing a printer to communicate with an external server, the operative words here are "without adding more restrictions". And when I made the statement, I did indicate the restrictions that were required in the WBMM context. I believe that in defining the interface that the printer will use in this context, you are defining the restrictions. That is, you are limiting the printer contacts and what can transpire between the printer and the service or client. I believe that this will be acceptable to most enterprises, although it may be necessary in some implementations to allow configuration of more constraints, such as not supporting some interfaces, requiring authentication or encryption and possibly disallowing certain operations. Regards, Bill Wagner/NetSilicon. -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Friday, February 28, 2003 9:51 AM To: 'imcdonald@sharplabs.com'; Wagner,William; BERKEMA,ALAN C (HP-Roseville,ex1) Cc: 'ps@pwg.org' Subject: PSI and Port 80, and printers traversing the firewall Hi Bill... A couple of questions for you... You mentioned the following with regards to PSI and port 80: I am very sad to hear that PSI will not use port 80; I think that will very much handicap the potential of what is an excellent capability. Of course, IPP was assigned port 631, but many implementations still listen on port 80 as well. In consideration of this, Ira and I spent some time looking at PSI, and the use of port 80, and port 3700 (psi-port), and came up with the following proposal: * A Print Service shall implement PSI on psi-port, and port 80 (and thus, the path to ALL psi interfaces must be of the form pwg-psips://server/psi/...) * A Target Device shall implement PSI only on port psi-port * A Client shall always try to communicate with a Print Service on psi-port first, and if that fails, then utilize port 80. We believe that this reasoning enables the following requirements: 1) A company can deploy a PSI Print Service on their normal, publically exposed web-server on port 80. 2) All communication to a Target Device is on port 3700 for network monitoring purposes. 3) Within and enterprise, communication between a client and a Print Service is on 3700 for network monitoring purposes. 4) If an administrator chooses to expose their print service on port 3700, then all traffic to it will be on 3700... Do you feel that this addresses your concerns? (And your customers?) Second: Having been though this at various places. Asking if they would allow a printer that talks to an external server, without adding more restrictions, will get a very quick NO. This model is very important for many of the PSI firewall traversing use models! I do think that implementers of Target Devices should not have their printers come configured "out of the box" with the ability to go and fetch data from an external server. This should probably be something that the administrator needs to enable for particular printers within their enterprise. However, once allowed by the administrator, these "public printers" would then be able to retrieve publically initiated print jobs. Another option is to only allow "authorized users" to initiate these out-bound requests. This would be accomplished by authenticating the user via http, and then the Target Device would need to authorize the user against an acl.. Comments?? Dave From dhall at hp.com Mon Mar 3 11:37:50 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:09 2009 Subject: PS> RE: PSI and Port 80, and printers traversing the firewall Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAB25@xvan01.vcd.hp.com> Hi Bill and All... See comments inline below.. Dave David, Many thanks for the consideration. 1. I may be getting confused with the terminology. PSI defines three types of entities all of which have "Client" capability. From Figure 1 in the Developer's Guide, lets call the user client the "Mobile Device". So one has: Mobile Device - with a client capability Print Service - Client Capability QueryEndpointsInterface ServiceCapabilitiesInterface JobControlInterface TargetDeviceSupportInterface TargetDevice- Client Capability JobControlInterface QueryEndpointsInterface ServiceCapabilitiesInterface Yep, the client term is difficult to nail down. I'll see if I can be more explicit in the following comments.. a. if there are no firewalls (or all components are inside a common network), there should be no problem using the psi-port communicating from any client to any interface b. in any case involving firewalls, any "server" interface needs special firewall handling, regardless of what port is used. Yep, exactly - the PSI "server" interfaces on a Print Service, and the PSI "server" interfaces on a Target Device. c. a mobile device may very well be trying to communicate to the Print Service through a foreign firewall, which does not support the PSI Port. So allowing the Mobile client a port 80 backup is highly desirable. This is the hope that by allowing a PSI Print Service to also expose PSI "server" interfaces over port 80 will allow for more deployment scenarios that if we restricted it to only 3700 d. it would seem that a target device might want to operate in only the client mode. (This appears to be in violation of the requirement that the target device support all interfaces, but it is an attractive capability regardless) The target therefore could pull jobs from a internet Print Service to which it subscribed. This would allow "internet printing" without needing special firewall handling for the Target Device. The need to provide special firewall handing is one reason why IPP has not become a widely used "internet" printing protocol. Allowing the target device to pull jobs from a server that can be accessed via the internet would resolve this problem. A true PSI Target Device does indeed need to implement the "server" interfaces. However, I don't believe that there is anything precluding vendors from implementing only the "client" side of a Target Device. This implementation of a Target Device simply makes the Target Device look like it is behind a firewall from the Print Services "client" perspective. This is a similiar situation to the "Bluetooth Target Device Proxy" where the handheld pretends to be a "Target Device" and pulls the data from the Print Service, and then pushes it to the printer via BlueTooth. But from your statement that "A Target Device shall implement PSI only on port psi-port", it is not clear to me that you are allowing the client in the target device to initiate a connection on port 80. I think that the intention here is that a Target Device shall implement the PSI "server" set of interfaces only on port psi-port. The "client" side of the Target Device should behaive as per the client rules - try 3700 first, then 80. I also do not understand your statement that: "If an administrator chooses to expose their print service on port 3700, then all traffic to it will be on 3700." Give the client "rule" that clients must try 3700 first, and then 80 - if a Print Service is exposed on 3700, then all PSI method invocations from clients will be on port 3700. I added this comment into the specification so that implementers / deployers understand that 3700 may be the only thing available. 2. With respect to my comment about MIS not allowing a printer to communicate with an external server, the operative words here are "without adding more restrictions". And when I made the statement, I did indicate the restrictions that were required in the WBMM context. I believe that in defining the interface that the printer will use in this context, you are defining the restrictions. That is, you are limiting the printer contacts and what can transpire between the printer and the service or client. I believe that this will be acceptable to most enterprises, although it may be necessary in some implementations to allow configuration of more constraints, such as not supporting some interfaces, requiring authentication or encryption and possibly disallowing certain operations. Yep, exactly. This makes a lot of sense. Regards, Bill Wagner/NetSilicon. -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Friday, February 28, 2003 9:51 AM To: 'imcdonald@sharplabs.com'; Wagner,William; BERKEMA,ALAN C (HP-Roseville,ex1) Cc: 'ps@pwg.org' Subject: PSI and Port 80, and printers traversing the firewall Hi Bill... A couple of questions for you... You mentioned the following with regards to PSI and port 80: I am very sad to hear that PSI will not use port 80; I think that will very much handicap the potential of what is an excellent capability. Of course, IPP was assigned port 631, but many implementations still listen on port 80 as well. In consideration of this, Ira and I spent some time looking at PSI, and the use of port 80, and port 3700 (psi-port), and came up with the following proposal: * A Print Service shall implement PSI on psi-port, and port 80 (and thus, the path to ALL psi interfaces must be of the form pwg-psips://server/psi/...) * A Target Device shall implement PSI only on port psi-port * A Client shall always try to communicate with a Print Service on psi-port first, and if that fails, then utilize port 80. We believe that this reasoning enables the following requirements: 1) A company can deploy a PSI Print Service on their normal, publically exposed web-server on port 80. 2) All communication to a Target Device is on port 3700 for network monitoring purposes. 3) Within and enterprise, communication between a client and a Print Service is on 3700 for network monitoring purposes. 4) If an administrator chooses to expose their print service on port 3700, then all traffic to it will be on 3700... Do you feel that this addresses your concerns? (And your customers?) Second: Having been though this at various places. Asking if they would allow a printer that talks to an external server, without adding more restrictions, will get a very quick NO. This model is very important for many of the PSI firewall traversing use models! I do think that implementers of Target Devices should not have their printers come configured "out of the box" with the ability to go and fetch data from an external server. This should probably be something that the administrator needs to enable for particular printers within their enterprise. However, once allowed by the administrator, these "public printers" would then be able to retrieve publically initiated print jobs. Another option is to only allow "authorized users" to initiate these out-bound requests. This would be accomplished by authenticating the user via http, and then the Target Device would need to authorize the user against an acl.. Comments?? Dave From dhall at hp.com Mon Mar 3 11:44:19 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:09 2009 Subject: PS> PSI Spec wd-psi10-20030303 available Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAB28@xvan01.vcd.hp.com> Hey All.. The latest working draft of the PSI 1.0 Specification is available at: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030303.doc ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030303.pdf It includes a new JobControl method - CloseJob. Also included is the new psi-port / port 80 discussion. Please review these for tomorrows teleconference. Thanks! Dave From WWagner at NetSilicon.com Mon Mar 3 11:49:32 2003 From: WWagner at NetSilicon.com (Wagner,William) Date: Wed May 6 14:02:09 2009 Subject: PS> RE: PSI and Port 80, and printers traversing the firewall Message-ID: <7F2C5DA4096E9D44B70E967CB54EEEDB0E85C0@mamail.digi.com> Dave, The clarification is appreciated. However, I still seem to be missing something on: "If an administrator chooses to expose their print service on port 3700, then all traffic to it will be on 3700." Give the client "rule" that clients must try 3700 first, and then 80 - if a Print Service is exposed on 3700, then all PSI method invocations from clients will be on port 3700. I added this comment into the specification so that implementers / deployers understand that 3700 may be the only thing available. Doesn't that conflict with the proposal that "A Print Service shall implement PSI on psi-port, and port 80 ", which suggests that the print service must listen on both ports. And, given the instance where the mobile client cannot get through the firewall at his location via the PSI-port, should not the print service also listen on port 80? Thanks, Bill Wagner -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Monday, March 03, 2003 11:38 AM To: Wagner,William; HALL,DAVID (HP-Vancouver,ex1); imcdonald@sharplabs.com; BERKEMA,ALAN C (HP-Roseville,ex1) Cc: ps@pwg.org Subject: RE: PSI and Port 80, and printers traversing the firewall Hi Bill and All... See comments inline below.. Dave David, Many thanks for the consideration. 1. I may be getting confused with the terminology. PSI defines three types of entities all of which have "Client" capability. From Figure 1 in the Developer's Guide, lets call the user client the "Mobile Device". So one has: Mobile Device - with a client capability Print Service - Client Capability QueryEndpointsInterface ServiceCapabilitiesInterface JobControlInterface TargetDeviceSupportInterface TargetDevice- Client Capability JobControlInterface QueryEndpointsInterface ServiceCapabilitiesInterface Yep, the client term is difficult to nail down. I'll see if I can be more explicit in the following comments.. a. if there are no firewalls (or all components are inside a common network), there should be no problem using the psi-port communicating from any client to any interface b. in any case involving firewalls, any "server" interface needs special firewall handling, regardless of what port is used. Yep, exactly - the PSI "server" interfaces on a Print Service, and the PSI "server" interfaces on a Target Device. c. a mobile device may very well be trying to communicate to the Print Service through a foreign firewall, which does not support the PSI Port. So allowing the Mobile client a port 80 backup is highly desirable. This is the hope that by allowing a PSI Print Service to also expose PSI "server" interfaces over port 80 will allow for more deployment scenarios that if we restricted it to only 3700 d. it would seem that a target device might want to operate in only the client mode. (This appears to be in violation of the requirement that the target device support all interfaces, but it is an attractive capability regardless) The target therefore could pull jobs from a internet Print Service to which it subscribed. This would allow "internet printing" without needing special firewall handling for the Target Device. The need to provide special firewall handing is one reason why IPP has not become a widely used "internet" printing protocol. Allowing the target device to pull jobs from a server that can be accessed via the internet would resolve this problem. A true PSI Target Device does indeed need to implement the "server" interfaces. However, I don't believe that there is anything precluding vendors from implementing only the "client" side of a Target Device. This implementation of a Target Device simply makes the Target Device look like it is behind a firewall from the Print Services "client" perspective. This is a similiar situation to the "Bluetooth Target Device Proxy" where the handheld pretends to be a "Target Device" and pulls the data from the Print Service, and then pushes it to the printer via BlueTooth. But from your statement that "A Target Device shall implement PSI only on port psi-port", it is not clear to me that you are allowing the client in the target device to initiate a connection on port 80. I think that the intention here is that a Target Device shall implement the PSI "server" set of interfaces only on port psi-port. The "client" side of the Target Device should behaive as per the client rules - try 3700 first, then 80. I also do not understand your statement that: "If an administrator chooses to expose their print service on port 3700, then all traffic to it will be on 3700." Give the client "rule" that clients must try 3700 first, and then 80 - if a Print Service is exposed on 3700, then all PSI method invocations from clients will be on port 3700. I added this comment into the specification so that implementers / deployers understand that 3700 may be the only thing available. 2. With respect to my comment about MIS not allowing a printer to communicate with an external server, the operative words here are "without adding more restrictions". And when I made the statement, I did indicate the restrictions that were required in the WBMM context. I believe that in defining the interface that the printer will use in this context, you are defining the restrictions. That is, you are limiting the printer contacts and what can transpire between the printer and the service or client. I believe that this will be acceptable to most enterprises, although it may be necessary in some implementations to allow configuration of more constraints, such as not supporting some interfaces, requiring authentication or encryption and possibly disallowing certain operations. Yep, exactly. This makes a lot of sense. Regards, Bill Wagner/NetSilicon. -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Friday, February 28, 2003 9:51 AM To: 'imcdonald@sharplabs.com'; Wagner,William; BERKEMA,ALAN C (HP-Roseville,ex1) Cc: 'ps@pwg.org' Subject: PSI and Port 80, and printers traversing the firewall Hi Bill... A couple of questions for you... You mentioned the following with regards to PSI and port 80: I am very sad to hear that PSI will not use port 80; I think that will very much handicap the potential of what is an excellent capability. Of course, IPP was assigned port 631, but many implementations still listen on port 80 as well. In consideration of this, Ira and I spent some time looking at PSI, and the use of port 80, and port 3700 (psi-port), and came up with the following proposal: * A Print Service shall implement PSI on psi-port, and port 80 (and thus, the path to ALL psi interfaces must be of the form pwg-psips://server/psi/...) * A Target Device shall implement PSI only on port psi-port * A Client shall always try to communicate with a Print Service on psi-port first, and if that fails, then utilize port 80. We believe that this reasoning enables the following requirements: 1) A company can deploy a PSI Print Service on their normal, publically exposed web-server on port 80. 2) All communication to a Target Device is on port 3700 for network monitoring purposes. 3) Within and enterprise, communication between a client and a Print Service is on 3700 for network monitoring purposes. 4) If an administrator chooses to expose their print service on port 3700, then all traffic to it will be on 3700... Do you feel that this addresses your concerns? (And your customers?) Second: Having been though this at various places. Asking if they would allow a printer that talks to an external server, without adding more restrictions, will get a very quick NO. This model is very important for many of the PSI firewall traversing use models! I do think that implementers of Target Devices should not have their printers come configured "out of the box" with the ability to go and fetch data from an external server. This should probably be something that the administrator needs to enable for particular printers within their enterprise. However, once allowed by the administrator, these "public printers" would then be able to retrieve publically initiated print jobs. Another option is to only allow "authorized users" to initiate these out-bound requests. This would be accomplished by authenticating the user via http, and then the Target Device would need to authorize the user against an acl.. Comments?? Dave From dhall at hp.com Mon Mar 3 11:58:58 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:09 2009 Subject: PS> RE: PSI and Port 80, and printers traversing the firewall Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAB2D@xvan01.vcd.hp.com> Let see.. The "expose their print service on port 3700" means that the admin has installed a Print Service on a machine behind his firewall, and then "port forwarded" port 3700 to that machine, then the external clients will end up connecting to the Print Service on port 3700, not port 80. So while the physical Print Service box will be available on both 3700 and 80 internally, the administrator can still chose to expose only port 3700 beyond the firewall. Make sense? Dave -----Original Message----- From: Wagner,William [mailto:WWagner@NetSilicon.com] Sent: Monday, March 03, 2003 8:50 AM To: HALL,DAVID (HP-Vancouver,ex1); imcdonald@sharplabs.com; BERKEMA,ALAN C (HP-Roseville,ex1) Cc: ps@pwg.org Subject: RE: PSI and Port 80, and printers traversing the firewall Dave, The clarification is appreciated. However, I still seem to be missing something on: "If an administrator chooses to expose their print service on port 3700, then all traffic to it will be on 3700." Give the client "rule" that clients must try 3700 first, and then 80 - if a Print Service is exposed on 3700, then all PSI method invocations from clients will be on port 3700. I added this comment into the specification so that implementers / deployers understand that 3700 may be the only thing available. Doesn't that conflict with the proposal that "A Print Service shall implement PSI on psi-port, and port 80 ", which suggests that the print service must listen on both ports. And, given the instance where the mobile client cannot get through the firewall at his location via the PSI-port, should not the print service also listen on port 80? Thanks, Bill Wagner -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Monday, March 03, 2003 11:38 AM To: Wagner,William; HALL,DAVID (HP-Vancouver,ex1); imcdonald@sharplabs.com; BERKEMA,ALAN C (HP-Roseville,ex1) Cc: ps@pwg.org Subject: RE: PSI and Port 80, and printers traversing the firewall Hi Bill and All... See comments inline below.. Dave David, Many thanks for the consideration. 1. I may be getting confused with the terminology. PSI defines three types of entities all of which have "Client" capability. From Figure 1 in the Developer's Guide, lets call the user client the "Mobile Device". So one has: Mobile Device - with a client capability Print Service - Client Capability QueryEndpointsInterface ServiceCapabilitiesInterface JobControlInterface TargetDeviceSupportInterface TargetDevice- Client Capability JobControlInterface QueryEndpointsInterface ServiceCapabilitiesInterface Yep, the client term is difficult to nail down. I'll see if I can be more explicit in the following comments.. a. if there are no firewalls (or all components are inside a common network), there should be no problem using the psi-port communicating from any client to any interface b. in any case involving firewalls, any "server" interface needs special firewall handling, regardless of what port is used. Yep, exactly - the PSI "server" interfaces on a Print Service, and the PSI "server" interfaces on a Target Device. c. a mobile device may very well be trying to communicate to the Print Service through a foreign firewall, which does not support the PSI Port. So allowing the Mobile client a port 80 backup is highly desirable. This is the hope that by allowing a PSI Print Service to also expose PSI "server" interfaces over port 80 will allow for more deployment scenarios that if we restricted it to only 3700 d. it would seem that a target device might want to operate in only the client mode. (This appears to be in violation of the requirement that the target device support all interfaces, but it is an attractive capability regardless) The target therefore could pull jobs from a internet Print Service to which it subscribed. This would allow "internet printing" without needing special firewall handling for the Target Device. The need to provide special firewall handing is one reason why IPP has not become a widely used "internet" printing protocol. Allowing the target device to pull jobs from a server that can be accessed via the internet would resolve this problem. A true PSI Target Device does indeed need to implement the "server" interfaces. However, I don't believe that there is anything precluding vendors from implementing only the "client" side of a Target Device. This implementation of a Target Device simply makes the Target Device look like it is behind a firewall from the Print Services "client" perspective. This is a similiar situation to the "Bluetooth Target Device Proxy" where the handheld pretends to be a "Target Device" and pulls the data from the Print Service, and then pushes it to the printer via BlueTooth. But from your statement that "A Target Device shall implement PSI only on port psi-port", it is not clear to me that you are allowing the client in the target device to initiate a connection on port 80. I think that the intention here is that a Target Device shall implement the PSI "server" set of interfaces only on port psi-port. The "client" side of the Target Device should behaive as per the client rules - try 3700 first, then 80. I also do not understand your statement that: "If an administrator chooses to expose their print service on port 3700, then all traffic to it will be on 3700." Give the client "rule" that clients must try 3700 first, and then 80 - if a Print Service is exposed on 3700, then all PSI method invocations from clients will be on port 3700. I added this comment into the specification so that implementers / deployers understand that 3700 may be the only thing available. 2. With respect to my comment about MIS not allowing a printer to communicate with an external server, the operative words here are "without adding more restrictions". And when I made the statement, I did indicate the restrictions that were required in the WBMM context. I believe that in defining the interface that the printer will use in this context, you are defining the restrictions. That is, you are limiting the printer contacts and what can transpire between the printer and the service or client. I believe that this will be acceptable to most enterprises, although it may be necessary in some implementations to allow configuration of more constraints, such as not supporting some interfaces, requiring authentication or encryption and possibly disallowing certain operations. Yep, exactly. This makes a lot of sense. Regards, Bill Wagner/NetSilicon. -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Friday, February 28, 2003 9:51 AM To: 'imcdonald@sharplabs.com'; Wagner,William; BERKEMA,ALAN C (HP-Roseville,ex1) Cc: 'ps@pwg.org' Subject: PSI and Port 80, and printers traversing the firewall Hi Bill... A couple of questions for you... You mentioned the following with regards to PSI and port 80: I am very sad to hear that PSI will not use port 80; I think that will very much handicap the potential of what is an excellent capability. Of course, IPP was assigned port 631, but many implementations still listen on port 80 as well. In consideration of this, Ira and I spent some time looking at PSI, and the use of port 80, and port 3700 (psi-port), and came up with the following proposal: * A Print Service shall implement PSI on psi-port, and port 80 (and thus, the path to ALL psi interfaces must be of the form pwg-psips://server/psi/...) * A Target Device shall implement PSI only on port psi-port * A Client shall always try to communicate with a Print Service on psi-port first, and if that fails, then utilize port 80. We believe that this reasoning enables the following requirements: 1) A company can deploy a PSI Print Service on their normal, publically exposed web-server on port 80. 2) All communication to a Target Device is on port 3700 for network monitoring purposes. 3) Within and enterprise, communication between a client and a Print Service is on 3700 for network monitoring purposes. 4) If an administrator chooses to expose their print service on port 3700, then all traffic to it will be on 3700... Do you feel that this addresses your concerns? (And your customers?) Second: Having been though this at various places. Asking if they would allow a printer that talks to an external server, without adding more restrictions, will get a very quick NO. This model is very important for many of the PSI firewall traversing use models! I do think that implementers of Target Devices should not have their printers come configured "out of the box" with the ability to go and fetch data from an external server. This should probably be something that the administrator needs to enable for particular printers within their enterprise. However, once allowed by the administrator, these "public printers" would then be able to retrieve publically initiated print jobs. Another option is to only allow "authorized users" to initiate these out-bound requests. This would be accomplished by authenticating the user via http, and then the Target Device would need to authorize the user against an acl.. Comments?? Dave From alan.berkema at hp.com Mon Mar 3 12:40:09 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:09 2009 Subject: PS> [PSI]: minutes 2/18; next call 03/04/03 Message-ID: <499DC368E25AD411B3F100902740AD650E6AD6E5@xrose03.rose.hp.com> Teleconference details: NEXT: Tuesday March 04 2003 (USA) Time: 8 AM (US PST) Number: 866-639-4738 Participant PIN: 7855605 Agenda: 1) PSI Port 2) Difficulty with AddDocumentByPost 3) Ready for Last Call 4) ? Meeting 02/18/03 PSI Working Group: *Alan Berkema *Dave Hall Gail Songer Jerry Thasher *Harry Lewis Ted Tronson Peter Mierau Peter Zehler Paul Tykodi *Bob Taylor Don Levinstone Lee Farrell Don Wright Kirk Ocke *Ira Mcdonald Amir Shahindoust Alain Regnier * = attendance Agenda: 1) Review Create Fetch Job 2) Schedule Update Brief Minutes 02/18/03 Minutes: 1) This is the function that is intended to solve the "and then a Miracle happens" when a client originates a job directly to the PS when the PS cannot contact the Target. Looking at this method lead to lots of good discussion around some of the methods that have not to date been scrutinized as closely as the main stream methods. Summary: 1) Create does not make sense in the method name, job was already created this just says go get it. Method name changed to just fetchJob. 2) This kicks off the getJobs method 3) Followed by getNextJob 0) Another out come was that associateTargetDevice was sorta half baked and we really only need registerTargetDevice. Lots of detail in latest rev. ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030303.doc ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030303.pdf 2) Schedule will discuss "last call" readiness at next call ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 27995593 Meeting Password: newpsi Host: Alan Berkema 1(916)7855605 From alan.berkema at hp.com Mon Mar 3 13:32:31 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:09 2009 Subject: PS> [PSI]: January 03 F2F Minutes Message-ID: <499DC368E25AD411B3F100902740AD650E6AD6E9@xrose03.rose.hp.com> Proposed meeting minutes have been posted ftp://ftp.pwg.org/pub/pwg/ps/wd/PSIMeetingMinutes0103.pdf Thanks Jerry, Alan From imcdonald at sharplabs.com Mon Mar 3 16:48:24 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:09 2009 Subject: PS> [PSI]: [corrected URL] January 03 F2F Minutes Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF19@mailsrvnt02.enet.sharplabs.com> Hi, The URL below is incorrect. The actual location is: ftp://ftp.pwg.org/pub/pwg/ps/PSIMeetingMinutes0103.pdf Thanks again Jerry, - Ira McDonald High North Inc -----Original Message----- From: BERKEMA,ALAN C (HP-Roseville,ex1) [mailto:alan.berkema@hp.com] Sent: Monday, March 03, 2003 12:33 PM To: 'a PSI pwg.org' Subject: PS> [PSI]: January 03 F2F Minutes Proposed meeting minutes have been posted ftp://ftp.pwg.org/pub/pwg/ps/wd/PSIMeetingMinutes0103.pdf Thanks Jerry, Alan From alain at tpo.ussj.ricoh.com Mon Mar 3 21:12:08 2003 From: alain at tpo.ussj.ricoh.com (Alain Regnier) Date: Wed May 6 14:02:09 2009 Subject: PS> a few questions about the current specification Message-ID: <60B6A4FA4A8CBC47A9B8B7DA28655C0C04C8AD@w2ksvr.tpo.ussj.ricoh.com> What is meant exactly by Method Support in the specification? Do we talk about the "implementation" or the "utilization" of an interface or a method? If we talk about the implementation, I don't really see why "CreateJob" and "CloseJob" are mandatory for Clients. (Why should Clients implement these methods?) 5.5.6 Regarding the filtering criteria of GetJobs, I'm not sure why we have to support element by element filtering. Isn't "group of elements" filtering enough? Do we really need such a granularity? It makes implementation more complex, and I'm not sure the gain in term of bandwidth, or XML processing is that good. (and you have to process the XML document anyway) 5.12 for FetchJobs, what else than JobURI, JobAccountingUserID and JobPassword might be needed in the jobFilter? Do we expect the Print Service to do any kind of filtering on other elements? Alain Regnier Ricoh Corp From dhall at hp.com Tue Mar 4 15:46:17 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:09 2009 Subject: PS> Separating WSDL into 3 files Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAB49@xvan01.vcd.hp.com> Hey All.. Does anyone know the syntatically correct way to do this? I'm in the JobCntrolBinding.wsdl, trying to figure out how to include the JobControlInterface.wsdl Dave From dhall at hp.com Tue Mar 4 18:25:03 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:09 2009 Subject: PS> PSI wd-psi10-20030304 Available Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAB4E@xvan01.vcd.hp.com> Hey All.. The latest working draft of the PSI 1.0 Specification is available at: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030304.doc ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030304.pdf It includes a new JobControl method - PushDocument, and the change of AddDocumentByPost to AddDocumentByPush. Thanks! Dave From dhall at hp.com Wed Mar 5 14:55:08 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:09 2009 Subject: PS> Successful PSI SOAP conversation! :) Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAB58@xvan01.vcd.hp.com> Hey All! We've gotten our first successful SOAP interaction between our JUnit test harness and our server! :) Here's a dump of the conversation. There is some clean-up to do to make it fully PSI spec compliant, but it should give you an idea of the client -> server interaction. (Note that this box is not publicly accessible. We hope to have a public ally accessible deployment for preliminary interops sometime in the next couple of weeks.) The basic set of calls are as follows: 1. HTTP request on PSI ServiceRootURL returns http://vcsdhall4.vcd.hp.com:3701/axis/services/QueryEndPointsInterface 2. QueryInterfaceDefinition(JobControlInterface) returns http://vcsdhall4.vcd.hp.com:3701/axis/services/JobControlInterface 3. CreateJob, AddDocumentByReference 4. Go into polling loop, calling GetJobElements, looking for completed state Dave tcpTrace version 0.6.0.648 Copyright 2000-2001 Simon Fell & Matt Humphrey. All rights reserved. Log Started, 03/05/2003 11:16:55:0484 Logged at, 03/05/2003 11:17:01:0671 GET /psi/0.95 HTTP/1.1 User-Agent: Java/1.4.1_01 Host: localhost:3701 Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2 Connection: keep-alive HTTP/1.1 200 OK Content-Type: text/plain Content-Length: 70 Date: Wed, 05 Mar 2003 19:17:01 GMT Server: Apache Coyote/1.0 http://vcsdhall4.vcd.hp.com:3701/axis/services/QueryEndPointsInterface Connection Opened, 03/05/2003 11:17:01:0640 Connection Closed, 03/05/2003 11:17:01:0671 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 950 # Bytes Server -> Client, 766 Client Data, POST /axis/services/QueryEndPointsInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "QueryInterfaceDefinition" Content-Length: 618 JobControlInterface 0.95 pwg-sm false Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:01 GMT Server: Apache Coyote/1.0 Connection: close http://vcsdhall4.vcd.hp.com:3701/axis/services/JobControlInterface< /InterfaceEndPointURI> http://vcsdhall4.vcd.hp.com:3701/axis/services/JobControlInterface/ wsdl Logged at, 03/05/2003 11:17:03:0671 Connection Opened, 03/05/2003 11:17:03:0359 Connection Closed, 03/05/2003 11:17:03:0671 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 1343 # Bytes Server -> Client, 601 Client Data, POST /axis/services/JobControlInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "CreateJob" Content-Length: 1029 pwg-unc://mep-print-serv/null true false Example PSI Job PSI User Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:03 GMT Server: Apache Coyote/1.0 Connection: close urn:uuid:61033211-f6e0-47fb-8eed-e4d864f4a25f Logged at, 03/05/2003 11:17:03:0781 Connection Opened, 03/05/2003 11:17:03:0703 Connection Closed, 03/05/2003 11:17:03:0781 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 986 # Bytes Server -> Client, 637 Client Data, POST /axis/services/JobControlInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "AddDocumentByReference" Content-Length: 660 urn:uuid:61033211-f6e0-47fb-8eed-e4d864f4a25f http://www.pwg.org/ps true Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:03 GMT Server: Apache Coyote/1.0 Connection: close urn:uuid:ad5309e1-cacf-46d5-a3ca-ea0cf0982177 Logged at, 03/05/2003 11:17:04:0218 Connection Opened, 03/05/2003 11:17:03:0843 Connection Closed, 03/05/2003 11:17:04:0218 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 927 # Bytes Server -> Client, 659 Client Data, POST /axis/services/JobControlInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "GetJobElements" Content-Length: 609 urn:uuid:61033211-f6e0-47fb-8eed-e4d864f4a25f processing Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:03 GMT Server: Apache Coyote/1.0 Connection: close pending Logged at, 03/05/2003 11:17:05:0265 Connection Opened, 03/05/2003 11:17:05:0234 Connection Closed, 03/05/2003 11:17:05:0265 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 927 # Bytes Server -> Client, 659 Client Data, POST /axis/services/JobControlInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "GetJobElements" Content-Length: 609 urn:uuid:61033211-f6e0-47fb-8eed-e4d864f4a25f processing Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:05 GMT Server: Apache Coyote/1.0 Connection: close pending Logged at, 03/05/2003 11:17:06:0312 Connection Opened, 03/05/2003 11:17:06:0265 Connection Closed, 03/05/2003 11:17:06:0312 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 927 # Bytes Server -> Client, 659 Client Data, POST /axis/services/JobControlInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "GetJobElements" Content-Length: 609 urn:uuid:61033211-f6e0-47fb-8eed-e4d864f4a25f processing Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:06 GMT Server: Apache Coyote/1.0 Connection: close pending Logged at, 03/05/2003 11:17:07:0421 Connection Opened, 03/05/2003 11:17:07:0375 Connection Closed, 03/05/2003 11:17:07:0421 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 927 # Bytes Server -> Client, 662 Client Data, POST /axis/services/JobControlInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "GetJobElements" Content-Length: 609 urn:uuid:61033211-f6e0-47fb-8eed-e4d864f4a25f processing Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:07 GMT Server: Apache Coyote/1.0 Connection: close processing Logged at, 03/05/2003 11:17:08:0468 Connection Opened, 03/05/2003 11:17:08:0421 Connection Closed, 03/05/2003 11:17:08:0468 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 927 # Bytes Server -> Client, 662 Client Data, POST /axis/services/JobControlInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "GetJobElements" Content-Length: 609 urn:uuid:61033211-f6e0-47fb-8eed-e4d864f4a25f processing Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:08 GMT Server: Apache Coyote/1.0 Connection: close processing Logged at, 03/05/2003 11:17:09:0531 Connection Opened, 03/05/2003 11:17:09:0484 Connection Closed, 03/05/2003 11:17:09:0531 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 927 # Bytes Server -> Client, 662 Client Data, POST /axis/services/JobControlInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "GetJobElements" Content-Length: 609 urn:uuid:61033211-f6e0-47fb-8eed-e4d864f4a25f processing Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:09 GMT Server: Apache Coyote/1.0 Connection: close processing Logged at, 03/05/2003 11:17:10:0593 Connection Opened, 03/05/2003 11:17:10:0546 Connection Closed, 03/05/2003 11:17:10:0593 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 927 # Bytes Server -> Client, 662 Client Data, POST /axis/services/JobControlInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "GetJobElements" Content-Length: 609 urn:uuid:61033211-f6e0-47fb-8eed-e4d864f4a25f processing Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:10 GMT Server: Apache Coyote/1.0 Connection: close processing Logged at, 03/05/2003 11:17:11:0562 Connection Opened, 03/05/2003 11:17:01:0562 Connection Closed, 03/05/2003 11:17:11:0562 Source, 127.0.0.1 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 161 # Bytes Server -> Client, 199 Client Data, GET /psi/0.95 HTTP/1.1 User-Agent: Java/1.4.1_01 Host: localhost:3701 Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2 Connection: keep-alive Server Data, HTTP/1.1 200 OK Content-Type: text/plain Content-Length: 70 Date: Wed, 05 Mar 2003 19:17:01 GMT Server: Apache Coyote/1.0 http://vcsdhall4.vcd.hp.com:3701/axis/services/QueryEndPointsInterface Logged at, 03/05/2003 11:17:11:0687 Connection Opened, 03/05/2003 11:17:11:0656 Connection Closed, 03/05/2003 11:17:11:0687 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 927 # Bytes Server -> Client, 662 Client Data, POST /axis/services/JobControlInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "GetJobElements" Content-Length: 609 urn:uuid:61033211-f6e0-47fb-8eed-e4d864f4a25f processing Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:11 GMT Server: Apache Coyote/1.0 Connection: close processing Logged at, 03/05/2003 11:17:12:0750 Connection Opened, 03/05/2003 11:17:12:0703 Connection Closed, 03/05/2003 11:17:12:0750 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 927 # Bytes Server -> Client, 662 Client Data, POST /axis/services/JobControlInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "GetJobElements" Content-Length: 609 urn:uuid:61033211-f6e0-47fb-8eed-e4d864f4a25f processing Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:12 GMT Server: Apache Coyote/1.0 Connection: close processing Logged at, 03/05/2003 11:17:13:0796 Connection Opened, 03/05/2003 11:17:13:0750 Connection Closed, 03/05/2003 11:17:13:0796 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 927 # Bytes Server -> Client, 662 Client Data, POST /axis/services/JobControlInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "GetJobElements" Content-Length: 609 urn:uuid:61033211-f6e0-47fb-8eed-e4d864f4a25f processing Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:13 GMT Server: Apache Coyote/1.0 Connection: close processing Logged at, 03/05/2003 11:17:14:0859 Connection Opened, 03/05/2003 11:17:14:0812 Connection Closed, 03/05/2003 11:17:14:0859 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 927 # Bytes Server -> Client, 662 Client Data, POST /axis/services/JobControlInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "GetJobElements" Content-Length: 609 urn:uuid:61033211-f6e0-47fb-8eed-e4d864f4a25f processing Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:14 GMT Server: Apache Coyote/1.0 Connection: close processing Logged at, 03/05/2003 11:17:15:0906 Connection Opened, 03/05/2003 11:17:15:0859 Connection Closed, 03/05/2003 11:17:15:0906 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 927 # Bytes Server -> Client, 662 Client Data, POST /axis/services/JobControlInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "GetJobElements" Content-Length: 609 urn:uuid:61033211-f6e0-47fb-8eed-e4d864f4a25f processing Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:15 GMT Server: Apache Coyote/1.0 Connection: close processing Logged at, 03/05/2003 11:17:17:0031 Connection Opened, 03/05/2003 11:17:16:0984 Connection Closed, 03/05/2003 11:17:17:0031 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 927 # Bytes Server -> Client, 662 Client Data, POST /axis/services/JobControlInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "GetJobElements" Content-Length: 609 urn:uuid:61033211-f6e0-47fb-8eed-e4d864f4a25f processing Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:17 GMT Server: Apache Coyote/1.0 Connection: close processing Logged at, 03/05/2003 11:17:18:0078 Connection Opened, 03/05/2003 11:17:18:0046 Connection Closed, 03/05/2003 11:17:18:0078 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 927 # Bytes Server -> Client, 662 Client Data, POST /axis/services/JobControlInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "GetJobElements" Content-Length: 609 urn:uuid:61033211-f6e0-47fb-8eed-e4d864f4a25f processing Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:18 GMT Server: Apache Coyote/1.0 Connection: close processing Logged at, 03/05/2003 11:17:19:0125 Connection Opened, 03/05/2003 11:17:19:0093 Connection Closed, 03/05/2003 11:17:19:0125 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 927 # Bytes Server -> Client, 662 Client Data, POST /axis/services/JobControlInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "GetJobElements" Content-Length: 609 urn:uuid:61033211-f6e0-47fb-8eed-e4d864f4a25f processing Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:19 GMT Server: Apache Coyote/1.0 Connection: close processing Logged at, 03/05/2003 11:17:20:0312 Connection Opened, 03/05/2003 11:17:20:0281 Connection Closed, 03/05/2003 11:17:20:0312 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 927 # Bytes Server -> Client, 662 Client Data, POST /axis/services/JobControlInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "GetJobElements" Content-Length: 609 urn:uuid:61033211-f6e0-47fb-8eed-e4d864f4a25f processing Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:20 GMT Server: Apache Coyote/1.0 Connection: close processing Logged at, 03/05/2003 11:17:21:0343 Connection Opened, 03/05/2003 11:17:21:0312 Connection Closed, 03/05/2003 11:17:21:0343 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 927 # Bytes Server -> Client, 662 Client Data, POST /axis/services/JobControlInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "GetJobElements" Content-Length: 609 urn:uuid:61033211-f6e0-47fb-8eed-e4d864f4a25f processing Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:21 GMT Server: Apache Coyote/1.0 Connection: close processing Logged at, 03/05/2003 11:17:22:0375 Connection Opened, 03/05/2003 11:17:22:0359 Connection Closed, 03/05/2003 11:17:22:0375 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 927 # Bytes Server -> Client, 662 Client Data, POST /axis/services/JobControlInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "GetJobElements" Content-Length: 609 urn:uuid:61033211-f6e0-47fb-8eed-e4d864f4a25f processing Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:22 GMT Server: Apache Coyote/1.0 Connection: close processing Logged at, 03/05/2003 11:17:23:0437 Connection Opened, 03/05/2003 11:17:23:0390 Connection Closed, 03/05/2003 11:17:23:0437 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 927 # Bytes Server -> Client, 662 Client Data, POST /axis/services/JobControlInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "GetJobElements" Content-Length: 609 urn:uuid:61033211-f6e0-47fb-8eed-e4d864f4a25f processing Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:23 GMT Server: Apache Coyote/1.0 Connection: close processing Logged at, 03/05/2003 11:17:24:0531 Connection Opened, 03/05/2003 11:17:24:0515 Connection Closed, 03/05/2003 11:17:24:0531 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 927 # Bytes Server -> Client, 661 Client Data, POST /axis/services/JobControlInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "GetJobElements" Content-Length: 609 urn:uuid:61033211-f6e0-47fb-8eed-e4d864f4a25f processing Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:24 GMT Server: Apache Coyote/1.0 Connection: close completed From alan.berkema at hp.com Wed Mar 5 18:44:35 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:09 2009 Subject: PS> [PSI]: minutes03/04/03; next call 03/11/03 Message-ID: <499DC368E25AD411B3F100902740AD650E6AD716@xrose03.rose.hp.com> Teleconference details: NEXT: Tuesday March 11 2003 (USA) Time: 8 AM (US PST) Number: 866-639-4738 Participant PIN: 7855605 Agenda: 1) Alain's e-mail Questions 2) addDocumnetByPush review 3) Ready for Last Call 4) ? Meeting 03/04/03 PSI Working Group: *Alan Berkema *Dave Hall Gail Songer -Jerry Thasher *Harry Lewis *Ted Tronson *Peter Mierau *Peter Zehler Paul Tykodi Bob Taylor Don Levinstone Lee Farrell Don Wright Kirk Ocke *Ira Mcdonald Amir Shahindoust *Alain Regnier *Mike Haller * = attendance Agenda: 1) PSI Port vs. Port 80 2) Difficulty with AddDocumentByPost 3) Alternate transport? 4) Alain's questions 5) Ready for Last Call Minutes: 1) Some desire to use PSI over port 80, some existing web servers and small office may only expose port 80. The psiport allows all trafiic to routed through this port and has load balancing advantages. Seperate accounting and security is also an advantage. See Ira's past discussion on Dynamic vs. Static ports at the end of these minutes for additional info. Summary: PSI devices will try the psiport first and this is the preffered port. Port 80 may be used as a last resort if the psiport fails. Port number 55559 will be used as the proto type port until we get an IANA number. 2 & 3) addDocumentByPost was changed to addDocumentByPush. This is followed by an HTTP PUT for data transfer *OR* a pushDocument method which passes the data by value, the data type is restricted to bin64 encoding PushDocument (documentURI : URI, documentData : base64Binary) : void The closeJob() method will replace the lastDocument flag in the addDocument* methods. This fixes a lot of logical holes. Much discussion about the error code for when a closeJob() occurs before all data has actually been transferred. I think "clientErrorDataPending" may be in the lead however, sequence error was a contender at one point. Need to carefully review all exception codes. 4) Alain's questions Even after running over time by close to an hour we did not get to this, it's up first next time. 5) Schedule will discuss "last call" readiness at next call Not ready yet, however, the pending "last call" seems to be getting folks to voice some needed improvements. Thanks, Alan ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 27995593 Meeting Password: newpsi Host: Alan Berkema 1(916)7855605 ---------------------------------------------------------------------------- - PSI interfaces SHOULD have a static port (IANA-registered by vendor 'PWG') that is always the PSI listen port. PSI interfaces SHOULD NOT use dynamic ports (even by protocol agreement during PSI WSDL sessions), because: 1) Firewalls and NAT (Network Address Translator) systems assume that all protocols allowed to pass (traverse the domain boundary) use static IANA-registered ports (permission rules are normally based on a specific application protocol over a specific numbered port). Firewalls/NATs often implement ALGs (Application Layer Gateways) that enforce fine-grained permission rules. But the premise is always that the protocol on a given port is INVARIANT, and is determined by the port number (FTP proxies are fundamentally dangerous, for this reason). Dynamic ports completely defeat ALGs and firewall permissions (thus destroying the 'security perimeter' of the firewall). (There are a series of horrible exceptions in ALGs around HTTP port 80, due to other 'hidden' application protocols - PSI should not go there...) 2) Boundary routers (between enterprise and public networks) and core routers (within the Internet backbone) manage quality of service and packet delivery by 'aggregating' destinations (host/port pairs) for routing decisions. Dynamic ports completely defeat traffic 'aggregation' (because the router has no way to know that the alternate port traffic is associated with the original static port traffic). Routers also block all ports that are not specifically authorized to cross a domain boundary (in one direction or the other - not necessarily both) in their permission rules. Dynamic ports simply won't work in the general case. Hope this helps. Cheers, - Ira McDonald High North Inc From imcdonald at sharplabs.com Thu Mar 6 10:28:29 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:09 2009 Subject: PS> Rationale for interim psi-port Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF20@mailsrvnt02.enet.sharplabs.com> Hi folks, As we discussed briefly on Tuesday, our recommendation, until IANA gives us an official "registered port" (greater than 1024), is to use "ephemeral port" 55559 as the interim psi-port for our prototyping and early testing (see section 5.1.1 of the spec that Dave Hall just posted). I just pulled down a current copy of the IANA Port Registry and found: lrs-paging 3700/tcp LRS NetPage lrs-paging 3700/udp LRS NetPage # Geoffrey Wossum February 2003 Cheers, - Ira McDonald High North Inc PS - An "ephemeral" or "dynamic" port is one greater than 49151. Such ports are used (for example) for the data transfer port for FTP (the control port MUST be 21). No one can reliably use an "ephemeral" port long-term. From alan.berkema at hp.com Mon Mar 10 12:15:15 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:09 2009 Subject: PS> [PSI]: additional number; next call 03/11/03 Message-ID: <499DC368E25AD411B3F100902740AD650E6AD735@xrose03.rose.hp.com> -----Original Message----- From: BERKEMA,ALAN C (HP-Roseville,ex1) [mailto:alan.berkema@hp.com] Sent: Wednesday, March 05, 2003 3:45 PM To: 'a PSI pwg.org' Subject: PS> [PSI]: minutes03/04/03; next call 03/11/03 Teleconference details: NEXT: Tuesday March 11 2003 (USA) Time: 8 AM (US PST) Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Alain's e-mail Questions 2) addDocumnetByPush review 3) Ready for Last Call 4) ? Meeting 03/04/03 PSI Working Group: *Alan Berkema *Dave Hall Gail Songer -Jerry Thasher *Harry Lewis *Ted Tronson *Peter Mierau *Peter Zehler Paul Tykodi Bob Taylor Don Levinstone Lee Farrell Don Wright Kirk Ocke *Ira Mcdonald Amir Shahindoust *Alain Regnier *Mike Haller * = attendance Agenda: 1) PSI Port vs. Port 80 2) Difficulty with AddDocumentByPost 3) Alternate transport? 4) Alain's questions 5) Ready for Last Call Minutes: 1) Some desire to use PSI over port 80, some existing web servers and small office may only expose port 80. The psiport allows all trafiic to routed through this port and has load balancing advantages. Seperate accounting and security is also an advantage. See Ira's past discussion on Dynamic vs. Static ports at the end of these minutes for additional info. Summary: PSI devices will try the psiport first and this is the preffered port. Port 80 may be used as a last resort if the psiport fails. Port number 55559 will be used as the proto type port until we get an IANA number. 2 & 3) addDocumentByPost was changed to addDocumentByPush. This is followed by an HTTP PUT for data transfer *OR* a pushDocument method which passes the data by value, the data type is restricted to bin64 encoding PushDocument (documentURI : URI, documentData : base64Binary) : void The closeJob() method will replace the lastDocument flag in the addDocument* methods. This fixes a lot of logical holes. Much discussion about the error code for when a closeJob() occurs before all data has actually been transferred. I think "clientErrorDataPending" may be in the lead however, sequence error was a contender at one point. Need to carefully review all exception codes. 4) Alain's questions Even after running over time by close to an hour we did not get to this, it's up first next time. 5) Schedule will discuss "last call" readiness at next call Not ready yet, however, the pending "last call" seems to be getting folks to voice some needed improvements. Thanks, Alan ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 27995593 Meeting Password: newpsi Host: Alan Berkema 1(916)7855605 ---------------------------------------------------------------------------- - PSI interfaces SHOULD have a static port (IANA-registered by vendor 'PWG') that is always the PSI listen port. PSI interfaces SHOULD NOT use dynamic ports (even by protocol agreement during PSI WSDL sessions), because: 1) Firewalls and NAT (Network Address Translator) systems assume that all protocols allowed to pass (traverse the domain boundary) use static IANA-registered ports (permission rules are normally based on a specific application protocol over a specific numbered port). Firewalls/NATs often implement ALGs (Application Layer Gateways) that enforce fine-grained permission rules. But the premise is always that the protocol on a given port is INVARIANT, and is determined by the port number (FTP proxies are fundamentally dangerous, for this reason). Dynamic ports completely defeat ALGs and firewall permissions (thus destroying the 'security perimeter' of the firewall). (There are a series of horrible exceptions in ALGs around HTTP port 80, due to other 'hidden' application protocols - PSI should not go there...) 2) Boundary routers (between enterprise and public networks) and core routers (within the Internet backbone) manage quality of service and packet delivery by 'aggregating' destinations (host/port pairs) for routing decisions. Dynamic ports completely defeat traffic 'aggregation' (because the router has no way to know that the alternate port traffic is associated with the original static port traffic). Routers also block all ports that are not specifically authorized to cross a domain boundary (in one direction or the other - not necessarily both) in their permission rules. Dynamic ports simply won't work in the general case. Hope this helps. Cheers, - Ira McDonald High North Inc From dhall at hp.com Mon Mar 10 12:45:53 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:09 2009 Subject: PS> New PSI 1.0 Working Draft 20030310 Available Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAB71@xvan01.vcd.hp.com> Hey All... The latest version of the PSI specification is available. It includes references to new WSDL, and the new WSDL points to the latest semantic model schema definitions. ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030310.doc ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030310.pdf Schemas: http://www.pwg.org/schemas/ps/20030310/QueryEndPointsInterface.wsdl http://www.pwg.org/schemas/ps/20030310/ServiceCapabilitiesInterface.wsdl http://www.pwg.org/schemas/ps/20030310/JobControlInterface.wsdl http://www.pwg.org/schemas/ps/20030310/TargetDeviceSupportInterface.wsdl Dave From dhall at hp.com Mon Mar 10 16:24:00 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:09 2009 Subject: FW: PS> New PSI 1.0 Working Draft 20030310 Available Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAB7B@xvan01.vcd.hp.com> Also... It includes the new definitions for the interfaces AddDocumentBy*, PushDocument Dave -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Monday, March 10, 2003 9:46 AM To: 'ps@pwg.org' Subject: PS> New PSI 1.0 Working Draft 20030310 Available Hey All... The latest version of the PSI specification is available. It includes references to new WSDL, and the new WSDL points to the latest semantic model schema definitions. ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030310.doc ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030310.pdf Schemas: http://www.pwg.org/schemas/ps/20030310/QueryEndPointsInterface.wsdl http://www.pwg.org/schemas/ps/20030310/ServiceCapabilitiesInterface.wsdl http://www.pwg.org/schemas/ps/20030310/JobControlInterface.wsdl http://www.pwg.org/schemas/ps/20030310/TargetDeviceSupportInterface.wsdl Dave From alan.berkema at hp.com Thu Mar 13 18:03:43 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:09 2009 Subject: PS> [PSI]: next call 03/18/03 mins 3/11 Message-ID: <499DC368E25AD411B3F100902740AD650E6AD772@xrose03.rose.hp.com> Teleconference details: NEXT: Tuesday March 18 2003 (USA) Time: 8 AM (US PST) Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) closeDocument 2) The Mandatory vs. Supported language action (see 1.1 below) 3) FetchJobs filter example note (see 1.3 below) 4) Other Spec. Changes Review 5) Ready for Last Call Meeting 03/04/03 PSI Working Group: *Alan Berkema *Dave Hall *Gail Songer *Jerry Thasher Harry Lewis *Ted Tronson Peter Mierau Peter Zehler Paul Tykodi *Bob Taylor Don Levinstone Lee Farrell Don Wright Kirk Ocke *Ira Mcdonald Amir Shahindoust Alain Regnier Mike Haller *Darrell Hopp * = attendance Minutes: Agenda: 1) Alain's e-mail Questions 2) addDocumnetByPush review 3) Ready for Last Call 4) ? 2) Once addDocumnetByPush is submitted no more addDoc operations permitted until data has completed. Other methods such as cancel or status are OK. closeDocument indicates that the data transfer has completed. Still some discussion pending on this method. 1) Alain's questions 1.1) What is meant exactly by Method Support in the specification? Do we talk about the "implementation" or the "utilization" of an interface or a method? If we talk about the implementation, I don't really see why "CreateJob" and "CloseJob" are mandatory for Clients. (Why should Clients implement these methods?) Method support means the method shall be implemented. Dave will fix the specfifcation to state the intent more clearly in terms of shall be implemented and client is required to call etc. 1.2) 5.5.6 Regarding the filtering criteria of GetJobs, I'm not sure why we have to support element by element filtering. Isn't "group of elements" filtering enough? Do we really need such a granularity? It makes implementation more complex, and I'm not sure the gain in term of bandwidth, or XML processing is that good. (and you have to process the XML document anyway) Believe that the level of filtering is appropriate. The complexity is in the Sevice and having less granularity may actually make it more complex for the Client. 1.3) 5.12 for FetchJobs, what else than JobURI, JobAccountingUserID and JobPassword might be needed in the jobFilter? Do we expect the Print Service to do any kind of filtering on other elements? These are not the only possibilities. The example should note that these values are the only possibilities. 3) Determine if the spec is ready to begin a 4 week last call cycle F2F April 4 2003 Line by line editorial review Last Call Straw Vote - need concrete comments to vote against Interop Proto testing plans and schedule 3/24 is the last date to post slides other presentations for F2F Action: Prepare PSI presentation for FSG F2F Owner: Dave & Alan Status: 4) Get Jobs - improved language Only the jobs that the user is authorized to view shall be returned. From dhall at hp.com Fri Mar 14 11:11:39 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:09 2009 Subject: PS> PSI 1.0 Working Draft 20030221 Available Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAB94@xvan01.vcd.hp.com> Hey All.. The latest updated doc is available at: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030313.doc ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030313.pdf It includes the new ClosePushDocument method. (Renamed from CloseDocument, since it is only utilized after AddDocumentByPush) Dave From dhall at hp.com Mon Mar 17 20:06:15 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:09 2009 Subject: PS> Please Review!: PSI Spec wd-psi10-20030317 Available Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FABA9@xvan01.vcd.hp.com> Hey All.. The latest Spec is available at: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030317.doc ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030317.pdf In finishing up the ClosePushDocument method, I realized that we needed to consider the parallel methods in the TargetDeviceSupport interface. To this end, I have made the following changes to the specification. Please review and be ready to comment in tomorrows phone conference. (Sorry for the late notice!) New TargetDeviceSupportIInterface Methods: CloseJob... (Mirrors JobControl CloseJob) PullDocument... (Mirrors JobControl PushDocument in band data) ClosePullDocument... (Mirrors JobControl ClosePushDocument) Changed methods in TargetDeviceSupportInterface: GetNextDocument -> Now returns a DataSourceURIs - a container of URI's of which the client can choose which one to pull the data from. Thanks! Dave From harryl at us.ibm.com Tue Mar 18 12:58:36 2003 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:02:09 2009 Subject: PS> Soap with attachments - relation to SOAP 1.1 Message-ID: See http://www.w3.org/TR/SOAP-attachments section 4. Seems this has been around for quite a while. I suspect we'd have better interop than we anticipate. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/ps/attachments/20030318/769bc084/attachment.html From dan_revel at hp.com Wed Mar 19 12:21:35 2003 From: dan_revel at hp.com (REVEL,DAN (HP-Vancouver,ex1)) Date: Wed May 6 14:02:09 2009 Subject: PS> Soap with attachments - relation to SOAP 1.1 Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF92E828@xvan01.vcd.hp.com> SOAP-attachments was a W3C submission, Microsoft et al. made a competing proposal, DIME, that seems to have more momentum: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwebsrv/ht ml/dimewsattch.asp -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, March 18, 2003 9:59 AM To: ps@pwg.org Subject: PS> Soap with attachments - relation to SOAP 1.1 See http://www.w3.org/TR/SOAP-attachments section 4. Seems this has been around for quite a while. I suspect we'd have better interop than we anticipate. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/ps/attachments/20030319/d9aa445c/attachment.html From imcdonald at sharplabs.com Wed Mar 19 13:36:13 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:09 2009 Subject: PS> Soap with attachments - relation to SOAP 1.1 Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF3A@mailsrvnt02.enet.sharplabs.com> Hi Dan, We're aware of DIME. But the concensus of the PSI working group members is that the in-band transmission of document data MUST always be Base64 wrapped binary data. PSI (like IPP) identifies authoritatively, in the separate "document-format" attribute, the wrapped binary data format, using an IANA-registered MIME type. In PSI, this method is called "AddDocumentByValue". In PSI, two other methods exist: - "AddDocumentByPush" RETURNS a list of data sink URIs. The PSI client selects a data sink URI (for example "http:...") and pushes the document data out-of-band and then calls the in-band method "PushDocumentDataDelivered" (to avoid the PSI server having to poll the repository to see when the out-of-band document data has been delivered). - "AddDocumentByReference" SENDS an out-of-band reference to the document data. But since PSI messages are transferred in SOAP message envelopes, the reference MAY point to the IN-BAND document data later in the same SOAP message. Thus the discussion of the support (or lack of it) for the original "SOAP with Attachments". If many/any of the deployed proxies or intermediaries do NOT support this flavor of "SOAP with Attachments" then we want to deprecate such a use of "AddDocumentByReference" in the parallel PSI Developers Guide (the implementors guide for PSI). Note that because of the DIME versus MIME nonsense, the PSI method "AddDocumentByValue" MUST always wrap the binary data in Base64 and MUST NOT wrap the data in any other format (although the wrapped data may be MIME, DIME, or doorknobs). Hope that clarifies the context a little. Cheers, - Ira McDonald, contributing editor for PSI spec High North Inc -----Original Message----- From: REVEL,DAN (HP-Vancouver,ex1) [mailto:dan_revel@hp.com] Sent: Wednesday, March 19, 2003 11:22 AM To: 'Harry Lewis'; ps@pwg.org Subject: RE: PS> Soap with attachments - relation to SOAP 1.1 SOAP-attachments was a W3C submission, Microsoft et al. made a competing proposal, DIME, that seems to have more momentum: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwebsrv/ht ml/dimewsattch.asp -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, March 18, 2003 9:59 AM To: ps@pwg.org Subject: PS> Soap with attachments - relation to SOAP 1.1 See http://www.w3.org/TR/SOAP-attachments section 4. Seems this has been around for quite a while. I suspect we'd have better interop than we anticipate. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- From fujisawa.jun at canon.co.jp Thu Mar 20 08:25:29 2003 From: fujisawa.jun at canon.co.jp (Jun Fujisawa) Date: Wed May 6 14:02:09 2009 Subject: PS> Soap with attachments - relation to SOAP 1.1 In-Reply-To: References: Message-ID: Hello Harry, At 10:58 AM -0700 03.3.18, Harry Lewis wrote: >See http://www.w3.org/TR/SOAP-attachments section 4. Seems this has been >around for quite a while. I suspect we'd have better interop than we >anticipate. Just a quick note. This W3C Note is a submission from HP and Microsoft over 2 years ago. The W3C XML Protocol WG has then published a Working Draft for the abstract specification of SOAP 1.2 Attachment Feature and is expected to continue working on to have a new concrete specification of SOAP binary attachments. -- Jun Fujisawa From dhall at hp.com Fri Mar 21 12:21:33 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:09 2009 Subject: PS> PSI wd-psi10-20030321 available. Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FABC1@xvan01.vcd.hp.com> Hi All! The latest PSI specification is now available at: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030321.doc ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030321.pdf The corresponding WSDL is also availble at: http://www.pwg.org/schemas/ps/20030321/ Dave From alan.berkema at hp.com Mon Mar 24 18:18:27 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:09 2009 Subject: PS> [PSI]: next call 03/25/03 Message-ID: <499DC368E25AD411B3F100902740AD650E6AD7CC@xrose03.rose.hp.com> Teleconference details: NEXT: Tuesday March 25 2003 (USA) Time: 8 AM (US PST) Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Plan a call in place of F2F 2) Early review comments? ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 27995593 Meeting Password: newpsi Host: Alan Berkema 1(916)7855605 From alan.berkema at hp.com Mon Mar 24 19:26:27 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:09 2009 Subject: PS> FW: [PSI]: F2F Canceled Message-ID: <499DC368E25AD411B3F100902740AD650E6AD7D0@xrose03.rose.hp.com> Second try. -----Original Message----- From: BERKEMA,ALAN C (HP-Roseville,ex1) Sent: Monday, March 24, 2003 2:25 PM To: 'pwg-announce@pwg.org' Subject: [PSI]: F2F Canceled Hi all, Unfortunately Dave Hall and I have been forced to cancel our travel to the Washington DC PSI meeting on April 4th 2003. With out the chair and the editor I do not think it makes sense to have this meeting and it is officially canceled. Since it is on the last day and the airlines are not charging a penalty, hopefully, you can just return a day sooner. In April we will hold a Last Call Comment Resolution meeting which might be F2F, or via phone conference. At tomorrows PSI call we will attempt to schedule a phone conference/WeBex to take the place of the F2F. Thanks for your understanding, Alan From imcdonald at sharplabs.com Tue Mar 25 12:18:24 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:09 2009 Subject: PS> document-id-uri semantics Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF47@mailsrvnt02.enet.sharplabs.com> Hi, The current "document-id-uri" in the IPP Document Object spec clearly that states that it is an opaque identifier, and cannot be used as the target of an operation (unlike the "job-uri" in RFC 2911). And it gives an example of an 'ipp:' schemed URI. I think I should write an Appendix to the Document Object that: (1) extends the IPP URL Scheme (adopted last month by the IETF for RFC publication as an IETF Proposed Standard) to apply to Document objects as well, (2) specifies the opaque identifier limitation, (3) is normatively referenced by the "document-id-uri" attribute definition in the main spec. As we discussed on the PSI telecon this morning, PSI doesn't care what the URL scheme is in the DocumentURI, just that it be unique within a print server. Comments? Cheers, - Ira McDonald, co-editor of IPP URL Scheme High North Inc From hastings at cp10.es.xerox.com Tue Mar 25 16:48:30 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:02:09 2009 Subject: PS> RE: SM> document-id-uri semantics Message-ID: Is there any experimental scheme that we could use, so we don't have to muck with the "ipp:" scheme? If there is, we could just mention what that scheme is in the spec. Or since this is a URI data type, is there some URN form that we could use to give each document a unique identifiers? All we want is a unique identifier across that one Printer. Its doesn't have to be unique across all Printers, right? We also need to agree as to over what time period the ID has to be unique? If the Printer is powered off and comes back again, does it have to continue to generate unique URIs that it never generated before? Or don't we have to be that strict. Tom -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Tuesday, March 25, 2003 09:18 To: 'sm@pwg.org'; 'ps@pwg.org' Subject: SM> document-id-uri semantics Hi, The current "document-id-uri" in the IPP Document Object spec clearly that states that it is an opaque identifier, and cannot be used as the target of an operation (unlike the "job-uri" in RFC 2911). And it gives an example of an 'ipp:' schemed URI. I think I should write an Appendix to the Document Object that: (1) extends the IPP URL Scheme (adopted last month by the IETF for RFC publication as an IETF Proposed Standard) to apply to Document objects as well, (2) specifies the opaque identifier limitation, (3) is normatively referenced by the "document-id-uri" attribute definition in the main spec. As we discussed on the PSI telecon this morning, PSI doesn't care what the URL scheme is in the DocumentURI, just that it be unique within a print server. Comments? Cheers, - Ira McDonald, co-editor of IPP URL Scheme High North Inc From hastings at cp10.es.xerox.com Tue Mar 25 17:31:30 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:02:09 2009 Subject: PS> Improvements of the IPP "document-format-version" and JDF MimeOfF ileTypeVersion attributes Message-ID: Today on the FSG Job Ticket API, Ira, Claudia, Till, and I were discussion the current IPP "document-format-version" attribute in the IPP Document Object spec Working Draft, dated March 24, 2003 and the JDF MimeOfFileTypeVersion attribute in the JDF FIleSpec proposal, dated March 21, 2003. This mail note has two specific proposals: 1. Put the version strings into a flat file that can be updated and used by implementers. The respective specs can have an initial sets of strings for the flat file. 2. Make the verson strings self-identifying. Both of these specs are to be discussed on Thursday, March 27, (PWG Semantic Model WG and CIP4 System Behaviour and Interoperability WG). The current text for the IPP "document-format-version" attribute is: 6.1.2.7 document-format-version (text(127)) This REQUIRED member Operation attribute contains the level or version of the document format identified by the "document-format" member attribute. The client MAY supply and the Printer MUST support this member attribute. Possible values are the same as the Printer MIB [rfc1759] prtInterpreterLangLevel (not prtInterpreterLangVersion), such as: '3': For Postscript level 3 [rfc1759]. '5e': For PCL 5e [rfc1759]. Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as:: 'PDF/X-1:2001': For PDF/X-1 [iso15930]. "? 'PDF/X-1.2001': For PDF/X-1a [iso15930] 'TIFF/IT-FP:1998': TIFF/IT [iso12639] - Full Page - baseline. 'TIFF/IT-CT:1998': TIFF/IT [iso12639] - Continuous Tone picture data - baseline 'TIFF/IT-FP/P1:1998': TIFF/IT [iso12639] - Full Page - profile 1 'TIFF/IT-CT/P1:1998': TIFF/IT [iso12639] - Continuous Tone picture data - profile 1 The current text for the JDF MimeOfFileTypeVersion attribute is: The level or version of the file format identified by MimeType or, FileType. Some example values are the same as the Printer MIB [rfc1759] prtInterpreterLangLevel, such as: "1", "2", "3" for MimeType = "application/postscript" "3", "4", "5", "5e" for MimeType = "application/vnd.hp-PCL" Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as: "5.0", "6.0", "2000", "XP" for MimeType = "application/msword" "1.3", "1.4", "PDF/X-1:2001", "PDF/X-1a:2001" for MimeType = "application/pdf" "2.0" for FileType = "DCS" "???" for FileType = "ICC Profile" ISSUE (Ann): What versions for ICC Profiles? "TIFF-IT/FP:1998", "TIFF-IT/CT:1998", "TIFF-IT/LW:1998" for FileType = "TIFF/IT" See Appendix A.1 "FileSpec Resource examples for MimeType, FileType, MimeOrFileTypeVersion attributes" for additional examples in common use by JDF applications. The two suggestions for improvement is: 1. Put the version strings into a flat file so that implementers can get them, so that new values can be added to easily, after appropriate review, without having to republish either the IPP Document Object spec or the CIP4 JDF spec. ISSUE: Whether both the PWG and CIP4 would have their own flat files that they would co-ordinate is an issue to be discussed. 2. The version string should be self identifying, e.g., PDF/1.3, not just 1.3, PS/3, not just 3, PCL/5e, not just 5e. And to build more on the Printer MIB, RFC 1759 (and soon to be published Printer MIBv2) use both the Language Family and the Language Level attributes for the version. The Language Families for PostScript is PS, for PCL is PCL, for PDF is PDF. In the Printer MIB there are two attributes (MIBs call them "objects"): prtInterpreterLangFamily OBJECT-TYPE -- NOTE: In RFC 1759, the enumeration values were implicitly -- defined by this object. SYNTAX PrtInterpreterLangFamilyTC MAX-ACCESS read-only STATUS current DESCRIPTION "The family name of a Page Description Language (PDL) or control language which this interpreter in the printer can interpret or emulate. NOTE: The above description has been modified from RFC 1759 for clarification." prtInterpreterLangLevel OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..31)) MAX-ACCESS read-only STATUS current DESCRIPTION "The level of the language which this interpreter is interpreting or emulating. This might contain a value like '5e'for an interpreter which is emulating level 5e of the PCL language. It might contain '2' for an interpreter which is emulating level 2 of the PostScript language. Similarly it might contain '2' for an interpreter which is emulating level 2 of the HPGL language." The prtInterpreterLangFamily has a Textual Convention for the assignment of about 62 printer languages. The symbolic names are of the form: langXxxx For example there are the following: langPCL(3), -- PCL. Starting with PCL version 5, -- HP-GL/2 is included as part of the -- PCL language. -- PCL and HP-GL/2 are registered -- trademarks of Hewlett-Packard -- Company. langHPGL(4), -- Hewlett-Packard Graphics Language. -- HP-GL is a registered trademark of -- Hewlett-Packard Company. langPJL(5), -- Peripheral Job Language. Appears in -- the data stream between data intended -- for a page description language. -- Hewlett-Packard Co. langPS(6), -- PostScript (tm) Language -- Postscript - a trademark of Adobe -- Systems Incorporated which may be -- registered in certain jurisdictions langIPDS(7), -- Intelligent Printer Data Stream -- Bi-directional print data stream for -- documents consisting of data objects -- (text, image, graphics, bar codes), -- resources (fonts, overlays) and page, -- form and finishing instructions. -- Facilitates system level device -- control, document tracking and error -- recovery throughout the print -- process. -- IBM Corporation. ... langPDF(54), -- Not in RFC 1759 -- Adobe Portable Document Format -- Adobe Systems, Inc. langRPDL(55), -- Not in RFC 1759 -- Ricoh Page Description Language for -- printers. -- Technical manual "RPDL command -- reference" No.307029 -- RICOH, Co. LTD langIntermecIPL(56), -- Not in RFC 1759 -- Intermec Printer Language for label -- printers. -- Technical Manual: "IPL Programmers -- Reference Manual" -- Intermec Corporation langUBIFingerprint(57), -- Not in RFC 1759 -- An intelligent basic-like programming -- language for label printers. -- Reference Manual: "UBI Fingerprint -- 7.1", No. 1-960434-00 -- United Barcode Industries langUBIDirectProtocol(58), -- Not in RFC 1759 -- An intelligent control language for -- label printers. -- Programmers guide: " UBI Direct -- Protocol", No. 1-960419-00 -- United Barcode Industries langFujitsu(59), -- Not in RFC 1759 -- Fujitsu Printer Language -- Reference Manual: -- "FM Printer Sequence" No. 80HP-0770 -- FUJITSU LIMITED langCGM(60), -- Not in RFC 1759 -- Computer Graphics Metafile -- MIME type 'image/cgm' langJPEG(61), -- Not in RFC 1759 -- Joint Photographic Experts Group -- MIME type 'image/jpeg' langCALS1(62), -- Not in RFC 1759 -- US DOD CALS1 (see MIL-STD-1840) -- MIME type 'application/cals-1840' langCALS2(63), -- Not in RFC 1759 -- US DOD CALS2 (see MIL-STD-1840) -- MIME type 'application/cals-1840' langNIRS(64), -- Not in RFC 1759 -- US DOD NIRS (see MIL-STD-1840) -- MIME type 'application/cals-1840' langC4(65) -- Not in RFC 1759 -- US DOD C4 (see MIL-STD-1840) -- MIME type 'application/cals-1840' So take the prtInterpreterLangFamily textual convention after the "lang", follow it with a "/" and then have the prtInterpreterLangLevel. So the updated IPP "document-format-version" member attribute would become: 6.1.2.7 document-format-version (text(127)) This REQUIRED member Operation attribute contains the level or version of the document format identified by the "document-format" member attribute. The client MAY supply and the Printer MUST support this member attribute. Possible values are the same as the Printer MIB [rfc1759] prtInterpreterLangFamily textual convention (minus the "lang" prefix) and prtInterpreterLangLevel (not prtInterpreterLangVersion) separated by a "/", such as: 'PS/3': For Postscript level 3 [rfc1759]. 'PCL/5e': For PCL 5e [rfc1759]. Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such a: 'PDF/X-1:2001': For PDF/X-1 [iso15930]. "? 'PDF/X-1.2001': For PDF/X-1a [iso15930] 'TIFF/IT-FP:1998': TIFF/IT [iso12639] - Full Page - baseline. 'TIFF/IT-CT:1998': TIFF/IT [iso12639] - Continuous Tone picture data - baseline 'TIFF/IT-FP/P1:1998': TIFF/IT [iso12639] - Full Page - profile 1 'TIFF/IT-CT/P1:1998': TIFF/IT [iso12639] - Continuous Tone picture data - profile 1 See PWG www.pwg.org [need URL] for a flat file list of the version strings currently recognized for use in the PWG Semantic Model and derivative protocols, such as IPP and PSI. and the updated JDF MimeOrFileTypeVersion attribute would become: The level or version of the file format identified by MimeType or, FileType. Some example values are the same as the Printer MIB [rfc1759] prtInterpreterLangFamily textual convention (minus the "lang" prefix) and prtInterpreterLangLevel, such as: "PS/1", "PS/2", "PS/3" for MimeType = "application/postscript" "PCL/3", "PDL/4", "PCL/5", "PCL/5e" for MimeType = "application/vnd.hp-PCL" Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as: "MSWORD/5.0", "MSWORD/6.0", "MSWORD/2000", "MSWORD/XP" for MimeType = "application/msword" "PDF/1.3", "PDF/1.4", "PDF/X-1:2001", "PDF/X-1a:2001" for MimeType = "application/pdf" "DCS/2.0" for FileType = "DCS" "???" for FileType = "ICC Profile" ISSUE (Ann): What versions for ICC Profiles? "TIFF-IT/FP:1998", "TIFF-IT/CT:1998", "TIFF-IT/LW:1998" for FileType = "TIFF/IT" See CIP4 www.cip4.org [need URL] for the flat text file that contains the version strings currently recognized for the "FileSpec Resource attributes: MimeType, FileType, MimeOrFileTypeVersion in common use by JDF applications. Comments? Tom From dhall at hp.com Wed Mar 26 17:44:48 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:09 2009 Subject: PS> HP PSI Server available Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FABDF@xvan01.vcd.hp.com> Hey All.. We have a 20030321 PSI 1.0 implementation available at the following PSI Service Root URL: pwg-psips://hpps.vcd.hwp6.net:55558/psi/1.0 (55558 is redirected to 55559 through a tcp trace... Put an http in place of pwg-psips and paste it into your browser... Let me know if you are interested in doing a phone conference interop sometime in the next couple of weeks... (Or after that!) It is still under development, so your mileage may vary! :) Dave From hastings at cp10.es.xerox.com Wed Mar 26 18:05:00 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:02:09 2009 Subject: PS> More improvements to the IPP "document-format-version" and JDF Mi meOrFileTypeVersion attributes [4 ISSUES] Message-ID: Ira and I had even further thoughts about the IPP "document-format-version" (wihch don't affect the corresponding JDF MimeOrFileTypeVersion attributes since it is a top level attribute in the FileSpec resource): The proposal from yesterday is to make the values of IPP "docuent-format-version" and JDF MimeOrFileTypeVersion attributes be self-identifying, because they start with a prefix that identifies the format: "PDF/", "PS/", "PCL/", "TIFF/IT-", "DCS/", "MSWORD/", etc. ISSUE 01: OK to add the prefix values as proposed yesterday to the IPP "docuent-format-version" and JDF MimeOrFileTypeVersion attributes to make the values self identifying indendent of the correspoding IPP "document-format" and JDF MimeType attributes? Today's further thought is that we can now promote the IPP "document-format-version" member Operation attribute back to being a top level Document object attribute to accompany the existing "document-format" Operation attribute. This is because "document-format-version-supported" attribute now makes sense as a Printer Descrition attribute on its own, since the values would be things like: "PDF/1.3", "PDF/X-1:2001", "PS/3", "PCL/5e", "TIFF/IT-FP/P1:1998", "DCS/2.0", "MSWORD/2000" and don't need to be paired up with the correspoding "document-format-supported" Printer attribute values: "applicaition/pdf", "application/postscript", "application/vnd.hp-PCL", and "application/msword" MIME type values. ISSUE 02: OK to add a "document-format-version" operation and Document Description attribute to the IPP Document object spec? Just like the "document-format" Operation attribute which is also a member attribute of the "document-format-details" (1setOf collection) Operation/Document Description attribute, we'd keep "document-format-version" as a member attribute as well with the same prefixed values. This now means that "document-format" and "document-format-version" have all parallel construction: a. They are both operation attributes. b. They both have correspoding Document Description attributes that the Printer copies to. c. They both have "xxx-supported" Printer attributes. d. There is a "document-format-default" which now can have a corresponding "document-format-version-default" Printer attribute. ISSUE 03: OK to add "document-format-default" printer attribute? e. The Printer MUST reject the request if the "document-format" isn't supported. ISSUE 04: Do we want to make the same rule for the "document-format-version" or keep it as a Best Effort, unless the client supplies "ipp-attribute-fidelity"='true' or "job-mandatory-attributes"='document-format-version'? Comments? Thanks, Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, March 25, 2003 14:32 To: sm@pwg.org; ps@pwg.org Cc: CIP4 System Behaviour and Interoperability WG [system_behaviour@cip4.org]; CIP4 Capabilities WG [capabilities@cip4.org] Subject: SM> Improvements of the IPP "document-format-version" and JDF MimeOfF ileTypeVersion attributes Today on the FSG Job Ticket API, Ira, Claudia, Till, and I were discussion the current IPP "document-format-version" attribute in the IPP Document Object spec Working Draft, dated March 24, 2003 and the JDF MimeOfFileTypeVersion attribute in the JDF FIleSpec proposal, dated March 21, 2003. This mail note has two specific proposals: 1. Put the version strings into a flat file that can be updated and used by implementers. The respective specs can have an initial sets of strings for the flat file. 2. Make the verson strings self-identifying. Both of these specs are to be discussed on Thursday, March 27, (PWG Semantic Model WG and CIP4 System Behaviour and Interoperability WG). The current text for the IPP "document-format-version" attribute is: 6.1.2.7 document-format-version (text(127)) This REQUIRED member Operation attribute contains the level or version of the document format identified by the "document-format" member attribute. The client MAY supply and the Printer MUST support this member attribute. Possible values are the same as the Printer MIB [rfc1759] prtInterpreterLangLevel (not prtInterpreterLangVersion), such as: '3': For Postscript level 3 [rfc1759]. '5e': For PCL 5e [rfc1759]. Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as:: 'PDF/X-1:2001': For PDF/X-1 [iso15930]. "? 'PDF/X-1.2001': For PDF/X-1a [iso15930] 'TIFF/IT-FP:1998': TIFF/IT [iso12639] - Full Page - baseline. 'TIFF/IT-CT:1998': TIFF/IT [iso12639] - Continuous Tone picture data - baseline 'TIFF/IT-FP/P1:1998': TIFF/IT [iso12639] - Full Page - profile 1 'TIFF/IT-CT/P1:1998': TIFF/IT [iso12639] - Continuous Tone picture data - profile 1 The current text for the JDF MimeOfFileTypeVersion attribute is: The level or version of the file format identified by MimeType or, FileType. Some example values are the same as the Printer MIB [rfc1759] prtInterpreterLangLevel, such as: "1", "2", "3" for MimeType = "application/postscript" "3", "4", "5", "5e" for MimeType = "application/vnd.hp-PCL" Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as: "5.0", "6.0", "2000", "XP" for MimeType = "application/msword" "1.3", "1.4", "PDF/X-1:2001", "PDF/X-1a:2001" for MimeType = "application/pdf" "2.0" for FileType = "DCS" "???" for FileType = "ICC Profile" ISSUE (Ann): What versions for ICC Profiles? "TIFF-IT/FP:1998", "TIFF-IT/CT:1998", "TIFF-IT/LW:1998" for FileType = "TIFF/IT" See Appendix A.1 "FileSpec Resource examples for MimeType, FileType, MimeOrFileTypeVersion attributes" for additional examples in common use by JDF applications. The two suggestions for improvement is: 1. Put the version strings into a flat file so that implementers can get them, so that new values can be added to easily, after appropriate review, without having to republish either the IPP Document Object spec or the CIP4 JDF spec. ISSUE: Whether both the PWG and CIP4 would have their own flat files that they would co-ordinate is an issue to be discussed. 2. The version string should be self identifying, e.g., PDF/1.3, not just 1.3, PS/3, not just 3, PCL/5e, not just 5e. And to build more on the Printer MIB, RFC 1759 (and soon to be published Printer MIBv2) use both the Language Family and the Language Level attributes for the version. The Language Families for PostScript is PS, for PCL is PCL, for PDF is PDF. In the Printer MIB there are two attributes (MIBs call them "objects"): prtInterpreterLangFamily OBJECT-TYPE -- NOTE: In RFC 1759, the enumeration values were implicitly -- defined by this object. SYNTAX PrtInterpreterLangFamilyTC MAX-ACCESS read-only STATUS current DESCRIPTION "The family name of a Page Description Language (PDL) or control language which this interpreter in the printer can interpret or emulate. NOTE: The above description has been modified from RFC 1759 for clarification." prtInterpreterLangLevel OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..31)) MAX-ACCESS read-only STATUS current DESCRIPTION "The level of the language which this interpreter is interpreting or emulating. This might contain a value like '5e'for an interpreter which is emulating level 5e of the PCL language. It might contain '2' for an interpreter which is emulating level 2 of the PostScript language. Similarly it might contain '2' for an interpreter which is emulating level 2 of the HPGL language." The prtInterpreterLangFamily has a Textual Convention for the assignment of about 62 printer languages. The symbolic names are of the form: langXxxx For example there are the following: langPCL(3), -- PCL. Starting with PCL version 5, -- HP-GL/2 is included as part of the -- PCL language. -- PCL and HP-GL/2 are registered -- trademarks of Hewlett-Packard -- Company. langHPGL(4), -- Hewlett-Packard Graphics Language. -- HP-GL is a registered trademark of -- Hewlett-Packard Company. langPJL(5), -- Peripheral Job Language. Appears in -- the data stream between data intended -- for a page description language. -- Hewlett-Packard Co. langPS(6), -- PostScript (tm) Language -- Postscript - a trademark of Adobe -- Systems Incorporated which may be -- registered in certain jurisdictions langIPDS(7), -- Intelligent Printer Data Stream -- Bi-directional print data stream for -- documents consisting of data objects -- (text, image, graphics, bar codes), -- resources (fonts, overlays) and page, -- form and finishing instructions. -- Facilitates system level device -- control, document tracking and error -- recovery throughout the print -- process. -- IBM Corporation. ... langPDF(54), -- Not in RFC 1759 -- Adobe Portable Document Format -- Adobe Systems, Inc. langRPDL(55), -- Not in RFC 1759 -- Ricoh Page Description Language for -- printers. -- Technical manual "RPDL command -- reference" No.307029 -- RICOH, Co. LTD langIntermecIPL(56), -- Not in RFC 1759 -- Intermec Printer Language for label -- printers. -- Technical Manual: "IPL Programmers -- Reference Manual" -- Intermec Corporation langUBIFingerprint(57), -- Not in RFC 1759 -- An intelligent basic-like programming -- language for label printers. -- Reference Manual: "UBI Fingerprint -- 7.1", No. 1-960434-00 -- United Barcode Industries langUBIDirectProtocol(58), -- Not in RFC 1759 -- An intelligent control language for -- label printers. -- Programmers guide: " UBI Direct -- Protocol", No. 1-960419-00 -- United Barcode Industries langFujitsu(59), -- Not in RFC 1759 -- Fujitsu Printer Language -- Reference Manual: -- "FM Printer Sequence" No. 80HP-0770 -- FUJITSU LIMITED langCGM(60), -- Not in RFC 1759 -- Computer Graphics Metafile -- MIME type 'image/cgm' langJPEG(61), -- Not in RFC 1759 -- Joint Photographic Experts Group -- MIME type 'image/jpeg' langCALS1(62), -- Not in RFC 1759 -- US DOD CALS1 (see MIL-STD-1840) -- MIME type 'application/cals-1840' langCALS2(63), -- Not in RFC 1759 -- US DOD CALS2 (see MIL-STD-1840) -- MIME type 'application/cals-1840' langNIRS(64), -- Not in RFC 1759 -- US DOD NIRS (see MIL-STD-1840) -- MIME type 'application/cals-1840' langC4(65) -- Not in RFC 1759 -- US DOD C4 (see MIL-STD-1840) -- MIME type 'application/cals-1840' So take the prtInterpreterLangFamily textual convention after the "lang", follow it with a "/" and then have the prtInterpreterLangLevel. So the updated IPP "document-format-version" member attribute would become: 6.1.2.7 document-format-version (text(127)) This REQUIRED member Operation attribute contains the level or version of the document format identified by the "document-format" member attribute. The client MAY supply and the Printer MUST support this member attribute. Possible values are the same as the Printer MIB [rfc1759] prtInterpreterLangFamily textual convention (minus the "lang" prefix) and prtInterpreterLangLevel (not prtInterpreterLangVersion) separated by a "/", such as: 'PS/3': For Postscript level 3 [rfc1759]. 'PCL/5e': For PCL 5e [rfc1759]. Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such a: 'PDF/X-1:2001': For PDF/X-1 [iso15930]. "? 'PDF/X-1.2001': For PDF/X-1a [iso15930] 'TIFF/IT-FP:1998': TIFF/IT [iso12639] - Full Page - baseline. 'TIFF/IT-CT:1998': TIFF/IT [iso12639] - Continuous Tone picture data - baseline 'TIFF/IT-FP/P1:1998': TIFF/IT [iso12639] - Full Page - profile 1 'TIFF/IT-CT/P1:1998': TIFF/IT [iso12639] - Continuous Tone picture data - profile 1 See PWG www.pwg.org [need URL] for a flat file list of the version strings currently recognized for use in the PWG Semantic Model and derivative protocols, such as IPP and PSI. and the updated JDF MimeOrFileTypeVersion attribute would become: The level or version of the file format identified by MimeType or, FileType. Some example values are the same as the Printer MIB [rfc1759] prtInterpreterLangFamily textual convention (minus the "lang" prefix) and prtInterpreterLangLevel, such as: "PS/1", "PS/2", "PS/3" for MimeType = "application/postscript" "PCL/3", "PDL/4", "PCL/5", "PCL/5e" for MimeType = "application/vnd.hp-PCL" Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as: "MSWORD/5.0", "MSWORD/6.0", "MSWORD/2000", "MSWORD/XP" for MimeType = "application/msword" "PDF/1.3", "PDF/1.4", "PDF/X-1:2001", "PDF/X-1a:2001" for MimeType = "application/pdf" "DCS/2.0" for FileType = "DCS" "???" for FileType = "ICC Profile" ISSUE (Ann): What versions for ICC Profiles? "TIFF-IT/FP:1998", "TIFF-IT/CT:1998", "TIFF-IT/LW:1998" for FileType = "TIFF/IT" See CIP4 www.cip4.org [need URL] for the flat text file that contains the version strings currently recognized for the "FileSpec Resource attributes: MimeType, FileType, MimeOrFileTypeVersion in common use by JDF applications. Comments? Tom From imcdonald at sharplabs.com Sun Mar 30 19:38:37 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:09 2009 Subject: PS> PWG PSI Fri 4 April 10:30am PST Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF5B@mailsrvnt02.enet.sharplabs.com> Hi, Phone numbers and Web-Ex info (to watch the slides) will follow. I took the schedule from Gail Songer's Web info from Amy Patel. Dave Hall and Alan Berkema - where's the announcement of the PSI special telecon this coming Friday? Cheers, - Ira McDonald High North Inc From alan.berkema at hp.com Mon Mar 31 11:19:22 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:09 2009 Subject: PS> [PSI]: Friday Phone & Webex Message-ID: <499DC368E25AD411B3F100902740AD650E6AD819@xrose03.rose.hp.com> PSI Call 10:00AM - 12noon 1:00PM - 3:00PM Dial-In #: +1 719-457-0335 Participant Password: 400908# Will begin with an overview for FSG folks Next page turner for Last Call Comments Dave can you pass this along to FSG? FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. Meeting Summary Meeting Name: PSI Last Call Review I Scheduled Time: 4/4/2003 at 10:00AM (GMT -08:00) Pacific Time, USA & Canada. Meeting Number: 21659206 Any meeting attendee can use this number to join the meeting, at https://hp.webex.com/join/ Password: newpsi ---------------------------------------------------------------------------- ------------------------------------------------------------------- Meeting Summary Meeting Name: PSI Last Call Review II Scheduled Time: 4/4/2003 at 1:00PM (GMT -08:00) Pacific Time, USA & Canada. Meeting Number: 26342152 Any meeting attendee can use this number to join the meeting, at https://hp.webex.com/join/ Password: newpsi From dhall at hp.com Mon Mar 31 18:08:30 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:09 2009 Subject: PS> Updated PSI Documents Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FABF8@xvan01.vcd.hp.com> Hi All! I've updated the developers guide and the interface usage presentation to be up to date with the latest PSI specification. They are available at the following: ftp://ftp.pwg.org/pub/pwg/ps/psi10-devl-20030328.doc ftp://ftp.pwg.org/pub/pwg/ps/psi10-devl-20030328.pdf ftp://ftp.pwg.org/pub/pwg/ps/psi10-usage-20030327.ppt ftp://ftp.pwg.org/pub/pwg/ps/psi10-usage-20030327.pdf Please take a look at them before Friday's PSI teleconference, as we will be reviewing these documents during the first hour as a PSI overview for the freesoftware group, and others that haven't seen PSI yet. (Ira, can you forward to the freesoftware group? Thanks!) Dave From imcdonald at sharplabs.com Tue Apr 1 12:25:41 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:09 2009 Subject: PS> RE: IPv6 RFCs? [searching for RFCs] Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF69@mailsrvnt02.enet.sharplabs.com> Hi Alan, [I copied the PSI list, because below is an FAQ answer]. First your question - yes RFC 2461 is what IPv6 uses to replace ARP (and quite few other protocols). With RFC 2461 you can resolve a neighbor's IPv6 network layer address into the corresponding datalink layer address (for example the IEEE 802.x 48-bit or 64-bit address). To Web search for RFCs, go the RFC Editor's home page http://www.rfc-editor.org and select the 'RFC Search' button. There are several IETF mechanisms for finding RFCs. The simplest is the RFC Index (titles, authors, dates, only): ftp://ftp.isi.edu/in-notes/rfc-index.txt Another is that (once your interested in a given RFC by title), every even-numbered century RFC (3100, 3200, etc.) is the complete latest version of "Internet Official Protocol Standards" (also called STD 1). According to a copy of the RFC Index that I just fetched, the latest that has been published is: 3300 Internet Official Protocol Standards. J. Reynolds, R. Braden, S. Ginoza, A. De La Cruz. November 2002. (Format: TXT=127805 bytes) (Obsoletes RFC3000) (Also STD0001) (Status: STANDARD) ftp://ftp.isi.edu/in-notes/rfc3300.txt Further, every century minus one (3099 , 3199, etc.) is the "RFC Summary" for that century (3099 is 3000 to 3099), containing the Title and Abstract of each hundred RFCs. These are the best for a detailed topic search (although their publication lags a bit behind the latest published RFCs). Hope all this helps. Cheers, - Ira -----Original Message----- From: BERKEMA,ALAN C (HP-Roseville,ex1) [mailto:alan.berkema@hp.com] Sent: Tuesday, April 01, 2003 10:45 AM To: 'McDonald, Ira' Subject: IPv6 RFCs? Hi Ira, This is off topic from PSI, but you really seem to have your RFCs down. How do I find what IPv6 is using for ARP? I found RFC 2461 neighbor Discovery, is that it? Is there an IETF way of finding the latest RFC's without resorting to Google? RFC1883 - The IPv6 base protocol. RFC1884 - The address specification. RFC1885 - Description of the control protocol, known as ICMP. RFC1886 - Addressing the problems of an enhanced Domain Name Service (DNS). RFC1933 - The transition mechanism. Thanks in adavance Alan From hastings at cp10.es.xerox.com Tue Apr 1 21:46:05 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:02:09 2009 Subject: PS> Summary of 9 recent ISSUES/fixes for the IPP Document object tele con, Thur, 4/3/03, 12-3 EST (9-12 PST) Message-ID: The 2nd and 3rd hours will be reviewing the IPP Document Object spec (sent out March 25: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324.pdf.zip (1,225 KB) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324.doc.zip (294 KB) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324-rev.pdf.zip (649 KB) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324-rev.doc.zip (309 KB) This note summarizes the suggestions that have been and issues raised since the document was sent out, including discussions in CIP4 about the JDF/FileSpec resource and the SM telecon March 27. The first part of this mail note is a summary of the issues and point to earlier mail messages that are appended for more detail and rationale. 1. Close-Job operation needs the same timeout Printer requirements as RFC 2911 has for Send-Document. 2. Remove "document-id-uri" Document Description attribute. PSI agreed last week that they can use the IPP "document-number" (integer(1:MAX)) Document Description attribute to identify documents within a job. 3. Add a "document-format-version" (text(127)) operation/Document Description attribute with self-identifing values, such as 'PS/3.0', 'PCL/5e', 'PDF/1.4', 'PDF/X-1a:2001' (See ISSUES 01 and 02 below for more details). The prefix is from the Printer MIB langTC values used in the prtInterpretedLangFamily object and the version after the "/" can be used in the Printer MIB prtInterpreterLangLevel object. 4. Add a "document-format-version-default" (text(127)) and "document-format-version-supported" (1setOf text(127)) Printer Description attributes to describe the default and supported values. (See ISSUES 03 below for more details). So "document-format-version" and "document-format" would have parallel semantics, including also being member attributes of "document-format-details" (1setOf collection). 5. ISSUE 04 (repeat of below): Is "document-format-version" a Best Effort (hint) unless "ipp-attribute-fidelity" = 'true" or "job-mandatory-attributes" = 'document-format-version' or do we make "document-format-version" be like "document-format" in that the Printer MUST reject the job if the Printer doesn't support the version? 6. Put the version strings into a flat text file that implementers and implementations can access on the PWG FTP site. Adding new values is simply done whenever they are registered or standardized with some recognized body, such as IANA, CIP4, ISO, etc. ISSUE 05: We need to convince CIP4 to use the same flat file for their FileSpec/@MimeOrFileTypeVersion attribute and/or have each of them shadow the other. 7. Add a "document-natural-language" (naturalLanguage) operation/Document Description attribute and a "document-natural-language-supported" (1setOf naturalLanguage) Printer Description attribute. The "document-natural-language" operation attribute is already defined in RFC 2911 for use with Print-Job, Send-Document, and Send-URI, so we are just continuing this RFC 2911 attribute for the Create-Document operation and making it a Document Description attribute as well, so that it can be queried. Also keep "document-natural-language" (naturalLanguage) as a member attribute of "document-format-details" for describing packages. The "document-natural-language" is needed in order to know how to display characters that depend on language. ISSUE 06: What about multiple languages in a single document for the top level attribute? ISSUE 06a: What about for the member attribute of "document-format-details"? 8. Add a "document-charset" (charset) operation/Document Description attribute and a "docuemnt-charset-supported" (1setOf charset) Printer Descrition attribute. This attribute is needed for the many plain text and markup languages in which the charset is not embedded in the data. For example, PCL often doesn't have the charset escape sequence in the data. Also many files use the various 8-bit ISO 8859 charsets in which the lower half is US-ASCII and the upper half is various Latin sets (about 8 or 9), Greek, Cyrllic, Hebrew, and Arabic. Shift JIS is another example where the left half is US-ASCII, but the right half can be one of a number of things. But if the data doesn't contain the charset escape sequences, this attribute can help the Printer know what the charset is in the Document. 9. There is one issue embedded in the Document Object spec: 6.1.2.2 document-creator-application-version (text(127)) This OPTIONAL member Operation attribute identifies the version number of the application that created the document. The intent of this attribute is for display to a human being, rather than being parsed by the Printer for purpose of affecting the interpreting by the Printer and so may also include the name of the application, as well as build or service pack numbers. Examples: "Winzip? 8.1 (4331)", "Acrobat 5.0.5 10/26/2001", "Microsoft? Word 2000 (9.0.4119 SR-1)" ISSUE: OK that the purpose is human consumption, instead of program consumption and that it be the same as the application shows in its help message? The two other version attribute: "document-format-version" and "document-format-os-version" are intended for program consumption, not human consumption. Its possible that CIP4 will want to have both types of versions for: applications, operating systems, and documet-formats. Tom Here is last week's thread with more details: -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, March 26, 2003 15:05 To: sm@pwg.org; ps@pwg.org Cc: CIP4 System Behaviour and Interoperability WG [system_behaviour@cip4.org]; CIP4 Capabilities WG [capabilities@cip4.org] Subject: SM> More improvements to the IPP "document-format-version" and JDF Mi meOrFileTypeVersion attributes [4 ISSUES] Ira and I had even further thoughts about the IPP "document-format-version" (wihch don't affect the corresponding JDF MimeOrFileTypeVersion attributes since it is a top level attribute in the FileSpec resource): The proposal from yesterday is to make the values of IPP "docuent-format-version" and JDF MimeOrFileTypeVersion attributes be self-identifying, because they start with a prefix that identifies the format: "PDF/", "PS/", "PCL/", "TIFF/IT-", "DCS/", "MSWORD/", etc. ISSUE 01: OK to add the prefix values as proposed yesterday to the IPP "docuent-format-version" and JDF MimeOrFileTypeVersion attributes to make the values self identifying indendent of the correspoding IPP "document-format" and JDF MimeType attributes? Today's further thought is that we can now promote the IPP "document-format-version" member Operation attribute back to being a top level Document object attribute to accompany the existing "document-format" Operation attribute. This is because "document-format-version-supported" attribute now makes sense as a Printer Descrition attribute on its own, since the values would be things like: "PDF/1.3", "PDF/X-1:2001", "PS/3", "PCL/5e", "TIFF/IT-FP/P1:1998", "DCS/2.0", "MSWORD/2000" and don't need to be paired up with the correspoding "document-format-supported" Printer attribute values: "applicaition/pdf", "application/postscript", "application/vnd.hp-PCL", and "application/msword" MIME type values. ISSUE 02: OK to add a "document-format-version" operation and Document Description attribute to the IPP Document object spec? Just like the "document-format" Operation attribute which is also a member attribute of the "document-format-details" (1setOf collection) Operation/Document Description attribute, we'd keep "document-format-version" as a member attribute as well with the same prefixed values. This now means that "document-format" and "document-format-version" have all parallel construction: a. They are both operation attributes. b. They both have correspoding Document Description attributes that the Printer copies to. c. They both have "xxx-supported" Printer attributes. d. There is a "document-format-default" which now can have a corresponding "document-format-version-default" Printer attribute. ISSUE 03: OK to add "document-format-default" printer attribute? e. The Printer MUST reject the request if the "document-format" isn't supported. ISSUE 04: Do we want to make the same rule for the "document-format-version" or keep it as a Best Effort, unless the client supplies "ipp-attribute-fidelity"='true' or "job-mandatory-attributes"='document-format-version'? Comments? Thanks, Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, March 25, 2003 14:32 To: sm@pwg.org; ps@pwg.org Cc: CIP4 System Behaviour and Interoperability WG [system_behaviour@cip4.org]; CIP4 Capabilities WG [capabilities@cip4.org] Subject: SM> Improvements of the IPP "document-format-version" and JDF MimeOfF ileTypeVersion attributes Today on the FSG Job Ticket API, Ira, Claudia, Till, and I were discussion the current IPP "document-format-version" attribute in the IPP Document Object spec Working Draft, dated March 24, 2003 and the JDF MimeOfFileTypeVersion attribute in the JDF FIleSpec proposal, dated March 21, 2003. This mail note has two specific proposals: 1. Put the version strings into a flat file that can be updated and used by implementers. The respective specs can have an initial sets of strings for the flat file. 2. Make the verson strings self-identifying. Both of these specs are to be discussed on Thursday, March 27, (PWG Semantic Model WG and CIP4 System Behaviour and Interoperability WG). The current text for the IPP "document-format-version" attribute is: 6.1.2.7 document-format-version (text(127)) This REQUIRED member Operation attribute contains the level or version of the document format identified by the "document-format" member attribute. The client MAY supply and the Printer MUST support this member attribute. Possible values are the same as the Printer MIB [rfc1759] prtInterpreterLangLevel (not prtInterpreterLangVersion), such as: '3': For Postscript level 3 [rfc1759]. '5e': For PCL 5e [rfc1759]. Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as:: 'PDF/X-1:2001': For PDF/X-1 [iso15930]. "? 'PDF/X-1.2001': For PDF/X-1a [iso15930] 'TIFF/IT-FP:1998': TIFF/IT [iso12639] - Full Page - baseline. 'TIFF/IT-CT:1998': TIFF/IT [iso12639] - Continuous Tone picture data - baseline 'TIFF/IT-FP/P1:1998': TIFF/IT [iso12639] - Full Page - profile 1 'TIFF/IT-CT/P1:1998': TIFF/IT [iso12639] - Continuous Tone picture data - profile 1 The current text for the JDF MimeOfFileTypeVersion attribute is: The level or version of the file format identified by MimeType or, FileType. Some example values are the same as the Printer MIB [rfc1759] prtInterpreterLangLevel, such as: "1", "2", "3" for MimeType = "application/postscript" "3", "4", "5", "5e" for MimeType = "application/vnd.hp-PCL" Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as: "5.0", "6.0", "2000", "XP" for MimeType = "application/msword" "1.3", "1.4", "PDF/X-1:2001", "PDF/X-1a:2001" for MimeType = "application/pdf" "2.0" for FileType = "DCS" "???" for FileType = "ICC Profile" ISSUE (Ann): What versions for ICC Profiles? "TIFF-IT/FP:1998", "TIFF-IT/CT:1998", "TIFF-IT/LW:1998" for FileType = "TIFF/IT" See Appendix A.1 "FileSpec Resource examples for MimeType, FileType, MimeOrFileTypeVersion attributes" for additional examples in common use by JDF applications. The two suggestions for improvement is: 1. Put the version strings into a flat file so that implementers can get them, so that new values can be added to easily, after appropriate review, without having to republish either the IPP Document Object spec or the CIP4 JDF spec. ISSUE: Whether both the PWG and CIP4 would have their own flat files that they would co-ordinate is an issue to be discussed. 2. The version string should be self identifying, e.g., PDF/1.3, not just 1.3, PS/3, not just 3, PCL/5e, not just 5e. And to build more on the Printer MIB, RFC 1759 (and soon to be published Printer MIBv2) use both the Language Family and the Language Level attributes for the version. The Language Families for PostScript is PS, for PCL is PCL, for PDF is PDF. In the Printer MIB there are two attributes (MIBs call them "objects"): prtInterpreterLangFamily OBJECT-TYPE -- NOTE: In RFC 1759, the enumeration values were implicitly -- defined by this object. SYNTAX PrtInterpreterLangFamilyTC MAX-ACCESS read-only STATUS current DESCRIPTION "The family name of a Page Description Language (PDL) or control language which this interpreter in the printer can interpret or emulate. NOTE: The above description has been modified from RFC 1759 for clarification." prtInterpreterLangLevel OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..31)) MAX-ACCESS read-only STATUS current DESCRIPTION "The level of the language which this interpreter is interpreting or emulating. This might contain a value like '5e'for an interpreter which is emulating level 5e of the PCL language. It might contain '2' for an interpreter which is emulating level 2 of the PostScript language. Similarly it might contain '2' for an interpreter which is emulating level 2 of the HPGL language." The prtInterpreterLangFamily has a Textual Convention for the assignment of about 62 printer languages. The symbolic names are of the form: langXxxx For example there are the following: langPCL(3), -- PCL. Starting with PCL version 5, -- HP-GL/2 is included as part of the -- PCL language. -- PCL and HP-GL/2 are registered -- trademarks of Hewlett-Packard -- Company. langHPGL(4), -- Hewlett-Packard Graphics Language. -- HP-GL is a registered trademark of -- Hewlett-Packard Company. langPJL(5), -- Peripheral Job Language. Appears in -- the data stream between data intended -- for a page description language. -- Hewlett-Packard Co. langPS(6), -- PostScript (tm) Language -- Postscript - a trademark of Adobe -- Systems Incorporated which may be -- registered in certain jurisdictions langIPDS(7), -- Intelligent Printer Data Stream -- Bi-directional print data stream for -- documents consisting of data objects -- (text, image, graphics, bar codes), -- resources (fonts, overlays) and page, -- form and finishing instructions. -- Facilitates system level device -- control, document tracking and error -- recovery throughout the print -- process. -- IBM Corporation. ... langPDF(54), -- Not in RFC 1759 -- Adobe Portable Document Format -- Adobe Systems, Inc. langRPDL(55), -- Not in RFC 1759 -- Ricoh Page Description Language for -- printers. -- Technical manual "RPDL command -- reference" No.307029 -- RICOH, Co. LTD langIntermecIPL(56), -- Not in RFC 1759 -- Intermec Printer Language for label -- printers. -- Technical Manual: "IPL Programmers -- Reference Manual" -- Intermec Corporation langUBIFingerprint(57), -- Not in RFC 1759 -- An intelligent basic-like programming -- language for label printers. -- Reference Manual: "UBI Fingerprint -- 7.1", No. 1-960434-00 -- United Barcode Industries langUBIDirectProtocol(58), -- Not in RFC 1759 -- An intelligent control language for -- label printers. -- Programmers guide: " UBI Direct -- Protocol", No. 1-960419-00 -- United Barcode Industries langFujitsu(59), -- Not in RFC 1759 -- Fujitsu Printer Language -- Reference Manual: -- "FM Printer Sequence" No. 80HP-0770 -- FUJITSU LIMITED langCGM(60), -- Not in RFC 1759 -- Computer Graphics Metafile -- MIME type 'image/cgm' langJPEG(61), -- Not in RFC 1759 -- Joint Photographic Experts Group -- MIME type 'image/jpeg' langCALS1(62), -- Not in RFC 1759 -- US DOD CALS1 (see MIL-STD-1840) -- MIME type 'application/cals-1840' langCALS2(63), -- Not in RFC 1759 -- US DOD CALS2 (see MIL-STD-1840) -- MIME type 'application/cals-1840' langNIRS(64), -- Not in RFC 1759 -- US DOD NIRS (see MIL-STD-1840) -- MIME type 'application/cals-1840' langC4(65) -- Not in RFC 1759 -- US DOD C4 (see MIL-STD-1840) -- MIME type 'application/cals-1840' So take the prtInterpreterLangFamily textual convention after the "lang", follow it with a "/" and then have the prtInterpreterLangLevel. So the updated IPP "document-format-version" member attribute would become: 6.1.2.7 document-format-version (text(127)) This REQUIRED member Operation attribute contains the level or version of the document format identified by the "document-format" member attribute. The client MAY supply and the Printer MUST support this member attribute. Possible values are the same as the Printer MIB [rfc1759] prtInterpreterLangFamily textual convention (minus the "lang" prefix) and prtInterpreterLangLevel (not prtInterpreterLangVersion) separated by a "/", such as: 'PS/3': For Postscript level 3 [rfc1759]. 'PCL/5e': For PCL 5e [rfc1759]. Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such a: 'PDF/X-1:2001': For PDF/X-1 [iso15930]. "? 'PDF/X-1.2001': For PDF/X-1a [iso15930] 'TIFF/IT-FP:1998': TIFF/IT [iso12639] - Full Page - baseline. 'TIFF/IT-CT:1998': TIFF/IT [iso12639] - Continuous Tone picture data - baseline 'TIFF/IT-FP/P1:1998': TIFF/IT [iso12639] - Full Page - profile 1 'TIFF/IT-CT/P1:1998': TIFF/IT [iso12639] - Continuous Tone picture data - profile 1 See PWG www.pwg.org [need URL] for a flat file list of the version strings currently recognized for use in the PWG Semantic Model and derivative protocols, such as IPP and PSI. and the updated JDF MimeOrFileTypeVersion attribute would become: The level or version of the file format identified by MimeType or, FileType. Some example values are the same as the Printer MIB [rfc1759] prtInterpreterLangFamily textual convention (minus the "lang" prefix) and prtInterpreterLangLevel, such as: "PS/1", "PS/2", "PS/3" for MimeType = "application/postscript" "PCL/3", "PDL/4", "PCL/5", "PCL/5e" for MimeType = "application/vnd.hp-PCL" Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as: "MSWORD/5.0", "MSWORD/6.0", "MSWORD/2000", "MSWORD/XP" for MimeType = "application/msword" "PDF/1.3", "PDF/1.4", "PDF/X-1:2001", "PDF/X-1a:2001" for MimeType = "application/pdf" "DCS/2.0" for FileType = "DCS" "???" for FileType = "ICC Profile" ISSUE (Ann): What versions for ICC Profiles? "TIFF-IT/FP:1998", "TIFF-IT/CT:1998", "TIFF-IT/LW:1998" for FileType = "TIFF/IT" See CIP4 www.cip4.org [need URL] for the flat text file that contains the version strings currently recognized for the "FileSpec Resource attributes: MimeType, FileType, MimeOrFileTypeVersion in common use by JDF applications. Comments? Tom From harryl at us.ibm.com Wed Apr 2 18:43:16 2003 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:02:09 2009 Subject: PS> Soap with attachments - relation to SOAP 1.1 In-Reply-To: <6F2B25E1D54DA6428013E7FB7CD84EBF92E828@xvan01.vcd.hp.com> Message-ID: Actually, I think that DIME had more momentum at one point but I believe the focus is now on SOAP w/attachments (including Microsoft and IBM). > > http://www.gotdotnet.com/team/jeffsch/paswa/paswa61.html > > http://www.gotdotnet.com/team/jeffsch/paswa/paswa61.pdf > > http://www.gotdotnet.com/team/jeffsch/paswa/paswa62.doc ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "REVEL,DAN (HP-Vancouver,ex1)" 03/19/2003 10:21 AM To: Harry Lewis/Boulder/IBM@IBMUS, ps@pwg.org cc: Subject: RE: PS> Soap with attachments - relation to SOAP 1.1 SOAP-attachments was a W3C submission, Microsoft et al. made a competing proposal, DIME, that seems to have more momentum: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwebsrv/html/dimewsattch.asp -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, March 18, 2003 9:59 AM To: ps@pwg.org Subject: PS> Soap with attachments - relation to SOAP 1.1 See http://www.w3.org/TR/SOAP-attachments section 4. Seems this has been around for quite a while. I suspect we'd have better interop than we anticipate. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/ps/attachments/20030402/fe0e51ca/attachment.html From hastings at cp10.es.xerox.com Wed Apr 2 21:23:31 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:02:09 2009 Subject: PS> RE: SM> Summary of 9 recent ISSUES/fixes for the IPP Document obj ect tele con, Thur, 4/3/03, 12-3 EST (9-12 PST) Message-ID: And a 10th issue for the Document Object spec: 10. At today's IPPFAX telecon, we discussed the following IPPFAX Printer Description attribute: digital-signatures-supported (1setOf type2 keyword) This attribute identifies which digital signatures technologies are supported by the Receiver. A Receiver MUST support this Printer Description attribute. TODO: Get list of keywords; can be found in "IPP driver install" spec We agreed that it should go in the IPP Document object spec, and that it should have a "digital-signature" (type2 keyword) operation/Document Description attribute that the client submits in a Document Creation operation as well. And therefore, the spelling of the corresponding "digital-signature-supported" (1setOf type2 keyword) Printer Description attribute should be without the "s". The description from the "IPP Driver Install" (IPP Printer Installation Extension) spec is: "digital-signature" One REQUIRED LOWER-CASE 'keyword' string identifying the mechanism used to ensure the integrity and authenticity of this set of Client Print Support Files. Standard values are: 'smime', 'pgp', 'dss', and 'xmldsig' which are defined in [RFC2634], [RFC1991], [dss], and [xmldsig], respectively. In addition, the special keyword value: 'none' is valid. The 'none' value MUST be supported if this attribute is supported. Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, April 01, 2003 18:46 To: sm@pwg.org Cc: ps@pwg.org Subject: SM> Summary of 9 recent ISSUES/fixes for the IPP Document object tele con, Thur, 4/3/03, 12-3 EST (9-12 PST) The 2nd and 3rd hours will be reviewing the IPP Document Object spec (sent out March 25: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324.pdf.zip (1,225 KB) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324.doc.zip (294 KB) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324-rev.pdf.zip (649 KB) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324-rev.doc.zip (309 KB) This note summarizes the suggestions that have been and issues raised since the document was sent out, including discussions in CIP4 about the JDF/FileSpec resource and the SM telecon March 27. The first part of this mail note is a summary of the issues and point to earlier mail messages that are appended for more detail and rationale. 1. Close-Job operation needs the same timeout Printer requirements as RFC 2911 has for Send-Document. 2. Remove "document-id-uri" Document Description attribute. PSI agreed last week that they can use the IPP "document-number" (integer(1:MAX)) Document Description attribute to identify documents within a job. 3. Add a "document-format-version" (text(127)) operation/Document Description attribute with self-identifing values, such as 'PS/3.0', 'PCL/5e', 'PDF/1.4', 'PDF/X-1a:2001' (See ISSUES 01 and 02 below for more details). The prefix is from the Printer MIB langTC values used in the prtInterpretedLangFamily object and the version after the "/" can be used in the Printer MIB prtInterpreterLangLevel object. 4. Add a "document-format-version-default" (text(127)) and "document-format-version-supported" (1setOf text(127)) Printer Description attributes to describe the default and supported values. (See ISSUES 03 below for more details). So "document-format-version" and "document-format" would have parallel semantics, including also being member attributes of "document-format-details" (1setOf collection). 5. ISSUE 04 (repeat of below): Is "document-format-version" a Best Effort (hint) unless "ipp-attribute-fidelity" = 'true" or "job-mandatory-attributes" = 'document-format-version' or do we make "document-format-version" be like "document-format" in that the Printer MUST reject the job if the Printer doesn't support the version? 6. Put the version strings into a flat text file that implementers and implementations can access on the PWG FTP site. Adding new values is simply done whenever they are registered or standardized with some recognized body, such as IANA, CIP4, ISO, etc. ISSUE 05: We need to convince CIP4 to use the same flat file for their FileSpec/@MimeOrFileTypeVersion attribute and/or have each of them shadow the other. 7. Add a "document-natural-language" (naturalLanguage) operation/Document Description attribute and a "document-natural-language-supported" (1setOf naturalLanguage) Printer Description attribute. The "document-natural-language" operation attribute is already defined in RFC 2911 for use with Print-Job, Send-Document, and Send-URI, so we are just continuing this RFC 2911 attribute for the Create-Document operation and making it a Document Description attribute as well, so that it can be queried. Also keep "document-natural-language" (naturalLanguage) as a member attribute of "document-format-details" for describing packages. The "document-natural-language" is needed in order to know how to display characters that depend on language. ISSUE 06: What about multiple languages in a single document for the top level attribute? ISSUE 06a: What about for the member attribute of "document-format-details"? 8. Add a "document-charset" (charset) operation/Document Description attribute and a "docuemnt-charset-supported" (1setOf charset) Printer Descrition attribute. This attribute is needed for the many plain text and markup languages in which the charset is not embedded in the data. For example, PCL often doesn't have the charset escape sequence in the data. Also many files use the various 8-bit ISO 8859 charsets in which the lower half is US-ASCII and the upper half is various Latin sets (about 8 or 9), Greek, Cyrllic, Hebrew, and Arabic. Shift JIS is another example where the left half is US-ASCII, but the right half can be one of a number of things. But if the data doesn't contain the charset escape sequences, this attribute can help the Printer know what the charset is in the Document. 9. There is one issue embedded in the Document Object spec: 6.1.2.2 document-creator-application-version (text(127)) This OPTIONAL member Operation attribute identifies the version number of the application that created the document. The intent of this attribute is for display to a human being, rather than being parsed by the Printer for purpose of affecting the interpreting by the Printer and so may also include the name of the application, as well as build or service pack numbers. Examples: "Winzip? 8.1 (4331)", "Acrobat 5.0.5 10/26/2001", "Microsoft? Word 2000 (9.0.4119 SR-1)" ISSUE: OK that the purpose is human consumption, instead of program consumption and that it be the same as the application shows in its help message? The two other version attribute: "document-format-version" and "document-format-os-version" are intended for program consumption, not human consumption. Its possible that CIP4 will want to have both types of versions for: applications, operating systems, and documet-formats. Tom Here is last week's thread with more details: -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, March 26, 2003 15:05 To: sm@pwg.org; ps@pwg.org Cc: CIP4 System Behaviour and Interoperability WG [system_behaviour@cip4.org]; CIP4 Capabilities WG [capabilities@cip4.org] Subject: SM> More improvements to the IPP "document-format-version" and JDF Mi meOrFileTypeVersion attributes [4 ISSUES] Ira and I had even further thoughts about the IPP "document-format-version" (wihch don't affect the corresponding JDF MimeOrFileTypeVersion attributes since it is a top level attribute in the FileSpec resource): The proposal from yesterday is to make the values of IPP "docuent-format-version" and JDF MimeOrFileTypeVersion attributes be self-identifying, because they start with a prefix that identifies the format: "PDF/", "PS/", "PCL/", "TIFF/IT-", "DCS/", "MSWORD/", etc. ISSUE 01: OK to add the prefix values as proposed yesterday to the IPP "docuent-format-version" and JDF MimeOrFileTypeVersion attributes to make the values self identifying indendent of the correspoding IPP "document-format" and JDF MimeType attributes? Today's further thought is that we can now promote the IPP "document-format-version" member Operation attribute back to being a top level Document object attribute to accompany the existing "document-format" Operation attribute. This is because "document-format-version-supported" attribute now makes sense as a Printer Descrition attribute on its own, since the values would be things like: "PDF/1.3", "PDF/X-1:2001", "PS/3", "PCL/5e", "TIFF/IT-FP/P1:1998", "DCS/2.0", "MSWORD/2000" and don't need to be paired up with the correspoding "document-format-supported" Printer attribute values: "applicaition/pdf", "application/postscript", "application/vnd.hp-PCL", and "application/msword" MIME type values. ISSUE 02: OK to add a "document-format-version" operation and Document Description attribute to the IPP Document object spec? Just like the "document-format" Operation attribute which is also a member attribute of the "document-format-details" (1setOf collection) Operation/Document Description attribute, we'd keep "document-format-version" as a member attribute as well with the same prefixed values. This now means that "document-format" and "document-format-version" have all parallel construction: a. They are both operation attributes. b. They both have correspoding Document Description attributes that the Printer copies to. c. They both have "xxx-supported" Printer attributes. d. There is a "document-format-default" which now can have a corresponding "document-format-version-default" Printer attribute. ISSUE 03: OK to add "document-format-default" printer attribute? e. The Printer MUST reject the request if the "document-format" isn't supported. ISSUE 04: Do we want to make the same rule for the "document-format-version" or keep it as a Best Effort, unless the client supplies "ipp-attribute-fidelity"='true' or "job-mandatory-attributes"='document-format-version'? Comments? Thanks, Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, March 25, 2003 14:32 To: sm@pwg.org; ps@pwg.org Cc: CIP4 System Behaviour and Interoperability WG [system_behaviour@cip4.org]; CIP4 Capabilities WG [capabilities@cip4.org] Subject: SM> Improvements of the IPP "document-format-version" and JDF MimeOfF ileTypeVersion attributes Today on the FSG Job Ticket API, Ira, Claudia, Till, and I were discussion the current IPP "document-format-version" attribute in the IPP Document Object spec Working Draft, dated March 24, 2003 and the JDF MimeOfFileTypeVersion attribute in the JDF FIleSpec proposal, dated March 21, 2003. This mail note has two specific proposals: 1. Put the version strings into a flat file that can be updated and used by implementers. The respective specs can have an initial sets of strings for the flat file. 2. Make the verson strings self-identifying. Both of these specs are to be discussed on Thursday, March 27, (PWG Semantic Model WG and CIP4 System Behaviour and Interoperability WG). The current text for the IPP "document-format-version" attribute is: 6.1.2.7 document-format-version (text(127)) This REQUIRED member Operation attribute contains the level or version of the document format identified by the "document-format" member attribute. The client MAY supply and the Printer MUST support this member attribute. Possible values are the same as the Printer MIB [rfc1759] prtInterpreterLangLevel (not prtInterpreterLangVersion), such as: '3': For Postscript level 3 [rfc1759]. '5e': For PCL 5e [rfc1759]. Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as:: 'PDF/X-1:2001': For PDF/X-1 [iso15930]. "? 'PDF/X-1.2001': For PDF/X-1a [iso15930] 'TIFF/IT-FP:1998': TIFF/IT [iso12639] - Full Page - baseline. 'TIFF/IT-CT:1998': TIFF/IT [iso12639] - Continuous Tone picture data - baseline 'TIFF/IT-FP/P1:1998': TIFF/IT [iso12639] - Full Page - profile 1 'TIFF/IT-CT/P1:1998': TIFF/IT [iso12639] - Continuous Tone picture data - profile 1 The current text for the JDF MimeOfFileTypeVersion attribute is: The level or version of the file format identified by MimeType or, FileType. Some example values are the same as the Printer MIB [rfc1759] prtInterpreterLangLevel, such as: "1", "2", "3" for MimeType = "application/postscript" "3", "4", "5", "5e" for MimeType = "application/vnd.hp-PCL" Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as: "5.0", "6.0", "2000", "XP" for MimeType = "application/msword" "1.3", "1.4", "PDF/X-1:2001", "PDF/X-1a:2001" for MimeType = "application/pdf" "2.0" for FileType = "DCS" "???" for FileType = "ICC Profile" ISSUE (Ann): What versions for ICC Profiles? "TIFF-IT/FP:1998", "TIFF-IT/CT:1998", "TIFF-IT/LW:1998" for FileType = "TIFF/IT" See Appendix A.1 "FileSpec Resource examples for MimeType, FileType, MimeOrFileTypeVersion attributes" for additional examples in common use by JDF applications. The two suggestions for improvement is: 1. Put the version strings into a flat file so that implementers can get them, so that new values can be added to easily, after appropriate review, without having to republish either the IPP Document Object spec or the CIP4 JDF spec. ISSUE: Whether both the PWG and CIP4 would have their own flat files that they would co-ordinate is an issue to be discussed. 2. The version string should be self identifying, e.g., PDF/1.3, not just 1.3, PS/3, not just 3, PCL/5e, not just 5e. And to build more on the Printer MIB, RFC 1759 (and soon to be published Printer MIBv2) use both the Language Family and the Language Level attributes for the version. The Language Families for PostScript is PS, for PCL is PCL, for PDF is PDF. In the Printer MIB there are two attributes (MIBs call them "objects"): prtInterpreterLangFamily OBJECT-TYPE -- NOTE: In RFC 1759, the enumeration values were implicitly -- defined by this object. SYNTAX PrtInterpreterLangFamilyTC MAX-ACCESS read-only STATUS current DESCRIPTION "The family name of a Page Description Language (PDL) or control language which this interpreter in the printer can interpret or emulate. NOTE: The above description has been modified from RFC 1759 for clarification." prtInterpreterLangLevel OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..31)) MAX-ACCESS read-only STATUS current DESCRIPTION "The level of the language which this interpreter is interpreting or emulating. This might contain a value like '5e'for an interpreter which is emulating level 5e of the PCL language. It might contain '2' for an interpreter which is emulating level 2 of the PostScript language. Similarly it might contain '2' for an interpreter which is emulating level 2 of the HPGL language." The prtInterpreterLangFamily has a Textual Convention for the assignment of about 62 printer languages. The symbolic names are of the form: langXxxx For example there are the following: langPCL(3), -- PCL. Starting with PCL version 5, -- HP-GL/2 is included as part of the -- PCL language. -- PCL and HP-GL/2 are registered -- trademarks of Hewlett-Packard -- Company. langHPGL(4), -- Hewlett-Packard Graphics Language. -- HP-GL is a registered trademark of -- Hewlett-Packard Company. langPJL(5), -- Peripheral Job Language. Appears in -- the data stream between data intended -- for a page description language. -- Hewlett-Packard Co. langPS(6), -- PostScript (tm) Language -- Postscript - a trademark of Adobe -- Systems Incorporated which may be -- registered in certain jurisdictions langIPDS(7), -- Intelligent Printer Data Stream -- Bi-directional print data stream for -- documents consisting of data objects -- (text, image, graphics, bar codes), -- resources (fonts, overlays) and page, -- form and finishing instructions. -- Facilitates system level device -- control, document tracking and error -- recovery throughout the print -- process. -- IBM Corporation. ... langPDF(54), -- Not in RFC 1759 -- Adobe Portable Document Format -- Adobe Systems, Inc. langRPDL(55), -- Not in RFC 1759 -- Ricoh Page Description Language for -- printers. -- Technical manual "RPDL command -- reference" No.307029 -- RICOH, Co. LTD langIntermecIPL(56), -- Not in RFC 1759 -- Intermec Printer Language for label -- printers. -- Technical Manual: "IPL Programmers -- Reference Manual" -- Intermec Corporation langUBIFingerprint(57), -- Not in RFC 1759 -- An intelligent basic-like programming -- language for label printers. -- Reference Manual: "UBI Fingerprint -- 7.1", No. 1-960434-00 -- United Barcode Industries langUBIDirectProtocol(58), -- Not in RFC 1759 -- An intelligent control language for -- label printers. -- Programmers guide: " UBI Direct -- Protocol", No. 1-960419-00 -- United Barcode Industries langFujitsu(59), -- Not in RFC 1759 -- Fujitsu Printer Language -- Reference Manual: -- "FM Printer Sequence" No. 80HP-0770 -- FUJITSU LIMITED langCGM(60), -- Not in RFC 1759 -- Computer Graphics Metafile -- MIME type 'image/cgm' langJPEG(61), -- Not in RFC 1759 -- Joint Photographic Experts Group -- MIME type 'image/jpeg' langCALS1(62), -- Not in RFC 1759 -- US DOD CALS1 (see MIL-STD-1840) -- MIME type 'application/cals-1840' langCALS2(63), -- Not in RFC 1759 -- US DOD CALS2 (see MIL-STD-1840) -- MIME type 'application/cals-1840' langNIRS(64), -- Not in RFC 1759 -- US DOD NIRS (see MIL-STD-1840) -- MIME type 'application/cals-1840' langC4(65) -- Not in RFC 1759 -- US DOD C4 (see MIL-STD-1840) -- MIME type 'application/cals-1840' So take the prtInterpreterLangFamily textual convention after the "lang", follow it with a "/" and then have the prtInterpreterLangLevel. So the updated IPP "document-format-version" member attribute would become: 6.1.2.7 document-format-version (text(127)) This REQUIRED member Operation attribute contains the level or version of the document format identified by the "document-format" member attribute. The client MAY supply and the Printer MUST support this member attribute. Possible values are the same as the Printer MIB [rfc1759] prtInterpreterLangFamily textual convention (minus the "lang" prefix) and prtInterpreterLangLevel (not prtInterpreterLangVersion) separated by a "/", such as: 'PS/3': For Postscript level 3 [rfc1759]. 'PCL/5e': For PCL 5e [rfc1759]. Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such a: 'PDF/X-1:2001': For PDF/X-1 [iso15930]. "? 'PDF/X-1.2001': For PDF/X-1a [iso15930] 'TIFF/IT-FP:1998': TIFF/IT [iso12639] - Full Page - baseline. 'TIFF/IT-CT:1998': TIFF/IT [iso12639] - Continuous Tone picture data - baseline 'TIFF/IT-FP/P1:1998': TIFF/IT [iso12639] - Full Page - profile 1 'TIFF/IT-CT/P1:1998': TIFF/IT [iso12639] - Continuous Tone picture data - profile 1 See PWG www.pwg.org [need URL] for a flat file list of the version strings currently recognized for use in the PWG Semantic Model and derivative protocols, such as IPP and PSI. and the updated JDF MimeOrFileTypeVersion attribute would become: The level or version of the file format identified by MimeType or, FileType. Some example values are the same as the Printer MIB [rfc1759] prtInterpreterLangFamily textual convention (minus the "lang" prefix) and prtInterpreterLangLevel, such as: "PS/1", "PS/2", "PS/3" for MimeType = "application/postscript" "PCL/3", "PDL/4", "PCL/5", "PCL/5e" for MimeType = "application/vnd.hp-PCL" Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as: "MSWORD/5.0", "MSWORD/6.0", "MSWORD/2000", "MSWORD/XP" for MimeType = "application/msword" "PDF/1.3", "PDF/1.4", "PDF/X-1:2001", "PDF/X-1a:2001" for MimeType = "application/pdf" "DCS/2.0" for FileType = "DCS" "???" for FileType = "ICC Profile" ISSUE (Ann): What versions for ICC Profiles? "TIFF-IT/FP:1998", "TIFF-IT/CT:1998", "TIFF-IT/LW:1998" for FileType = "TIFF/IT" See CIP4 www.cip4.org [need URL] for the flat text file that contains the version strings currently recognized for the "FileSpec Resource attributes: MimeType, FileType, MimeOrFileTypeVersion in common use by JDF applications. Comments? Tom From alan.berkema at hp.com Thu Apr 3 16:42:35 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:09 2009 Subject: PS> [PSI]: Last Call Process Message-ID: <499DC368E25AD411B3F100902740AD650E6AD848@xrose03.rose.hp.com> At tomorrows call shall we collect comments separately like comments at an IEEE Letter Ballot and meet after April 21 to resolve the comments: Resolve means: 1) Accept as is 2) Reject 3) Accept with further discussion and re-work 4) ??? What do you think? Alan From imcdonald at sharplabs.com Fri Apr 4 11:35:22 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:09 2009 Subject: PS> [PSI]: Fri 4 April 10am PST - Telecon/WebEx Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF6E@mailsrvnt02.enet.sharplabs.com> Hi Alan and Dave, Nancy and I are headed out the door for three/four days on the road up north. Sorry I can't join the PSI telecon today. I'll see my mail again on Monday. Cheers, - Ira -----Original Message----- From: BERKEMA,ALAN C (HP-Roseville,ex1) [mailto:alan.berkema@hp.com] Sent: Monday, March 31, 2003 10:19 AM To: pwg-announce@pwg.org; 'a PSI pwg.org' Cc: pwg@pwg.org Subject: PS> [PSI]: Fri 4 April 12pm - Telecon/WebEx PSI Call 10:00AM - 12noon 1:00PM - 3:00PM Dial-In #: +1 719-457-0335 Participant Password: 400908# Will begin with an overview for FSG folks Next page turner for Last Call Comments Dave can you pass this along to FSG? FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. Meeting Summary Meeting Name: PSI Last Call Review I Scheduled Time: 4/4/2003 at 10:00AM (GMT -08:00) Pacific Time, USA & Canada. Meeting Number: 21659206 Any meeting attendee can use this number to join the meeting, at https://hp.webex.com/join/ Password: newpsi ---------------------------------------------------------------------------- ------------------------------------------------------------------- Meeting Summary Meeting Name: PSI Last Call Review II Scheduled Time: 4/4/2003 at 1:00PM (GMT -08:00) Pacific Time, USA & Canada. Meeting Number: 26342152 Any meeting attendee can use this number to join the meeting, at https://hp.webex.com/join/ Password: newpsi From alan.berkema at hp.com Fri Apr 4 18:42:27 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:09 2009 Subject: PS> [PSI]: next call 04/08/03- 2 hours Message-ID: <499DC368E25AD411B3F100902740AD650E6AD85C@xrose03.rose.hp.com> Teleconference details: NEXT: Tuesday April 08 2003 (USA) Time: 8:00AM (US PDT) Until: 10:00AM Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Brief Update of F2F 2) Continue Last Call Comment Process with the TargetDeviceInterface ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 27995593 Meeting Password: newpsi Host: Alan Berkema 1(916)7855605 From dhall at hp.com Fri Apr 4 18:51:18 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:10 2009 Subject: PS> Last Call Review Comments Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAC26@xvan01.vcd.hp.com> Hi All... The Last Call Review Comments from today's conference call are available at: ftp://ftp.pwg.org/pub/pwg/ps/wd/lcrc-psi10-20030404.doc ftp://ftp.pwg.org/pub/pwg/ps/wd/lcrc-psi10-20030404.pdf Note that the changes in the document are preliminary - they are used to capture Last Call Proposals. Each will need to be individually excepted or rejected. We will continue the review process on next Tuesday's teleconference. Dave From dhall at hp.com Mon Apr 7 12:19:06 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:10 2009 Subject: PS> Updated hpps trace Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAC2A@xvan01.vcd.hp.com> Hey All... I've update our external PSI server (pwg-psips://hpps.vcd.hwp6.net/psi/1.0) to the latest PSI WSDL (http://www.pwg.org/schemas/ps/20030411). Attached is a trace log for a simple AddDocumentByReference job. Dave <> -------------- next part -------------- A non-text attachment was scrubbed... Name: hpps20030411.log Type: application/octet-stream Size: 142346 bytes Desc: not available Url : http://www.pwg.org/archives/ps/attachments/20030407/ea439a5e/hpps20030411.obj From alan.berkema at hp.com Tue Apr 8 17:56:48 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:10 2009 Subject: PS> [PSI]: next call 04/15/03- 2 hours Message-ID: <499DC368E25AD411B3F100902740AD650E6AD86B@xrose03.rose.hp.com> Teleconference details: NEXT: Tuesday April 15 2003 (USA) Time: 8:00AM (US PDT) Until: 10:00AM Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Continue Last Call Comment Process with the TargetDeviceInterface ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 27995593 Meeting Password: newpsi Host: Alan Berkema 1(916)7855605 From hastings at cp10.es.xerox.com Wed Apr 9 07:54:04 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:02:10 2009 Subject: PS> IPP Document Object Spec available for Thursday, April 10, SM Tel econ, 10-11 PDT (1-2 EDT) Message-ID: I've finished the editing on the IPP Document Object Spec and have down loaded it to: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip 1353 KB ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.doc.zip 326 KB This will be reviewed on Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT). Sorry for the short notice, but the editing took way more time than I thought. Version 0.9, 7 April 2003, agreements from the April 3 telecon: 1. Added "document-charset" (charset), "document-digital-signature" (type2 keyword), "document-format-version" (text(127)), and "document-natural-language" (naturalLanguage) Operation and Document Description attributes and corresponding "xxx-default" and "xxx-supported" Printer Description attributes. 2. Changed the "document-natural-language" member attribute of "document-format-details" (1setOf collection) operation attribute to be 1setOf, but kept the top level "document-natural-language" Operation attribute as single-valued. 3. Added Summary Table 2 of new Operation/Document Description attributes. 4. Defined CONDITIONALLY REQUIRED and CMUST Conformance Terms. 5. Deleted the "document-id-uri" Operation attribute no longer needed by PSI. 6. Changed "ipp-attribute-fidelity" so it doesn't affect operation attributes, so it is the same as in [RFC2911]. 7. Clarified the operation attributes supplied at the Job Level in Print-Job and Print-URI versus Create-Job by introducing the "p" notation in Table 7. 8. Added columns to Table 7 to show the corresponding Document Description attributes and the "xxx-default" and "xxx-supported" Printer Description attributes. 9. Clarified that all of the new Operation attributes are hints, except "document-charset" and "document-format" and that the client can turn them into Must Honor by supplying their keyword attribute names in the "job-mandatory-attributes Operation attribute. 10. Add the unique lang prefix from the Printer MIB to all "document-format-version" values, so that they can all be in a single flat list for the Printer's "document-format-version-supported" Printer Description attribute. There are four issues embedded in the document and a 5th from Dennis (see below): 6.1.1 document-charset (charset) ISSUE 01: Since we agreed that this attribute isn't a hint, OK to make it CONDITIONALLY REQUIRED for Printers that support charset-ambiguous document formats? If the Printer supports this "document-digital-signature" Operation attribute and the value supplied by the client, the Printer MUST verify the signature according to the rule for that signature format. If the signature does not verify, then the Printer MUST either (1) ignore the signature or (2) put the job on hold and wait for human intervention, depending on implementation. The Printer gives no additional indication to the client. ISSUE 02: Is either (1) ignore the signature or (2) put the job on hold the correct behavior for the Printer if the digital signature doesn't verify? This Printer behavior is backwards compatible with a Printer that doesn't support the "digital-signature" attribute. However, if the Printer supports the "job-mandatory-attributes" attribute (see section 8.1.2) and the client supplies the "job-mandatory-attribute" Operation attribute with the 'digital-signature' keyword value, then the Printer MUST reject the job if the "digital-signature" attribute is supplied with a value that isn't supported by the Printer (or the Printer doesn't support the "digital-signature" attribute at all). Thus the client can force the Printer to reject a signed document for a signature technology that the Printer does not support. ISSUE 03: What if the digital signature is supported, but the signature fails verification by the Printer when "job-mandatory-attributes" identifies 'document-digital-signature'? The values of the "document-format" and their corresponding "document-format-version" values will be kept in a flat text file on the PWG server for use by the PWG and CIP4. Implementers and implementations will be able to access this file at any time (at CD writing time, install time, vendor update time, and/or at power-up time, etc.). New values will be added to the flat file by its Maintainer after sending to the PWG list for a two week review whenever they are registered with or standardized by some recognized body, such as IANA, CIP4, ISO, etc. ACTION ITEM (Tom): Get CIP4 buy-in to use the same flat file (which will require an additional field for the JDF FileType attribute. ACTION ITEM (Tom and Ira): Propose a format for the file. The URL is: ftp://ftp.pwg.org/pub/pwg/???.txt ISSUE 04: What should the URL be for the flat file? What is the formatting conventions for the flat file. Is it a PWG Schema of sorts? and here is ISSUE 05 from Dennis Carney: - I brought this up on the call, but I'll mention it again, since I'm not sure whether it was resolved. You sell a printer. You happen to have found out that some specific thing goes wrong when a user uses Powerpoint 2000 on Windows NT 4.0, such that your printer always messes up the printout. How do you specify this in document-format-details-implemented? And a much simpler issue on these same lines: why would *anyone*, ever, return any values for the document-creator-application-name-implemented or document-creator-application-version-implemented member attributes--why would anyone want to try to list all applications they support? Similarly for the two "os" member attributes--I might know I don't provide special drivers for Macintosh, but anyone using an LPR utility on Macintosh, with a PDF file, *can* print to me from Macintosh. Even if there *were* some OSes I wanted to say I don't support (which seems doubtful), I have to do this by listing all *other* OSes? I guess in summary: I can see the use for the 5th-8th member attributes of document-format-details-implemented, but not for the 1st-4th. Tom From don at lexmark.com Wed Apr 9 16:07:59 2003 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:02:10 2009 Subject: PS> Dead-on-arrival proposal from "IPP Document Object Spec available for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)" Message-ID: In regards to issue 4 and some background preceding it: ---------------- The values of the "document-format" and their corresponding "document-format-version" values will be kept in a flat text file on the PWG server for use by the PWG and CIP4. Implementers and implementations will be able to access this file at any time (at CD writing time, install time, vendor update time, and/or at power-up time, etc.). New values will be added to the flat file by its Maintainer after sending to the PWG list for a two week review whenever they are registered with or standardized by some recognized body, such as IANA, CIP4, ISO, etc. ACTION ITEM (Tom): Get CIP4 buy-in to use the same flat file (which will require an additional field for the JDF FileType attribute. ACTION ITEM (Tom and Ira): Propose a format for the file. The URL is: ftp://ftp.pwg.org/pub/pwg/???.txt ISSUE 04: What should the URL be for the flat file? What is the formatting conventions for the flat file. Is it a PWG Schema of sorts? ---------------- I CANNOT SUPPORT USING THE PWG SERVER BY ANYTHING OTHER THAN HUMAN BEINGS!!!!! Any proposal that endorses or proposes access by machines "at install time" or "at power-up time" is simply not workable unless some other company wants to support what will become multiple machines with giant bandwidth pipes to the internet to support millions of printers and other devices. I suggest you find another solution. ******************************************* Don Wright don@lexmark.com Chair, IEEE SA Standards Board Member, IEEE-ISTO Board of Directors f.wright@ieee.org / f.wright@computer.org Director, Alliances and Standards Lexmark International 740 New Circle Rd C14/082-3 Lexington, Ky 40550 859-825-4808 (phone) 603-963-8352 (fax) ******************************************* ---------------------- Forwarded by Don Wright/Lex/Lexmark on 04/09/2003 04:01 PM --------------------------- "Hastings, Tom N" @pwg.org on 04/09/2003 07:54:04 AM Sent by: owner-ps@pwg.org To: sm@pwg.org cc: ps@pwg.org Subject: PS> IPP Document Object Spec available for Thursday, April 10, SM Tel econ, 10-11 PDT (1-2 EDT) I've finished the editing on the IPP Document Object Spec and have down loaded it to: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip 1353 KB ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.doc.zip 326 KB This will be reviewed on Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT). Sorry for the short notice, but the editing took way more time than I thought. Version 0.9, 7 April 2003, agreements from the April 3 telecon: 1. Added "document-charset" (charset), "document-digital-signature" (type2 keyword), "document-format-version" (text(127)), and "document-natural-language" (naturalLanguage) Operation and Document Description attributes and corresponding "xxx-default" and "xxx-supported" Printer Description attributes. 2. Changed the "document-natural-language" member attribute of "document-format-details" (1setOf collection) operation attribute to be 1setOf, but kept the top level "document-natural-language" Operation attribute as single-valued. 3. Added Summary Table 2 of new Operation/Document Description attributes. 4. Defined CONDITIONALLY REQUIRED and CMUST Conformance Terms. 5. Deleted the "document-id-uri" Operation attribute no longer needed by PSI. 6. Changed "ipp-attribute-fidelity" so it doesn't affect operation attributes, so it is the same as in [RFC2911]. 7. Clarified the operation attributes supplied at the Job Level in Print-Job and Print-URI versus Create-Job by introducing the "p" notation in Table 7. 8. Added columns to Table 7 to show the corresponding Document Description attributes and the "xxx-default" and "xxx-supported" Printer Description attributes. 9. Clarified that all of the new Operation attributes are hints, except "document-charset" and "document-format" and that the client can turn them into Must Honor by supplying their keyword attribute names in the "job-mandatory-attributes Operation attribute. 10. Add the unique lang prefix from the Printer MIB to all "document-format-version" values, so that they can all be in a single flat list for the Printer's "document-format-version-supported" Printer Description attribute. There are four issues embedded in the document and a 5th from Dennis (see below): 6.1.1 document-charset (charset) ISSUE 01: Since we agreed that this attribute isn't a hint, OK to make it CONDITIONALLY REQUIRED for Printers that support charset-ambiguous document formats? If the Printer supports this "document-digital-signature" Operation attribute and the value supplied by the client, the Printer MUST verify the signature according to the rule for that signature format. If the signature does not verify, then the Printer MUST either (1) ignore the signature or (2) put the job on hold and wait for human intervention, depending on implementation. The Printer gives no additional indication to the client. ISSUE 02: Is either (1) ignore the signature or (2) put the job on hold the correct behavior for the Printer if the digital signature doesn't verify? This Printer behavior is backwards compatible with a Printer that doesn't support the "digital-signature" attribute. However, if the Printer supports the "job-mandatory-attributes" attribute (see section 8.1.2) and the client supplies the "job-mandatory-attribute" Operation attribute with the 'digital-signature' keyword value, then the Printer MUST reject the job if the "digital-signature" attribute is supplied with a value that isn't supported by the Printer (or the Printer doesn't support the "digital-signature" attribute at all). Thus the client can force the Printer to reject a signed document for a signature technology that the Printer does not support. ISSUE 03: What if the digital signature is supported, but the signature fails verification by the Printer when "job-mandatory-attributes" identifies 'document-digital-signature'? The values of the "document-format" and their corresponding "document-format-version" values will be kept in a flat text file on the PWG server for use by the PWG and CIP4. Implementers and implementations will be able to access this file at any time (at CD writing time, install time, vendor update time, and/or at power-up time, etc.). New values will be added to the flat file by its Maintainer after sending to the PWG list for a two week review whenever they are registered with or standardized by some recognized body, such as IANA, CIP4, ISO, etc. ACTION ITEM (Tom): Get CIP4 buy-in to use the same flat file (which will require an additional field for the JDF FileType attribute. ACTION ITEM (Tom and Ira): Propose a format for the file. The URL is: ftp://ftp.pwg.org/pub/pwg/???.txt ISSUE 04: What should the URL be for the flat file? What is the formatting conventions for the flat file. Is it a PWG Schema of sorts? and here is ISSUE 05 from Dennis Carney: - I brought this up on the call, but I'll mention it again, since I'm not sure whether it was resolved. You sell a printer. You happen to have found out that some specific thing goes wrong when a user uses Powerpoint 2000 on Windows NT 4.0, such that your printer always messes up the printout. How do you specify this in document-format-details-implemented? And a much simpler issue on these same lines: why would *anyone*, ever, return any values for the document-creator-application-name-implemented or document-creator-application-version-implemented member attributes--why would anyone want to try to list all applications they support? Similarly for the two "os" member attributes--I might know I don't provide special drivers for Macintosh, but anyone using an LPR utility on Macintosh, with a PDF file, *can* print to me from Macintosh. Even if there *were* some OSes I wanted to say I don't support (which seems doubtful), I have to do this by listing all *other* OSes? I guess in summary: I can see the use for the 5th-8th member attributes of document-format-details-implemented, but not for the 1st-4th. Tom From harryl at us.ibm.com Wed Apr 9 18:45:51 2003 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:02:10 2009 Subject: PS> Re: SM> Dead-on-arrival proposal from "IPP Document Object Spec available for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)" In-Reply-To: Message-ID: We touched on this earlier in the year in the context of SM schemas. We backed off when we backed off the design point where devices would hit the server real-time. If we're drifting back in that direction, we'll have to develop our requirements in terms of bandwidth, QOS, and look for commercial solutions and determine how to fund this via ISTO PWG. I do think it should be feasible to find a commercial solution that meets our needs at an affordable price. I agree with Don that we can't expect a volunteer member to bear this responsibility! ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- don@lexmark.com Sent by: owner-sm@pwg.org 04/09/2003 02:07 PM To: sm@pwg.org, ps@pwg.org cc: Subject: SM> Dead-on-arrival proposal from "IPP Document Object Spec available for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)" In regards to issue 4 and some background preceding it: ---------------- The values of the "document-format" and their corresponding "document-format-version" values will be kept in a flat text file on the PWG server for use by the PWG and CIP4. Implementers and implementations will be able to access this file at any time (at CD writing time, install time, vendor update time, and/or at power-up time, etc.). New values will be added to the flat file by its Maintainer after sending to the PWG list for a two week review whenever they are registered with or standardized by some recognized body, such as IANA, CIP4, ISO, etc. ACTION ITEM (Tom): Get CIP4 buy-in to use the same flat file (which will require an additional field for the JDF FileType attribute. ACTION ITEM (Tom and Ira): Propose a format for the file. The URL is: ftp://ftp.pwg.org/pub/pwg/???.txt ISSUE 04: What should the URL be for the flat file? What is the formatting conventions for the flat file. Is it a PWG Schema of sorts? ---------------- I CANNOT SUPPORT USING THE PWG SERVER BY ANYTHING OTHER THAN HUMAN BEINGS!!!!! Any proposal that endorses or proposes access by machines "at install time" or "at power-up time" is simply not workable unless some other company wants to support what will become multiple machines with giant bandwidth pipes to the internet to support millions of printers and other devices. I suggest you find another solution. ******************************************* Don Wright don@lexmark.com Chair, IEEE SA Standards Board Member, IEEE-ISTO Board of Directors f.wright@ieee.org / f.wright@computer.org Director, Alliances and Standards Lexmark International 740 New Circle Rd C14/082-3 Lexington, Ky 40550 859-825-4808 (phone) 603-963-8352 (fax) ******************************************* ---------------------- Forwarded by Don Wright/Lex/Lexmark on 04/09/2003 04:01 PM --------------------------- "Hastings, Tom N" @pwg.org on 04/09/2003 07:54:04 AM Sent by: owner-ps@pwg.org To: sm@pwg.org cc: ps@pwg.org Subject: PS> IPP Document Object Spec available for Thursday, April 10, SM Tel econ, 10-11 PDT (1-2 EDT) I've finished the editing on the IPP Document Object Spec and have down loaded it to: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip 1353 KB ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.doc.zip 326 KB This will be reviewed on Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT). Sorry for the short notice, but the editing took way more time than I thought. Version 0.9, 7 April 2003, agreements from the April 3 telecon: 1. Added "document-charset" (charset), "document-digital-signature" (type2 keyword), "document-format-version" (text(127)), and "document-natural-language" (naturalLanguage) Operation and Document Description attributes and corresponding "xxx-default" and "xxx-supported" Printer Description attributes. 2. Changed the "document-natural-language" member attribute of "document-format-details" (1setOf collection) operation attribute to be 1setOf, but kept the top level "document-natural-language" Operation attribute as single-valued. 3. Added Summary Table 2 of new Operation/Document Description attributes. 4. Defined CONDITIONALLY REQUIRED and CMUST Conformance Terms. 5. Deleted the "document-id-uri" Operation attribute no longer needed by PSI. 6. Changed "ipp-attribute-fidelity" so it doesn't affect operation attributes, so it is the same as in [RFC2911]. 7. Clarified the operation attributes supplied at the Job Level in Print-Job and Print-URI versus Create-Job by introducing the "p" notation in Table 7. 8. Added columns to Table 7 to show the corresponding Document Description attributes and the "xxx-default" and "xxx-supported" Printer Description attributes. 9. Clarified that all of the new Operation attributes are hints, except "document-charset" and "document-format" and that the client can turn them into Must Honor by supplying their keyword attribute names in the "job-mandatory-attributes Operation attribute. 10. Add the unique lang prefix from the Printer MIB to all "document-format-version" values, so that they can all be in a single flat list for the Printer's "document-format-version-supported" Printer Description attribute. There are four issues embedded in the document and a 5th from Dennis (see below): 6.1.1 document-charset (charset) ISSUE 01: Since we agreed that this attribute isn't a hint, OK to make it CONDITIONALLY REQUIRED for Printers that support charset-ambiguous document formats? If the Printer supports this "document-digital-signature" Operation attribute and the value supplied by the client, the Printer MUST verify the signature according to the rule for that signature format. If the signature does not verify, then the Printer MUST either (1) ignore the signature or (2) put the job on hold and wait for human intervention, depending on implementation. The Printer gives no additional indication to the client. ISSUE 02: Is either (1) ignore the signature or (2) put the job on hold the correct behavior for the Printer if the digital signature doesn't verify? This Printer behavior is backwards compatible with a Printer that doesn't support the "digital-signature" attribute. However, if the Printer supports the "job-mandatory-attributes" attribute (see section 8.1.2) and the client supplies the "job-mandatory-attribute" Operation attribute with the 'digital-signature' keyword value, then the Printer MUST reject the job if the "digital-signature" attribute is supplied with a value that isn't supported by the Printer (or the Printer doesn't support the "digital-signature" attribute at all). Thus the client can force the Printer to reject a signed document for a signature technology that the Printer does not support. ISSUE 03: What if the digital signature is supported, but the signature fails verification by the Printer when "job-mandatory-attributes" identifies 'document-digital-signature'? The values of the "document-format" and their corresponding "document-format-version" values will be kept in a flat text file on the PWG server for use by the PWG and CIP4. Implementers and implementations will be able to access this file at any time (at CD writing time, install time, vendor update time, and/or at power-up time, etc.). New values will be added to the flat file by its Maintainer after sending to the PWG list for a two week review whenever they are registered with or standardized by some recognized body, such as IANA, CIP4, ISO, etc. ACTION ITEM (Tom): Get CIP4 buy-in to use the same flat file (which will require an additional field for the JDF FileType attribute. ACTION ITEM (Tom and Ira): Propose a format for the file. The URL is: ftp://ftp.pwg.org/pub/pwg/???.txt ISSUE 04: What should the URL be for the flat file? What is the formatting conventions for the flat file. Is it a PWG Schema of sorts? and here is ISSUE 05 from Dennis Carney: - I brought this up on the call, but I'll mention it again, since I'm not sure whether it was resolved. You sell a printer. You happen to have found out that some specific thing goes wrong when a user uses Powerpoint 2000 on Windows NT 4.0, such that your printer always messes up the printout. How do you specify this in document-format-details-implemented? And a much simpler issue on these same lines: why would *anyone*, ever, return any values for the document-creator-application-name-implemented or document-creator-application-version-implemented member attributes--why would anyone want to try to list all applications they support? Similarly for the two "os" member attributes--I might know I don't provide special drivers for Macintosh, but anyone using an LPR utility on Macintosh, with a PDF file, *can* print to me from Macintosh. Even if there *were* some OSes I wanted to say I don't support (which seems doubtful), I have to do this by listing all *other* OSes? I guess in summary: I can see the use for the 5th-8th member attributes of document-format-details-implemented, but not for the 1st-4th. Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/ps/attachments/20030409/e4cf8fd8/attachment.html From hastings at cp10.es.xerox.com Thu Apr 10 11:59:48 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:02:10 2009 Subject: PS> RE: SM> Dead-on-arrival proposal from "IPP Document Object Spec a vailable for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)" Message-ID: Don, I think that you hit on the criteria that the file is intended for human use, not automatic machine use. So how about the idea that a human installer and/or administrator can go and fetch the flat file at any time. If the site isn't available, the human will have to try again later. Also I think that the scemas are only for human consumption. The URL is used as an ID to indicate version. Tom -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Wednesday, April 09, 2003 15:46 To: don@lexmark.com Cc: ps@pwg.org; sm@pwg.org Subject: Re: SM> Dead-on-arrival proposal from "IPP Document Object Spec available for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)" We touched on this earlier in the year in the context of SM schemas. We backed off when we backed off the design point where devices would hit the server real-time. If we're drifting back in that direction, we'll have to develop our requirements in terms of bandwidth, QOS, and look for commercial solutions and determine how to fund this via ISTO PWG. I do think it should be feasible to find a commercial solution that meets our needs at an affordable price. I agree with Don that we can't expect a volunteer member to bear this responsibility! ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- don@lexmark.com Sent by: owner-sm@pwg.org 04/09/2003 02:07 PM To: sm@pwg.org, ps@pwg.org cc: Subject: SM> Dead-on-arrival proposal from "IPP Document Object Spec available for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)" In regards to issue 4 and some background preceding it: ---------------- The values of the "document-format" and their corresponding "document-format-version" values will be kept in a flat text file on the PWG server for use by the PWG and CIP4. Implementers and implementations will be able to access this file at any time (at CD writing time, install time, vendor update time, and/or at power-up time, etc.). New values will be added to the flat file by its Maintainer after sending to the PWG list for a two week review whenever they are registered with or standardized by some recognized body, such as IANA, CIP4, ISO, etc. ACTION ITEM (Tom): Get CIP4 buy-in to use the same flat file (which will require an additional field for the JDF FileType attribute. ACTION ITEM (Tom and Ira): Propose a format for the file. The URL is: ftp://ftp.pwg.org/pub/pwg/???.txt ISSUE 04: What should the URL be for the flat file? What is the formatting conventions for the flat file. Is it a PWG Schema of sorts? ---------------- I CANNOT SUPPORT USING THE PWG SERVER BY ANYTHING OTHER THAN HUMAN BEINGS!!!!! Any proposal that endorses or proposes access by machines "at install time" or "at power-up time" is simply not workable unless some other company wants to support what will become multiple machines with giant bandwidth pipes to the internet to support millions of printers and other devices. I suggest you find another solution. ******************************************* Don Wright don@lexmark.com Chair, IEEE SA Standards Board Member, IEEE-ISTO Board of Directors f.wright@ieee.org / f.wright@computer.org Director, Alliances and Standards Lexmark International 740 New Circle Rd C14/082-3 Lexington, Ky 40550 859-825-4808 (phone) 603-963-8352 (fax) ******************************************* ---------------------- Forwarded by Don Wright/Lex/Lexmark on 04/09/2003 04:01 PM --------------------------- "Hastings, Tom N" @pwg.org on 04/09/2003 07:54:04 AM Sent by: owner-ps@pwg.org To: sm@pwg.org cc: ps@pwg.org Subject: PS> IPP Document Object Spec available for Thursday, April 10, SM Tel econ, 10-11 PDT (1-2 EDT) I've finished the editing on the IPP Document Object Spec and have down loaded it to: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip 1353 KB ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.doc.zip 326 KB This will be reviewed on Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT). Sorry for the short notice, but the editing took way more time than I thought. Version 0.9, 7 April 2003, agreements from the April 3 telecon: 1. Added "document-charset" (charset), "document-digital-signature" (type2 keyword), "document-format-version" (text(127)), and "document-natural-language" (naturalLanguage) Operation and Document Description attributes and corresponding "xxx-default" and "xxx-supported" Printer Description attributes. 2. Changed the "document-natural-language" member attribute of "document-format-details" (1setOf collection) operation attribute to be 1setOf, but kept the top level "document-natural-language" Operation attribute as single-valued. 3. Added Summary Table 2 of new Operation/Document Description attributes. 4. Defined CONDITIONALLY REQUIRED and CMUST Conformance Terms. 5. Deleted the "document-id-uri" Operation attribute no longer needed by PSI. 6. Changed "ipp-attribute-fidelity" so it doesn't affect operation attributes, so it is the same as in [RFC2911]. 7. Clarified the operation attributes supplied at the Job Level in Print-Job and Print-URI versus Create-Job by introducing the "p" notation in Table 7. 8. Added columns to Table 7 to show the corresponding Document Description attributes and the "xxx-default" and "xxx-supported" Printer Description attributes. 9. Clarified that all of the new Operation attributes are hints, except "document-charset" and "document-format" and that the client can turn them into Must Honor by supplying their keyword attribute names in the "job-mandatory-attributes Operation attribute. 10. Add the unique lang prefix from the Printer MIB to all "document-format-version" values, so that they can all be in a single flat list for the Printer's "document-format-version-supported" Printer Description attribute. There are four issues embedded in the document and a 5th from Dennis (see below): 6.1.1 document-charset (charset) ISSUE 01: Since we agreed that this attribute isn't a hint, OK to make it CONDITIONALLY REQUIRED for Printers that support charset-ambiguous document formats? If the Printer supports this "document-digital-signature" Operation attribute and the value supplied by the client, the Printer MUST verify the signature according to the rule for that signature format. If the signature does not verify, then the Printer MUST either (1) ignore the signature or (2) put the job on hold and wait for human intervention, depending on implementation. The Printer gives no additional indication to the client. ISSUE 02: Is either (1) ignore the signature or (2) put the job on hold the correct behavior for the Printer if the digital signature doesn't verify? This Printer behavior is backwards compatible with a Printer that doesn't support the "digital-signature" attribute. However, if the Printer supports the "job-mandatory-attributes" attribute (see section 8.1.2) and the client supplies the "job-mandatory-attribute" Operation attribute with the 'digital-signature' keyword value, then the Printer MUST reject the job if the "digital-signature" attribute is supplied with a value that isn't supported by the Printer (or the Printer doesn't support the "digital-signature" attribute at all). Thus the client can force the Printer to reject a signed document for a signature technology that the Printer does not support. ISSUE 03: What if the digital signature is supported, but the signature fails verification by the Printer when "job-mandatory-attributes" identifies 'document-digital-signature'? The values of the "document-format" and their corresponding "document-format-version" values will be kept in a flat text file on the PWG server for use by the PWG and CIP4. Implementers and implementations will be able to access this file at any time (at CD writing time, install time, vendor update time, and/or at power-up time, etc.). New values will be added to the flat file by its Maintainer after sending to the PWG list for a two week review whenever they are registered with or standardized by some recognized body, such as IANA, CIP4, ISO, etc. ACTION ITEM (Tom): Get CIP4 buy-in to use the same flat file (which will require an additional field for the JDF FileType attribute. ACTION ITEM (Tom and Ira): Propose a format for the file. The URL is: ftp://ftp.pwg.org/pub/pwg/???.txt ISSUE 04: What should the URL be for the flat file? What is the formatting conventions for the flat file. Is it a PWG Schema of sorts? and here is ISSUE 05 from Dennis Carney: - I brought this up on the call, but I'll mention it again, since I'm not sure whether it was resolved. You sell a printer. You happen to have found out that some specific thing goes wrong when a user uses Powerpoint 2000 on Windows NT 4.0, such that your printer always messes up the printout. How do you specify this in document-format-details-implemented? And a much simpler issue on these same lines: why would *anyone*, ever, return any values for the document-creator-application-name-implemented or document-creator-application-version-implemented member attributes--why would anyone want to try to list all applications they support? Similarly for the two "os" member attributes--I might know I don't provide special drivers for Macintosh, but anyone using an LPR utility on Macintosh, with a PDF file, *can* print to me from Macintosh. Even if there *were* some OSes I wanted to say I don't support (which seems doubtful), I have to do this by listing all *other* OSes? I guess in summary: I can see the use for the 5th-8th member attributes of document-format-details-implemented, but not for the 1st-4th. Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/ps/attachments/20030410/2bfcca2a/attachment.html From don at lexmark.com Thu Apr 10 14:07:58 2003 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:02:10 2009 Subject: PS> RE: SM> Dead-on-arrival proposal from "IPP Document Object Spec a vailable for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)" Message-ID: Tom: ANY use of the PWG machines for "production" purposes by either the printer itself, an application running on a computer platform or by an end-user administrator/installer is not something we (me or Lexmark) can support. ********************************************** Don Wright don@lexmark.com Chair, IEEE SA Standards Board Member, IEEE-ISTO Board of Directors f.wright@ieee.org / f.wright@computer.org Director, Alliances & Standards Lexmark International 740 New Circle Rd Lexington, Ky 40550 859-825-4808 (phone) 603-963-8352 (fax) ********************************************** "Hastings, Tom N" on 04/10/2003 11:59:48 AM To: Harry Lewis , don@lexmark.com cc: ps@pwg.org, sm@pwg.org Subject: RE: SM> Dead-on-arrival proposal from "IPP Document Object Spec a vailable for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)" Don, I think that you hit on the criteria that the file is intended for human use, not automatic machine use. So how about the idea that a human installer and/or administrator can go and fetch the flat file at any time. If the site isn't available, the human will have to try again later. Also I think that the scemas are only for human consumption. The URL is used as an ID to indicate version. Tom -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Wednesday, April 09, 2003 15:46 To: don@lexmark.com Cc: ps@pwg.org; sm@pwg.org Subject: Re: SM> Dead-on-arrival proposal from "IPP Document Object Spec available for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)" We touched on this earlier in the year in the context of SM schemas. We backed off when we backed off the design point where devices would hit the server real-time. If we're drifting back in that direction, we'll have to develop our requirements in terms of bandwidth, QOS, and look for commercial solutions and determine how to fund this via ISTO PWG. I do think it should be feasible to find a commercial solution that meets our needs at an affordable price. I agree with Don that we can't expect a volunteer member to bear this responsibility! ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- don@lexmark.com Sent by: owner-sm@pwg.org 04/09/2003 02:07 PM To: sm@pwg.org, ps@pwg.org cc: Subject: SM> Dead-on-arrival proposal from "IPP Document Object Spec available for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)" In regards to issue 4 and some background preceding it: ---------------- The values of the "document-format" and their corresponding "document-format-version" values will be kept in a flat text file on the PWG server for use by the PWG and CIP4. Implementers and implementations will be able to access this file at any time (at CD writing time, install time, vendor update time, and/or at power-up time, etc.). New values will be added to the flat file by its Maintainer after sending to the PWG list for a two week review whenever they are registered with or standardized by some recognized body, such as IANA, CIP4, ISO, etc. ACTION ITEM (Tom): Get CIP4 buy-in to use the same flat file (which will require an additional field for the JDF FileType attribute. ACTION ITEM (Tom and Ira): Propose a format for the file. The URL is: ftp://ftp.pwg.org/pub/pwg/???.txt ISSUE 04: What should the URL be for the flat file? What is the formatting conventions for the flat file. Is it a PWG Schema of sorts? ---------------- I CANNOT SUPPORT USING THE PWG SERVER BY ANYTHING OTHER THAN HUMAN BEINGS!!!!! Any proposal that endorses or proposes access by machines "at install time" or "at power-up time" is simply not workable unless some other company wants to support what will become multiple machines with giant bandwidth pipes to the internet to support millions of printers and other devices. I suggest you find another solution. ******************************************* Don Wright don@lexmark.com Chair, IEEE SA Standards Board Member, IEEE-ISTO Board of Directors f.wright@ieee.org / f.wright@computer.org Director, Alliances and Standards Lexmark International 740 New Circle Rd C14/082-3 Lexington, Ky 40550 859-825-4808 (phone) 603-963-8352 (fax) ******************************************* ---------------------- Forwarded by Don Wright/Lex/Lexmark on 04/09/2003 04:01 PM --------------------------- "Hastings, Tom N" @pwg.org on 04/09/2003 07:54:04 AM Sent by: owner-ps@pwg.org To: sm@pwg.org cc: ps@pwg.org Subject: PS> IPP Document Object Spec available for Thursday, April 10, SM Tel econ, 10-11 PDT (1-2 EDT) I've finished the editing on the IPP Document Object Spec and have down loaded it to: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip 1353 KB ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.doc.zip 326 KB This will be reviewed on Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT). Sorry for the short notice, but the editing took way more time than I thought. Version 0.9, 7 April 2003, agreements from the April 3 telecon: 1. Added "document-charset" (charset), "document-digital-signature" (type2 keyword), "document-format-version" (text(127)), and "document-natural-language" (naturalLanguage) Operation and Document Description attributes and corresponding "xxx-default" and "xxx-supported" Printer Description attributes. 2. Changed the "document-natural-language" member attribute of "document-format-details" (1setOf collection) operation attribute to be 1setOf, but kept the top level "document-natural-language" Operation attribute as single-valued. 3. Added Summary Table 2 of new Operation/Document Description attributes. 4. Defined CONDITIONALLY REQUIRED and CMUST Conformance Terms. 5. Deleted the "document-id-uri" Operation attribute no longer needed by PSI. 6. Changed "ipp-attribute-fidelity" so it doesn't affect operation attributes, so it is the same as in [RFC2911]. 7. Clarified the operation attributes supplied at the Job Level in Print-Job and Print-URI versus Create-Job by introducing the "p" notation in Table 7. 8. Added columns to Table 7 to show the corresponding Document Description attributes and the "xxx-default" and "xxx-supported" Printer Description attributes. 9. Clarified that all of the new Operation attributes are hints, except "document-charset" and "document-format" and that the client can turn them into Must Honor by supplying their keyword attribute names in the "job-mandatory-attributes Operation attribute. 10. Add the unique lang prefix from the Printer MIB to all "document-format-version" values, so that they can all be in a single flat list for the Printer's "document-format-version-supported" Printer Description attribute. There are four issues embedded in the document and a 5th from Dennis (see below): 6.1.1 document-charset (charset) ISSUE 01: Since we agreed that this attribute isn't a hint, OK to make it CONDITIONALLY REQUIRED for Printers that support charset-ambiguous document formats? If the Printer supports this "document-digital-signature" Operation attribute and the value supplied by the client, the Printer MUST verify the signature according to the rule for that signature format. If the signature does not verify, then the Printer MUST either (1) ignore the signature or (2) put the job on hold and wait for human intervention, depending on implementation. The Printer gives no additional indication to the client. ISSUE 02: Is either (1) ignore the signature or (2) put the job on hold the correct behavior for the Printer if the digital signature doesn't verify? This Printer behavior is backwards compatible with a Printer that doesn't support the "digital-signature" attribute. However, if the Printer supports the "job-mandatory-attributes" attribute (see section 8.1.2) and the client supplies the "job-mandatory-attribute" Operation attribute with the 'digital-signature' keyword value, then the Printer MUST reject the job if the "digital-signature" attribute is supplied with a value that isn't supported by the Printer (or the Printer doesn't support the "digital-signature" attribute at all). Thus the client can force the Printer to reject a signed document for a signature technology that the Printer does not support. ISSUE 03: What if the digital signature is supported, but the signature fails verification by the Printer when "job-mandatory-attributes" identifies 'document-digital-signature'? The values of the "document-format" and their corresponding "document-format-version" values will be kept in a flat text file on the PWG server for use by the PWG and CIP4. Implementers and implementations will be able to access this file at any time (at CD writing time, install time, vendor update time, and/or at power-up time, etc.). New values will be added to the flat file by its Maintainer after sending to the PWG list for a two week review whenever they are registered with or standardized by some recognized body, such as IANA, CIP4, ISO, etc. ACTION ITEM (Tom): Get CIP4 buy-in to use the same flat file (which will require an additional field for the JDF FileType attribute. ACTION ITEM (Tom and Ira): Propose a format for the file. The URL is: ftp://ftp.pwg.org/pub/pwg/???.txt ISSUE 04: What should the URL be for the flat file? What is the formatting conventions for the flat file. Is it a PWG Schema of sorts? and here is ISSUE 05 from Dennis Carney: - I brought this up on the call, but I'll mention it again, since I'm not sure whether it was resolved. You sell a printer. You happen to have found out that some specific thing goes wrong when a user uses Powerpoint 2000 on Windows NT 4.0, such that your printer always messes up the printout. How do you specify this in document-format-details-implemented? And a much simpler issue on these same lines: why would *anyone*, ever, return any values for the document-creator-application-name-implemented or document-creator-application-version-implemented member attributes--why would anyone want to try to list all applications they support? Similarly for the two "os" member attributes--I might know I don't provide special drivers for Macintosh, but anyone using an LPR utility on Macintosh, with a PDF file, *can* print to me from Macintosh. Even if there *were* some OSes I wanted to say I don't support (which seems doubtful), I have to do this by listing all *other* OSes? I guess in summary: I can see the use for the 5th-8th member attributes of document-format-details-implemented, but not for the 1st-4th. Tom (See attached file: C.htm) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/ps/attachments/20030410/b322230e/iso-8859-1QC.html From alan.berkema at hp.com Tue Apr 15 14:02:28 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:10 2009 Subject: PS> [PSI]: next call 04/22/03- 2 hours Message-ID: <6CD0BB10724459478066E90327DBB651204459@xrose01.rose.hp.com> Teleconference details: NEXT: Tuesday April 22 2003 (USA) Time: 8:00AM (US PDT) Until: 10:00AM Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Last Call Comment Resolution based on the spec that Dave will post soon. Only potential controversial items will be reviewed. Most of the language changes will be accepted at the prerogative of our editor. After this meeting the speciation will be submitted for a 10 day re-circulation Last Call. Comments may be submitted via e-mail. We do not plan another page turner. Thanks, Alan ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 27995593 Meeting Password: newpsi Host: Alan Berkema 1(916)7855605 From dhall at hp.com Wed Apr 16 13:53:38 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:10 2009 Subject: PS> Where to publish xsd / wsdl Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAC70@xvan01.vcd.hp.com> Hey All.. As we create new WSDL and XSD documents, and their "simple" counterparts, where should we publish the schemas? I would propose the following: * The schemas should have the EXACT SAME NAMESPACE - this is required if the "on the wire" envelopes should look the same. * The Full schemas should be published where they are currently being published: (http://www.pwg.org/schemas//) * The simple schemas should be published at: (http://www.pwg.org/schemas//) What do you think? Dave From imcdonald at sharplabs.com Thu Apr 17 10:57:41 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:10 2009 Subject: PS> FW: [Srvloc-discuss] SLP API for Java Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF86@mailsrvnt02.enet.sharplabs.com> -----Original Message----- From: Matt Peterson [mailto:mpeterson@center7.com] Sent: Wednesday, April 16, 2003 12:14 PM To: openslp-devel@lists.sourceforge.net; srvloc-discuss@lists.sourceforge.net; openslp-users@lists.sourceforge.net; openslp-announce@lists.sourceforge.net Subject: [Srvloc-discuss] SLP API for Java Hi, Thanks to Dave Cooper and Solars Corporation, the OpenSLP project is able to offer a pure Java implementation of the SLP API. has been posted on the OpenSLP web site. For more information see: http://www.openslp.org/download.html#java ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Srvloc-discuss mailing list Srvloc-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/srvloc-discuss From hastings at cp10.es.xerox.com Thu Apr 17 17:00:59 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:02:10 2009 Subject: PS> 4 significant proposed increases in conformance requirements for the IPP Document object spec Message-ID: Attendees: Harry Lewis, Bob Taylor, Dave Hall, Lee Farrell, Gail Songer, Ira McDonald, Peter Zehler, Tom Hastings (did I miss anyone?) At today's PWG Semantic Model telecon we did a page by page review of the IPP Document Object Spec in preparation for Last Call: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip This mail note contains several significant changes in Printer conformance requirements that we agreed to for the indicated reasons. However, because of their significance, we agreed to post these changes to the DL for a two week comment period. Objectsion and comments on these changes are due by Friday, May 2, end of business. Silence will be interpreted as approval, so if you object, please send email. The other less significant agreements will be posted in a separate mail note as minutes. We resolved all of the issues and did the page by page review up to page 42 Table 7. We will continue the page by page at another two hour telecon next Thursday, April 24, same time: 1-3 PM EDT (10-12 PDT) with the same version of the specification. Same call-in number and HP webex. Agreed to significant conformance requirements changes: 1. Change the Send-URI operation and the corresponding "reference-uri-schemes-supported" (1setOf uriScheme) Printer Description attribute from OPTIONAL to REQUIRED for a Printer to support. We agreed that a conforming implementation MAY have an empty list for the "reference-uri-schemes-supported" Printer Description attribute. Reason: PSI requires this operation (and has no OPTIONAL attributes). Optional operations are much less likely to get support by clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. 2. Change the Set-Document-Attributes operation from OPTIIOAL to REQUIRED for a Printer to support. Reason: This is the Document object spec and users should be able to modify a Document object after the job is submitted. Optional operations are much less likely to get support by users clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. 3. Change the Set-Job-Attributes operation from OPTIONAL to RECOMMENDED for a Printer to support. Reason: To go along with the change in the conformance requirements for the Set-Document-Attributes operation. However, don't REQUIRE Set-Job-Attributes, since most of the interesting attributes are document attributes, not job attributes. 4. Add an OPTIONAL 'guaranteed" value (see [ippsave] section 8.1) for the "pdl-overrides-supported" Printer Description attribute (REQUIRED in [rfc2911] section 4.4.28) to augment 'not-attempted', and 'attempted' values. Also add a REQUIRED "pdl-override-attributes-guaranteed" (1setOf type2 keyword) Printer Description attribute. The values indicate those Job Template and Document Template attributes for which the Printer guarrantees success in overriding the corresponding instruction in the PDL data. The values of this attribute returned in the Get-Printer-Attributes response MAY be colored by the "document-format" operation attribute supplied by the client in the request, if the Printer's guarrantee depends on the document format. A conforming Printer MAY return 'none' as the value. Reason: The IPPFAX needs the ability for the Printer to indicate which Job Template and Document Template attributes the Printer is able to guarantee success in overriding the PDL. Waiting for the Production Printing Set2 [ippsave] to be updated does meet the schedule for IPPFAX which is also trying to go out to last call. Also this extension is analoguous to our addition of "job-mandatory-attributes" to give a finer granularity to "ipp-attribute-fidelity" (boolean) operation attribute. Please send comments by Friday, May 2, 2003. Thanks, Tom From harryl at us.ibm.com Fri Apr 18 13:16:11 2003 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:02:10 2009 Subject: PS> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec In-Reply-To: Message-ID: I'm afraid we are 1. Over complicating the Document Object - This is really beginning to look like IPPv2 2. Risking lackluster adoption based on unnecessary mandatory operations Look at the premise behind (2), below. "... users should be able to modify a document object after the job is submitted...". This might be something nice for some users but there are simpler alternatives (such as canceling the job and resubmitting it).... that don't require an architectural mandate. As for (4) guaranteeing pdl-override... I've always been opposed to the concept of pdl-override... it's premise being that we can't keep ourselves from generating Postscript with embedded production instructions and even if we could there is a mass of Postscript (still) being used for interchange. This was not true when me made the error of specifying pdl-override in IPP and it is less true today. Separating content from production instruction via the use of a job ticket has always been the goal. That goal is now within reach. I think, then, it is time to consider deprecating pdl-override...certainly not elevating the "feature" by mandating further complexity. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Hastings, Tom N" Sent by: owner-ipp@pwg.org 04/17/2003 03:00 PM To: sm@pwg.org cc: ps@pwg.org, ipp@pwg.org Subject: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec Attendees: Harry Lewis, Bob Taylor, Dave Hall, Lee Farrell, Gail Songer, Ira McDonald, Peter Zehler, Tom Hastings (did I miss anyone?) At today's PWG Semantic Model telecon we did a page by page review of the IPP Document Object Spec in preparation for Last Call: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip This mail note contains several significant changes in Printer conformance requirements that we agreed to for the indicated reasons. However, because of their significance, we agreed to post these changes to the DL for a two week comment period. Objectsion and comments on these changes are due by Friday, May 2, end of business. Silence will be interpreted as approval, so if you object, please send email. The other less significant agreements will be posted in a separate mail note as minutes. We resolved all of the issues and did the page by page review up to page 42 Table 7. We will continue the page by page at another two hour telecon next Thursday, April 24, same time: 1-3 PM EDT (10-12 PDT) with the same version of the specification. Same call-in number and HP webex. Agreed to significant conformance requirements changes: 1. Change the Send-URI operation and the corresponding "reference-uri-schemes-supported" (1setOf uriScheme) Printer Description attribute from OPTIONAL to REQUIRED for a Printer to support. We agreed that a conforming implementation MAY have an empty list for the "reference-uri-schemes-supported" Printer Description attribute. Reason: PSI requires this operation (and has no OPTIONAL attributes). Optional operations are much less likely to get support by clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. 2. Change the Set-Document-Attributes operation from OPTIIOAL to REQUIRED for a Printer to support. Reason: This is the Document object spec and users should be able to modify a Document object after the job is submitted. Optional operations are much less likely to get support by users clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. 3. Change the Set-Job-Attributes operation from OPTIONAL to RECOMMENDED for a Printer to support. Reason: To go along with the change in the conformance requirements for the Set-Document-Attributes operation. However, don't REQUIRE Set-Job-Attributes, since most of the interesting attributes are document attributes, not job attributes. 4. Add an OPTIONAL 'guaranteed" value (see [ippsave] section 8.1) for the "pdl-overrides-supported" Printer Description attribute (REQUIRED in [rfc2911] section 4.4.28) to augment 'not-attempted', and 'attempted' values. Also add a REQUIRED "pdl-override-attributes-guaranteed" (1setOf type2 keyword) Printer Description attribute. The values indicate those Job Template and Document Template attributes for which the Printer guarrantees success in overriding the corresponding instruction in the PDL data. The values of this attribute returned in the Get-Printer-Attributes response MAY be colored by the "document-format" operation attribute supplied by the client in the request, if the Printer's guarrantee depends on the document format. A conforming Printer MAY return 'none' as the value. Reason: The IPPFAX needs the ability for the Printer to indicate which Job Template and Document Template attributes the Printer is able to guarantee success in overriding the PDL. Waiting for the Production Printing Set2 [ippsave] to be updated does meet the schedule for IPPFAX which is also trying to go out to last call. Also this extension is analoguous to our addition of "job-mandatory-attributes" to give a finer granularity to "ipp-attribute-fidelity" (boolean) operation attribute. Please send comments by Friday, May 2, 2003. Thanks, Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/ps/attachments/20030418/fc1bc6f2/attachment.html From imcdonald at sharplabs.com Fri Apr 18 14:34:17 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:10 2009 Subject: PS> RE: IPP> 4 significant proposed increases in conformance requirem ents for the IPP Document object spec Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF8B@mailsrvnt02.enet.sharplabs.com> Hi Michael, Tom's notes are actually incomplete. A conforming implementation MUST support at least one scheme (I suggested we RECOMMEND that 'http:'), but an administrator _at_run_time_ may choose to disable this feature by reconfiguring "reference-uri-schemes-supported". I proposed making this operation (Send-URI) mandatory. But only if ALL implementations MUST support at least one reference scheme and SHOULD support 'http:' (note that PSI servers MUST support 'http:' for the AddDocumentByReference method). I contend that the burden of adding a minimal HTTP client to an existing IPP-based printer is minimal. That's the question. Cheers, - Ira McDonald -----Original Message----- From: Michael Sweet [mailto:mike@easysw.com] Sent: Friday, April 18, 2003 6:50 AM To: Hastings, Tom N Cc: sm@pwg.org; ps@pwg.org; ipp@pwg.org Subject: Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec [My initial comments; I still haven't finished going through the document object spec, so I may have more comments early next week] Hastings, Tom N wrote: > ... > 1. Change the Send-URI operation and the corresponding > "reference-uri-schemes-supported" (1setOf uriScheme) Printer > Description attribute from OPTIONAL to REQUIRED for a Printer to > support. We agreed that a conforming implementation MAY have an > empty list for the "reference-uri-schemes-supported" Printer > Description attribute. So in essense you are just changing the status code from server-error-operation-not-supported to client-error-uri-scheme-not-supported. > Reason: PSI requires this operation (and has no OPTIONAL > attributes). Optional operations are much less likely to get support > by clients. It is best practice for an OPTIONAL extension > specification (such as this spec) to have no OPTIONAL operations, so > that user clients will receive the same level of service from all > Printer implementations that support this extension. This reasoning makes no sense since you are also saying that "reference-uri-schemes-supported" can be an empty list, which means that you still have no service from an implementation that doesn't really support Send-URI. Also, I still question the usefulness of Send-URI and Print-URI since security issues (authentication and access control) make implementation for non-trivial URIs difficult, if not impossible. > 2. Change the Set-Document-Attributes operation from OPTIIOAL to > REQUIRED for a Printer to support. OK, however I think the state <-> status table (table 5) isn't right - what if you want to restart a job but print only 1 copy of the first document? > 3. Change the Set-Job-Attributes operation from OPTIONAL to > RECOMMENDED for a Printer to support. > > Reason: To go along with the change in the conformance requirements > for the Set-Document-Attributes operation. However, don't REQUIRE > Set-Job-Attributes, since most of the interesting attributes are > document attributes, not job attributes. Hmm, I'll have to review the current spec some more, but I don't remember a section on Set-Job-Attributes in the March 24th draft. Any chance you can post a message to the *IPP* list whenever you put a new draft up please? Also, it might be helpful to know when you plan on doing telecons - it can be difficult to schedule the time, but I *do* attend them occasionally... (I didn't get messages about either on the IPP list) > 4. Add an OPTIONAL 'guaranteed" value (see [ippsave] section 8.1) for > the "pdl-overrides-supported" Printer Description attribute (REQUIRED > in [rfc2911] section 4.4.28) to augment 'not-attempted', and > 'attempted' values. Also add a REQUIRED > ... OK, no problem with this. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike at easysw dot com Printing Software for UNIX http://www.easysw.com From imcdonald at sharplabs.com Fri Apr 18 14:38:46 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:10 2009 Subject: PS> RE: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF8C@mailsrvnt02.enet.sharplabs.com> Hi Harry, (1) PSI has ALREADY made all of the equivalent WSDL methods REQUIRED. I'm merely suggesting equivalent functionality for the IPP Document object implementors. And yes it _is_ like IPPv2 - the Document object is the main thing missing from IPP/1.1. But this is just and extension. We're not mandating that all IPP/1.1 implementations support the Document object and operations. (2) The FSG expects to (using PAPI/1.0 API) convert any job ticket instructions to IPP job stream instructions. The job ticket support of PDL override is useless in the Free Standards Linux environment without the correspond IPP attributes. Cheers, - Ira -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Friday, April 18, 2003 12:16 PM To: Hastings, Tom N Cc: ipp@pwg.org; ps@pwg.org; sm@pwg.org Subject: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec I'm afraid we are 1. Over complicating the Document Object - This is really beginning to look like IPPv2 2. Risking lackluster adoption based on unnecessary mandatory operations Look at the premise behind (2), below. "... users should be able to modify a document object after the job is submitted...". This might be something nice for some users but there are simpler alternatives (such as canceling the job and resubmitting it).... that don't require an architectural mandate. As for (4) guaranteeing pdl-override... I've always been opposed to the concept of pdl-override... it's premise being that we can't keep ourselves from generating Postscript with embedded production instructions and even if we could there is a mass of Postscript (still) being used for interchange. This was not true when me made the error of specifying pdl-override in IPP and it is less true today. Separating content from production instruction via the use of a job ticket has always been the goal. That goal is now within reach. I think, then, it is time to consider deprecating pdl-override...certainly not elevating the "feature" by mandating further complexity. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Hastings, Tom N" Sent by: owner-ipp@pwg.org 04/17/2003 03:00 PM To: sm@pwg.org cc: ps@pwg.org, ipp@pwg.org Subject: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec Attendees: Harry Lewis, Bob Taylor, Dave Hall, Lee Farrell, Gail Songer, Ira McDonald, Peter Zehler, Tom Hastings (did I miss anyone?) At today's PWG Semantic Model telecon we did a page by page review of the IPP Document Object Spec in preparation for Last Call: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip This mail note contains several significant changes in Printer conformance requirements that we agreed to for the indicated reasons. However, because of their significance, we agreed to post these changes to the DL for a two week comment period. Objectsion and comments on these changes are due by Friday, May 2, end of business. Silence will be interpreted as approval, so if you object, please send email. The other less significant agreements will be posted in a separate mail note as minutes. We resolved all of the issues and did the page by page review up to page 42 Table 7. We will continue the page by page at another two hour telecon next Thursday, April 24, same time: 1-3 PM EDT (10-12 PDT) with the same version of the specification. Same call-in number and HP webex. Agreed to significant conformance requirements changes: 1. Change the Send-URI operation and the corresponding "reference-uri-schemes-supported" (1setOf uriScheme) Printer Description attribute from OPTIONAL to REQUIRED for a Printer to support. We agreed that a conforming implementation MAY have an empty list for the "reference-uri-schemes-supported" Printer Description attribute. Reason: PSI requires this operation (and has no OPTIONAL attributes). Optional operations are much less likely to get support by clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. 2. Change the Set-Document-Attributes operation from OPTIIOAL to REQUIRED for a Printer to support. Reason: This is the Document object spec and users should be able to modify a Document object after the job is submitted. Optional operations are much less likely to get support by users clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. 3. Change the Set-Job-Attributes operation from OPTIONAL to RECOMMENDED for a Printer to support. Reason: To go along with the change in the conformance requirements for the Set-Document-Attributes operation. However, don't REQUIRE Set-Job-Attributes, since most of the interesting attributes are document attributes, not job attributes. 4. Add an OPTIONAL 'guaranteed" value (see [ippsave] section 8.1) for the "pdl-overrides-supported" Printer Description attribute (REQUIRED in [rfc2911] section 4.4.28) to augment 'not-attempted', and 'attempted' values. Also add a REQUIRED "pdl-override-attributes-guaranteed" (1setOf type2 keyword) Printer Description attribute. The values indicate those Job Template and Document Template attributes for which the Printer guarrantees success in overriding the corresponding instruction in the PDL data. The values of this attribute returned in the Get-Printer-Attributes response MAY be colored by the "document-format" operation attribute supplied by the client in the request, if the Printer's guarrantee depends on the document format. A conforming Printer MAY return 'none' as the value. Reason: The IPPFAX needs the ability for the Printer to indicate which Job Template and Document Template attributes the Printer is able to guarantee success in overriding the PDL. Waiting for the Production Printing Set2 [ippsave] to be updated does meet the schedule for IPPFAX which is also trying to go out to last call. Also this extension is analoguous to our addition of "job-mandatory-attributes" to give a finer granularity to "ipp-attribute-fidelity" (boolean) operation attribute. Please send comments by Friday, May 2, 2003. Thanks, Tom From dcarney at us.ibm.com Fri Apr 18 16:45:20 2003 From: dcarney at us.ibm.com (Dennis Carney) Date: Wed May 6 14:02:10 2009 Subject: PS> Re: SM> 4 significant proposed increases in conformance requirements for the IPP Document object spec Message-ID: My comments below marked by . A couple overall comments: 1) It seems like the Document object spec is becoming a grab-bag for all the ideas we come up with, whether they make sense as part of the Document object or not--the spec risks becoming a "Here's a bunch of things that we thought of that would make IPP cooler" spec. 2) I don't like the argument that we should not have OPTIONAL things in the Document object spec. Here are some reasons: - Even if we did what was proposed below, there would still be many, many OPTIONALs in the spec. If we really believe in our argument, those should all be REQUIRED, right? No? Why not? Oh, so there *is* a line between what should be OPTIONAL and what should be REQUIRED? Well, if there *is* a line, that sort of invalidates our argument that there shouldn't be any OPTIONALs. - The Document object spec has become more than just an extension. I think it is seriously rivaling RFC2911 in term of complexity (not in pages, but in complexity, with all those tables for example). This is NOT a criticism--having a Document object is a good idea and this spec is a very good one. But once a spec gets as complex as this one, it is unreasonable to consider it as just an extension that can have the "luxury" of not having any OPTIONALs. Dennis Carney IBM Printing Systems -------------------------------------------------- 1. Change the Send-URI operation and the corresponding "reference-uri-schemes-supported" (1setOf uriScheme) Printer Description attribute from OPTIONAL to REQUIRED for a Printer to support. We agreed that a conforming implementation MAY have an empty list for the "reference-uri-schemes-supported" Printer Description attribute. Reason: PSI requires this operation (and has no OPTIONAL attributes). Optional operations are much less likely to get support by clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. PSI and IPP are different. Look at the PSI "Use Cases" from the Developers Guide--there are no "Joe is at his desk and wants to print to the printer down the hall" use cases. That's not the point of PSI. PSI is very web-oriented, and as such, it makes sense to print by reference. With IPP, printing by reference is really not mainline, so it should be optional. And what does Send-URI have to do with the document object? Ok, it is a way to send a document, but the Document object spec should describe the Document object, NOT try to redefine the way IPP works, imho. 2. Change the Set-Document-Attributes operation from OPTIIOAL to REQUIRED for a Printer to support. Reason: This is the Document object spec and users should be able to modify a Document object after the job is submitted. Optional operations are much less likely to get support by users clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. It seems to have been a long-standing tradition in IPP that the ability to do "Set"s is optional. I don't see why this should change now. What is so special about Set-Document-Attributes? Why aren't we mandating the other "Set" operations as well while we're at it? 3. Change the Set-Job-Attributes operation from OPTIONAL to RECOMMENDED for a Printer to support. Reason: To go along with the change in the conformance requirements for the Set-Document-Attributes operation. However, don't REQUIRE Set-Job-Attributes, since most of the interesting attributes are document attributes, not job attributes. I have less problem here since we aren't going to REQUIRED, but my last comment is valid here as well. 4. Add an OPTIONAL 'guaranteed" value (see [ippsave] section 8.1) for the "pdl-overrides-supported" Printer Description attribute (REQUIRED in [rfc2911] section 4.4.28) to augment 'not-attempted', and 'attempted' values. Also add a REQUIRED "pdl-override-attributes-guaranteed" (1setOf type2 keyword) Printer Description attribute. The values indicate those Job Template and Document Template attributes for which the Printer guarrantees success in overriding the corresponding instruction in the PDL data. The values of this attribute returned in the Get-Printer-Attributes response MAY be colored by the "document-format" operation attribute supplied by the client in the request, if the Printer's guarrantee depends on the document format. A conforming Printer MAY return 'none' as the value. Reason: The IPPFAX needs the ability for the Printer to indicate which Job Template and Document Template attributes the Printer is able to guarantee success in overriding the PDL. Waiting for the Production Printing Set2 [ippsave] to be updated does meet the schedule for IPPFAX which is also trying to go out to last call. Also this extension is analoguous to our addition of "job-mandatory-attributes" to give a finer granularity to "ipp-attribute-fidelity" (boolean) operation attribute. The 'guaranteed' value: So you are only listing this value that already exists in another spec in the interest of trying to get the value to be "official" as quick as possible? I guess I can't argue with that, but it does seem a bit strange to me. I guess [ippsave] is going to be updated to refer to the Document object spec rather than define this new value? The "pdl-override-attributes-guaranteed" attribute: I agree that this was a shortcoming of IPP--the printer had no ability to say which attributes it could override and which it couldn't. I wonder about its applicability to the Document object, but... From hastings at cp10.es.xerox.com Fri Apr 18 19:15:18 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:02:10 2009 Subject: PS> 2 more significant proposed increases in conformance requirements for the IPP Document object spec Message-ID: In summarizing the significant conformance requirement increases that we agreed to today in the review of the IPP Document Object spec review, I forgot two more: 1. Add a REQUIRED way to the Get-Documents operation for the client to get the Documents following the limit requested in a previous request. So add the "start-after-document-number" (integer (0:MAX)) Operation attribute. 2. Add a REQUIRED way to the Get-Jobs operation for the client to get the Jobs following the limit requested in a previous request. So add the "start-after-job-id" (integer (0:MAX)) Operation attribute. Please send any comments on these additions by Friday, May 2, COB. Here are the complete proposed text for these attributes and the updated "limit" Operation attribute: 1.1 Get-Jobs ([rfc2911] section 3.2.6) This REQUIRED Job operation returns requested attributes of either completed or not completed Jobs. The following (new) "start-after-job-id" (integer(0:MAX)) Operation attribute is defined which in combination with the "limit" operation attribute ([rfc2911] section 3.2.6) permits a client to request selected ranges of jobs: 1.1.1 "limit" (integer(1:MAX)): The client OPTIONALLY supplies this Operation attribute. The Printer MUST support this Operation attribute. It is an integer value that determines the maximum number of Jobs that a client will receive from the Printer even if "which-jobs" or "my-jobs" constrain which jobs are returned. The limit is a "stateless limit" in that if the value supplied by the client is 'N', then only the first 'N' jobs are returned in the Get-Jobs Response. If the client does not supply the "limit" attribute, the Printer responds with all applicable Jobs. However, if the client also supplies the "start-after-job-id" Operation attribute (section 4.2.2) with a value 'M', the Printer returns the N Jobs starting with the Job following the one with "job-id" = 'M'. 1.1.2 "start-after-job-id" (integer(0:MAX)): The client OPTIONALLY supplies this Operation attribute. The Printer MUST support this Operation attribute. If the client supplies this attribute with a job-id value 'M', the Printer MUST return Jobs starting with the Job that is after the one with "job-id" = 'M'. If the client does not supply this attribute, the Printer assumes a '0' value which causes the Printer to return any Jobs with any "job-id" that meet the requested criteria (specified by "which-jobs" and/or "my-jobs", etc.). When the client steps through the jobs N at a time, the client MUST set the "start-after-job-id" attribute from the "job-id' of the last Job returned in a previous Get-Jobs response (rather than just adding 'N', since Printers MAY assign job-ids out or order). The client can detect when there are no more jobs when the Printer returns fewer jobs than requested by the "limit" Operation attribute ('N'). In the case when the last number of jobs returned is exactly N jobs, the client will make an extra request and receive no jobs back (still with a 'successful-ok' success code). However, this case still meets the criteria for no more Jobs since the number of Jobs returned (0) is less than "limit".. Note when the client steps through the Jobs supplying the "limit" and "start-after-job-id" Operation attributes in successive Get-Jobs requests, there are some race conditions which the client implementer needs to take into account: * For 'non-completed' Jobs (see [rfc2911] section 3.2.6.2), the Printer MUST return the Jobs in the order of the "expected time to complete" with the first expected to complete being returned first, etc. Because some Printers MAY: (1) process jobs out of order received, and/or (2) assign "job-id" in a non-monotonically increasing manner, occasionally a race condition MAY cause some jobs not be returned and some jobs MAY be returned more than once. The only way for a client to eliminate this race condition for 'not-completed' Jobs is to request all Jobs by supplying neither the "limit" nor the "start-after-job-id" Operation attribute. * For 'completed' jobs (see [rfc2911] section 3.2.6.2), the Printer MUST return the jobs in the order of "newest to oldest" to complete. Therefore, no jobs will be missed and/or doubly returned. 1.2 Get-Documents Operation This REQUIRED Job operation allows a client to retrieve the list of Document objects belonging to the target Job object. The client MAY also supply a list of Document attribute names and/or attribute group names. A group of Document object attributes will be returned for each Document object in the Job. This operation is similar to the Get-Document-Attributes operation (see section 3.5), except that this Get-Documents operation returns attributes from all Document objects contained in the Job object, instead of from a single selected Document object in the Job object. As with the Get-Document-Attributes operation the Printer MUST only return attributes that were submitted by a client when the Document object was created by the Create-Document, Send-Document, or Send-URI operations and possibly modified by the Set-Document-Attributes operation (see section 3.7). 1.2.1 Get-Documents Request The client submits the Get-Documents request to a Printer. The Get-Documents is similar to the Get-Jobs operations (see [rfc2911] section 3.2.6) except that there are no equivalents to the "which-jobs" and "my-jobs" Operation attributes. The following groups of attributes are part of the Get-Documents Request: Group 1: Operation Attributes Natural Language and Character Set: The "attributes-charset" and "attributes-natural-language" attributes as described in [rfc2911] section 3.1.4.1. Target: Either (1) the "printer-uri" (uri) plus "job-id" (integer(1:MAX)) or (2) the "job-uri" (uri) Operation attribute(s) which define the target Job object for this operation as described in [rfc2911] section 3.1.5. Requesting User Name: The "requesting-user-name" (name(MAX)) attribute SHOULD be supplied by the client as described in [rfc2911] section 8.3. 1.2.1.1 "limit" (integer(1:MAX)): The client OPTIONALLY supplies this Operation attribute. The Printer MUST support this Operation attribute. It is an integer value that determines the maximum number of Documents that a client will receive from the Printer. If the client supplies the "limit" attribute with a value 'N' and the "start-after-document-number" attribute with a value 'M', the Printer returns the N Documents starting with the Document after the one with "document-number" = 'M'. The limit is a "stateless limit" in that if the value supplied by the client is 'N', then only the first 'N' Documents are returned in the Get-Documents Response. If the client does not supply the "limit" attribute, the Printer responds with all Documents in the Job. However, if the client also supplies the "start-after-document-number" Operation attribute (section 4.3.1.2) with a value 'M', the Printer returns the N Documents starting with the Document following the one with "document-number" = 'M'. 1.2.1.2 "start-after-document-number" (integer(0:MAX)): The client OPTIONALLY supplies this Operation attribute. The Printer MUST support this Operation attribute. If the client supplies this attribute with a document-number value 'M', the Printer MUST return Documents starting with the Document that is after the one with "document-number" = 'M'. If the client does not supply this attribute, the Printer assumes a '0' value which causes the Printer to return Documents starting with "document-number" = '1' (which is the first document in the Job). Note: canceled Documents (see section 3.7) are still returned, but deleted Documents (see section 3.8) are skipped over, since they don't exist (leaving gaps in the "document-number" sequence). Please send any comments on these additions by Friday, May 2, COB. Thanks, Tom From hastings at cp10.es.xerox.com Fri Apr 18 22:10:36 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:02:10 2009 Subject: PS> RE: IPP> 4 significant proposed increases in conformance requirem ents for the IPP Document object spec Message-ID: Michael, Thanks for your comments. See my replies bracketed by ... Michael wrote: ... > 2. Change the Set-Document-Attributes operation from OPTIIOAL to > REQUIRED for a Printer to support. OK, however I think the state <-> status table (table 5) isn't right - what if you want to restart a job but print only 1 copy of the first document? (It's Table 6 in the April 7 spec, which regrettably was not announced on the IPP DL, only on the SM and PS DLs. Peter and I will make sure to announce IPP specs and telecons on the IPP DL too. The April 7 spec is at: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip ) Yes, the transition table doesn't allow the client to modify a document with Set-Document-Attributes after the Document has 'completed', 'aborted', or 'canceled'. This same transition table is in the published RFC 3380 for the Set-Job-Attributes operation as well. The reason is that a completed, canceled, or aborted job/document should have the record of what was requested, for accounting and/or the help desk trying to figure out what went wrong. If you want to modify a job and resubmit it as in your example to change the number of copies and reprint: the idea is that the client does a Restart-Job (or Reprocess-Job) with the "job-hold-until" operation attribute supplied (see [RFC 2911] section 3.3.7, Restart-Job(. Then the client can modify it with Set-Document-Attributes while the job is in the 'pending-held' state. Then the client can release the modified job for printing with Release-Job (section 3.3.6). > 3. Change the Set-Job-Attributes operation from OPTIONAL to > RECOMMENDED for a Printer to support. > > Reason: To go along with the change in the conformance requirements > for the Set-Document-Attributes operation. However, don't REQUIRE > Set-Job-Attributes, since most of the interesting attributes are > document attributes, not job attributes. Hmm, I'll have to review the current spec some more, but I don't remember a section on Set-Job-Attributes in the March 24th draft. Set-Job-Attributes wasn't in the March 24th draft or the April 7 th draft. However, in proposing to REQUIRE the Set-Document-Attributes operation it seemed reasonsable to increase the requirements for the Set-Job-Attributes operation to at lease RECOMMENDED. But that is what we are asking for feed back on. So in order to conform to the IPP Document object spec, it is RECOMMENDED that the Printer also support Set-Job-Attributes. Any chance you can post a message to the *IPP* list whenever you put a new draft up please? Also, it might be helpful to know when you plan on doing telecons - it can be difficult to schedule the time, but I *do* attend them occasionally... Peter and I will make sure to announce IPP specs and telecons on the IPP DL too. The April 7 spec is at: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip There wont' be a new spec either. We're continuing the page by page. Please send any othre comments and/or join the next telecon, Thursday, April 24, 1-3 PM EDT: > Dial in Info: > Phone Number: (877) 776-6306 > (Phone Number for Xerox Employees: 8*594-0576) > PARTICIPANT PASSCODE: 437874# We're also using webex: > ------------------------- > FIRST TIME USERS > ------------------------- > For fully interactive meetings, including the ability > to present your documents and applications, a one-time > setup takes less than 10 minutes. Click this URL to set up now: > > http://hp.webex.com > > Then click New User. > ------------------------- > > On Thursday use: > https://hp.webex.com/join/ > > Then click join unlisted meeting. > Use the info below: > ------------------------- The meeting number and password will be announced next week. ... From harryl at us.ibm.com Sat Apr 19 12:03:05 2003 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:02:10 2009 Subject: PS> RE: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec In-Reply-To: <116DB56CD7DED511BC7800508B2CA53735CF8C@mailsrvnt02.enet.sharplabs.com> Message-ID: 1. Help me out as to where PSI states this it is mandatory to support modification of a Document object after the job is submitted. 2. I support healthy alignment with FSG and I've been pushing for a job ticket interface to PSI. It's just... every time I ask for a show of hands regarding actual support for PDL-override the response is always lackluster. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "McDonald, Ira" Sent by: owner-sm@pwg.org 04/18/2003 12:38 PM To: Harry Lewis/Boulder/IBM@IBMUS, "Hastings, Tom N" cc: ipp@pwg.org, ps@pwg.org, sm@pwg.org Subject: RE: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec Hi Harry, (1) PSI has ALREADY made all of the equivalent WSDL methods REQUIRED. I'm merely suggesting equivalent functionality for the IPP Document object implementors. And yes it _is_ like IPPv2 - the Document object is the main thing missing from IPP/1.1. But this is just and extension. We're not mandating that all IPP/1.1 implementations support the Document object and operations. (2) The FSG expects to (using PAPI/1.0 API) convert any job ticket instructions to IPP job stream instructions. The job ticket support of PDL override is useless in the Free Standards Linux environment without the correspond IPP attributes. Cheers, - Ira -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Friday, April 18, 2003 12:16 PM To: Hastings, Tom N Cc: ipp@pwg.org; ps@pwg.org; sm@pwg.org Subject: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec I'm afraid we are 1. Over complicating the Document Object - This is really beginning to look like IPPv2 2. Risking lackluster adoption based on unnecessary mandatory operations Look at the premise behind (2), below. "... users should be able to modify a document object after the job is submitted...". This might be something nice for some users but there are simpler alternatives (such as canceling the job and resubmitting it).... that don't require an architectural mandate. As for (4) guaranteeing pdl-override... I've always been opposed to the concept of pdl-override... it's premise being that we can't keep ourselves from generating Postscript with embedded production instructions and even if we could there is a mass of Postscript (still) being used for interchange. This was not true when me made the error of specifying pdl-override in IPP and it is less true today. Separating content from production instruction via the use of a job ticket has always been the goal. That goal is now within reach. I think, then, it is time to consider deprecating pdl-override...certainly not elevating the "feature" by mandating further complexity. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Hastings, Tom N" Sent by: owner-ipp@pwg.org 04/17/2003 03:00 PM To: sm@pwg.org cc: ps@pwg.org, ipp@pwg.org Subject: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec Attendees: Harry Lewis, Bob Taylor, Dave Hall, Lee Farrell, Gail Songer, Ira McDonald, Peter Zehler, Tom Hastings (did I miss anyone?) At today's PWG Semantic Model telecon we did a page by page review of the IPP Document Object Spec in preparation for Last Call: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip This mail note contains several significant changes in Printer conformance requirements that we agreed to for the indicated reasons. However, because of their significance, we agreed to post these changes to the DL for a two week comment period. Objectsion and comments on these changes are due by Friday, May 2, end of business. Silence will be interpreted as approval, so if you object, please send email. The other less significant agreements will be posted in a separate mail note as minutes. We resolved all of the issues and did the page by page review up to page 42 Table 7. We will continue the page by page at another two hour telecon next Thursday, April 24, same time: 1-3 PM EDT (10-12 PDT) with the same version of the specification. Same call-in number and HP webex. Agreed to significant conformance requirements changes: 1. Change the Send-URI operation and the corresponding "reference-uri-schemes-supported" (1setOf uriScheme) Printer Description attribute from OPTIONAL to REQUIRED for a Printer to support. We agreed that a conforming implementation MAY have an empty list for the "reference-uri-schemes-supported" Printer Description attribute. Reason: PSI requires this operation (and has no OPTIONAL attributes). Optional operations are much less likely to get support by clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. 2. Change the Set-Document-Attributes operation from OPTIIOAL to REQUIRED for a Printer to support. Reason: This is the Document object spec and users should be able to modify a Document object after the job is submitted. Optional operations are much less likely to get support by users clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. 3. Change the Set-Job-Attributes operation from OPTIONAL to RECOMMENDED for a Printer to support. Reason: To go along with the change in the conformance requirements for the Set-Document-Attributes operation. However, don't REQUIRE Set-Job-Attributes, since most of the interesting attributes are document attributes, not job attributes. 4. Add an OPTIONAL 'guaranteed" value (see [ippsave] section 8.1) for the "pdl-overrides-supported" Printer Description attribute (REQUIRED in [rfc2911] section 4.4.28) to augment 'not-attempted', and 'attempted' values. Also add a REQUIRED "pdl-override-attributes-guaranteed" (1setOf type2 keyword) Printer Description attribute. The values indicate those Job Template and Document Template attributes for which the Printer guarrantees success in overriding the corresponding instruction in the PDL data. The values of this attribute returned in the Get-Printer-Attributes response MAY be colored by the "document-format" operation attribute supplied by the client in the request, if the Printer's guarrantee depends on the document format. A conforming Printer MAY return 'none' as the value. Reason: The IPPFAX needs the ability for the Printer to indicate which Job Template and Document Template attributes the Printer is able to guarantee success in overriding the PDL. Waiting for the Production Printing Set2 [ippsave] to be updated does meet the schedule for IPPFAX which is also trying to go out to last call. Also this extension is analoguous to our addition of "job-mandatory-attributes" to give a finer granularity to "ipp-attribute-fidelity" (boolean) operation attribute. Please send comments by Friday, May 2, 2003. Thanks, Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/ps/attachments/20030419/ba7a2581/attachment.html From imcdonald at sharplabs.com Sat Apr 19 16:57:38 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:10 2009 Subject: PS> RE: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF8E@mailsrvnt02.enet.sharplabs.com> Hi Harry, 1) Support for modifying document object after submission is present in the FetchJobs interface that can OVERRIDE existing job or document attributes as the job flows from PSI Print Service to PSI Target Device. Whereas IPP Resubmit/Restart do NOT allow the attributes to be modified in the operation but require "job-hold-until" to be set to allow SUBSEQUENT use of the (OPTIONAL) Set-Job-Attributes. But what I meant below was: Send-Document and Send-URI are both OPTIONAL in IPP/1.1, but the AddDocumentByValue and AddDocumentByReference are REQUIRED in PSI/1.0. Since we are only just now adding Document objects to IPP, I simply propose that we offer PSI-equivalent capabilities in the protocol (for implementations of the Document object specification _only_). 2) I agree that PDL override is hard to implement (in _some_ PDLs), but what Tom and I have proposed is to disambiguate _which_ attributes (if any) can be guaranteed to successfully override the PDL. Seems to me like a good clarity enhancement to IPP. Cheers, - Ira -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Saturday, April 19, 2003 11:03 AM To: McDonald, Ira Cc: Hastings, Tom N; ipp@pwg.org; ps@pwg.org; sm@pwg.org Subject: RE: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec 1. Help me out as to where PSI states this it is mandatory to support modification of a Document object after the job is submitted. 2. I support healthy alignment with FSG and I've been pushing for a job ticket interface to PSI. It's just... every time I ask for a show of hands regarding actual support for PDL-override the response is always lackluster. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "McDonald, Ira" Sent by: owner-sm@pwg.org 04/18/2003 12:38 PM To: Harry Lewis/Boulder/IBM@IBMUS, "Hastings, Tom N" cc: ipp@pwg.org, ps@pwg.org, sm@pwg.org Subject: RE: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec Hi Harry, (1) PSI has ALREADY made all of the equivalent WSDL methods REQUIRED. I'm merely suggesting equivalent functionality for the IPP Document object implementors. And yes it _is_ like IPPv2 - the Document object is the main thing missing from IPP/1.1. But this is just and extension. We're not mandating that all IPP/1.1 implementations support the Document object and operations. (2) The FSG expects to (using PAPI/1.0 API) convert any job ticket instructions to IPP job stream instructions. The job ticket support of PDL override is useless in the Free Standards Linux environment without the correspond IPP attributes. Cheers, - Ira -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Friday, April 18, 2003 12:16 PM To: Hastings, Tom N Cc: ipp@pwg.org; ps@pwg.org; sm@pwg.org Subject: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec I'm afraid we are 1. Over complicating the Document Object - This is really beginning to look like IPPv2 2. Risking lackluster adoption based on unnecessary mandatory operations Look at the premise behind (2), below. "... users should be able to modify a document object after the job is submitted...". This might be something nice for some users but there are simpler alternatives (such as canceling the job and resubmitting it).... that don't require an architectural mandate. As for (4) guaranteeing pdl-override... I've always been opposed to the concept of pdl-override... it's premise being that we can't keep ourselves from generating Postscript with embedded production instructions and even if we could there is a mass of Postscript (still) being used for interchange. This was not true when me made the error of specifying pdl-override in IPP and it is less true today. Separating content from production instruction via the use of a job ticket has always been the goal. That goal is now within reach. I think, then, it is time to consider deprecating pdl-override...certainly not elevating the "feature" by mandating further complexity. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Hastings, Tom N" Sent by: owner-ipp@pwg.org 04/17/2003 03:00 PM To: sm@pwg.org cc: ps@pwg.org, ipp@pwg.org Subject: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec Attendees: Harry Lewis, Bob Taylor, Dave Hall, Lee Farrell, Gail Songer, Ira McDonald, Peter Zehler, Tom Hastings (did I miss anyone?) At today's PWG Semantic Model telecon we did a page by page review of the IPP Document Object Spec in preparation for Last Call: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip This mail note contains several significant changes in Printer conformance requirements that we agreed to for the indicated reasons. However, because of their significance, we agreed to post these changes to the DL for a two week comment period. Objectsion and comments on these changes are due by Friday, May 2, end of business. Silence will be interpreted as approval, so if you object, please send email. The other less significant agreements will be posted in a separate mail note as minutes. We resolved all of the issues and did the page by page review up to page 42 Table 7. We will continue the page by page at another two hour telecon next Thursday, April 24, same time: 1-3 PM EDT (10-12 PDT) with the same version of the specification. Same call-in number and HP webex. Agreed to significant conformance requirements changes: 1. Change the Send-URI operation and the corresponding "reference-uri-schemes-supported" (1setOf uriScheme) Printer Description attribute from OPTIONAL to REQUIRED for a Printer to support. We agreed that a conforming implementation MAY have an empty list for the "reference-uri-schemes-supported" Printer Description attribute. Reason: PSI requires this operation (and has no OPTIONAL attributes). Optional operations are much less likely to get support by clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. 2. Change the Set-Document-Attributes operation from OPTIIOAL to REQUIRED for a Printer to support. Reason: This is the Document object spec and users should be able to modify a Document object after the job is submitted. Optional operations are much less likely to get support by users clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. 3. Change the Set-Job-Attributes operation from OPTIONAL to RECOMMENDED for a Printer to support. Reason: To go along with the change in the conformance requirements for the Set-Document-Attributes operation. However, don't REQUIRE Set-Job-Attributes, since most of the interesting attributes are document attributes, not job attributes. 4. Add an OPTIONAL 'guaranteed" value (see [ippsave] section 8.1) for the "pdl-overrides-supported" Printer Description attribute (REQUIRED in [rfc2911] section 4.4.28) to augment 'not-attempted', and 'attempted' values. Also add a REQUIRED "pdl-override-attributes-guaranteed" (1setOf type2 keyword) Printer Description attribute. The values indicate those Job Template and Document Template attributes for which the Printer guarrantees success in overriding the corresponding instruction in the PDL data. The values of this attribute returned in the Get-Printer-Attributes response MAY be colored by the "document-format" operation attribute supplied by the client in the request, if the Printer's guarrantee depends on the document format. A conforming Printer MAY return 'none' as the value. Reason: The IPPFAX needs the ability for the Printer to indicate which Job Template and Document Template attributes the Printer is able to guarantee success in overriding the PDL. Waiting for the Production Printing Set2 [ippsave] to be updated does meet the schedule for IPPFAX which is also trying to go out to last call. Also this extension is analoguous to our addition of "job-mandatory-attributes" to give a finer granularity to "ipp-attribute-fidelity" (boolean) operation attribute. Please send comments by Friday, May 2, 2003. Thanks, Tom From imcdonald at sharplabs.com Sun Apr 20 16:54:02 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:10 2009 Subject: PS> RE: [SPAM] RE: IPP> 4 significant proposed increases in conforman ce requirem ents for the IPP Document object spec Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF92@mailsrvnt02.enet.sharplabs.com> Hi Michael, Inline comments below. Cheers, - Ira -----Original Message----- From: Mike Sweet [mailto:mike@easysw.com] Sent: Saturday, April 19, 2003 10:11 PM To: McDonald, Ira Cc: Hastings, Tom N; sm@pwg.org; ps@pwg.org; ipp@pwg.org Subject: Re: [SPAM] RE: IPP> 4 significant proposed increases in conformance requirem ents for the IPP Document object spec McDonald, Ira wrote: > ... > Tom's notes are actually incomplete. A conforming implementation > MUST support at least one scheme (I suggested we RECOMMEND that > 'http:'), but an administrator _at_run_time_ may choose to disable > this feature by reconfiguring "reference-uri-schemes-supported". Well, then you will likely find very few implementations. We've been working on Print-URI/Send-URI support for CUPS 1.2 and the authentication/security/performance issues are a real hassle for a real-world implementation. Also, you can be sure that any CUPS implementation of the spec WILL NOT enable print-by-reference by default for serious security reasons, and there will be extremely high barriers in place to limit how and where you can print from. > I proposed making this operation (Send-URI) mandatory. But only > if ALL implementations MUST support at least one reference scheme > and SHOULD support 'http:' (note that PSI servers MUST support > 'http:' for the AddDocumentByReference method). Is there any practical reason why PSI can't just require stricter requirements than the basic IPP mapping? It seems idiotic to require print-by-reference for IPP whose goals are different than PSI. _my_ goal is full-bandwidth application gateways between IPP and PSI. Everywhere that IPP doesn't have a feature at all (the out-of-band push in PSI's AddDocumentByPush) or has made a feature optional (PSI's AddDocumentByReference), the gateway will fail entirely. Note, PSI _is_ sending (over a TLS-secured channel) whatever username and password or certificate necessary to do the SMTP, IMAP, HTTPS, or whatever connection for the AddDocumentByReference, from the client embedded in the PSI Print Service or Target Device. If this is security nightmare for IPP, then the same applies to PSI - why is it so hard if the Print Service simply impersonates the end user? (I know this can't work if the end user's TLS certificate is restricted to access from a pre-configured source FQDN for the end user's system, but that problem _isn't_ soluble.) > I contend that the burden of adding a minimal HTTP client to an > existing IPP-based printer is minimal. That's the question. For a server that will only handle a single connection at a time, and for simple accesses without authentication, it can be implemented fairly easily. However, for any non-trivial implementation there are authentication, security, and performance issues that MUST be dealt with. Consider a typical web application like email which uses HTTP authentication, cookies, encryption, and probably some sort of host/ip-based session key; a print-by-reference approach is doomed to fail even if we can pass all of the required info to the IPP server, since it will somehow have to re-login and go to the right URL. Assuming it *does* work somehow, you need to securely manage this authentication information or risk compromising a remote system. I don't doubt that there is some minimal functionality that can be provided by Print-URI and friends, however the cost/benefit ratio is too high and I believe will hurt adoption of the document object spec. Well, print by reference is the main design center of PSI, so if it will hurt adoption of IPP Document objects, then it will equally hurt PSI adoption. Do you think PSI is in trouble?? -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From imcdonald at sharplabs.com Sun Apr 20 16:44:03 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:10 2009 Subject: PS> RE: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF91@mailsrvnt02.enet.sharplabs.com> Hi Michael, Actually scaling, centering, and cropping are all addressed for IPPFAX (extensions that will certainly migrate to general IPP/1.1 implementations). Cheers, - Ira -----Original Message----- From: Mike Sweet [mailto:mike@easysw.com] Sent: Saturday, April 19, 2003 10:14 PM To: McDonald, Ira Cc: 'Harry Lewis'; Hastings, Tom N; ipp@pwg.org; ps@pwg.org; sm@pwg.org Subject: Re: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec McDonald, Ira wrote: > ... > 2) I agree that PDL override is hard to implement (in _some_ PDLs), but > what Tom and I have proposed is to disambiguate _which_ attributes > (if any) can be guaranteed to successfully override the PDL. Seems > to me like a good clarity enhancement to IPP. PDL override is not even well-defined; what do you do with a PDF file that was formatted for a different media size? Scale it? Center it? Crop it? What constitutes an override??? -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From alan.berkema at hp.com Mon Apr 21 11:29:11 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:10 2009 Subject: PS> [PSI]: 4/22 Postponed - next call 04/29/03- 2 hours Message-ID: <6CD0BB10724459478066E90327DBB65120445D@xrose01.rose.hp.com> Hi All, Dave is still working hard on the changes from the last call review and will not have a new doc until early Thursday 4/24. Therefore we will not have a call on 4/22 Talk to you next week. Alan Teleconference details: NEXT: Tuesday April 29 2003 (USA) Time: 8:00AM (US PDT) Until: 10:00AM Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Last Call Comment Resolution based on the spec that Dave will post soon. Only potential controversial items will be reviewed. Most of the language changes will be accepted at the prerogative of our editor. After this meeting the speciation will be submitted for a 10 day re-circulation Last Call. Comments may be submitted via e-mail. We do not plan another page turner. Thanks, Alan ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 27995593 Meeting Password: newpsi Host: Alan Berkema 1(916)7855605 From hastings at cp10.es.xerox.com Mon Apr 21 12:08:26 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:02:10 2009 Subject: PS> 1 more significant proposed conformance change to the IPP Documen t object spec Message-ID: In going over my notes I discovered one more significant conformance changes proposed change for the IPP Document object from Thursday's April 17, telecon. This proposal will also go through the two-week comment period. 1. DEPRECATE the way a client can close a Job by supplying an empty Send-Document operation supplying the "last-document" = 'true' operation attribute for a Job created with Create-Job and any of (1) Create-Document/Send-Data, (2) Send-Document, and/or (3) Send-URI. When the Printer accepts this no-data Send-Document operation with "last-document" = 'true' the Printer MUST set the still REQUIRED "last-document" Document Description attribute. Instead, the client SHOULD use the new Close-Job operation (which also sets the "last-document" Document Description attribute). The Printer MUST continue to support this method of closing a job with an empty Send-Document request for backward compatibility with existing clients. As with the other two mail messages on significant conformance requirements changes, I will not edit this comment into the spec until we reach consensus on Friday, May 1. Please send comments. Tom From dcarney at us.ibm.com Mon Apr 21 12:11:46 2003 From: dcarney at us.ibm.com (Dennis Carney) Date: Wed May 6 14:02:10 2009 Subject: PS> Re: IPP> 2 more significant proposed increases in conformance requirements for the IPP Document object spec Message-ID: This might be an awful idea, so feel free to shoot it down with vicious force... Based on the desire to have extensions that do not include OPTIONAL items, might it make sense to break the current Document object spec into two: - The "Base Document object" spec, which defines the basics of the Document object and has no OPTIONAL items: everything is mandatory. This would make interop a breeze, and would hopefully also encourage adoption since the spec would hopefully be relatively small. - The "Extended Document object" spec, containing all the currently OPTIONAL items. This spec *could* also make all the extensions mandatory (I would think that making absolutely *everything* mandatory would discourage adoption, however). The process of going through the current spec to determine which items are "Base" and which are "Extended" might also result in determining which items aren't "Document object" items at all. Dennis Carney IBM Printing Systems Mike Sweet To: "Hastings, Tom N" Sent by: cc: sm@pwg.org, ps@pwg.org, ipp@pwg.org owner-ipp@pwg.org Subject: Re: IPP> 2 more significant proposed increases in conformance requirements for the IPP Document object spec 04/19/03 08:54 PM Hastings, Tom N wrote: > ... > 2. Add a REQUIRED way to the Get-Jobs operation for the client to get the > Jobs following the limit requested in a previous request. > > So add the "start-after-job-id" (integer (0:MAX)) Operation attribute. This is a nice addition, but has ABSOLUTELY NOTHING TO DO WITH DOCUMENT OBJECTS. It doesn't belong here. If anything, you should put together a single, small spec that adds this functionality to Get-Jobs separately. A pain, but this single attribute is useful on its own. Also, you probably need to have a way to let the client know that this attribute is supported, e.g. "start-after-job-id-supported (boolean)"... -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From dcarney at us.ibm.com Mon Apr 21 18:52:41 2003 From: dcarney at us.ibm.com (Dennis Carney) Date: Wed May 6 14:02:10 2009 Subject: PS> Re: IPP> 2 more significant proposed increases in conformance requirements for the IPP Document object spec Message-ID: I think that these ideas are good ones. However, I wonder why we didn't do anything about this before. In fact, in 2911, it is specifically called out that we purposely didn't handle this situation (2911, section 3.2.6.1: "There is no mechanism to allow for the next 'M' jobs after the first 'N' jobs."). Does anyone remember whether there was a good reason this issue was sidestepped? I've made 3 specific comments inline below, marked with . Dennis Carney IBM Printing Systems "Hastings, Tom N" cc: ps@pwg.org, ipp@pwg.org Sent by: Subject: IPP> 2 more significant proposed increases in conformance requirements for the IPP owner-ipp@pwg.org Document object spec 04/18/03 05:15 PM In summarizing the significant conformance requirement increases that we agreed to today in the review of the IPP Document Object spec review, I forgot two more: 1. Add a REQUIRED way to the Get-Documents operation for the client to get the Documents following the limit requested in a previous request. So add the "start-after-document-number" (integer (0:MAX)) Operation attribute. 2. Add a REQUIRED way to the Get-Jobs operation for the client to get the Jobs following the limit requested in a previous request. So add the "start-after-job-id" (integer (0:MAX)) Operation attribute. Please send any comments on these additions by Friday, May 2, COB. Here are the complete proposed text for these attributes and the updated "limit" Operation attribute: 1.1 Get-Jobs ([rfc2911] section 3.2.6) This REQUIRED Job operation returns requested attributes of either completed or not completed Jobs. The following (new) "start-after-job-id" (integer(0:MAX)) Operation attribute is defined which in combination with the "limit" operation attribute ([rfc2911] section 3.2.6) permits a client to request selected ranges of jobs: 1.1.1 "limit" (integer(1:MAX)): The client OPTIONALLY supplies this Operation attribute. The Printer MUST support this Operation attribute. It is an integer value that determines the maximum number of Jobs that a client will receive from the Printer even if "which-jobs" or "my-jobs" constrain which jobs are returned. The limit is a "stateless limit" in that if the value supplied by the client is 'N', then only the first 'N' jobs are returned in the Get-Jobs Response. If the client does not supply the "limit" attribute, the Printer responds with all applicable Jobs. However, if the client also supplies the "start-after-job-id" Operation attribute (section 4.2.2) with a value 'M', the Printer returns the N Jobs starting with the Job following the one with "job-id" = 'M'. We need to say what happens if job-id M is no longer in the list. I think the answer could be different for the two cases (non-completed vs. completed), making this a bit more complicated. If asking for *non-completed* jobs after job-id M, it is possible that M has completed since the client made the last call and is therefore no longer in the non-completed list. Unfortunately, this gets messy: 1) If M completed successfully, the printer should return the first N non-completed jobs (i.e. the same as if M hadn't been specified at all). 2) If M was canceled/aborted, it seems like the printer should ideally return the next job after M, *if* M hadn't been canceled/aborted. This extra attempt at correctness is, I guess, not really necessary, since the text below states that the caller can get strange results. Otherwise, if asking for *completed* jobs after job-id M, it is possible that M has been managed out of the completed list since the client made the last call. In *this* case, since completed jobs are returned in the opposite order of non-completed jobs, the printer should return an empty list. That is, since completed jobs are returned from newest to oldest, if M was managed out, jobs "after" (but actually printed before!) M are presumably also managed out, so there are actually no jobs "after" M in the completed list. This is the "correctly functioning" case of job-id M not being in the list, but there is also the "error" case where job-id M is just a bad value--it does seem strange to mandate that the printer return an empty list and success whenever the caller sends a bad "start-after-job-id" value. Maybe we want some new status-code: something like client-error-bad-start-id. Or we could possibly reuse client-error-gone or client-error-not-possible or some other existing status-code. Then there is just one answer for all the above cases: if M is not in the list, return an error and let the client decide what to do. 1.1.2 "start-after-job-id" (integer(0:MAX)): The client OPTIONALLY supplies this Operation attribute. The Printer MUST support this Operation attribute. If the client supplies this attribute with a job-id value 'M', the Printer MUST return Jobs starting with the Job that is after the one with "job-id" = 'M'. If the client does not supply this attribute, the Printer assumes a '0' value which causes the Printer to return any Jobs with any "job-id" that meet the requested criteria (specified by "which-jobs" and/or "my-jobs", etc.). When the client steps through the jobs N at a time, the client MUST set the "start-after-job-id" attribute from the "job-id' of the last Job returned in a previous Get-Jobs response (rather than just adding 'N', since Printers MAY assign job-ids out or order). The client can detect when there are no more jobs when the Printer returns fewer jobs than requested by the "limit" Operation attribute ('N'). In the case when the last number of jobs returned is exactly N jobs, the client will make an extra request and receive no jobs back (still with a 'successful-ok' success code). However, this case still meets the criteria for no more Jobs since the number of Jobs returned (0) is less than "limit".. Note when the client steps through the Jobs supplying the "limit" and "start-after-job-id" Operation attributes in successive Get-Jobs requests, there are some race conditions which the client implementer needs to take into account: * For 'non-completed' Jobs (see [rfc2911] section 3.2.6.2), the Printer MUST return the Jobs in the order of the "expected time to complete" with the first expected to complete being returned first, etc. Because some Printers MAY: (1) process jobs out of order received, and/or (2) assign "job-id" in a non-monotonically increasing manner, occasionally a race condition MAY cause some jobs not be returned and some jobs MAY be returned more than once. The only way for a client to eliminate this race condition for 'not-completed' Jobs is to request all Jobs by supplying neither the "limit" nor the "start-after-job-id" Operation attribute. * For 'completed' jobs (see [rfc2911] section 3.2.6.2), the Printer MUST return the jobs in the order of "newest to oldest" to complete. Therefore, no jobs will be missed and/or doubly returned. 1.2 Get-Documents Operation This REQUIRED Job operation allows a client to retrieve the list of Document objects belonging to the target Job object. The client MAY also supply a list of Document attribute names and/or attribute group names. A group of Document object attributes will be returned for each Document object in the Job. This operation is similar to the Get-Document-Attributes operation (see section 3.5), except that this Get-Documents operation returns attributes from all Document objects contained in the Job object, instead of from a single selected Document object in the Job object. As with the Get-Document-Attributes operation the Printer MUST only return attributes that were submitted by a client when the Document object was created by the Create-Document, Send-Document, or Send-URI operations and possibly modified by the Set-Document-Attributes operation (see section 3.7). 1.2.1 Get-Documents Request The client submits the Get-Documents request to a Printer. The Get-Documents is similar to the Get-Jobs operations (see [rfc2911] section 3.2.6) except that there are no equivalents to the "which-jobs" and "my-jobs" Operation attributes. The following groups of attributes are part of the Get-Documents Request: Group 1: Operation Attributes Natural Language and Character Set: The "attributes-charset" and "attributes-natural-language" attributes as described in [rfc2911] section 3.1.4.1. Target: Either (1) the "printer-uri" (uri) plus "job-id" (integer(1:MAX)) or (2) the "job-uri" (uri) Operation attribute(s) which define the target Job object for this operation as described in [rfc2911] section 3.1.5. Requesting User Name: The "requesting-user-name" (name(MAX)) attribute SHOULD be supplied by the client as described in [rfc2911] section 8.3. 1.2.1.1 "limit" (integer(1:MAX)): The client OPTIONALLY supplies this Operation attribute. The Printer MUST support this Operation attribute. It is an integer value that determines the maximum number of Documents that a client will receive from the Printer. If the client supplies the "limit" attribute with a value 'N' and the "start-after-document-number" attribute with a value 'M', the Printer returns the N Documents starting with the Document after the one with "document-number" = 'M'. The limit is a "stateless limit" in that if the value supplied by the client is 'N', then only the first 'N' Documents are returned in the Get-Documents Response. If the client does not supply the "limit" attribute, the Printer responds with all Documents in the Job. However, if the client also supplies the "start-after-document-number" Operation attribute (section 4.3.1.2) with a value 'M', the Printer returns the N Documents starting with the Document following the one with "document-number" = 'M'. Editorial: The above paragraph would flow better without the fourth sentence (the one starting "If the client supplies..."). 1.2.1.2 "start-after-document-number" (integer(0:MAX)): The client OPTIONALLY supplies this Operation attribute. The Printer MUST support this Operation attribute. If the client supplies this attribute with a document-number value 'M', the Printer MUST return Documents starting with the Document that is after the one with "document-number" = 'M'. If the client does not supply this attribute, the Printer assumes a '0' value which causes the Printer to return Documents starting with "document-number" = '1' (which is the first document in the Job). Note: canceled Documents (see section 3.7) are still returned, but deleted Documents (see section 3.8) are skipped over, since they don't exist (leaving gaps in the "document-number" sequence). Due to the fact that deleted Documents disappear, we have the same problem as discussed above: Document number M might no longer exist. The expected behavior for this should be similar to that decided upon for jobs, I would think; however, for Document objects, the "ideal" behavior would be to return the Documents starting with the first after Document M that hasn't been deleted. Unfortunately, this "pretend like M is still there" strategy doesn't really work as a general solution in the Get-Jobs case. Please send any comments on these additions by Friday, May 2, COB. Thanks, Tom From dcarney at us.ibm.com Mon Apr 21 19:14:18 2003 From: dcarney at us.ibm.com (Dennis Carney) Date: Wed May 6 14:02:10 2009 Subject: PS> Re: SM> 1 more significant proposed conformance change to the IPP Documen t object spec Message-ID: I'm a bit confused: I had the (apparently flawed) impression that the plan was to deprecate, for a client, using the "last-document" operation attribute entirely--that is, say the "correct" way to say a job was done was to do Close-Job. If we do that, we will by definition deprecate the special case you're discussing below, right? Am I thinking of PSI or maybe SM? Since deprecation is only a suggestion, might it make sense to deprecate "last-document" entirely? (The Printer will still have to support it, but we're encouraging clients to move to Close-Job.) Do we want to make such a stand? Dennis "Hastings, Tom N" cc: ps@pwg.org, ipp@pwg.org Sent by: Subject: SM> 1 more significant proposed conformance change to the IPP Documen t object spec owner-sm@pwg.org 04/21/03 10:08 AM In going over my notes I discovered one more significant conformance changes proposed change for the IPP Document object from Thursday's April 17, telecon. This proposal will also go through the two-week comment period. 1. DEPRECATE the way a client can close a Job by supplying an empty Send-Document operation supplying the "last-document" = 'true' operation attribute for a Job created with Create-Job and any of (1) Create-Document/Send-Data, (2) Send-Document, and/or (3) Send-URI. When the Printer accepts this no-data Send-Document operation with "last-document" = 'true' the Printer MUST set the still REQUIRED "last-document" Document Description attribute. Instead, the client SHOULD use the new Close-Job operation (which also sets the "last-document" Document Description attribute). The Printer MUST continue to support this method of closing a job with an empty Send-Document request for backward compatibility with existing clients. As with the other two mail messages on significant conformance requirements changes, I will not edit this comment into the spec until we reach consensus on Friday, May 1. Please send comments. Tom From dhall at hp.com Tue Apr 22 12:27:27 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:10 2009 Subject: PS> WSDL Namespaces Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAC8B@xvan01.vcd.hp.com> Hey All.. There are two ways we can declare our namespaces - one where the namespace actually has the path fully correct: http://www.pwg.org/schemas/ps/20030411 And another where the namespace doesn't correspond directly to the location: http://www.pwg.org/ps/20030411 Any recommendations / opinions? Dave From dhall at hp.com Wed Apr 23 11:23:06 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:10 2009 Subject: PS> IPP and Printer Pooling Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAC9C@xvan01.vcd.hp.com> Hey All... Some clarification discussion came up in the last meeting around the CreateJob method, and what should happen if the client does not specify a targetDeviceIdentifier, and the deliverToTargetDevice parameter. So far, I have only been thinking about delayed association of a Target Device, and not about the Print Service picking a Target Device based upon the requirements of the Job. Can someone describe the Use Cases around Printer Pooling? What are the requirements? Thanks! Dave From imcdonald at sharplabs.com Wed Apr 23 14:17:26 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:10 2009 Subject: PS> IPP and Printer Pooling Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF97@mailsrvnt02.enet.sharplabs.com> Hi Dave, The common case for IPP-based spoolers (like CUPS) is that the IPP Printer object supports (by some out-of-band configuration not in RFC 2911) two or more target print devices. When a user submits a job (Create-Job, Print-Job, or Print-URI), the IPP Printer object selects an available target print device and displays the NAME (not the URL, sadly) of the selected target print device in the read-only Job attribute: "output-device-assigned". I have proposed that we add an IPP Printer Description attribute: "output-device-supported(1setOf text(127))" Further, the future IPP Device object (strongly based on the Printer MIB attributes) should have a "device-name" Description attribute that MUST correspond to one of the published values of "output-device-supported". So, an IPP abstract Printer object actually ALWAYS represents a 'printer pool'. But sometimes it's a pool of one. For PSI, we need to disambiguate the mapping from PSI Print Service to IPP Printer object. I naively have always thought it was a one-to-one mapping. If so, a PSI Print Service has the same property that it always represents a 'pool', the value of an attribute of REGISTERED (and not merely KNOWN by discovery) available target devices. Comments? Cheers, - Ira McDonald High North Inc -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Wednesday, April 23, 2003 11:23 AM To: 'ps@pwg.org' Subject: PS> IPP and Printer Pooling Hey All... Some clarification discussion came up in the last meeting around the CreateJob method, and what should happen if the client does not specify a targetDeviceIdentifier, and the deliverToTargetDevice parameter. So far, I have only been thinking about delayed association of a Target Device, and not about the Print Service picking a Target Device based upon the requirements of the Job. Can someone describe the Use Cases around Printer Pooling? What are the requirements? Thanks! Dave From dhall at hp.com Tue Apr 29 11:05:17 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:10 2009 Subject: PS> RE: Next Call Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FACB4@xvan01.vcd.hp.com> I posted yesterday, but I didn't see it come through the reflector... Next week.. :) Hi All... Well, I still haven't made it through the entire PSI specification yet - So, tomorrow's meeting is canceled. Look for a update later this week about having a review next week. Thanks! Dave -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, April 29, 2003 8:02 AM To: BERKEMA,ALAN C (HP-Roseville,ex1) Cc: dhall@hp.com Subject: Next Call I don't see any sign of a call today. Is this correct? (I'm probably confused) ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/ps/attachments/20030429/e9b79ef0/attachment.html From dhall at hp.com Wed Apr 30 17:49:30 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:10 2009 Subject: PS> New PSI Specification Document Available Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FACC5@xvan01.vcd.hp.com> Hey All... A new PSI Specification Document is available at: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030430.doc ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030430.pdf It incorporates all of the Last Call Review comments (Prefixed with LCRC), as well as some issues raised during the last call process. (Previxed with ISSUE). We will walk through the LCRCs and ISSUEs next Tuesday. Meeting details to follow in a subsequent message. I have returned the document to a Working Draft given the number of modifications discovered in the Last Call process. Once we have reviewed the LCRCs and the ISSUEs reviewed and resolved, I believe we should start a new, shorter Last Call process again. Dave From dhall at hp.com Fri May 2 16:50:00 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:10 2009 Subject: PS> Next Tuesday (5/6) Meeting Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FACCC@xvan01.vcd.hp.com> Hey All.. On next Tuesday, we will review the latest PSI document, each of the last call review comments, along with the issues. Dave Sprint 866-639-4756 574-935-6714 #2124228 ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Date: 5/6/2003 Time: 8:00AM, (GMT -07:00) Pacific Time, USA & Canada (DayLight Time) Meeting Number: 28476876 Meeting Password: new_psi From harryl at us.ibm.com Tue May 6 15:31:33 2003 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:02:10 2009 Subject: PS> PSI port-number (3800) assigned. Message-ID: Good news! The long awaited PSI port number has been assigned. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- ----- Forwarded by Harry Lewis/Boulder/IBM on 05/06/2003 01:31 PM ----- "IANA" 05/06/2003 01:24 PM To: Harry Lewis/Boulder/IBM@IBMUS cc: , , Subject: Re: Application for port-number (3800) Dear Harry, Thank you for returning my call and please accept our apologies for the delay. We have assigned the following user port number with you as the point of contact: pwgpsi 3800/tcp Print Services Interface pwgpsi 3800/udp Pring Services Interface # Harry Lewis May 2003 Please notify the IANA if there is a change in contact information by completing the following template: If there is anything else I can help you with, please do not hesitate to contact me. Thank you, Michelle S. Cotton IANA Administrator *************************************************************** Internet Assigned Numbers Authority (IANA) 4676 Admiralty Way, Suite 330 Marina del Rey, California 90292 Voice: (310) 823-9358 FAX: (310) 823-8649 email: iana@iana.org *************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/ps/attachments/20030506/2cff21b2/attachment.html From alan.berkema at hp.com Mon May 12 17:16:04 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:10 2009 Subject: PS> [PSI]:next call 05/13/03- 2 hours Message-ID: <6CD0BB10724459478066E90327DBB6512044DB@xrose01.rose.hp.com> Teleconference details: NEXT: Tuesday May 13 2003 (USA) Time: 8:00AM (US PDT) Until: 10:00AM Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Continue Last Call Comment Resolution ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 21727912 Meeting Password: newpsi Host: Alan Berkema 1(916)7855605 From alan.berkema at hp.com Tue May 13 15:18:23 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:10 2009 Subject: PS> [PSI]:next call 05/20/03- 2 hours? Message-ID: <6CD0BB10724459478066E90327DBB6512044E6@xrose01.rose.hp.com> Teleconference details: NEXT: Tuesday May 20 2003 (USA) Time: 8:00AM (US PDT) Until: 10:00AM (Think this will just go apx 1 hour) Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Review major changes from Last Call Comment Resolution ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 21727912 Meeting Password: newpsi Host: Alan Berkema 1(916)7855605 From dhall at hp.com Fri May 16 16:09:16 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:10 2009 Subject: PS> wd-psi10-20030513.doc available Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAD05@xvan01.vcd.hp.com> ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030513.doc Hey All.. The latest wd PSI specification has been published. Acrobat couldn't convert it for some reason, so no PDF this time.. (Ira, can you give it a shot?) Dave From imcdonald at sharplabs.com Fri May 16 16:36:18 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:10 2009 Subject: PS> [PDF of] wd-psi10-20030513.doc available Message-ID: <116DB56CD7DED511BC7800508B2CA53735CFDA@mailsrvnt02.enet.sharplabs.com> Hi folks, I created a PDF (213KB versus 737KB for MS Word source) and stored at: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030513.pdf Cheers, - Ira -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Friday, May 16, 2003 4:09 PM To: 'ps@pwg.org' Subject: PS> wd-psi10-20030513.doc available ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030513.doc Hey All.. The latest wd PSI specification has been published. Acrobat couldn't convert it for some reason, so no PDF this time.. (Ira, can you give it a shot?) Dave From alan.berkema at hp.com Tue May 20 18:13:52 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:10 2009 Subject: PS> [PSI]: Interop Fest 1 Message-ID: <6CD0BB10724459478066E90327DBB651204523@xrose01.rose.hp.com> Hi All, PSI will conduct it's first interoperability event on July 15th & 16th at HP's Vancouver Wa site. Detailed logistics will follow. In order to make this event successful we need as many PSI devices as possible. Please let me know as soon as you can if you will attend and what devices you will bring to the party. We will have an interoperability test plan proposal before the June 20 F2F. This will be reviewed and finalized at the F2F. We expect this to include Basic Job Submission methods. Status, Cancel will be wants . Target Device Interface will be later. Thanks, Alan From alan.berkema at hp.com Mon May 26 11:29:13 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:10 2009 Subject: PS> [PSI] NO call 05/27/03 next 6/3 Message-ID: <6CD0BB10724459478066E90327DBB65120454D@xrose01.rose.hp.com> Dave is on a well deserved vacation this week. We will have a call on 6/3 Thanks, Alan Teleconference details: NEXT: Tuesday June 3 2003 (USA) Time: 8:00AM (US PDT) Until: 10:00AM (Think this will just go apx 1 hour) Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Review major changes from Last Call Comment Resolution ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 21727912 Meeting Password: newpsi Host: Alan Berkema 1(916)7855605 From alan.berkema at hp.com Tue May 27 13:07:08 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:10 2009 Subject: PS> RE: [PSI]: Interop Fest 1 Message-ID: <6CD0BB10724459478066E90327DBB65120454E@xrose01.rose.hp.com> For this event we will use the WSDL based on the 20030411 specification. This gives us a stable base for testing. http://www.pwg.org/schemas/ps/20030411/ Future events will use the version that results for the Last call re-circ. RSVP asap Thanks, Alan -----Original Message----- From: BERKEMA,ALAN C (HP-Roseville,ex1) [mailto:alan.berkema@hp.com] Sent: Tuesday, May 20, 2003 3:14 PM To: 'a PSI pwg.org' Subject: PS> [PSI]: Interop Fest 1 Hi All, PSI will conduct it's first interoperability event on July 15th & 16th at HP's Vancouver Wa site. Detailed logistics will follow. In order to make this event successful we need as many PSI devices as possible. Please let me know as soon as you can if you will attend and what devices you will bring to the party. We will have an interoperability test plan proposal before the June 20 F2F. This will be reviewed and finalized at the F2F. We expect this to include Basic Job Submission methods. Status, Cancel will be wants . Target Device Interface will be later. Thanks, Alan From hastings at cp10.es.xerox.com Mon Jun 2 03:00:08 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:02:10 2009 Subject: PS> Does PSI need "document-format-details-implemented"? Message-ID: We are reviewing the IPP Job Extensions spec (JOBX) next Wednesday, June 4, at the IPPFAX telecon, 1-3 PM PST. Could the PSI WG look at this ISSUE at its Tuesday, June 3 telecon? See Page 38, section 7.7 for the description of the "document-format-details-implemented" Printer attribute. 6. ISSUE: Who needs document-format-details-implemented (1setOf collection) Printer attribute? Does PSI? We assume yes. However, if PSI does support Capabilities, then we shouldn't define "document-format-details-implemented" in the [jobx] spec, since it is a poor man's Capabilities. 7. We agreed that the "document-format-implemented" member attribute of the document-format-details-implemented (1setOf collection) attribute should be changed to a single value, since it really a "key" value. So each collection value has only one "document-format". It would be good to get some feedback on the ipp@pwg.org DL about this issue before Wednesday's telecon. Thanks, Tom Here is the complete information for the Wednesday Review, if you'd care to join: -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Sunday, June 01, 2003 23:28 To: ipp@pwg.org Cc: ifx@pwg.org Subject: IFX> Updated JOBX spec for Wed, June 4, 1-3 PM PDT (4-6 PM EDT) teleco n (10 ISSUES) I've uploaded the updated version of the Job Extension spec for review Wednesday, 1-3 PM PDT (4-6 PM EDT): ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030530.pdf.zip (572KB) ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030530.doc.zip (125KB) ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030530-rev.pdf (262KB) ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030530-rev.doc.zip (142KB) Please send any comments to the ipp@pwg.org DL only! > Rick Seeler has invited you to a MeetingPlace voice conference. > > Date/Time: June 04, 2003, 01:00 PM America/Los_Angeles > Meeting ID: 123123 > Password: > Frequency: Once > > MeetingPlace Phone Numbers: > Local: 408-536-9900 Here is the webex info - Name: IFX Date: 6/4/2003 Time: 1:00PM, (GMT -07:00) Pacific Time, USA & Canada (DayLight Time) Meeting Number: 29378444 Meeting Password: pwgifx Here are the changes from the last version we reviewed at the May 28 telecon: Version 0.3, 30 May 2003: Agreements reaches at the May 28, 2003 telecon: 1. Moved the Close-Job operation to the futures specification. 2. Added the "pages-per-subset" Job Template from [pwg5100.4]. See Appendix B section 17 for the minor differences. 3. Added the terms: "Best Effort, Finished Document, Page, Page Subset, and Sheet. 4. Clarified the conformance relationships between "xxx" Operation attributes and their corresponding "xxx-default" and "xxx-supported" Printer attributes. 5. Added rationale for each missing "xxx-default" and "xxx-supported" attribute. 6. Added 'errors-detected' and 'warnings-detected' "job-state-reasons" values. 7. Added the new 'choice_iso_a4_210x297mm_na_letter_8.5x11in' "media" attribute value which is a choice of two approximately equal media. 8. Added the requirements for choice media keyword values for inclusion in a revision of the PWG IEEE-ISTO 5101.1. 9. Changed the "document-format-implemented" member attribute from 1setOf mimeMediaType to mimeMediaType since it is the key attribute value. 10. Added another "document-format-implemented" example. 11. Updated the IANA section to agree with the additions. The following 10 issues are highlighted in the document: ISSUE 01: OK that the "job-mandatory-attributes" Operation attribute has nothing to do with guaranteeing (that the attribute will supersede the PDL), but only with whether the Printer will accept the job with unsupported attributes requested - TNH ISSUE 02: From DMC: It seems like it might be possible, for certain implementations, to have a default output-device. The problem is that normally the "xxx-default" is REQUIRED [TH: not for operation attributes, so we say a Printer MAY support the "output-device-default"], whereas my idea would be more to allow a Printer to advertise a default only if it matched its actual implementation. 3.1.3.1 Why there is no "output-device-requested-default" attribute ISSUE 02 (repeat): From DMC: Should we add an "output-device-requested-default" Printer Description attribute that a Printer MAY support when it supports the "output-device-requested" Operation attribute? ISSUE 03: (Thought up while writing up the reason for no default): [rfc2911] does have the concept of attribute coloring that causes the values of Printer attributes to depend on the "document-format". Thus, we could have "document-format-version-default" whose value depends on the value of the "document-format". Do we want to have "document-format-version-default", which, if supported, the Printer MUST color the value depending on the "document-format" Operation attribute supplied in the Get-Printer-Attributes request? All part of ISSUE 04: If the client supplies more integer values for the "pages-per-subset" attribute than the Printer supports, the Printer MUST treat the remaining values as Unsupported Attribute values as follows (see [rfc2911] section 3.1.7): If the client supplies the "attribute-fidelity" Operation attribute with a 'false' value (see section 3.1.1) or omits the attribute altogether, the Printer MUST (1) otherwise accept the Job, (2) return the 'successful-ok-attributes-ignored-or-substituted' status code, and (3) return in the Unsupported Attribute Group the additional values not supported. If the client supplies either the "attribute-fidelity" Operation attribute with a 'true' value or the "job-mandatory-attributes" Operation attribute with the 'pages-per-subset' keyword value (see section 3.1.2), the Printer MUST reject the job. ISSUE 04: PWG 5100.4 was silent on whether a Printer MUST support any number of integer values for "pages-per-subset" or whether the number was implementation dependent. Is supporting only a single value considered a conforming implementation so that the above error handling is sufficient? ISSUE 05: PWG 5100.4 had the "pages-per-subset-supported" attribute specified as a boolean. MUST a Printer support any number of integer values for the "pages-per-subset" (1setOf integer(1:MAX)) Job Template attribute? If supporting a maximum number, even as low as '1', is considered conforming, should we change the attribute syntax of the "pages-per-subset-supported" to integer(1:MAX) to indicate the maximum number of values supported by the Printer? Or is it sufficient for the Printer to return in the Unsupported Attributes group the remaining values of the "pages-per-subset" (integer(1:MAX)) attribute that aren't supported? ISSUE 06: What about the maximum number of pages in a Page Subset? MUST a Printer support any number up to MAX in any Page Subset? Part of ISSUE 07: The Printer MAY scale the image to fit, but any scaling MUST be isomorphic scaling and without image content loss. ISSUE 07: Why even allow the Printer to scale? Lets simplify this choice concept to sizes that are approximately the same, such as A4 and na-letter, rather than allowing a choice, of, say, A4 or A3 which would require scaling. That makes interoperability more difficult. ISSUE 08: Who needs the "document-format-details-implemented" attribute? Does PSI? We assume yes. However, if PSI does support Capabilities, then we shouldn't define "document-format-details-implemented" in this spec, since "document-format-details-implemented" is a poor man's capability mechanism. ACTION ITEM (Tom): Ask PSI whether they intend to use "document-format-details-implemented"? If not, should "document-format-details-implemented" be moved to the IPP Futures document, or just deleted and wait for someone to request it? Document Color Separation (DCS), version 2.0. ISSUE 10: Need a reference All part of ISSUE 09: [pwg5100.4] Herriot, R., Ocke, K., "Internet Printing Protocol (IPP): Override Attributes for Documents and Pages", IEEE-ISTO 5100.4-2001, February 7, 2001, ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.4.pdf. - being obsoleted by (1) a new Page Overrides specification which removes the "document-overrides" Job Template attribute and Operation attribute in favor of using the Document Object [ippdoc] and (2) this specification [ippjobx] definition of "pages-per-subset" Job Template attribute. ISSUE 09: The IETF process never revises an RFC, but just updates or obsoletes one with another RFC. On the other hand most other standards organizations, such as ANSI, ISO, (IEEE?), and POSIX, require that standards be reviewed and if necessary be "revised". I think that we are "revising" PWG IEEE-ISTO 5100.4, not "obsoleting" it. This is just a terminology question. The second paragraph of the PWG process section 4.2 says: "Working Drafts and Candidate Standards correspond to a specific version of the Standard they are defining. Unless the working group is engaged in an effort to revise an existing PWG Standard, the Working Drafts and Candidate Standards are always defining PWG Standard Version 1.0." and section 4.4.1 says: "Although the maturity level will not appear on PWG Candidate Standards or PWG Standards, if a Candidate Standard needs to be revised, any resulting PWG Working Drafts will have a maturity level indicated on their title page." From dhall at hp.com Tue Jun 3 10:04:32 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:10 2009 Subject: PS> wd-psi10-20030601.doc available Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAD3E@xvan01.vcd.hp.com> Hey All! I'm on vacation in Wisconsin today, and will be dialing in on a slow 28.8 connection. Please download the latest document this morning: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030601.doc Ira - If I can get you to do the PDF conversion, that would be great! I'll have to try re-installing acrobat on my system.. Dave From imcdonald at sharplabs.com Tue Jun 3 10:42:14 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:10 2009 Subject: PS> [PDF of] wd-psi10-20030601.doc available Message-ID: <116DB56CD7DED511BC7800508B2CA53735D015@mailsrvnt02.enet.sharplabs.com> Hi Dave, Converted to PDF and stored at: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030601.pdf Cheers, - Ira -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Tuesday, June 03, 2003 10:05 AM To: 'ps@pwg.org' Subject: PS> wd-psi10-20030601.doc available Hey All! I'm on vacation in Wisconsin today, and will be dialing in on a slow 28.8 connection. Please download the latest document this morning: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030601.doc Ira - If I can get you to do the PDF conversion, that would be great! I'll have to try re-installing acrobat on my system.. Dave From alan.berkema at hp.com Wed Jun 4 11:42:28 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:10 2009 Subject: PS> [PSI] offcycle call 06/6/03 Message-ID: <6CD0BB10724459478066E90327DBB65120457E@xrose01.rose.hp.com> Hi all, Dave & Ira and I will get together at this time. Others are welcome. Note new webex info. NEXT: Tuesday June 6 2003 (USA) Time: 8:00AM (US PDT) Until: 10:00AM (Think this will just go apx 1 hour) Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Work on reaming actions to get spec ready to post on 6/9 ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 25369512 Meeting Password: newpsi Host: Alan Berkema 1(916)7855605 From imcdonald at sharplabs.com Thu Jun 5 21:04:12 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:10 2009 Subject: PS> Examples and Query parameters for PSI Message-ID: <116DB56CD7DED511BC7800508B2CA53735D02C@mailsrvnt02.enet.sharplabs.com> Hi Dave and Alan, Friday (6 June 2003) Below is one entire new section, new text for three existing sections, and some revised examples for existing sections, for the PSI spec. Cheers, - Ira ---------------------------------------- [Entire new section 7.1 - please delete entirely former section 7.1.1] 7.1 'PWG Standard URI Query Parameters' The following PWG standard URI query parameters are defined for use with any URL scheme in specifying Target Device Identifiers (section 7.2), Reference URI (section 7.3), or any other URI. Conformance: (1) A PSI Client MUST specify each parameter keyword in lowercase. (2) A PSI Client MUST specify well-known parameter values in lowercase. (3) A PSI Client MAY specify string parameter values in mixed case. 7.1.1 'auth' Client authentication mechanism required to access this URI, e.g., ipp://bar.com/printer?auth=digest Well-known values defined in section 4.4.2 of [RFC2911] are: 'none': no user authentication (i.e., 'anonymous'). 'requesting-user-name': user specified in protocol operation. 'basic': HTTP basic authentication [RFC2617]. 'digest': HTTP digest authentication [RFC2617]. 'certificate': user authenticated via certificate. 7.1.2 'binary' Binary transfer mode required to access this URI, e.g., ftp://joe:blues@myhost.com:21/somefile.pdf?passive=true&binary=true Well-known values are: 'true': Use binary transfer mode. 'false': Use text transfer mode (default, when absent). 7.1.3 'cert' Client certificate URI required to access this URI, e.g., ipp://bar.com/printer?auth=certificate&sec=tls&cert=ldap://f.com/abc 7.1.4 'domain' Domain name for any non-Internet URI scheme, e.g., pwg-unc://PrintServer15/*?domain=Accounting 7.1.5 'legacy' Legacy Target Device Identifier specified as a URI for PSI proxy, e.g., pwg-psitd://ps.foo.com/psi/1.0?legacy=pwg-unc://server/share 7.1.6 'location' Human-readable geographic location referenced by this URI, e.g., http://pwg-psitd:/foo.com/psi/1.0?location=First%20Floor 7.1.7 'name' Human-readable friendly name referenced by this URI, e.g., http://pwg-psitd:/foo.com/psi/1.0?name=Dave's%20Printer 7.1.8 'passive' Passive mode required to access this URI, e.g., ftp://joe:blues@myhost.com:21/somefile.txt?passive=true Well-known values are: 'true': Use passive mode. 'false': Do not use passive mode (default, when absent). 7.1.9 'pw' Password required to access this URI, e.g., pop://joe;auth=login@foo.com:110?sec=ssl3&pw=bingo&msgid=123 7.1.10 'sec' Security mechanism required to access this URI, e.g., ipp://bar.com/printer?auth=digest&sec=tls Well-known values defined in section 4.4.3 of [RFC2911] are: 'none': no security mechanism (i.e., 'anonymous'). 'ssl3': SSL3 [SSL] security for communications channel. 'tls': TLS [RFC2246] security for communications channel. ---------------------------------------- [ [ Dave - add examples in former TD Identifier sections. ] ] [ [ New text for former section 7.1.6 'ipp' ] ] A URL for an IPP print service [RFC2911]. Example: ipp://bar.com:631/printer?auth=digest&sec=tls Notes: (1) REQUIRED 'host' here is 'bar.com' (2) OPTIONAL 'port' here is '631' (default for IPP) (3) OPTIONAL 'path' here is 'printer' (4) PSI standard query 'auth' here is 'digest' [RFC2617] (5) PSI standard query 'sec' here is 'tls' [RFC2246] [ [ New text for former section 7.1.7 'ippfax' ] ] A URL for an IPPFAX print service [IPPFAX]. Example: ippfax://foo.com/faxprinter?auth=certificate Notes: (1) REQUIRED 'host' here is 'foo.com' (2) OPTIONAL 'path' here is 'faxprinter' (3) PSI standard query 'auth' here is 'certificate' [ [ New text for former section 7.1.8 'lpr' ] ] A URL for an LPR print service [RFC1179]. Example: lpr://bar.com:515/printer?location=First%20Floor Notes: (1) REQUIRED 'host' here is 'bar.com' (2) OPTIONAL 'port' here is '515' (default for LPR) (3) OPTIONAL 'path' here is 'printer' (4) PSI standard query 'location' here is 'First Floor' ---------------------------------------- [ [ Dave - fix broken examples in former Reference sections. ] ] [ [ Corrected example for former section 7.2.2 'ftp' ] ] ftp://joe:blues@myhost.com:21/somefile.pdf?passive=true&binary=true [ [ Corrected example for former section 7.2.4 'pop' ] ] pop://joe;auth=login@foo.com:110?sec=ssl3&pw=bingo&msgid=123 &attid=1.doc,2.doc,etc [ [ Corrected example for former section 7.2.5 'imap' ] ] imap://joe;auth=login@foo.com:143?sec=ssl3&pw=bingo&msgid=123 &attid=1.doc,2.doc,etc ---------------------------------------- From alan.berkema at hp.com Fri Jun 6 12:29:36 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:10 2009 Subject: PS> [PSI]: New Dates for Interop Event 1 Message-ID: <6CD0BB10724459478066E90327DBB65120458F@xrose01.rose.hp.com> All, To accommodate the companies that will attend PSI Interop 1 we have changed the dates to August 12th and 13th, 2003. Location is the same. For this event we will use the WSDL based on the 20030411 specification. This gives us a stable base for testing. http://www.pwg.org/schemas/ps/20030411/ Future events will use the version that results for the Last call re-circ. RSVP asap Thanks, Alan -----Original Message----- From: BERKEMA,ALAN C (HP-Roseville,ex1) [mailto:alan.berkema@hp.com] Sent: Tuesday, May 20, 2003 3:14 PM To: 'a PSI pwg.org' Subject: PS> [PSI]: Interop Fest 1 Hi All, PSI will conduct it's first interoperability event on July 15th & 16th at HP's Vancouver Wa site. Detailed logistics will follow. In order to make this event successful we need as many PSI devices as possible. Please let me know as soon as you can if you will attend and what devices you will bring to the party. We will have an interoperability test plan proposal before the June 20 F2F. This will be reviewed and finalized at the F2F. We expect this to include Basic Job Submission methods. Status, Cancel will be wants . Target Device Interface will be later. Thanks, Alan From dhall at hp.com Mon Jun 9 14:37:36 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:10 2009 Subject: PS> PSI 06/10 telecon. 866-639-4756 #2124228 Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAD53@xvan01.vcd.hp.com> Hi All... We will have an hour teleconference tomorrow to review the f2f meeting agenda. Dave Sprint 866-639-4756 574-935-6714 ID: 2124228 Hello David Hall, You have successfully scheduled the following meeting: Topic: psi Date: Tuesday, June 10, 2003 Time: 8:00 am, Pacific Daylight Time (GMT -07:00, San Jose) Meeting number: 745635264 Meeting password: new@psi02 http://www.webex.com We've got to start meeting like this(TM) From dhall at hp.com Tue Jun 10 11:06:36 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:10 2009 Subject: PS> wd-psi10-20030606 available. Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAD57@xvan01.vcd.hp.com> Hi All.. The psi spec is available for review at: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030606.doc ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030606.pdf We will be reviewing this at the f2f next friday.. Dave From dhall at hp.com Tue Jun 10 11:30:31 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:10 2009 Subject: PS> Tentative PSI Agenda Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAD58@xvan01.vcd.hp.com> Agenda for PSI F2F... (Done by 2 or 3??) Round table introductions Schedule review * Interop * Rest of the year PSI Overview Q&A (if needed) Test Plan Discussion * Minimal Client Testing o ByPush o ByReference o ByValue? * Status and Cancel Developers Guide Discussion Page turner to incorporate comments for last call review Please provide any additional feedback for the agenda via the reflector. Thanks! Dave From imcdonald at sharplabs.com Tue Jun 10 11:58:11 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:10 2009 Subject: PS> Tentative PSI Agenda [for Fri 20 June - F2F] Message-ID: <116DB56CD7DED511BC7800508B2CA53735D03B@mailsrvnt02.enet.sharplabs.com> Hi Dave, And also, as we just discussed, possibly a dial-in setup for the first 2 hours of the meeting (Round table, Schedule, Overview/Q&A), at least). Many FSG Open Printing members couldn't travel because of (relatively) short notice, so there might be a lot better FSG attendance for a PSI overview by teleconference. Cheers, - Ira McDonald High North Inc -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Tuesday, June 10, 2003 11:31 AM To: 'ps@pwg.org' Subject: PS> Tentative PSI Agenda Agenda for PSI F2F... (Done by 2 or 3??) Round table introductions Schedule review * Interop * Rest of the year PSI Overview Q&A (if needed) Test Plan Discussion * Minimal Client Testing o ByPush o ByReference o ByValue? * Status and Cancel Developers Guide Discussion Page turner to incorporate comments for last call review Please provide any additional feedback for the agenda via the reflector. Thanks! Dave From imcdonald at sharplabs.com Wed Jun 11 12:48:54 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:10 2009 Subject: PS> FW: Proposed new Job and Document events (IPP Notifications) Message-ID: <116DB56CD7DED511BC7800508B2CA53735D048@mailsrvnt02.enet.sharplabs.com> Oops - blew the PSI address, - Ira -----Original Message----- From: McDonald, Ira Sent: Wednesday, June 11, 2003 12:47 PM To: 'ifx@pwg.org'; 'psi@pwg.org' Subject: Proposed new Job and Document events (IPP Notifications) Hi folks, Wedesday (11 June 2003) Per an action item of mine from last week's PSI telecon (3 June) and in preparation for our IFX telecon on IPP Notifications and IPPGET this afternoon, below are all of the currently defined IPP events: 'printer-state-changed' REQUIRED (sub-events) 'printer-restarted' OPTIONAL 'printer-shutdown' OPTIONAL 'printer-stopped' REQUIRED 'printer-config-changed' REQUIRED (sub-events) 'printer-media-changed' OPTIONAL 'printer-finishings-changed' OPTIONAL 'printer-queue-order-changed' OPTIONAL 'job-state-changed' REQUIRED (sub-events) 'job-created' REQUIRED 'job-completed' REQUIRED 'job-stopped' OPTIONAL 'job-config-changed' OPTIONAL 'job-progress' OPTIONAL (page-level progress) I propose (for IPPFAX) two new job progress sub-events: 'job-progress' OPTIONAL (page-level progress) (sub-events) 'job-error' OPTIONAL (page-level error) 'job-warning' OPTIONAL (page-level warning) I propose (for IPP Document object) a new set of document events: 'document-state-changed' REQUIRED (if Document object supported) (sub-events) 'document-created' REQUIRED 'document-completed' REQUIRED Also worth considering are the (oddly, undefined) 'job-processing' and 'document-processing' events. Comments? Cheers, - Ira McDonald High North Inc From alan.berkema at hp.com Tue Jun 24 12:52:24 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:10 2009 Subject: PS> [PSI] Next Call 07/01/03 Message-ID: <0806DAA43B1555479D53B58675D3468345830E@xrose01.rose.hp.com> Note new webex number and more secure passwd :) Teleconference details: NEXT: Tuesday July 1 2003 (USA) Time: 8:00AM (US PDT) Until: 10:00AM (Think this will just go apx 1 hour) Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Review TODOs from F2F in preparation for Last Call ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting number: 742973971 Meeting password: newpsi1! Host: Alan Berkema 1(916)7855605 From alan.berkema at hp.com Mon Jun 30 18:41:32 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:10 2009 Subject: PS> [PSI] Postponded - Next Call 07/01/03 Message-ID: <0806DAA43B1555479D53B58675D3468345832F@xrose01.rose.hp.com> Hey all, I just found out that some folks are on vacation this week and Dave is not done with his edits. I will be at the 1394 TA meeting next week so the new next call date is July 15th. Have a fun 4th! Alan ---- Note new webex number and more secure passwd :) Teleconference details: NEXT: Tuesday July 15 2003 (USA) Time: 8:00AM (US PDT) Until: 10:00AM (Think this will just go apx 1 hour) Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Review TODOs from F2F in preparation for Last Call ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting number: 742973971 Meeting password: newpsi1! Host: Alan Berkema 1(916)7855605 From alan.berkema at hp.com Tue Jul 1 18:22:45 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:10 2009 Subject: PS> [PSI]: Meeting Minutes 06/20/2003 Portland F2F Message-ID: <0806DAA43B1555479D53B58675D3468345833D@xrose01.rose.hp.com> Thanks Jerry -------------- next part -------------- A non-text attachment was scrubbed... Name: PSI Minutes 062003.pdf Type: application/octet-stream Size: 43286 bytes Desc: not available Url : http://www.pwg.org/archives/ps/attachments/20030701/27591bd4/PSIMinutes062003.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: agenda_060620.pdf Type: application/octet-stream Size: 72975 bytes Desc: not available Url : http://www.pwg.org/archives/ps/attachments/20030701/27591bd4/agenda_060620.obj From imcdonald at sharplabs.com Sun Jul 6 14:37:04 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:10 2009 Subject: PS> FW: SMB URL v05. Message-ID: <116DB56CD7DED511BC7800508B2CA53735D089@mailsrvnt02.enet.sharplabs.com> Hi folks, I've been corresponding with Chris Hertel (author of the 'smb:' URL scheme) recently. We could use the standard 'smb:' scheme to completely replace our need for a 'pwg-unc:' scheme in PSI/1.0. Chris says that it's already shipping in Mac OS 10 and elsewhere. Below is Chris' note to the IETF URI Review mailing list (a recent effort by IETF Area Director Ted Hardie to 'move along' URL schemes). Very good terse summary of the issues around SMB URLs in the TCP/IP environment. The spec itself is excellent reading (see URL below). Cheers, - Ira McDonald High North Inc -----Original Message----- From: Christopher R. Hertel [mailto:crh@ubiqx.mn.org] Sent: Sunday, July 06, 2003 3:23 AM To: uri-review@ietf.org Subject: SMB URL v05. Hello everyone. I've just joined this list. Please be gentle. ;) I have been working sporadically on a URI specification for SMB. SMB is the Server Message Block protocol, which is at the heart of Microsoft's filesharing system (now known as CIFS). The SMB filesharing protocol is implemented by several "third party" vendors, and in Open Source by the Samba and jCIFS projects. SMB itself is a relatively old protocol, and there are a number of quirks that must be accounted for in the URI design. In particular, there is all of RFC1001/1002 (STD 19) which specifies a mechanism for implementing the NetBIOS API on top of TCP/UDP/IPv4. Along with that comes all sorts of context information which must be supplied in order to give the NetBIOS addresses meaning in an IP environment. I have been providing draft SMB URI specifications to the IETF for about 2.5 years now. The current version number is 04, and it is due to expire in a few days. I have a minor update ready, and will send it along to keep the draft alive. The problems are: 1) I really have no idea how to push the SMB URI Internet Draft through the standards process. 2) I know a lot about SMB and NBT, and very little about URIs. To be honest, I'm not really clear on the difference between a URL and a URI (and I'm not even ashamed to admit it). :) 3) SMB is a difficult protocol, and the most important aspect of the drafts that I have submitted is the semantic mapping between the SMB URI format and SMB/NBT (NBT is a name commonly given to NetBIOS over TCP/IP as described in STD 19). In the past few years, I have gotten some very helpful feedback from Roy Fielding and Larry Masinter, and also from the SMB/CIFS development community. More recently, however, I have also received a request to "get on with it". A very reasonable request, I believe. Several vendors have already implemented support for the SMB URI in their products. It is in Thursby's Dave, Mac OS 10, and KDE Konqueror, to name a few. So, I am writing to ask for assistance in finishing this thing, either by bronzing it and putting it on a pedestal or by driving a stake through it's corrupt and evil heart. The current draft may be found here: http://www.ietf.org/internet-drafts/draft-crhertel-smb-url-04.txt I look forward to your replies (yes, I'm wearing a helmet). Sincerely, Chris Hertel -)----- -- "Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X Samba Team -- http://www.samba.org/ -)----- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)----- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)----- crh@ubiqx.mn.org OnLineBook -- http://ubiqx.org/cifs/ -)----- crh@ubiqx.org From dhall at hp.com Mon Jul 7 14:13:19 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:10 2009 Subject: PS> FW: SMB URL v05. Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FADC4@xvan01.vcd.hp.com> After reviewing the SMB specification, it seem that the smb: scheme should replace the pwg-unc: scheme that we have defined in PSI. Any dissention? I'll make a pass at getting it in the spec, and then we can review at tomorrows telecon. Dave -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Sunday, July 06, 2003 11:37 AM To: 'ps@pwg.org' Subject: PS> FW: SMB URL v05. Hi folks, I've been corresponding with Chris Hertel (author of the 'smb:' URL scheme) recently. We could use the standard 'smb:' scheme to completely replace our need for a 'pwg-unc:' scheme in PSI/1.0. Chris says that it's already shipping in Mac OS 10 and elsewhere. Below is Chris' note to the IETF URI Review mailing list (a recent effort by IETF Area Director Ted Hardie to 'move along' URL schemes). Very good terse summary of the issues around SMB URLs in the TCP/IP environment. The spec itself is excellent reading (see URL below). Cheers, - Ira McDonald High North Inc -----Original Message----- From: Christopher R. Hertel [mailto:crh@ubiqx.mn.org] Sent: Sunday, July 06, 2003 3:23 AM To: uri-review@ietf.org Subject: SMB URL v05. Hello everyone. I've just joined this list. Please be gentle. ;) I have been working sporadically on a URI specification for SMB. SMB is the Server Message Block protocol, which is at the heart of Microsoft's filesharing system (now known as CIFS). The SMB filesharing protocol is implemented by several "third party" vendors, and in Open Source by the Samba and jCIFS projects. SMB itself is a relatively old protocol, and there are a number of quirks that must be accounted for in the URI design. In particular, there is all of RFC1001/1002 (STD 19) which specifies a mechanism for implementing the NetBIOS API on top of TCP/UDP/IPv4. Along with that comes all sorts of context information which must be supplied in order to give the NetBIOS addresses meaning in an IP environment. I have been providing draft SMB URI specifications to the IETF for about 2.5 years now. The current version number is 04, and it is due to expire in a few days. I have a minor update ready, and will send it along to keep the draft alive. The problems are: 1) I really have no idea how to push the SMB URI Internet Draft through the standards process. 2) I know a lot about SMB and NBT, and very little about URIs. To be honest, I'm not really clear on the difference between a URL and a URI (and I'm not even ashamed to admit it). :) 3) SMB is a difficult protocol, and the most important aspect of the drafts that I have submitted is the semantic mapping between the SMB URI format and SMB/NBT (NBT is a name commonly given to NetBIOS over TCP/IP as described in STD 19). In the past few years, I have gotten some very helpful feedback from Roy Fielding and Larry Masinter, and also from the SMB/CIFS development community. More recently, however, I have also received a request to "get on with it". A very reasonable request, I believe. Several vendors have already implemented support for the SMB URI in their products. It is in Thursby's Dave, Mac OS 10, and KDE Konqueror, to name a few. So, I am writing to ask for assistance in finishing this thing, either by bronzing it and putting it on a pedestal or by driving a stake through it's corrupt and evil heart. The current draft may be found here: http://www.ietf.org/internet-drafts/draft-crhertel-smb-url-04.txt I look forward to your replies (yes, I'm wearing a helmet). Sincerely, Chris Hertel -)----- -- "Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X Samba Team -- http://www.samba.org/ -)----- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)----- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)----- crh@ubiqx.mn.org OnLineBook -- http://ubiqx.org/cifs/ -)----- crh@ubiqx.org From dhall at hp.com Mon Jul 7 15:54:47 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:10 2009 Subject: PS> Next Call 7/15,updated doc... Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FADC6@xvan01.vcd.hp.com> Hey All.. I've published the latest document revision: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030707.doc ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030707.pdf Looks like our next phone conference isn't untill teh 15 however. Talk to you next week! Dave -----Original Message----- From: BERKEMA,ALAN C (HP-Roseville,ex1) [mailto:alan.berkema@hp.com] Sent: Monday, June 30, 2003 3:42 PM To: 'a PSI pwg.org' Subject: PS> [PSI] Postponded - Next Call 07/01/03 Hey all, I just found out that some folks are on vacation this week and Dave is not done with his edits. I will be at the 1394 TA meeting next week so the new next call date is July 15th. Have a fun 4th! Alan ---- Note new webex number and more secure passwd :) Teleconference details: NEXT: Tuesday July 15 2003 (USA) Time: 8:00AM (US PDT) Until: 10:00AM (Think this will just go apx 1 hour) Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Review TODOs from F2F in preparation for Last Call ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting number: 742973971 Meeting password: newpsi1! Host: Alan Berkema 1(916)7855605 From imcdonald at sharplabs.com Tue Jul 8 12:10:34 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:10 2009 Subject: PS> FW: SMB URL v05. Message-ID: <116DB56CD7DED511BC7800508B2CA53735D090@mailsrvnt02.enet.sharplabs.com> Hi Dave, Thanks for the new PSI draft! About adding SMB right away to our PSI spec: Caution - the 'smb:' URL spec is quite mature (and widely deployed) - but it has just _finally_ been submitted last week to the IETF's "URI Review" mailing - the moderator (Ted Hardie) just replied that he'd be busy until after the IETF 57th Plenary in Vienna, Austria next week (13-18 July). Ted also asked "do the implementations support/use 'smb:' or 'cifs:' synonym schemes defined in this I-D"? Chris replied that they _all_ support/use "smb:" - some also accept 'cifs:' for compatibility - good news for PSI simplicity. If we move from 'pwg-unc:' to 'smb:' right now, we'll have (I believe) a Normative dependency on an unreviewed Internet-Draft. To get 'smb:' published as an approved RFC will take: a) review and revision on the mailing list; b) review and approval by an IETF Area Director; c) an IETF 4-week 'last call'; and d) movement through RFC Editor's queue. That's six to twelve months (pretty conservatively, I'm afraid). A possible finesse would be to put the "smb:" replacement for "pwg-unc:" in a new appendix "Experimental Target Device URLs (Informative)" (where we could also put my current work-in-progress on PWG URL schemes for Novell PServer, AppleTalk PAP and other legacy print protocols). I'm also plugging away at a threats model and discussion for a decent "Security Considerations" section of PSI. Which do you want first? More legacy URL schemes with ABNF and so on, or the Security Considerations? Cheers, - Ira McDonald High North Inc -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Monday, July 07, 2003 2:13 PM To: 'McDonald, Ira'; 'ps@pwg.org' Subject: RE: PS> FW: SMB URL v05. After reviewing the SMB specification, it seem that the smb: scheme should replace the pwg-unc: scheme that we have defined in PSI. Any dissention? I'll make a pass at getting it in the spec, and then we can review at tomorrows telecon. Dave -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Sunday, July 06, 2003 11:37 AM To: 'ps@pwg.org' Subject: PS> FW: SMB URL v05. Hi folks, I've been corresponding with Chris Hertel (author of the 'smb:' URL scheme) recently. We could use the standard 'smb:' scheme to completely replace our need for a 'pwg-unc:' scheme in PSI/1.0. Chris says that it's already shipping in Mac OS 10 and elsewhere. Below is Chris' note to the IETF URI Review mailing list (a recent effort by IETF Area Director Ted Hardie to 'move along' URL schemes). Very good terse summary of the issues around SMB URLs in the TCP/IP environment. The spec itself is excellent reading (see URL below). Cheers, - Ira McDonald High North Inc -----Original Message----- From: Christopher R. Hertel [mailto:crh@ubiqx.mn.org] Sent: Sunday, July 06, 2003 3:23 AM To: uri-review@ietf.org Subject: SMB URL v05. Hello everyone. I've just joined this list. Please be gentle. ;) I have been working sporadically on a URI specification for SMB. SMB is the Server Message Block protocol, which is at the heart of Microsoft's filesharing system (now known as CIFS). The SMB filesharing protocol is implemented by several "third party" vendors, and in Open Source by the Samba and jCIFS projects. SMB itself is a relatively old protocol, and there are a number of quirks that must be accounted for in the URI design. In particular, there is all of RFC1001/1002 (STD 19) which specifies a mechanism for implementing the NetBIOS API on top of TCP/UDP/IPv4. Along with that comes all sorts of context information which must be supplied in order to give the NetBIOS addresses meaning in an IP environment. I have been providing draft SMB URI specifications to the IETF for about 2.5 years now. The current version number is 04, and it is due to expire in a few days. I have a minor update ready, and will send it along to keep the draft alive. The problems are: 1) I really have no idea how to push the SMB URI Internet Draft through the standards process. 2) I know a lot about SMB and NBT, and very little about URIs. To be honest, I'm not really clear on the difference between a URL and a URI (and I'm not even ashamed to admit it). :) 3) SMB is a difficult protocol, and the most important aspect of the drafts that I have submitted is the semantic mapping between the SMB URI format and SMB/NBT (NBT is a name commonly given to NetBIOS over TCP/IP as described in STD 19). In the past few years, I have gotten some very helpful feedback from Roy Fielding and Larry Masinter, and also from the SMB/CIFS development community. More recently, however, I have also received a request to "get on with it". A very reasonable request, I believe. Several vendors have already implemented support for the SMB URI in their products. It is in Thursby's Dave, Mac OS 10, and KDE Konqueror, to name a few. So, I am writing to ask for assistance in finishing this thing, either by bronzing it and putting it on a pedestal or by driving a stake through it's corrupt and evil heart. The current draft may be found here: http://www.ietf.org/internet-drafts/draft-crhertel-smb-url-04.txt I look forward to your replies (yes, I'm wearing a helmet). Sincerely, Chris Hertel -)----- -- "Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X Samba Team -- http://www.samba.org/ -)----- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)----- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)----- crh@ubiqx.mn.org OnLineBook -- http://ubiqx.org/cifs/ -)----- crh@ubiqx.org From imcdonald at sharplabs.com Wed Jul 9 11:31:11 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:10 2009 Subject: PS> FW: [Uri-review] SMB URL v05. Message-ID: <116DB56CD7DED511BC7800508B2CA53735D094@mailsrvnt02.enet.sharplabs.com> -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Wednesday, July 09, 2003 11:22 AM To: 'Christopher R. Hertel' Cc: hardie@qualcomm.com; uri-review@ietf.org Subject: RE: [Uri-review] SMB URL v05. Hi folks, Here's a link to Chris Hertel's latest Internet-Draft of the SMB URL scheme, posted on the IEEE/ISTO Printer Working Group's anonymous FTP server: ftp://ftp.pwg.org/pub/pwg/ps/draft-crhertel-smb-url-05.txt It should also be available from the IETF I-D repositories after next week's IETF 57 in Vienna. Thanks, - Ira McDonald High North Inc PS - The IEEE/ISTO PWG folks would like to allow use of the SMB URL scheme in their new Web services printing protocol (PSI) for 'legacy' print system references. _______________________________________________ Uri-review mailing list Uri-review@ietf.org https://www1.ietf.org/mailman/listinfo/uri-review From dhall at hp.com Mon Jul 14 16:22:17 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:10 2009 Subject: PS> Meeting 7/15 - 866-639-4756 #2124228 Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FADEF@xvan01.vcd.hp.com> Hey All... Here is the info for tomorrows PSI teleconference: Topic: PSI Date: Tuesday, July 15, 2003 Time: 8:00 am, Pacific Daylight Time (GMT -07:00, San Jose) Meeting number: 742137205 866-639-4756 574-935-6714 #2124228 See you all there! Dave From imcdonald at sharplabs.com Mon Jul 14 16:30:31 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:10 2009 Subject: PS> Meeting 7/15 - 866-639-4756 #2124228 Message-ID: <116DB56CD7DED511BC7800508B2CA53735D0A4@mailsrvnt02.enet.sharplabs.com> Hi folks, Here's the URL that Dave sent out last week for the latest PSI spec: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030707.doc ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030707.pdf Cheers, - Ira McDonald High North Inc -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Monday, July 14, 2003 4:22 PM To: 'ps@pwg.org' Subject: PS> Meeting 7/15 - 866-639-4756 #2124228 Hey All... Here is the info for tomorrows PSI teleconference: Topic: PSI Date: Tuesday, July 15, 2003 Time: 8:00 am, Pacific Daylight Time (GMT -07:00, San Jose) Meeting number: 742137205 866-639-4756 574-935-6714 #2124228 See you all there! Dave From imcdonald at sharplabs.com Mon Jul 14 21:58:38 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:10 2009 Subject: PS> [PSI Reqs] Meeting 7/15 - 866-639-4756 #2124228 Message-ID: <116DB56CD7DED511BC7800508B2CA53735D0A5@mailsrvnt02.enet.sharplabs.com> Hi, As we discovered belatedly last week for WBMM and IPPFAX, the PWG Process (both old and new) REQUIRES that: * Each WG Requirements spec MUST be FORMALLY APPROVED (just like a PWG 'standards-track' spec, w/out prototyping, etc.) BEFORE the WG Protocol spec can become a Candidate Standard. At tomorrow's PSI telecon, I'd like to discuss: (a) Needed revisions for the PSI Reqs spec (v0.81, Oct 2002); and (b) Security Considerations section for PSI Protocol spec that describes the detailed network topology (firewalls, subnets, etc.) of each of the 5 Usage Scenarios in the PSI Reqs spec. The latest PSI Reqs spec is at: ftp://ftp.pwg.org/pub/pwg/ps/psi_requirements081.doc ftp://ftp.pwg.org/pub/pwg/ps/psi_requirements081.pdf Cheers, - Ira McDonald High North Inc -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Monday, July 14, 2003 4:31 PM To: 'HALL,DAVID (HP-Vancouver,ex1)'; 'ps@pwg.org' Subject: RE: PS> Meeting 7/15 - 866-639-4756 #2124228 Hi folks, Here's the URL that Dave sent out last week for the latest PSI spec: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030707.doc ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030707.pdf Cheers, - Ira McDonald High North Inc -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Monday, July 14, 2003 4:22 PM To: 'ps@pwg.org' Subject: PS> Meeting 7/15 - 866-639-4756 #2124228 Hey All... Here is the info for tomorrows PSI teleconference: Topic: PSI Date: Tuesday, July 15, 2003 Time: 8:00 am, Pacific Daylight Time (GMT -07:00, San Jose) Meeting number: 742137205 866-639-4756 574-935-6714 #2124228 See you all there! Dave From dhall at hp.com Tue Jul 15 11:03:33 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:11 2009 Subject: PS> Meeting 7/15 - 866-639-4756 #2124228 Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FADF1@xvan01.vcd.hp.com> new_psi2 is the webex password -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Monday, July 14, 2003 1:22 PM To: 'ps@pwg.org' Subject: PS> Meeting 7/15 - 866-639-4756 #2124228 Hey All... Here is the info for tomorrows PSI teleconference: Topic: PSI Date: Tuesday, July 15, 2003 Time: 8:00 am, Pacific Daylight Time (GMT -07:00, San Jose) Meeting number: 742137205 866-639-4756 574-935-6714 #2124228 See you all there! Dave From alan.berkema at hp.com Fri Jul 18 14:53:08 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:11 2009 Subject: PS> [PSI] No Call 07/22 Next Call 07/29/03 Message-ID: <0806DAA43B1555479D53B58675D34683458376@xrose01.rose.hp.com> Teleconference details: NEXT: Tuesday July 29 2003 (USA) Time: 8:00AM (US PDT) Until: 9:00AM Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Review Spec 2) Semantic Model Dependancy Update 3) Actions to move forward ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting number: 743057814 Meeting password: newpsi-1 Host: Alan Berkema 1(916)7855605 From imcdonald at sharplabs.com Mon Jul 21 13:43:35 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:11 2009 Subject: PS> FW: IPP> Re: ISSUE 17: about server-error-too-many-jobs (0x050B) Message-ID: <116DB56CD7DED511BC7800508B2CA53735D0BA@mailsrvnt02.enet.sharplabs.com> Hi, Michael Sweet's comments on 'server-error-too-many-jobs/documents'. Cheers, - Ira McDonald High North Inc -----Original Message----- From: Michael Sweet [mailto:mike@easysw.com] Sent: Monday, July 21, 2003 11:09 AM To: Hastings, Tom N Cc: ipp@pwg.org Subject: IPP> Re: ISSUE 17: about server-error-too-many-jobs (0x050B) Hastings, Tom N wrote: > Michael, > > Do you have some input on this issue in the Document object spec about what > we should say about whether or not the client should try again (later) on > the proposed new server-error-too-many-jobs (0x050B): > > 22. About ISSUE17: > 13.1 server-error-too-many-jobs (0x050B) > The client has attempted to create a Job using any of the Job Creation > operations which would exceed the capacity of the Printer and/or the policy > for this user or type of Job. The client SHOULD NOT try again later. DMC > ISSUE17: I would have said SHOULD try again later, because resources might > have been freed up. That is, I would have read "too many jobs" as a > resource issue and "too many documents" as a policy issue. If we're saying > not to try again, we should be clear that this error should only be returned > if the problem is not expected to go away. > > Good ISSUE! It would be good to get Michael Sweet's input on this, since he > requested these error codes. I think that the status codes for both too-many-jobs and too-many-documents should be worded such that a client MAY try again later, not SHOULD or SHOULD NOT. If we want to differentiate hard and soft errors, I would recommend using server-error-not-possible to specify that it is not possible to create a new job or document (i.e. not-possible means don't retry, too-many-foos means you MAY retry...) -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike at easysw dot com Printing Software for UNIX http://www.easysw.com From alan.berkema at hp.com Mon Jul 28 11:55:57 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:11 2009 Subject: PS> [PSI] Reminder Next Call 07/29/03 Message-ID: <0806DAA43B1555479D53B58675D3468345838E@xrose01.rose.hp.com> Teleconference details: NEXT: Tuesday July 29 2003 (USA) Time: 8:00AM (US PDT) Until: 9:00AM Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Recent work items form Dave & Ira 2) Semantic Model Dependancy Update 3) Actions to move forward 4) Interop Test Plan ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting number: 743057814 Meeting password: newpsi-1 Host: Alan Berkema 1(916)7855605 From hastings at cp10.es.xerox.com Mon Jul 28 16:25:24 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:02:11 2009 Subject: PS> RE: ISSUE 17: about server-error-too-many-jobs (0x050B) [comment on Document Object spec] Message-ID: Here are the current specifications for these two new error status codes from the current Document Object spec (circa June 3 with Dennis's comments added): 13.1 server-error-too-many-jobs (0x050B) The client has attempted to create a Job using any of the Job Creation operations which would exceed the capacity of the Printer and/or the policy for this user or type of Job. The client SHOULD NOT try again later. DMC ISSUE17: I would have said SHOULD try again later, because resources might have been freed up. That is, I would have read "too many jobs" as a resource issue and "too many documents" as a policy issue. If we're saying not to try again, we should be clear that this error should only be returned if the problem is not expected to go away. 13.2 server-error-too-many-documents (0x050C) The client has attempted to create a Document using any of the Document Creation operations which would exceed the capacity of the Printer for this Job and/or the policy for this user or type of Job. The client SHOULD NOT try again later. For server-error-too-many-jobs: "The client SHOULD NOT try again later" Dennis proposes: "The client SHOULD try again later." Michael proposes: Remove the policy possibility from the description and use 'client-error-not-possible' to mean a hard error and use MAY: The client has attempted to create a Job using any of the Job Creation operations which would exceed the capacity of the Printer. The client MAY try again later. Looking at the status codes descriptions in [rfc2911], I'd suggest: The client has attempted to create a Job using any of the Job Creation operations which would exceed the capacity of the Printer. The client MAY try the unmodified request again at some later point in time with an expectation that the capacity condition may have changed. For server-error-too-many-documents: "The client SHOULD NOT try again later" Dennis proposes no change. Michael proposes the same change: The client has attempted to create a Document using any of the Document Creation operations which would exceed the capacity of the Printer for this Job. The client MAY try again later. How about to align more with [rfc2911]: The client has attempted to create a Document using any of the Document Creation operations which would exceed the capacity of the Printer for this Job. The client MAY try the unmodified request again at some later point in time with an expectation that the capacity condition may have changed. Tom -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Monday, July 21, 2003 10:44 To: 'sm@pwg.org'; 'ps@pwg.org' Subject: SM> FW: IPP> Re: ISSUE 17: about server-error-too-many-jobs (0x050B) Hi, Michael Sweet's comments on 'server-error-too-many-jobs/documents'. Cheers, - Ira McDonald High North Inc -----Original Message----- From: Michael Sweet [mailto:mike@easysw.com] Sent: Monday, July 21, 2003 11:09 AM To: Hastings, Tom N Cc: ipp@pwg.org Subject: IPP> Re: ISSUE 17: about server-error-too-many-jobs (0x050B) Hastings, Tom N wrote: > Michael, > > Do you have some input on this issue in the Document object spec about what > we should say about whether or not the client should try again (later) on > the proposed new server-error-too-many-jobs (0x050B): > > 22. About ISSUE17: > 13.1 server-error-too-many-jobs (0x050B) > The client has attempted to create a Job using any of the Job Creation > operations which would exceed the capacity of the Printer and/or the policy > for this user or type of Job. The client SHOULD NOT try again later. DMC > ISSUE17: I would have said SHOULD try again later, because resources might > have been freed up. That is, I would have read "too many jobs" as a > resource issue and "too many documents" as a policy issue. If we're saying > not to try again, we should be clear that this error should only be returned > if the problem is not expected to go away. > > Good ISSUE! It would be good to get Michael Sweet's input on this, since he > requested these error codes. I think that the status codes for both too-many-jobs and too-many-documents should be worded such that a client MAY try again later, not SHOULD or SHOULD NOT. If we want to differentiate hard and soft errors, I would recommend using server-error-not-possible to specify that it is not possible to create a new job or document (i.e. not-possible means don't retry, too-many-foos means you MAY retry...) -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike at easysw dot com Printing Software for UNIX http://www.easysw.com From alan.berkema at hp.com Tue Jul 29 17:10:36 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:11 2009 Subject: PS> [PSI]: Mtg. Minutes 7/29/03 Message-ID: <0806DAA43B1555479D53B58675D346834583A7@xrose01.rose.hp.com> PSI Working Group: *Alan Berkema *Dave Hall *Ira McDonald Jerry Thrasher *Harry Lewis *Ted Tronson Peter Mierau Peter Zehler Gail Songer Paul Tykodi Bob Taylor Lee Farrell Don Wright * = attendance 07/29/03 Agenda 1) Recent work items form Dave & Ira 2) Semantic Model Dependency Update 3) Actions to move forward 4) Interop Test Plan Minutes: 1) Recent work items form Dave & Ira Dave and Ira were Unable to meet last week. Will schedule next Tuesday 8/5/2003 to work on the PSI requirements document. Major point is that the use model diagrams could be embellished to show network domains, such as Public Internet or Private Intranet etc. The domains could be used be used to identify security threats. The threats should be categorized and addressed with recommendations for default configurations and/or solutions. PSI Spec has added headers for new sections called: IEEE ISTO PWG Considerations (IANA?) International Considerations Conformance Section Suggesting apx. one page each for PS, TD & Client. Example a PS shall implement all 4 interfaces, a TD implements 3 interfaces. Includes critical details. 2) Semantic Model Dependency Update Pete will update on Thursday. 3) Actions to move forward Still do not have a succinct list of actions needed for next last call. 4) Interop Test Plan Event will now be conducted remotely. Dave will leverage tests that he has for a test plan and send to the participants. Tests will include the specific methods and the parameter values which will be tested. Parameters, such as unsupported, that will not be tested will also be identified Dave will send new logistics for conference call number and webex info. Thanks, Alan From alan.berkema at hp.com Tue Jul 29 17:34:46 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:11 2009 Subject: PS> [PSI] Next Call 08/05/03 Message-ID: <0806DAA43B1555479D53B58675D346834583A8@xrose01.rose.hp.com> NO Call on 8/12/2003 - Interop Event Teleconference details: NEXT: Tuesday August 5 2003 (USA) Time: 8:00AM (US PDT) Until: 9:00AM Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Requirements Doc 2) New Spec Considerations and Conformance Sections 3) Suuccint List of Actions needed to go to next Last Call ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting number: 743057814 Meeting password: newpsi-1 Host: Alan Berkema 1(916)7855605 From imcdonald at sharplabs.com Tue Jul 29 18:31:32 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:11 2009 Subject: PS> RE: ISSUE 17: about server-error-too-many-jobs (0x050B) [comment on Document Object spec] Message-ID: <116DB56CD7DED511BC7800508B2CA53735D0CB@mailsrvnt02.enet.sharplabs.com> Hi Tom, I agree with your suggested rewording below. Cheers, - Ira McDonald High North Inc -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Monday, July 28, 2003 4:25 PM To: McDonald, Ira; 'sm@pwg.org'; 'ps@pwg.org' Subject: RE: ISSUE 17: about server-error-too-many-jobs (0x050B) [comment on Document Object spec] Here are the current specifications for these two new error status codes from the current Document Object spec (circa June 3 with Dennis's comments added): 13.1 server-error-too-many-jobs (0x050B) The client has attempted to create a Job using any of the Job Creation operations which would exceed the capacity of the Printer and/or the policy for this user or type of Job. The client SHOULD NOT try again later. DMC ISSUE17: I would have said SHOULD try again later, because resources might have been freed up. That is, I would have read "too many jobs" as a resource issue and "too many documents" as a policy issue. If we're saying not to try again, we should be clear that this error should only be returned if the problem is not expected to go away. 13.2 server-error-too-many-documents (0x050C) The client has attempted to create a Document using any of the Document Creation operations which would exceed the capacity of the Printer for this Job and/or the policy for this user or type of Job. The client SHOULD NOT try again later. For server-error-too-many-jobs: "The client SHOULD NOT try again later" Dennis proposes: "The client SHOULD try again later." Michael proposes: Remove the policy possibility from the description and use 'client-error-not-possible' to mean a hard error and use MAY: The client has attempted to create a Job using any of the Job Creation operations which would exceed the capacity of the Printer. The client MAY try again later. Looking at the status codes descriptions in [rfc2911], I'd suggest: The client has attempted to create a Job using any of the Job Creation operations which would exceed the capacity of the Printer. The client MAY try the unmodified request again at some later point in time with an expectation that the capacity condition may have changed. For server-error-too-many-documents: "The client SHOULD NOT try again later" Dennis proposes no change. Michael proposes the same change: The client has attempted to create a Document using any of the Document Creation operations which would exceed the capacity of the Printer for this Job. The client MAY try again later. How about to align more with [rfc2911]: The client has attempted to create a Document using any of the Document Creation operations which would exceed the capacity of the Printer for this Job. The client MAY try the unmodified request again at some later point in time with an expectation that the capacity condition may have changed. Tom -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Monday, July 21, 2003 10:44 To: 'sm@pwg.org'; 'ps@pwg.org' Subject: SM> FW: IPP> Re: ISSUE 17: about server-error-too-many-jobs (0x050B) Hi, Michael Sweet's comments on 'server-error-too-many-jobs/documents'. Cheers, - Ira McDonald High North Inc -----Original Message----- From: Michael Sweet [mailto:mike@easysw.com] Sent: Monday, July 21, 2003 11:09 AM To: Hastings, Tom N Cc: ipp@pwg.org Subject: IPP> Re: ISSUE 17: about server-error-too-many-jobs (0x050B) Hastings, Tom N wrote: > Michael, > > Do you have some input on this issue in the Document object spec about what > we should say about whether or not the client should try again (later) on > the proposed new server-error-too-many-jobs (0x050B): > > 22. About ISSUE17: > 13.1 server-error-too-many-jobs (0x050B) > The client has attempted to create a Job using any of the Job Creation > operations which would exceed the capacity of the Printer and/or the policy > for this user or type of Job. The client SHOULD NOT try again later. DMC > ISSUE17: I would have said SHOULD try again later, because resources might > have been freed up. That is, I would have read "too many jobs" as a > resource issue and "too many documents" as a policy issue. If we're saying > not to try again, we should be clear that this error should only be returned > if the problem is not expected to go away. > > Good ISSUE! It would be good to get Michael Sweet's input on this, since he > requested these error codes. I think that the status codes for both too-many-jobs and too-many-documents should be worded such that a client MAY try again later, not SHOULD or SHOULD NOT. If we want to differentiate hard and soft errors, I would recommend using server-error-not-possible to specify that it is not possible to create a new job or document (i.e. not-possible means don't retry, too-many-foos means you MAY retry...) -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike at easysw dot com Printing Software for UNIX http://www.easysw.com From imcdonald at sharplabs.com Mon Aug 4 14:30:19 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:11 2009 Subject: PS> FW: IETF moves on LDAP Printer schema Message-ID: <116DB56CD7DED511BC7800508B2CA53735D0DB@mailsrvnt02.enet.sharplabs.com> Hi folks, To my complete amazement, we just got lucky. The IETF assigned a new Area Director to shepherd our LDAP Printer scheme (Ted Hardie of Qualcomm) and he intends to move it forward for IETF four week 'last call' in the near future (for publication as a future Informational RFC). Apparently, sometimes pigs do fly!!! Cheers, - Ira McDonald, co-editor of LDAP Printer schema High North Inc -----Original Message----- From: McDonald, Ira Sent: Monday, August 04, 2003 2:25 PM To: 'hardie@qualcomm.com'; McDonald, Ira; 'Pat Fleming'; 'Harry Lewis'; 'Kurt@OpenLDAP.org' Subject: RE: Help with review of draft-fleming-ldap-printer-schema-02.txt Hi Ted, Wow! Thanks for your instant reply. I just sent a note to the RFC Editor and copied you and Kurt ASAP, so soon you will be able to schedule an IETF last call. Cheers, - Ira McDonald High North Inc -----Original Message----- From: hardie@qualcomm.com [mailto:hardie@qualcomm.com] Sent: Monday, August 04, 2003 1:59 PM To: McDonald, Ira; 'Pat Fleming'; 'Harry Lewis'; 'Kurt@OpenLDAP.org' Subject: Re: Help with review of draft-fleming-ldap-printer-schema-02.txt Hi, I would also like help moving this forward. As a first step, would you be willing for us to last call the document? This is not required for an informational document, but I believe that in this case the combination of technologies (and the time it has been on the plate) would make that prudent. If you are, please let the RFC Editor know that this will be moving from "Independent via RFC Editor" to "Independent, sponsored by AD"; I'll then mark the change in the tracker and issue a four week last call. Assuming no issues come up, we should be able to get it on the ballot after the last call. thanks, Ted Hardie At 10:44 AM -0700 8/4/03, McDonald, Ira wrote: >Hi Ted and Kurt, > >Pat Fleming and I revised this LDAP Printer schema document >in response to comments from Kurt and others in June 2002. >FYI - below is the release notice Pat Fleming and I sent when >we posted draft-02 last year. > >Patrik Faltstrom has never replied to any of our subsequent >notes. > >I found out in the IETF I-D Tracker that Ted is now our shepherd >and the docment remains in 'Expert Review' (since February 2002). > >Printer industry folks active in the IETF and the IEEE/ISTO >PWG (Printer Working Group) would very much like to get this >Informational RFC published. Two IEEE/ISTO PWGs protocols >now under development recommend support of this LDAP Printer >schema for service advertising. > >Any help moving this document forward would be greatly >appreciated. > >Cheers, >- Ira McDonald, co-editor of LDAP Printer schema > High North Inc > (consultant at Sharp Labs, Easy Software, and elsewhere) > imcdonald@sharplabs.com > >-------------------------------------------------------------- > > >Copies: IPP WG > SLP Discussion List > Pat Fleming > Ken Jones > Harry Lewis > Ira McDonald > >Hi folks, Sunday (30 June 2002) > >I've just sent a final version of 'LDAP Schema for Printer Services' to >the Internet-Drafts editor and posted a copy on the PWG server in the >directory 'ftp://ftp.pwg.org/pub/pwg/ipp/new_LDAP/' in the file: > > (June 2002) > >There have been a number of minor revisions, based on IESG 'last call' >comments. The document includes a change history appendix (to be >deleted before RFC publication - see below). > >The technical content is entirely unchanged from the previous version. > >As soon as this I-D is available in the IETF repository, we will request >that it be published as an Informational RFC. > >Cheers, >- Ira McDonald (co-editor of LDAP printer schema) > High North Inc > imcdonald@sharplabs.com > >------------------------------------------------------------------------ > >Copies: Internet Drafts Editor > Pat Fleming > Ira McDonald > >I-D Editor, Sunday (30 June 2002) > >Please place this document in the Internet-Drafts repository named: > > (June 2002) > >It replaces the previous: > > (February 2002) > >There have been a number of minor revisions, based on IESG 'last call' >comments. The document includes a change history appendix (to be >deleted before RFC publication). > >The technical content is entirely unchanged from the previous version. > >Abstract > > This document defines a schema, object classes and attributes, for > printers and printer services, for use with directories that support > Lightweight Directory Access Protocol v3 (LDAP-TS). This document is > based on the printer attributes listed in Appendix E of Internet > Printing Protocol/1.1 (IPP) (RFC 2911). A few additional printer > attributes are based on definitions in the Printer MIB (RFC 1759). > >Thanks very much, >- Ira McDonald (co-editor of LDAP printer schema) > High North Inc > imcdonald@sharplabs.com > >------------------------------------------------------------------------ > >[Excerpt from Change History] > > 30 June 2002 - draft-fleming-ldap-printer-schema-02.txt > - Final edits after IESG 'last call'; > - Revised title page and section 12 'Acknowledgments' to acknowledge > Ken Jones and Harry Lewis as major contributors (rather than as > current editors), per new RFC Editor policies; > - Rewrote and simplified Abstract and section 1 Introduction, per > comments from Kurt Zeilenga; > - Added section 1.1 'Rationale for using DirectoryString syntax', per > comments from Kurt Zeilenga; > - Added section 1.2 'Rationale for using caseIgnoreMatch', per > comments from Kurt Zeilenga; > - Added section 1.3 'Rationale for using caseIgnoreSubstringsMatch', > per comments from Kurt Zeilenga; > - Renamed section 2 to 'Terminology and Conventions' and added schema > definition format reference, per comments from Kurt Zeilenga; > - Revised section 3 and section 4 to remove (erroneous) guidance on > adding new attributes to existing classes and discussion of RDN for > auxiliary classes, per comments from Kurt Zeilenga and Ryan Moats; > - Revised section 4 'Definition of Attribute Types' to remove > (erroneous) guidance on support of matching rules, per comments > from Kurt Zeilenga; > - Revised section 4 'Definition of Attribute Types' to remove > normative/lengthy descriptions from the DESC clauses and place them > _below_ each formal attribute definition, per comments from Kurt > Zeilenga; > - Revised section 4 'Definition of Attribute Types', removing all > ORDERING clauses using 'caseIgnoreOrderingMatch', per comments from > Kurt Zeilenga; > - Revised sections 4.x printer-uri, printer-xri-supported, and > printer-more-info, to provide guidance on application handling of > malformed URI and reference new sections 1.1, 1.2, and 1.3, per > comments from Kurt Zeilenga; > - Revised section 6 'Definition of Matching Rules' to remove > (erroneous) guidance on support of matching rules, per comments > from Kurt Zeilenga; > - Revised section 7 'IANA Considerations' to include completed > templates for IANA registration of new object classes and attribute > types, defined in this document; > - Revised section 9 'Security Considerations' to reference RFC 2829 > (for authentication methods) and RFC 2830 (for TLS confidentiality > and integrity), per comments from Kurt Zeilenga; > - Revised (former) section 10 'References', to separate normative and > informative references, per comments from Kurt Zeilenga; > - Corrected author contact info. From alan.berkema at hp.com Mon Aug 4 14:47:06 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:11 2009 Subject: PS> [PSI] NEW TIME!!! Next Call 08/05/03 Message-ID: <0806DAA43B1555479D53B58675D346834583D8@xrose01.rose.hp.com> Hi all, Enough regulars agreed to make this one time change. Thanks Teleconference details: NEXT: Tuesday August 5 2003 (USA) Time: 9:00AM (US PDT) Until: 10:00AM Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Requirements Doc 2) New Spec Considerations and Conformance Sections 3) Suuccint List of Actions needed to go to next Last Call ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 9:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting number: 743057814 Meeting password: newpsi-1 Host: Alan Berkema 1(916)7855605 From imcdonald at sharplabs.com Mon Aug 4 15:27:25 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:11 2009 Subject: PS> FW: Help with review of draft-fleming-ldap-printer-schema-02.txt Message-ID: <116DB56CD7DED511BC7800508B2CA53735D0DD@mailsrvnt02.enet.sharplabs.com> Hi folks, I personally think we should award SOMETHING to Ted Hardie for being the most responsive IETF Area Director I've ever heard of. See below. Cheers, - Ira McDonald, co-editor of LDAP Printer schema High North Inc -----Original Message----- From: hardie@qualcomm.com [mailto:hardie@qualcomm.com] Sent: Monday, August 04, 2003 2:46 PM To: McDonald, Ira; 'Pat Fleming'; 'Harry Lewis'; 'Kurt@OpenLDAP.org' Subject: RE: Help with review of draft-fleming-ldap-printer-schema-02.txt I got the note, and I've updated the tracker and sent a request to the Secretariat for a last call. That should be a four week call (September 1 or 2). Thanks again for your help on moving this forward, regards, Ted Hardie At 11:24 AM -0700 8/4/03, McDonald, Ira wrote: >Hi Ted, > >Wow! Thanks for your instant reply. > >I just sent a note to the RFC Editor and copied you and Kurt >ASAP, so soon you will be able to schedule an IETF last call. > >Cheers, >- Ira McDonald > High North Inc > > >-----Original Message----- >From: hardie@qualcomm.com [mailto:hardie@qualcomm.com] >Sent: Monday, August 04, 2003 1:59 PM >To: McDonald, Ira; 'Pat Fleming'; 'Harry Lewis'; 'Kurt@OpenLDAP.org' >Subject: Re: Help with review of >draft-fleming-ldap-printer-schema-02.txt > > >Hi, > I would also like help moving this forward. As a first >step, would you be willing for us to last call the document? This >is not required for an informational document, but I believe >that in this case the combination of technologies (and the time >it has been on the plate) would make that prudent. If you >are, please let the RFC Editor know that this will be moving >from "Independent via RFC Editor" to "Independent, sponsored >by AD"; I'll then mark the change in the tracker and issue a >four week last call. Assuming no issues come up, we should >be able to get it on the ballot after the last call. > thanks, > Ted Hardie > > >At 10:44 AM -0700 8/4/03, McDonald, Ira wrote: >>Hi Ted and Kurt, >> >>Pat Fleming and I revised this LDAP Printer schema document >>in response to comments from Kurt and others in June 2002. >>FYI - below is the release notice Pat Fleming and I sent when >>we posted draft-02 last year. >> >>Patrik Faltstrom has never replied to any of our subsequent >>notes. >> >>I found out in the IETF I-D Tracker that Ted is now our shepherd >>and the docment remains in 'Expert Review' (since February 2002). >> >>Printer industry folks active in the IETF and the IEEE/ISTO >>PWG (Printer Working Group) would very much like to get this >>Informational RFC published. Two IEEE/ISTO PWGs protocols >>now under development recommend support of this LDAP Printer >>schema for service advertising. >> >>Any help moving this document forward would be greatly >>appreciated. >> >>Cheers, >>- Ira McDonald, co-editor of LDAP Printer schema >> High North Inc >> (consultant at Sharp Labs, Easy Software, and elsewhere) >> imcdonald@sharplabs.com >> >>-------------------------------------------------------------- >> >> >>Copies: IPP WG >> SLP Discussion List >> Pat Fleming >> Ken Jones >> Harry Lewis >> Ira McDonald >> >>Hi folks, Sunday (30 June 2002) >> >>I've just sent a final version of 'LDAP Schema for Printer Services' to >>the Internet-Drafts editor and posted a copy on the PWG server in the >>directory 'ftp://ftp.pwg.org/pub/pwg/ipp/new_LDAP/' in the file: >> >> (June 2002) >> >>There have been a number of minor revisions, based on IESG 'last call' >>comments. The document includes a change history appendix (to be >>deleted before RFC publication - see below). >> >>The technical content is entirely unchanged from the previous version. >> >>As soon as this I-D is available in the IETF repository, we will request >>that it be published as an Informational RFC. >> >>Cheers, >>- Ira McDonald (co-editor of LDAP printer schema) >> High North Inc >> imcdonald@sharplabs.com >> >>------------------------------------------------------------------------ >> >>Copies: Internet Drafts Editor >> Pat Fleming >> Ira McDonald > > >>I-D Editor, Sunday (30 June 2002) >> >>Please place this document in the Internet-Drafts repository named: >> >> (June 2002) >> >>It replaces the previous: >> >> (February 2002) >> >>There have been a number of minor revisions, based on IESG 'last call' >>comments. The document includes a change history appendix (to be >>deleted before RFC publication). >> >>The technical content is entirely unchanged from the previous version. >> >>Abstract >> >> This document defines a schema, object classes and attributes, for >> printers and printer services, for use with directories that support >> Lightweight Directory Access Protocol v3 (LDAP-TS). This document is >> based on the printer attributes listed in Appendix E of Internet >> Printing Protocol/1.1 (IPP) (RFC 2911). A few additional printer >> attributes are based on definitions in the Printer MIB (RFC 1759). >> >>Thanks very much, >>- Ira McDonald (co-editor of LDAP printer schema) >> High North Inc >> imcdonald@sharplabs.com >> >>------------------------------------------------------------------------ >> >>[Excerpt from Change History] >> >> 30 June 2002 - draft-fleming-ldap-printer-schema-02.txt >> - Final edits after IESG 'last call'; >> - Revised title page and section 12 'Acknowledgments' to acknowledge >> Ken Jones and Harry Lewis as major contributors (rather than as >> current editors), per new RFC Editor policies; >> - Rewrote and simplified Abstract and section 1 Introduction, per >> comments from Kurt Zeilenga; >> - Added section 1.1 'Rationale for using DirectoryString syntax', per >> comments from Kurt Zeilenga; >> - Added section 1.2 'Rationale for using caseIgnoreMatch', per >> comments from Kurt Zeilenga; >> - Added section 1.3 'Rationale for using caseIgnoreSubstringsMatch', >> per comments from Kurt Zeilenga; >> - Renamed section 2 to 'Terminology and Conventions' and added schema >> definition format reference, per comments from Kurt Zeilenga; >> - Revised section 3 and section 4 to remove (erroneous) guidance on >> adding new attributes to existing classes and discussion of RDN for >> auxiliary classes, per comments from Kurt Zeilenga and Ryan Moats; >> - Revised section 4 'Definition of Attribute Types' to remove >> (erroneous) guidance on support of matching rules, per comments >> from Kurt Zeilenga; >> - Revised section 4 'Definition of Attribute Types' to remove >> normative/lengthy descriptions from the DESC clauses and place them >> _below_ each formal attribute definition, per comments from Kurt >> Zeilenga; >> - Revised section 4 'Definition of Attribute Types', removing all >> ORDERING clauses using 'caseIgnoreOrderingMatch', per comments from >> Kurt Zeilenga; >> - Revised sections 4.x printer-uri, printer-xri-supported, and >> printer-more-info, to provide guidance on application handling of >> malformed URI and reference new sections 1.1, 1.2, and 1.3, per >> comments from Kurt Zeilenga; >> - Revised section 6 'Definition of Matching Rules' to remove >> (erroneous) guidance on support of matching rules, per comments >> from Kurt Zeilenga; >> - Revised section 7 'IANA Considerations' to include completed >> templates for IANA registration of new object classes and attribute >> types, defined in this document; >> - Revised section 9 'Security Considerations' to reference RFC 2829 >> (for authentication methods) and RFC 2830 (for TLS confidentiality >> and integrity), per comments from Kurt Zeilenga; >> - Revised (former) section 10 'References', to separate normative and >> informative references, per comments from Kurt Zeilenga; >> - Corrected author contact info. From alan.berkema at hp.com Tue Aug 5 18:32:36 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:11 2009 Subject: PS> [PSI] Next Call 08/19/03 Message-ID: <0806DAA43B1555479D53B58675D346834583DD@xrose01.rose.hp.com> NO CALL 08/12/2003 Interop Date Teleconference details: NEXT: Tuesday August 19 2003 (USA) NOTE: 2 hours Time: 8:00AM (US PDT) Until: 10:00AM Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Requirements Doc 2) Spec Review 3) Suuccint List of Actions needed to go to next Last Call ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 9:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting number: 743057814 Meeting password: newpsi-1 Host: Alan Berkema 1(916)7855605 From imcdonald at sharplabs.com Wed Aug 6 14:41:18 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:11 2009 Subject: PS> Enhance version of Use Model 1 diagram Message-ID: <116DB56CD7DED511BC7800508B2CA537B00143@mailsrvnt02.enet.sharplabs.com> Hi Alan and Dave, Below is a simple ASCII-art enhancement of Use Model 1 diagram, showing the actual network technologies and connectivity, so that we can address concrete security threats. Comments? Cheers, - Ira McDonald High North Inc -------------------------- Use Model 1 ------------- ------------- | | ! | | Print |<---------------(5)----------------! Content | | Service | ! Provider | | (PS) | ! | ------------- ------------- E ^ ^ | ADSL Modem T1 Circuit | n | | | ISP ( ------ ) ISP | e | | | ( ) | t(3) (4) (6) ( INTERNET ) (0) L | | | ( ) | A | | | ( ------ ) GSM Cellular | N v v v Wireless ISP v ------------- ------------- | | ! | | Target |<---------------(1)----------------! Mobile | | Device | Bluetooth PAN ! Device | | (Printer) |<---------------(2)----------------! | ------------- ------------- (PSI Client) Data Flows: (0) Browse - Public Internet browse for content URL (1) Discovery - Bluetooth discovery (2) Reference - Bluetooth print-by-reference of content URL (3) C2S - Ethernet LAN PSI print job (4) T2S - Ethernet LAN PSI print job (5) Content - Public Internet fetch of content URL (6) Formatted Data - Ethernet LAN PSI print job From imcdonald at sharplabs.com Tue Aug 19 11:10:56 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:11 2009 Subject: PS> [Hey where's Alan and Dave? ] Next Call 08/19/03 Message-ID: <116DB56CD7DED511BC7800508B2CA537B00166@mailsrvnt02.enet.sharplabs.com> Hi, It's now ten minutes past the hour and I'm still getting "waiting music" on the PSI telecon. _are_ we meeting today? Cheers, - Ira -----Original Message----- From: BERKEMA,ALAN C (HP-Roseville,ex1) [mailto:alan.berkema@hp.com] Sent: Tuesday, August 05, 2003 6:33 PM To: 'a PSI pwg.org' Subject: PS> [PSI] Next Call 08/19/03 NO CALL 08/12/2003 Interop Date Teleconference details: NEXT: Tuesday August 19 2003 (USA) NOTE: 2 hours Time: 8:00AM (US PDT) Until: 10:00AM Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Requirements Doc 2) Spec Review 3) Suuccint List of Actions needed to go to next Last Call ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 9:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting number: 743057814 Meeting password: newpsi-1 Host: Alan Berkema 1(916)7855605 From alan.berkema at hp.com Mon Aug 25 12:48:08 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:11 2009 Subject: PS> [PSI] Next Call 08/26/03 Message-ID: <0806DAA43B1555479D53B58675D3468345841C@xrose01.rose.hp.com> Teleconference details: NEXT: Tuesday August 26 2003 (USA) NO Call 9/2/2003 (Day after Labor day) Time: 8:00AM (US PDT) Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Requirements Doc 2) Spec Review 3) Succinct List of Actions needed to go to next Last Call ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 9:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting number: 743057814 Meeting password: newpsi-1 Host: Alan Berkema 1(916)7855605 From alan.berkema at hp.com Mon Aug 25 13:14:42 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:11 2009 Subject: PS> [PSI] Diagrams for Next Call 08/26/03 Message-ID: <0806DAA43B1555479D53B58675D3468345841E@xrose01.rose.hp.com> Teleconference details: NEXT: Tuesday August 26 2003 (USA) NO Call 9/2/2003 (Day after Labor day) Time: 8:00AM (US PDT) Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Requirements Doc 2) Spec Review 3) Succinct List of Actions needed to go to next Last Call ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 9:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting number: 743057814 Meeting password: newpsi-1 Host: Alan Berkema 1(916)7855605 -------------- next part -------------- A non-text attachment was scrubbed... Name: psi reqs figs 2.pdf Type: application/octet-stream Size: 62715 bytes Desc: not available Url : http://www.pwg.org/archives/ps/attachments/20030825/4df6685c/psireqsfigs2.obj From imcdonald at sharplabs.com Tue Aug 26 14:19:36 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:11 2009 Subject: PS> PSI conformance requirements draft Message-ID: <116DB56CD7DED511BC7800508B2CA537B0017E@mailsrvnt02.enet.sharplabs.com> Hi folks, Tuesday (26 August 2003) Below is a first draft of section 10 "Conformance" for the PSI Spec, per my action item at today's PSI telecon. PLEASE send comments and corrections ASAP. We need to get a completed draft of the PSI spec out by 19 September, for review at the PWG face-to-face in New York in early October. Cheers, - Ira McDonald High North Inc ----------------------------------------------- 10. Conformance This section specifies the conformance requirements (necessary for basic interoperability) and conformance recommendations (useful for improved interoperability) for all implementations of the PSI/1.0 protocol. 10.1 PSI/1.0 Common Conformance The following common conformance REQUIREMENTS apply to every PSI/1.0 implementation (Client, Print Service, or Target Device). Every PSI/1.0 implementation: (1) MUST publish the role-independent checklist of conformance claims, in product installation and product packaging literature, as defined in this section 10.1; (2) MUST publish the role-specific checklist of conformance claims, in product installation and product packaging literature, as defined in applicable sections 10.2, 10.3, and/or 10.4 below; (3) MUST support [SOAP1.1] and [WSDL1.1]; (4) MUST support the [HTTP/1.1] binding of [SOAP/1.1]; (5) MUST support the Printer Object and all mandatory elements as defined in section 7.1; (6) MUST support the Job Object and all mandatory elements as defined in section 7.2; (7) MUST support the Document Object and all mandatory elements as defined in section 7.3; (8) MUST support pwg-psips and pwg-psitd URL schemes for Target Devices, as defined in section 8.2.4; (9) MUST support the http URL scheme for References, as defined in section 8.3.1. The following common conformance RECOMMENDATIONS apply to every PSI/1.0 implementation (Client, Print Service, or Target Device). Every PSI/1.0 implementation: (1) SHOULD support [SOAP1.2] and [WSDL1.2]; (2) SHOULD support non-HTTP bindings of [SOAP1.1] or later SOAP versions; (3) SHOULD support device discovery via the PSI Service Root URL as defined in section 5.1; (4) SHOULD support device discovery for specific supported environments, for example using [SLP2.0]; (5) SHOULD support secure sessions over [TLS1.0] or later TLS versions, as defined in section 5.2; (6) SHOULD support the ipp URL scheme for Target Devices, as defined in section 8.2.5; (7) SHOULD support the ftp URL scheme for References, as defined in section 8.3.2. 10.2 PSI/1.0 Client Conformance The following conformance REQUIREMENTS apply to a PSI/1.0 Client. Every PSI/1.0 Client implementation: (1) MUST support the client role in the QueryEndPointsInterface, for access to PSI/1.0 Print Services and PSI/1.0 Target Devices, as defined in section 5.3; (2) MUST support the client role in the ServiceCapabilitesInterface, for access to PSI/1.0 Print Services and PSI/1.0 Target Devices, as defined in section 5.4; (3) MUST support the client role in the JobControlInterface, for access to PSI/1.0 Print Services and PSI/1.0 Target Devices, as defined in section 5.5. 10.3 PSI/1.0 Print Service Conformance The following conformance REQUIREMENTS apply to a PSI/1.0 Print Service. Every PSI/1.0 Print Service implementation: (1) MUST support the client role in the QueryEndPointsInterface, for access to PSI/1.0 Print Services and PSI/1.0 Target Devices, as defined in section 5.3; (2) MUST support the client role in the ServiceCapabilitesInterface, for access to PSI/1.0 Print Services and PSI/1.0 Target Devices, as defined in section 5.4; (3) MUST support the client role in the JobControlInterface, for access to PSI/1.0 Print Services and PSI/1.0 Target Devices, as defined in section 5.5; (4) MUST support the server role in the QueryEndPointsInterface, for access from PSI/1.0 Clients and PSI/1.0 Target Devices, as defined in section 5.3; (5) MUST support the server role in the ServiceCapabilitesInterface, for access from PSI/1.0 Clients and PSI/1.0 Target Devices, as defined in section 5.4; (6) MUST support the server role in the JobControlInterface, for access from PSI/1.0 Clients and PSI/1.0 Target Devices, as defined in section 5.5; (7) MUST support the server role in the TargetDeviceSupportInterface, for access from PSI/1.0 Target Devices, as defined in section 5.6. 10.4 PSI/1.0 Target Device Conformance The following conformance REQUIREMENTS apply to a PSI/1.0 Target Device. Every PSI/1.0 Target Device implementation: (1) MUST support the client role in the QueryEndPointsInterface, for access to PSI/1.0 Print Services, as defined in section 5.3; (2) MUST support the client role in the ServiceCapabilitesInterface, for access to PSI/1.0 Print Services, as defined in section 5.4; (3) MUST support the client role in the JobControlInterface, for access to PSI/1.0 Print Services, as defined in section 5.5; (4) MUST support the server role in the QueryEndPointsInterface, for access from PSI/1.0 Clients and PSI/1.0 Print Services, as defined in section 5.3; (5) MUST support the server role in the ServiceCapabilitesInterface, for access from PSI/1.0 Clients and PSI/1.0 Print Services, as defined in section 5.4; (6) MUST support the server role in the JobControlInterface, for access from PSI/1.0 Clients and PSI/1.0 Print Services, as defined in section 5.5; (7) MUST support the client role in the TargetDeviceSupportInterface, for access to PSI/1.0 Print Services, as defined in section 5.6. From alan.berkema at hp.com Tue Aug 26 16:17:39 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:11 2009 Subject: PS> [PSI] Next Call 09/09/03 Message-ID: <0806DAA43B1555479D53B58675D3468345842D@xrose01.rose.hp.com> Teleconference details: NEXT: Tuesday Septemebr 9 2003 (USA) NO Call 09/02/2003 (Day after Labor day) Time: 8:00AM (US PDT) Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Review Requirements Doc Changes ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting number: 743057814 Meeting password: newpsi-1 Host: Alan Berkema 1(916)7855605 From alan.berkema at hp.com Tue Aug 26 16:34:28 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:11 2009 Subject: PS> [PSI]: Schedule & Actions from Mtg. 8/26/03 Message-ID: <0806DAA43B1555479D53B58675D3468345842E@xrose01.rose.hp.com> PSI Working Group: *Alan Berkema *Dave Hall *Ira McDonald *Jerry Thrasher *Harry Lewis Ted Tronson Peter Mierau *Peter Zehler Gail Songer Paul Tykodi Bob Taylor Lee Farrell Don Wright * = attendance 08/26/03 Agenda 1) Review updated Use Model Diagrams 2) Schedule & Actions Minutes: 1) Review updated Use Model Diagrams Only a few minor changes to the Use Model Diagram which will appear in the next version of the PSI MRD doc. 2) Schedule & Actions 08/26/03 - Ira e-mail conformance requirements draft 09/05/03 - Alan distribute updated PSI MRD 09/09/03 - Discuss reviewer comments of updated PSI MRD 09/09/03 - Discuss reviewer comments of conformance requirements draft 09/12/03 - Dave distribute updated PSI spec. 09/16/03 - Discuss reviewer comments of updated PSI spec. 09/19/03 - Incorporate reviewer comments and Last Call candidate PSI MRD 09/19/03 - Incorporate reviewer comments and Last Call candidate PSI spec. 10/07/03 - F2F review of PSI spec and MRD 10/17/03 - Post F2F reviewed PSI spec and MRD for 10 day Last Call Thanks, Alan From imcdonald at sharplabs.com Tue Aug 26 18:18:54 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:11 2009 Subject: PS> Reminder about PSI Reqs filename Message-ID: <116DB56CD7DED511BC7800508B2CA537B00181@mailsrvnt02.enet.sharplabs.com> Hi Alan, A reminder. Please name the file containing your upcoming PSI Requirements draft as follows: wd-psireq10-200309xx.pdf/doc The adopted document will eventually be published (according to Process/2.0): req-psireq10-2003yyxx.pdf/doc Cheers, - Ira McDonald High North Inc From imcdonald at sharplabs.com Tue Aug 26 18:59:19 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:11 2009 Subject: PS> W3C drafts - Web Svcs Architecture and Glossary Message-ID: <116DB56CD7DED511BC7800508B2CA537B00182@mailsrvnt02.enet.sharplabs.com> Hi folks, Both of these documents are very well worth reading: http://www.w3.org/TR/2003/WD-ws-arch-20030808/ http://www.w3.org/TR/2003/WD-ws-gloss-20030808/ The glossary contains good definitions of a number of useful terms (Dave Hall and Alan Berkema, take note). Cheers, - Ira McDonald High North Inc From alan.berkema at hp.com Fri Sep 5 14:41:40 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:11 2009 Subject: PS> [PSI]: New MRD Message-ID: <0806DAA43B1555479D53B58675D3468345848D@xrose01.rose.hp.com> Here is my action for Tuesday, Sorry I do not have time to post. Alan <> -------------- next part -------------- A non-text attachment was scrubbed... Name: wd-psireq10-200309xx.pdf Type: application/octet-stream Size: 182224 bytes Desc: not available Url : http://www.pwg.org/archives/ps/attachments/20030905/23cce3f8/wd-psireq10-200309xx.obj From imcdonald at sharplabs.com Sun Sep 7 19:37:43 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:11 2009 Subject: PS> [PSI]: [Posted] New MRD Message-ID: <116DB56CD7DED511BC7800508B2CA537B00196@mailsrvnt02.enet.sharplabs.com> Hi, New PSI Requirements spec posted at: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psireq10-200309xx.pdf Cheers, - Ira McDonald High North Inc -----Original Message----- From: BERKEMA,ALAN C (HP-Roseville,ex1) [mailto:alan.berkema@hp.com] Sent: Friday, September 05, 2003 2:42 PM To: 'a PSI pwg.org' Subject: PS> [PSI]: New MRD Here is my action for Tuesday, Sorry I do not have time to post. Alan <> From imcdonald at sharplabs.com Mon Sep 8 21:08:02 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:11 2009 Subject: PS> FW: draft-black-snmp-uri-00.txt Message-ID: <116DB56CD7DED511BC7800508B2CA537B00199@mailsrvnt02.enet.sharplabs.com> Hi folks, FYI - a new SNMP URI scheme draft - worth looking at: ftp://ftp.ietf.org/internet-drafts/draft-black-snmp-uri-00.txt Cheers, - Ira McDonald High North Inc -----Original Message----- From: Paul Hoffman / IMC [mailto:phoffman@imc.org] Sent: Monday, September 08, 2003 2:44 PM To: uri@w3.org Subject: draft-black-snmp-uri-00.txt There's a new URI document, draft-black-snmp-uri-00.txt, which discusses a URI for the SNMP protocol. The author of the draft is on this list but apparently unable to post. He's open for comments. --Paul Hoffman, Director --Internet Mail Consortium From imcdonald at sharplabs.com Tue Sep 9 11:00:28 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:11 2009 Subject: PS> FW: Latest PSI Specifiecation Message-ID: <116DB56CD7DED511BC7800508B2CA537B0019D@mailsrvnt02.enet.sharplabs.com> Hi, Posted in ZIP only (doc and pdf to follow) due to time constraints: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030729.zip Cheers, - Ira -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Tuesday, September 09, 2003 10:50 AM To: 'McDonald, Ira' Subject: FW: Latest PSI Specifiecation Don't know if this made it through the reflector.. Dave -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) Sent: Tuesday, September 09, 2003 7:37 AM To: 'ps@pwg.org' Subject: Latest PSI Specifiecation Sorry for the late update - Here is the latest (as of 07/29!! - Has it been that long already?) Dave From harryl at us.ibm.com Tue Sep 9 12:42:47 2003 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:02:11 2009 Subject: PS> Mandatory binding Message-ID: During today's conference call the topic of a mandatory binding came up. We would prefer to publish the interface and binding WSDL separately and define a discovery method. We're not sure if UDDI is too coarse a discovery method for this purpose. ---------------------------------------------- Harry Lewis Chairman - IEEE-ISTO Printer Working Group http://www.pwg.org IBM Printing Systems http://www.ibm.com/printers 303-924-5337 ---------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/ps/attachments/20030909/dc844444/attachment.html From imcdonald at sharplabs.com Tue Sep 9 13:59:03 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:11 2009 Subject: PS> Posted latest PSI Specification (20030729) Message-ID: <116DB56CD7DED511BC7800508B2CA537B0019E@mailsrvnt02.enet.sharplabs.com> Hi, Now available on the FTP site at: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030729.pdf (PDF without revision marks) ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030729.doc (MS Word source but READ-ONLY copy from ZIP file) (Note that the file dates are today (20030909), but this is Dave's end-of-July most recent text). Cheers, - Ira McDonald High North Inc -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Tuesday, September 09, 2003 11:00 AM To: 'ps@pwg.org' Subject: PS> FW: Latest PSI Specifiecation Hi, Posted in ZIP only (doc and pdf to follow) due to time constraints: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030729.zip Cheers, - Ira -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Tuesday, September 09, 2003 10:50 AM To: 'McDonald, Ira' Subject: FW: Latest PSI Specifiecation Don't know if this made it through the reflector.. Dave -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) Sent: Tuesday, September 09, 2003 7:37 AM To: 'ps@pwg.org' Subject: Latest PSI Specifiecation Sorry for the late update - Here is the latest (as of 07/29!! - Has it been that long already?) Dave From imcdonald at sharplabs.com Tue Sep 9 14:11:38 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:11 2009 Subject: PS> Revised PSI conformance requirements draft (9 Sept) Message-ID: <116DB56CD7DED511BC7800508B2CA537B0019F@mailsrvnt02.enet.sharplabs.com> Hi folks, Tuesday (9 September 2003) Below is a second draft of section 10 "Conformance" for the PSI Spec, revised after our partial review at today's PSI telecon. Dave Hall now plans to get a completed draft of the PSI spec out by 26 September, for review at the PWG face-to-face in New York on 7 October. Changes to section 10.1 from first draft (26 August): (1) Added new sentence to first paragraph (about documentation); (2) Moved the first two requirements (documentation) in section 10.1 to a new paragraph for product literature recommendations; (3) Added new requirements and recommendations for XML and WSDL; (4) Added three new 'Rationale' paragraphs to section 10.1 (explaining the choices of requirement versus recommandation); (5) Rewrote several requirements and recommendations for clarity. Comments? Cheers, - Ira McDonald High North Inc ----------------------------------------------- 10. Conformance This section specifies the conformance requirements (necessary for basic interoperability) and conformance recommendations (useful for improved interoperability) for all implementations of the PSI/1.0 protocol. This section also specifies the conformance recommentations for PSI product literature (useful for informed customer purchasing decisions). 10.1 PSI/1.0 Common Conformance The following common conformance REQUIREMENTS apply to every PSI/1.0 implementation (Client, Print Service, or Target Device). Every PSI/1.0 implementation: (1) MUST support (produce and consume) valid [XML1.0] documents; (2) MUST support (publish URLs for) valid [WSDL1.1] interfaces; (3) MUST support (produce and consume) valid [SOAP1.1] messages; (4) MUST support the [HTTP/1.1] binding of [SOAP/1.1]; (5) MUST support the Printer Object and all mandatory elements, as defined in section 7.1; (6) MUST support the Job Object and all mandatory elements, as defined in section 7.2; (7) MUST support the Document Object and all mandatory elements, as defined in section 7.3; (8) MUST support pwg-psips and pwg-psitd URL schemes for Target Devices, as defined in section 8.2.4; (9) MUST support the http URL scheme for References, as defined in section 8.3.1. Rationale: Customers should be able to purchase PSI-based products with basic interoperability guaranteed for those PSI products. The following common conformance RECOMMENDATIONS apply to every PSI/1.0 implementation (Client, Print Service, or Target Device). Every PSI/1.0 implementation: (1) SHOULD support [XML1.1] or later XML versions; (2) SHOULD support [WSDL1.2] or later WSDL versions; (3) SHOULD support [SOAP1.2] or later SOAP versions; (4) SHOULD support non-HTTP bindings of [SOAP1.1] or later SOAP versions; (5) SHOULD support device discovery via the PSI Service Root URL as defined in section 5.1; (6) SHOULD support device discovery for specific supported environments, for example using [SLP2.0]; (7) SHOULD support secure sessions over [TLS1.0] or later TLS versions, as defined in section 5.2; (8) SHOULD support the ipp URL scheme for Target Devices, as defined in section 8.2.5; (9) SHOULD support the ftp URL scheme for References, as defined in section 8.3.2. Rationale: Customers should be able to purchase PSI-based products with improved interoperability probable for those PSI products. The following common conformance RECOMMENDATIONS apply to product literature. All products that claim PSI/1.0 conformance: (1) SHOULD publish the role-independent checklist of conformance claims, as defined in applicable paragraphs of this section 10.1 above, in installation, packaging, or other literature (e.g., Web pages); (2) SHOULD publish the role-specific checklist of conformance claims, as defined in applicable sections 10.2, 10.3, and/or 10.4 below, in installation, packaging, or other literature (e.g., Web pages). Rationale: Customers should be able to purchase PSI-based products with specific interoperability verified for those PSI products. 10.2 PSI/1.0 Client Conformance The following conformance REQUIREMENTS apply to a PSI/1.0 Client. Every PSI/1.0 Client implementation: (1) MUST support the client role in the QueryEndPointsInterface, for access to PSI/1.0 Print Services and PSI/1.0 Target Devices, as defined in section 5.3; (2) MUST support the client role in the ServiceCapabilitesInterface, for access to PSI/1.0 Print Services and PSI/1.0 Target Devices, as defined in section 5.4; (3) MUST support the client role in the JobControlInterface, for access to PSI/1.0 Print Services and PSI/1.0 Target Devices, as defined in section 5.5. 10.3 PSI/1.0 Print Service Conformance The following conformance REQUIREMENTS apply to a PSI/1.0 Print Service. Every PSI/1.0 Print Service implementation: (1) MUST support the client role in the QueryEndPointsInterface, for access to PSI/1.0 Print Services and PSI/1.0 Target Devices, as defined in section 5.3; (2) MUST support the client role in the ServiceCapabilitesInterface, for access to PSI/1.0 Print Services and PSI/1.0 Target Devices, as defined in section 5.4; (3) MUST support the client role in the JobControlInterface, for access to PSI/1.0 Print Services and PSI/1.0 Target Devices, as defined in section 5.5; (4) MUST support the server role in the QueryEndPointsInterface, for access from PSI/1.0 Clients and PSI/1.0 Target Devices, as defined in section 5.3; (5) MUST support the server role in the ServiceCapabilitesInterface, for access from PSI/1.0 Clients and PSI/1.0 Target Devices, as defined in section 5.4; (6) MUST support the server role in the JobControlInterface, for access from PSI/1.0 Clients and PSI/1.0 Target Devices, as defined in section 5.5; (7) MUST support the server role in the TargetDeviceSupportInterface, for access from PSI/1.0 Target Devices, as defined in section 5.6. 10.4 PSI/1.0 Target Device Conformance The following conformance REQUIREMENTS apply to a PSI/1.0 Target Device. Every PSI/1.0 Target Device implementation: (1) MUST support the client role in the QueryEndPointsInterface, for access to PSI/1.0 Print Services, as defined in section 5.3; (2) MUST support the client role in the ServiceCapabilitesInterface, for access to PSI/1.0 Print Services, as defined in section 5.4; (3) MUST support the client role in the JobControlInterface, for access to PSI/1.0 Print Services, as defined in section 5.5; (4) MUST support the server role in the QueryEndPointsInterface, for access from PSI/1.0 Clients and PSI/1.0 Print Services, as defined in section 5.3; (5) MUST support the server role in the ServiceCapabilitesInterface, for access from PSI/1.0 Clients and PSI/1.0 Print Services, as defined in section 5.4; (6) MUST support the server role in the JobControlInterface, for access from PSI/1.0 Clients and PSI/1.0 Print Services, as defined in section 5.5; (7) MUST support the client role in the TargetDeviceSupportInterface, for access to PSI/1.0 Print Services, as defined in section 5.6. From imcdonald at sharplabs.com Tue Sep 9 14:41:36 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:11 2009 Subject: PS> Mandatory binding Message-ID: <116DB56CD7DED511BC7800508B2CA537B001A2@mailsrvnt02.enet.sharplabs.com> Hi, To clarify a little... PSI conformance print services and target devices MUST publish URLs for the WSDL for each of their supported interfaces (see my revised conformance requirements message earlier today). Tools exist that convert WSDL to appropriate SOAP messages. A "SOAP binding" is a definition of SOAP message _transport_ over HTTP, SMTP, BEEP, or whatever (those three are currently standardized). For interoperability, clients and servers need to be able to consume and validate published WSDL definitions of other PSI servers. For interoperability, all PSI/1.0 clients and servers MUST support the HTTP/1.1 transport binding of SOAP/1.1. Separately, PSI/1.0 doesn't (yet) require support for UDDI based discovery. I question the desirability of adding a UDDI infrastructure dependence to all PSI/1.0 implementations. Cheers, - Ira McDonald High North Inc -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, September 09, 2003 12:43 PM To: ps@pwg.org Subject: PS> Mandatory binding During today's conference call the topic of a mandatory binding came up. We would prefer to publish the interface and binding WSDL separately and define a discovery method. We're not sure if UDDI is too coarse a discovery method for this purpose. ---------------------------------------------- Harry Lewis Chairman - IEEE-ISTO Printer Working Group http://www.pwg.org IBM Printing Systems http://www.ibm.com/printers 303-924-5337 ---------------------------------------------- From harryl at us.ibm.com Tue Sep 9 14:49:22 2003 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:02:11 2009 Subject: PS> Mandatory binding In-Reply-To: <116DB56CD7DED511BC7800508B2CA537B001A2@mailsrvnt02.enet.sharplabs.com> Message-ID: I guess we're saying it is not really necessary for interoperability that all PSI/1.0 clients and servers MUST support the HTTP/1.1 transport binding when the WSDL can call out the binding. ---------------------------------------------- Harry Lewis Chairman - IEEE-ISTO Printer Working Group http://www.pwg.org IBM Printing Systems http://www.ibm.com/printers 303-924-5337 ---------------------------------------------- "McDonald, Ira" 09/09/2003 12:41 PM To Harry Lewis/Boulder/IBM@IBMUS, ps@pwg.org cc Subject RE: PS> Mandatory binding Hi, To clarify a little... PSI conformance print services and target devices MUST publish URLs for the WSDL for each of their supported interfaces (see my revised conformance requirements message earlier today). Tools exist that convert WSDL to appropriate SOAP messages. A "SOAP binding" is a definition of SOAP message _transport_ over HTTP, SMTP, BEEP, or whatever (those three are currently standardized). For interoperability, clients and servers need to be able to consume and validate published WSDL definitions of other PSI servers. For interoperability, all PSI/1.0 clients and servers MUST support the HTTP/1.1 transport binding of SOAP/1.1. Separately, PSI/1.0 doesn't (yet) require support for UDDI based discovery. I question the desirability of adding a UDDI infrastructure dependence to all PSI/1.0 implementations. Cheers, - Ira McDonald High North Inc -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, September 09, 2003 12:43 PM To: ps@pwg.org Subject: PS> Mandatory binding During today's conference call the topic of a mandatory binding came up. We would prefer to publish the interface and binding WSDL separately and define a discovery method. We're not sure if UDDI is too coarse a discovery method for this purpose. ---------------------------------------------- Harry Lewis Chairman - IEEE-ISTO Printer Working Group http://www.pwg.org IBM Printing Systems http://www.ibm.com/printers 303-924-5337 ---------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/ps/attachments/20030909/b896deec/attachment.html From imcdonald at sharplabs.com Mon Sep 15 19:55:42 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:11 2009 Subject: PS> PSI call on Tues 16 Sept?? Message-ID: <116DB56CD7DED511BC7800508B2CA537B001B0@mailsrvnt02.enet.sharplabs.com> Hi, My notes didn't capture this. Is there a PSI telecon tomorrow? I believe the answer is yes. Agenda: (a) continue to review revised PSI section 10 Conformance Requirements that I sent out last Tuesday (9 Sept); (b) review Alan's updated MRD. Right? Cheers, - Ira McDonald High North Inc From alan.berkema at hp.com Tue Sep 16 10:38:38 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:11 2009 Subject: PS> [PSI] Next Call 09/16/03 Message-ID: <0806DAA43B1555479D53B58675D346834584D5@xrose01.rose.hp.com> Teleconference details: NEXT: Tuesday Septemebr 16 2003 (USA) Time: 8:00AM (US PDT) Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Review Requirements Doc Changes ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting number: 743057814 Meeting password: newpsi-1 Host: Alan Berkema 1(916)7855605 From alan.berkema at hp.com Tue Sep 16 10:49:16 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:11 2009 Subject: PS> PSI call on Tues 16 Sept?? Message-ID: <0806DAA43B1555479D53B58675D346834584D7@xrose01.rose.hp.com> Yes, just sent out same numbers, thought I did this before? Your agenda is works for me. Alan -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Monday, September 15, 2003 4:56 PM To: 'ps@pwg.org' Subject: PS> PSI call on Tues 16 Sept?? Hi, My notes didn't capture this. Is there a PSI telecon tomorrow? I believe the answer is yes. Agenda: (a) continue to review revised PSI section 10 Conformance Requirements that I sent out last Tuesday (9 Sept); (b) review Alan's updated MRD. Right? Cheers, - Ira McDonald High North Inc From alan.berkema at hp.com Tue Sep 16 12:45:25 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:11 2009 Subject: PS> [PSI] New Day / New Time : Next Call 09/22/03 Message-ID: <0806DAA43B1555479D53B58675D346834584D9@xrose01.rose.hp.com> One Time Change: Teleconference details: NEXT: Monday Septemebr 22 2003 (USA) NO Call 9/30/03 Date before F2F Time: 9:00AM (US PDT) Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Review Conformance Specs (see Ira's e-mail) 2) Review Requirements Doc Changes especially section 5 & 6 ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting number: 743057814 Meeting password: newpsi-1 Host: Alan Berkema 1(916)7855605 From imcdonald at sharplabs.com Mon Sep 22 11:21:06 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:11 2009 Subject: PS> [PSI] Mon 22 Sept - New Day / New Time ONCE Message-ID: <116DB56CD7DED511BC7800508B2CA537B001BD@mailsrvnt02.enet.sharplabs.com> Hi, Just a reminder that this week's PSI telecon is in 40 minutes today! Cheers, - Ira -----Original Message----- From: BERKEMA,ALAN C (HP-Roseville,ex1) [mailto:alan.berkema@hp.com] Sent: Tuesday, September 16, 2003 12:45 PM To: 'a PSI pwg.org' Subject: PS> [PSI] Mon 22 Sept - New Day / New Time ONCE One Time Change: Teleconference details: NEXT: Monday Septemebr 22 2003 (USA) NO Call 9/30/03 Date before F2F Time: 9:00AM (US PDT) Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Review Conformance Specs (see Ira's e-mail) 2) Review Requirements Doc Changes especially section 5 & 6 ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting number: 743057814 Meeting password: newpsi-1 Host: Alan Berkema 1(916)7855605 From imcdonald at sharplabs.com Mon Sep 22 15:08:48 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:11 2009 Subject: PS> Section 10 Conformance - final draft (22 Sept) Message-ID: <116DB56CD7DED511BC7800508B2CA537B001BE@mailsrvnt02.enet.sharplabs.com> Hi folks, Monday (22 September 2003) Below is a third draft of section 10 "Conformance", revised per our review at today's PSI telecon, to be folded into the PSI Spec. Dave Hall now plans to get a completed draft of the PSI spec out by 26 September, for review at the PWG face-to-face in New York on Tuesday (7 October). We plan to have _all_day_ dial-in to the PSI face-to-face. Dave - the issues are labelled 'ISSUE[01/02/03]' - please fixup numbers. Dave - MOST conformance requirements/recommendations in all other spec sections (like 5.x) should probably be DELETED - so that the conformance is specified in accurate detail in sections 10.x only. Comments? Cheers, - Ira McDonald High North Inc ----------------------------------------------- Changes for third draft (22 Sept) from second draft (9 Sept): (1) Divided section 10.1 into 10.1.1, 10.1.2, 10.1.3, for clarity; (2) Added two issues to section 10.1.1 about pwg-psixx and http URLs; (3) Removed reference to WSDL/1.2 from section 10.1.2 item(2), per Jerry Thrasher comment that the next WSDL version may in fact be 2.0; (4) Moved former section 10.1.2 item (5) (PSI Service Root URL) and divided into sections 10.2, 10.3, 10.4, per PSI telecon concensus; (5) Reworded current section 10.1.2 item (5) (specific device discovery) to replace reference to SLP/2.0 with "Windows, Netware...". (6) Divided section 10.2 into 10.2.1 and 10.2.2, for clarity; (7) Moved former section 10.2 items (1) and (2) to section 10.2.2, per PSI telecon concensus; (8) Added one issue to section 10.2.2 about QueryEndpointsInterface; (9) Divided section 10.3 into 10.3.1 and 10.3.2, for clarity; (10) Moved former section 10.3 items (1), (2), (3) to section 10.3.2, per PSI telecon concensus; (11) Divided section 10.4 into 10.4.1 and 10.4.2, for clarity; (12) Moved former section 10.4 item (2) to section 10.4.2, per PSI telecon concensus. ----------------------------------------------- 10. Conformance This section specifies the conformance requirements (necessary for basic interoperability) and conformance recommendations (useful for improved interoperability) for all implementations of the PSI/1.0 protocol. This section also specifies the conformance recommentations for PSI product literature (useful for informed customer purchasing decisions). 10.1 PSI/1.0 Common Conformance 10.1.1 PSI/1.0 Common Implementation Requirements The following common conformance REQUIREMENTS apply to every PSI/1.0 implementation (Client, Print Service, or Target Device). Every PSI/1.0 implementation: (1) MUST support (produce and consume) valid [XML1.0] documents; (2) MUST support (produce and/or consume) valid [WSDL1.1] interfaces; (3) MUST support (produce and consume) valid [SOAP1.1] messages; (4) MUST support the [HTTP/1.1] binding of [SOAP/1.1]; (5) MUST support the Printer Object and all mandatory elements, as defined in section 7.1; (6) MUST support the Job Object and all mandatory elements, as defined in section 7.2; (7) MUST support the Document Object and all mandatory elements, as defined in section 7.3; (8) MUST support pwg-psips and pwg-psitd URL schemes for Target Devices, as defined in section 8.2.4; (9) MUST support the http URL scheme for References, as defined in section 8.3.1. Rationale: Customers should be able to purchase PSI-based products with basic interoperability guaranteed for those PSI products. ISSUE 01: Should item (8) above (pwg-psips/td target device URL support) be changed to SHOULD (recommendation), because the first PSI Print Services will only talk to Target Devices (printers) via existing print protocols (IPP, LPR, etc.). ISSUE 02: Should item (9) above (http reference URL support) be changed to SHOULD (recommendation), at least for PSI Clients (so that reference printing need not be implemented by clients). 10.1.2 PSI/1.0 Common Implementation Recommendations The following common conformance RECOMMENDATIONS apply to every PSI/1.0 implementation (Client, Print Service, or Target Device). Every PSI/1.0 implementation: (1) SHOULD support [XML1.1] or later XML versions; (2) SHOULD support later WSDL versions; (3) SHOULD support [SOAP1.2] or later SOAP versions; (4) SHOULD support non-HTTP bindings (SMTP, BEEP, etc.) of [SOAP1.1] or later SOAP versions; (5) SHOULD support native device discovery for the implementation's supported environments (Windows, NetWare, UNIX, Linux, etc.); (6) SHOULD support secure sessions over [TLS1.0] or later TLS versions, as defined in section 5.2; (7) SHOULD support the ipp URL scheme for Target Devices, as defined in section 8.2.5; (8) SHOULD support the ftp URL scheme for References, as defined in section 8.3.2. Rationale: Customers should be able to purchase PSI-based products with improved interoperability probable for those PSI products. 10.1.3 PSI/1.0 Common Literature Recommendations The following common conformance RECOMMENDATIONS apply to product literature. All products that claim PSI/1.0 conformance: (1) SHOULD publish the role-independent checklist of conformance claims, as defined in applicable paragraphs of this section 10.1 above, in installation, packaging, or other literature (e.g., Web pages); (2) SHOULD publish the role-specific checklist of conformance claims, as defined in applicable sections 10.2, 10.3, and/or 10.4 below, in installation, packaging, or other literature (e.g., Web pages). Rationale: Customers should be able to purchase PSI-based products with specific interoperability verified for those PSI products. 10.2 PSI/1.0 Client Conformance 10.2.1 PSI/1.0 Client Requirements The following conformance REQUIREMENTS apply to a PSI/1.0 Client. Every PSI/1.0 Client implementation: (1) MUST support the client role in the JobControlInterface, for access to PSI/1.0 Print Services and PSI/1.0 Target Devices, as defined in section 5.5. 10.2.2 PSI/1.0 Client Recommendations The following conformance RECOMMENDATIONS apply to a PSI/1.0 Client. Every PSI/1.0 Client implementation: (1) SHOULD support the client role in the QueryEndPointsInterface, for access to PSI/1.0 Print Services and PSI/1.0 Target Devices, as defined in section 5.3; (2) SHOULD support the client role in the ServiceCapabilitesInterface, for access to PSI/1.0 Print Services and PSI/1.0 Target Devices, as defined in section 5.4; (3) SHOULD support device discovery via the PSI Service Root URL as defined in section 5.1. ISSUE 03: Should item (1) above (QueryEndPointsInterface) be changed to MUST (requirement), because dynamic discovery of JobControlInterface may not be easy without this additional step 10.3 PSI/1.0 Print Service Conformance 10.3.1 PSI/1.0 Print Service Requirements The following conformance REQUIREMENTS apply to a PSI/1.0 Print Service. Every PSI/1.0 Print Service implementation: (1) MUST support the server role in the QueryEndPointsInterface, for access from PSI/1.0 Clients and PSI/1.0 Target Devices, as defined in section 5.3; (2) MUST support the server role in the ServiceCapabilitesInterface, for access from PSI/1.0 Clients and PSI/1.0 Target Devices, as defined in section 5.4; (3) MUST support the server role in the JobControlInterface, for access from PSI/1.0 Clients and PSI/1.0 Target Devices, as defined in section 5.5; (4) MUST support the server role in the TargetDeviceSupportInterface, for access from PSI/1.0 Target Devices, as defined in section 5.6; (5) MUST support device discovery via the PSI Service Root URL as defined in section 5.1. 10.3.2 PSI/1.0 Print Service Recommendations The following conformance RECOMMENDATIONS apply to a PSI/1.0 Print Service. Every PSI/1.0 Print Service implementation: (1) SHOULD support the client role in the QueryEndPointsInterface, for access to PSI/1.0 Print Services and PSI/1.0 Target Devices, as defined in section 5.3; (2) SHOULD support the client role in the ServiceCapabilitesInterface, for access to PSI/1.0 Print Services and PSI/1.0 Target Devices, as defined in section 5.4; (3) SHOULD support the client role in the JobControlInterface, for access to PSI/1.0 Print Services and PSI/1.0 Target Devices, as defined in section 5.5. 10.4 PSI/1.0 Target Device Conformance 10.4.1 PSI/1.0 Target Device Requirements The following conformance REQUIREMENTS apply to a PSI/1.0 Target Device. Every PSI/1.0 Target Device implementation: (1) MUST support the client role in the QueryEndPointsInterface, for access to PSI/1.0 Print Services, as defined in section 5.3; (2) MUST support the client role in the JobControlInterface, for access to PSI/1.0 Print Services, as defined in section 5.5; (3) MUST support the client role in the TargetDeviceSupportInterface, for access to PSI/1.0 Print Services, as defined in section 5.6; (4) MUST support the server role in the QueryEndPointsInterface, for access from PSI/1.0 Clients and PSI/1.0 Print Services, as defined in section 5.3; (5) MUST support the server role in the ServiceCapabilitesInterface, for access from PSI/1.0 Clients and PSI/1.0 Print Services, as defined in section 5.4; (6) MUST support the server role in the JobControlInterface, for access from PSI/1.0 Clients and PSI/1.0 Print Services, as defined in section 5.5; (7) MUST support device discovery via the PSI Service Root URL as defined in section 5.1. 10.4.2 PSI/1.0 Target Device Recommendations The following conformance RECOMMENDATIONS apply to a PSI/1.0 Target Device. Every PSI/1.0 Target Device implementation: (1) SHOULD support the client role in the ServiceCapabilitesInterface, for access to PSI/1.0 Print Services, as defined in section 5.4. From alan.berkema at hp.com Wed Sep 24 15:27:17 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:11 2009 Subject: PS> [PSI]: Oct 7 Mtg Agenda/Logistics Message-ID: <0806DAA43B1555479D53B58675D346830354FDD5@xrose01.rose.hp.com> NO Call 09/30/2003 This meeting will Use Webex and Teleconference, Harry is still checking to insure the room has LAN. Jerry will bring a Polycom, Harry will bring an Access Point (and Polycom ?)and I will bring a hub. The meeting will begin at 8:30AM Eastern Time, Heads up, that means 5:30AM West Coast, for those that couldn't travel. ** All Documents Posted on 9/26/2003 ** Agenda: o 8:00 AM - Coffee o 8:30 AM - Review Agenda o Introductions o Accept minutes From Last Mtg o Brief Overview of where we are, where we are going o 9:00 AM Review Requirements Document o 11:00 AM - Review PSI Spec. o 12:00 PM - Lunch - West Coast folks drive to work if needed o 1:00 PM - Continue Spec Review until Finished (~5:00 PM) Phone Bridge : TBD ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting number: 742003126 Meeting password: newpsi-1 Host: Alan Berkema 1(916)7855605 Alan Berkema Senior Engineer Scientist Connectivity Roseville, CA Hewlett-Packard Company 916 785-5605 Phone aberkema@hp.com From alan.berkema at hp.com Wed Sep 24 18:33:22 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:11 2009 Subject: PS> [PSI}: Marketing Requiremets Docs Posted Message-ID: <0806DAA43B1555479D53B58675D346830354FDD7@xrose01.rose.hp.com> ftp://ftp.pwg.org/pub/pwg/ps/wd-psireq10-200309_87.doc ftp://ftp.pwg.org/pub/pwg/ps/wd-psireq10-200309_87.pdf New content is sections 4.n.1 and section 5.1 Thanks, Alan From imcdonald at sharplabs.com Mon Sep 29 16:03:43 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:11 2009 Subject: PS> FW: Latest PSI Spec (26 Sept) Message-ID: <116DB56CD7DED511BC7800508B2CA537B001D4@mailsrvnt02.enet.sharplabs.com> Hi folks, Converted to PDF and stored on the PWG FTP server at: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030926.pdf - Adobe Acrobat version (245 KB) ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030926.doc - MS Word source (1.04 MB) ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030926.zip - ZIP of MS Word source (227 KB) Please review/send comments on this PDF version for the upcoming PSI face-to-face on Tuesday (7 October 2003). Cheers, - Ira McDonald [for Dave Hall, Editor] High North Inc -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Monday, September 29, 2003 2:44 PM To: 'McDonald, Ira' Subject: Latest Spec Hey Ira... Can you create a PDF from the attached word doc, and upload them both? I can't seem to find the username / password combo. Thanks! Dave From alan.berkema at hp.com Thu Oct 2 11:18:57 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:11 2009 Subject: PS> [PSI]: Update: Oct 7 Mtg Agenda/Logistics Message-ID: <0806DAA43B1555479D53B58675D346830354FDFA@xrose01.rose.hp.com> Phone Bridge Info: Dial In: 1-866-365-4406 Toll #: 1-303-248-9655 Passcode: 2635888# ----------------------------------- NO Call 09/30/2003 This meeting will Use Webex and Teleconference, Harry is still checking to insure the room has LAN. Jerry will bring a Polycom, Harry will bring an Access Point (and Polycom ?)and I will bring a hub. The meeting will begin at 8:30AM Eastern Time, Heads up, that means 5:30AM West Coast, for those that couldn't travel. ** All Documents Posted on 9/26/2003 ** Agenda: o 8:00 AM - Coffee o 8:30 AM - Review Agenda o Introductions o Accept minutes From Last Mtg o Brief Overview of where we are, where we are going o 9:00 AM Review Requirements Document o 11:00 AM - Review PSI Spec. o 12:00 PM - Lunch - West Coast folks drive to work if needed o 1:00 PM - Continue Spec Review until Finished (~5:00 PM) Phone Bridge : See Top ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting number: 742003126 Meeting password: newpsi-1 Host: Alan Berkema 1(916)7855605 Alan Berkema Senior Engineer Scientist Connectivity Roseville, CA Hewlett-Packard Company 916 785-5605 Phone aberkema@hp.com From imcdonald at sharplabs.com Tue Oct 7 08:28:12 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:11 2009 Subject: PS> FW: PSI Slides for F2F (7 Oct 2003) Message-ID: <116DB56CD7DED511BC7800508B2CA537B001EC@mailsrvnt02.enet.sharplabs.com> Hi, I just posted Alan's slides for today's PWG PSI face-to-face in NYC (and telecon) to the PWG FTP site at: ftp://ftp.pwg.org/pub/pwg/ps/psi_pwg_overview_20031007.pdf (there are underscores, not spaces, in the simple filename) Cheers, - Ira -----Original Message----- From: BERKEMA,ALAN C (HP-Roseville,ex1) [mailto:alan.berkema@hp.com] Sent: Thursday, October 02, 2003 3:31 PM To: 'Ira McDonald' Subject: PSI Slides for F2F Hey Ira have a look. I am leaving for NY on 10/4 so I may not be able to change it. Hear you are on the road today. Thanks, Alan Alan Berkema Senior Engineer Scientist Connectivity Roseville, CA Hewlett-Packard Company 916 785-5605 Phone aberkema@hp.com From imcdonald at sharplabs.com Tue Oct 14 18:10:34 2003 From: imcdonald at sharplabs.com (Ira McDonald) Date: Wed May 6 14:02:11 2009 Subject: PS> PSI test message Message-ID: <3F8C3C1A.4842.55878E7@localhost> Please ignore - trying to fix my email client, - Ira From imcdonald at sharplabs.com Sun Oct 19 19:32:06 2003 From: imcdonald at sharplabs.com (Ira McDonald) Date: Wed May 6 14:02:11 2009 Subject: PS> Draft of PWG/IANA, I18N, and Security sections Message-ID: <3F92E6B6.23943.AECFA45@localhost> Hi folks, Sunday (21 October 2003) Below is draft text for inclusion in the PSI/10 protocol spec for: - Section 11 "PWG and IANA Considerations" - Section 12 "Internationalization Considerations" - Section 13 "Security Considerations" - Additions to "Normative References" - Additions to "Informative References" Dave - the following section numbers are probably wrong after our face-to-face move of some sections to the 'Conformance' section. Dave - there are a number of normative (MUST or SHOULD) requirements in this new Section 13 "Security Considerations". I suggest we simply add a pointer to these requirements to Section xx 'Conformance'. OK? Comments? Cheers, - Ira McDonald, contributing editor to PSI/1.0 High North Inc ---------------------------------------------------------------------- -- 11. PWG and IANA Considerations This document does not require any new PWG or IANA registration support. The following paragraphs describe some existing PWG, IANA, W3C, and ISO registered standard elements used in PSI/1.0: This PSI/1.0 document uses the existing standard elements of Job and Document objects defined in the PWG Semantic Model [PWG-SM]. The accompanying PSI/1.0 WSDL references schema defined in [PWG-SM]. The [XML] 'encoding' attribute contains a 'charset tag' [RFC2978]. New standard values may be registered according to [RFC2978] in the IANA Registry of Charset Tags [IANA-CHAR]. The [XML] 'lang' attribute contains a 'language tag' [RFC3066], i.e., a 'language code' [ISO639] optionally followed by a hyphen and a 'country code' [ISO3166]. New standard values (other than existing [ISO639] registrations) may be registered according to [RFC3066] in the IANA Registry of Language Tags [IANA-LANG]. The [PWG-SM] 'DocumentNaturalLanguage' element also contains a 'language tag' [RFC3066]. The [PWG-SM] 'DocumentFormat' element contains a MIME (content) media type [RFC2046]. New standard values may be registered according to [RFC2048] in the IANA Registry of Media Types [IANA-MIME]. ---------------------------------------------------------------------- -- 12. Internationalization Considerations PSI/1.0 implementations conform to all the best practice recommendations in "IETF Policy on Character Sets and Languages" [RFC2277]. PSI/1.0 implementations exchange [XML] information based on XML Schema [XSD] defined in the PWG Semantic Model [PWG-SM]. The [XML] 'encoding' attribute (which MUST be supplied by PSI/1.0 Clients) SHOULD be set to 'utf-8' [RFC2279], as recommended by [RFC2277]. The [XML] 'lang' attribute (which SHOULD be supplied by PSI/1.0 Clients) SHOULD be set to a value conforming to [RFC3066], as recommended by [RFC2277]. The [PWG-SM] 'DocumentNaturalLanguage' element (which SHOULD be suppled by PSI/1.0 Clients) SHOULD be set to a value conforming to [RFC3066], as recommended by [RFC2277]. ---------------------------------------------------------------------- -- 13. Security Considerations This section describes the security threats against PSI/1.0 clients and servers. This section specifies the security conformance requirements and recommendations for PSI/1.0 implementations. This section addresses most security issues by reference to applicable underlying protocol specifications, for example, [SOAP1.1], [HTTP1.1] and [TLS]. 13.1 Internet Threat Model This section is adapted from section 3 of "Guidelines for Writing RFC Text on Security Considerations" [RFC3552]. In the Internet threat model, we assume that the end-systems engaging in a protocol exchange have not themselves been compromised. Protecting against an attack when of the end-systems has itself been compromised is extraordinarily difficult. By contrast, we assume that the attacker has nearly complete control of the communications channel over which the end-systems communicate. This means that the attacker can read any PDU (Protocol Data Unit) on the network and undetectably remove, change, or inject forged packets onto the wire. This includes being able to generate packets that appear to be from a trusted machine. Thus, even if the end-system with which you wish to communicate is itself secure, the Internet environment provides no assurance that packets which claim to be from that system in fact are. It's important to realize that the meaning of a PDU is different at different levels. At the [IP] level, a PDU means an IP packet. At the TCP level, it means a TCP segment. At the application layer, it means some kind of application PDU. For instance, at the level of [SOAP1.1], it means a single SOAP request or response message, while at the [HTTP1.1] level, it means a single HTTP request or response message. 13.1.1 Passive Attacks In a passive attack, the attacker reads packets off the network but does not write them. The simplest way to mount such an attack is to simply be on the same LAN as the victim. On most common LAN configurations, including Ethernet, 802.3, and FDDI, any machine on the wire can read all traffic destined for any other machine on the same LAN. Note that switching hubs make this sort of sniffing substantially more difficult, since traffic destined for a machine only goes to the network segment that machine is located on. Wireless communications channels deserve special consideration, especially with the recent and growing popularity of wireless-based LANs, such as those using 802.11. Since the data is simply broadcast on well known radio frequencies, an attacker simply needs to be able to receive those transmissions. Such channels are especially vulnerable to passive attacks. Although many such channels include cryptographic protection, it is often of very poor quality. Passive attacks described in [RFC3552] and considered in PSI/1.0 are: (1) Confidentiality Violations - PSI/1.0 implementations MUST support [TLS] for protection against exposure of private business data. (2) Password Sniffing - PSI/1.0 implementations MUST support [TLS] and MUST NOT transfer cleartext passwords over unencrypted channels. (3) Offline Cryptographic Attacks - PSI/1.0 implementations MUST support [TLS] to protect against dictionary attacks against password- based challenge/response protocols [HTTPAuth]. 13.1.2 Active Attacks In an active attack, the attacker writes packets to the network and may read responses from the network. Active attacks that involve sending forged packets but not receiving any responses are called 'blind attacks'. When IP [RFC791] is used without [IPSec], there is no authentication for the sender address. Active attacks that involve forging an IP packet with a false source address are called 'spoofing attacks'. An IP packet with a forged source address may sometimes be screened out by the network infrastructure. For instance, many packet filtering firewalls screen out all packets with source addresses on the internal network that arrive on the external interface. Note that this provides no protection against an attacker who is inside the firewall. In general, protocol designers should assume that attackers can forge IP packets. Not all active attacks require forging addresses. For example, the TCP SYN denial of service attack does not require disguising the sender's address. However, it is common practice to disguise one's address in order to conceal one's identity if an attack is discovered. Active attacks described in [RFC3552] and considered in PSI/1.0 are: (1) Message Replay Attacks - PSI/1.0 implementations MUST support [TLS] and SHOULD always use at least [TLS] data integrity services for protection against [SOAP1.1] transaction replays by an attacker who has recorded a sequence of messages off the wire. (2) Message Insertion Attacks - PSI/1.0 implementations MUST support [TLS] and SHOULD always use at least [TLS] data integrity services for protection against message insertion by an attacker. PSI/1.0 implementations over [HTTP1.1] MUST take active measures to protect against denial-of-service attacks (for example, numerous incoming [TCP] connections from the same remote host or remote domain). (3) Message Deletion Attacks - PSI/1.0 implementations MUST support [TLS] and SHOULD always use at least [TLS] data integrity services for protection against message deletion by an attacker. (4) Message Modification Attacks - PSI/1.0 implementations MUST support [TLS] and SHOULD always use at least [TLS] data integrity services for protection against message modification by an attacker. (5) Man-In-The-Middle Attacks - PSI/1.0 implementations MUST support [TLS] and SHOULD always use at least [TLS] data integrity services and both Client and Server Authentication during [TLS] startup for protection against man-in-the-middle attacks. 13.2 Enterprise Threat Model In the enterprise threat model, we can no longer assume that the end-systems engaging in a protocol exchange have not themselves been compromised. Physical security of workstations and network printers in an enterprise network is often the weakest point of security defenses. And print jobs typically produce hardcopy, which an inside attacker can simply steal. Network security problems are actually worse in an enterprise network. Firewalls and border routers no longer provide any useful protection. Users and administrators who deploy PSI/1.0 products in enterprise networks SHOULD enforce the use of [TLS] and SHOULD enforce the use of strong Client and Server Authentication during [TLS] startup. 13.3 Mobile Threat Model In the mobile threat model, we can no longer defend against attackers based on network topology. Mobile clients may access home, business, or commercial PSI/1.0 products via: (1) Public Wireless - Cellular ISPs, IEEE 802.11 wireless Ethernet 'hot spots' in airports, etc. (2) Local Wireless - Bluetooth/IRDA-enabled laptops and printers, etc. Users and administrators who deploy PSI/1.0 products in mobile networks SHOULD enforce the use of [TLS] and SHOULD enforce the use of strong Client and Server Authentication during [TLS] startup. [IPSec] also offers significant security advantages in mobile networks. 13.4 HTTP Threat Model PSI/1.0 implementations are vulnerable to the following HTTP threats described in section 15 'Security Considerations' of [HTTP1.1]: (1) Attacks on personal information - [HTTP1.1] clients and servers in PSI/1.0 implementations MUST protect sensitive personal information, such as name, email address, etc. (see section 15.1 of [HTTP1.1]). (2) Attacks based on file and path names - [HTTP1.1] servers in PSI/1.0 implementations MUST NOT expose 'nearby' resources that were NOT explicitly configured for network access by administrators (see section 15.2 of [HTTP1.1]). (3) Attacks based on DNS spoofing - [HTTP1.1] clients and servers in PSI/1.0 implementations SHOULD NOT cache DNS name resolution results beyond their time-to-live value (see section 15.3 of [HTTP1.1]). (4) Attacks based on Location header spoofing - [HTTP1.1] servers in PSI/1.0 implementations MUST verify the validity of Location and Content-Location header data when supporting multiple trust domains (see section 15.4 of [HTTP1.1]). (5) Attacks based on Content-Disposition headers - [HTTP1.1] servers in PSI/1.0 implementations MUST defend against Content-Disposition header attacks (see section 15.5 of [HTTP1.1]). (6) Attacks based on retention of authentication credentials - [HTTP1.1] clients in PSI/1.0 implementations SHOULD NOT retain cached user authentication credentials beyond an administratively configured idle client time (see section 15.6 of [HTTP1.1]). (7) Attacks on HTTP Proxies - [HTTP1.1] servers in PSI/1.0 implementations SHOULD take active measures to defend against man-in-the-middle attacks and single source or distributed denial-of-service attacks (see section 15.7 of [HTTP1.1]). ---------------------------------------------------------------------- -- [for addition to Normative References section] [IANA-CHAR] IANA Registry of Charset Tags, archived at: ftp://ftp.iana.org/assignments/character-sets [IANA-LANG] IANA Registry of Language Tags, archived at: ftp://ftp.iana.org/assignments/language-tag-info [IANA-MIME] IANA Registry of Media Types, archived at: ftp://ftp.iana.org/assignments/media-types [IP] Postel, J. "Internet Protocol", RFC 791, September 1981. [IPSec] Kent, S., Atkinson, R. "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [SOAP1.2] See [SOAP1.2-0], [SOAP1.2-1], and [SOAP1.2-2]. [SOAP1.2-0] "SOAP Version 1.2 Part 0: Primer", W3C Recommendation, June 2003. [SOAP1.2-1] "SOAP Version 1.2 Part 1: Messaging Framework", W3C Recommendation, June 2003. [SOAP1.2-2] "SOAP Version 1.2 Part 2: Adjuncts", W3C Recommendation, June 2003. [TCP] Postel, J. "Transmission Control Protocol", RFC 793, September 1981. [WSDL1.2] See [WSDL1.2-1], [WSDL1.2-2], and [WSDL1.2-3] below. [WSDL1.2-1] "Web Services Description Language (WSDL) Version 1.2 -- Part 1: Core Language", W3C Working Draft, June 2003. [WSDL1.2-2] "Web Services Description Language (WSDL) Version 1.2 -- Part 2: Message Patterns", W3C Working Draft, June 2003. [WSDL1.2-3] "Web Services Description Language (WSDL) Version 1.2 -- Part 3: Bindings", W3C Working Draft, June 2003. [XML] See [XML1.0] and [XML1.1] below. [XML1.0] "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C Recommendation, October 2000. [XML1.1] "Extensible Markup Language (XML) 1.1", W3C Candidate Recommendation, October 2002. [XSD] See [XSD-1] and [XSD-2] below. [XSD-1] "XML Schema Part 1: Structures", W3C Recommendation, May 2001. [XSD-2] "XML Schema Part 2: Datatypes", W3C Recommendation, May 2001. [for addition to Informative References section] [ISO639] See [ISO639-1] and [ISO639-2] below. [ISO639-1] "Codes for the Representation of Names of Languages -- Part 1: Alpha-2 Code", ISO/IEC 639-1, 2000. [ISO639-2] "Codes for the Representation of Names of Languages -- Part 2: Alpha-3 Code", ISO/IEC 639-2, 1998. [ISO3166] See [ISO3166-1] and [ISO3166-2] below. [ISO3166-1] "Codes for the Representation of Names of Countries and their Subdivisions, Part 1: Country Codes", ISO/ISO 3166- 1, 1997. [ISO3166-2] "Codes for the Representation of Names of Countries and their Subdivisions, Part 2: Country Subdivision Codes", ISO/ISO 3166-2, 1998. [RFC2046] Freed, N., Borenstein, N. "MIME Part Two: Media Types", RFC 2046, November 1996. [RFC2048] Freed, N., Borenstein, N. "MIME Part Four: Registration Procedures", RFC 2048, November 1996. [RFC2277] Alvestrand, H. "IETF Policy on Character Sets and Languages", RFC 2277, January 1998. [RFC2279] Yergeau, F. "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. [RFC2978] Freed, N., Postel, J. "IANA Charset Registration Procedures", RFC 2978, October 2000. [RFC3066] Alvestrand, H. "Tags for the Identification of Languages", RFC 3066, January 2001. Ira McDonald (Musician / Network Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 Phone: +1-906-494-2434 Email: imcdonald@sharplabs.com From alan.berkema at hp.com Mon Oct 20 23:35:05 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:11 2009 Subject: PS> NO PSI Call 10/21 Message-ID: No Call this week stay tuned for future calls Thanks, Alan _____ Alan Berkema Senior Engineer Scientist Connectivity Roseville, CA Hewlett-Packard Company 916 785-5605 Phone aberkema@hp.com _____ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/ps/attachments/20031020/5780fb82/attachment.html From imcdonald at sharplabs.com Tue Oct 21 13:53:29 2003 From: imcdonald at sharplabs.com (Ira McDonald) Date: Wed May 6 14:02:11 2009 Subject: PS> PSI Reqs revised Security/Discovery sections Message-ID: <3F953A59.31977.63F2D4@localhost> Hi folks, Tuesday (21 October 2003) Below are complete rewrite replacements for the former sections: - 5.4 Security - 6.1 Print Service Discovery Requirements Note that at our face-to-face review two weeks ago, we decided to DELETE entirely the former sections: - 5.5 Accounting Metrics - to be DELETED - 6 Other Considerations - to be DELETED Thus, the two replacement sections now are: - 5.4 Security - 5.5 Discovery Cheers, - Ira McDonald High North Inc ------------------------------------------------------------------------ 5.4 Security The PSI shall select one or more existing standard end-to-end security protocols. The selected PSI security protocol(s) shall be specified as optional to use for all PSI implementations, but mandatory to support for all PSI implementations. The selected PSI security protocol(s) shall support: (1) Client Authentication - protection from PSI service access by any unauthenticated client system or process. (2) Server Authentication - protection from PSI service offering by any unauthenticated server system or process. (3) Data Integrity - protection from PSI message insertion, message deletion, or message modification by any intermediate system. (4) Data Privacy - protection from PSI message content disclosure to any intermediate system. The PSI shall NOT specify or encourage the use of any hop-by-hop (link or network layer) security protocols, because they do not offer any end-to-end (application, session, or transport layer) security. 5.5 Discovery The PSI should select and recommend one or more existing standard discovery protocols. The selected PSI disovery protocol(s) should support: (1) Service advertising (2) Service type discovery (3) Service capabilities discovery (4) Device advertising (5) Device type discovery (6) Device capabilities discovery Ira McDonald (Musician / Network Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 Phone: +1-906-494-2434 Email: imcdonald@sharplabs.com From alan.berkema at hp.com Wed Oct 22 15:35:30 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:11 2009 Subject: PS> PSI Reqs revised Security/Discovery sections Message-ID: <7A371016E109114EA47C89370296278B290DFB@xrose01.rose.hp.com> Thanks Ira, One minor note, instead of deleting accounting it now says Accounting Attributes (instead of metrics) and it just says: The PSI shall support accounting metrics and attributes as defined in a named version of the PWG Semantic model. Alan -----Original Message----- From: owner-ps@pwg.org [mailto:owner-ps@pwg.org]On Behalf Of Ira McDonald Sent: Tuesday, October 21, 2003 10:53 AM To: ps@pwg.org Subject: PS> PSI Reqs revised Security/Discovery sections Hi folks, Tuesday (21 October 2003) Below are complete rewrite replacements for the former sections: - 5.4 Security - 6.1 Print Service Discovery Requirements Note that at our face-to-face review two weeks ago, we decided to DELETE entirely the former sections: - 5.5 Accounting Metrics - to be DELETED - 6 Other Considerations - to be DELETED Thus, the two replacement sections now are: - 5.4 Security - 5.5 Discovery Cheers, - Ira McDonald High North Inc ------------------------------------------------------------------------ 5.4 Security The PSI shall select one or more existing standard end-to-end security protocols. The selected PSI security protocol(s) shall be specified as optional to use for all PSI implementations, but mandatory to support for all PSI implementations. The selected PSI security protocol(s) shall support: (1) Client Authentication - protection from PSI service access by any unauthenticated client system or process. (2) Server Authentication - protection from PSI service offering by any unauthenticated server system or process. (3) Data Integrity - protection from PSI message insertion, message deletion, or message modification by any intermediate system. (4) Data Privacy - protection from PSI message content disclosure to any intermediate system. The PSI shall NOT specify or encourage the use of any hop-by-hop (link or network layer) security protocols, because they do not offer any end-to-end (application, session, or transport layer) security. 5.5 Discovery The PSI should select and recommend one or more existing standard discovery protocols. The selected PSI disovery protocol(s) should support: (1) Service advertising (2) Service type discovery (3) Service capabilities discovery (4) Device advertising (5) Device type discovery (6) Device capabilities discovery Ira McDonald (Musician / Network Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 Phone: +1-906-494-2434 Email: imcdonald@sharplabs.com From alan.berkema at hp.com Wed Oct 22 15:51:26 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:11 2009 Subject: PS> [PSI]: New MRD Posted Message-ID: <7A371016E109114EA47C89370296278B2FD163@xrose01.rose.hp.com> Word version has changes turned on, pdf is clean. ftp://ftp.pwg.org/pub/pwg/ps/wd-psireq10-200309_89.doc ftp://ftp.pwg.org/pub/pwg/ps/ wd-psireq10-200309_89.pdf regards, Alan _____ Alan Berkema Senior Engineer Scientist Connectivity Roseville, CA Hewlett-Packard Company 916 785-5605 Phone aberkema@hp.com _____ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/ps/attachments/20031022/c3fdf7aa/attachment.html From imcdonald at sharplabs.com Wed Oct 22 18:08:31 2003 From: imcdonald at sharplabs.com (imcdonald@sharplabs.com) Date: Wed May 6 14:02:11 2009 Subject: PS> PSI Reqs revised Security/Discovery sections In-Reply-To: <7A371016E109114EA47C89370296278B290DFB@xrose01.rose.hp.com> Message-ID: <3F96C79F.27475.FBA25E@localhost> Hi Alan, Thanks - I stand corrected. Cheers, - Ira > Thanks Ira, > > One minor note, instead of deleting accounting it now > says Accounting Attributes (instead of metrics) > and it just says: > The PSI shall support accounting metrics and attributes as > defined in a named version of the PWG Semantic model. > > Alan > > > -----Original Message----- > From: owner-ps@pwg.org [mailto:owner-ps@pwg.org]On Behalf Of Ira > McDonald > Sent: Tuesday, October 21, 2003 10:53 AM > To: ps@pwg.org > Subject: PS> PSI Reqs revised Security/Discovery sections > > > Hi folks, Tuesday (21 October > 2003) > > Below are complete rewrite replacements for the former sections: > > - 5.4 Security > - 6.1 Print Service Discovery Requirements > > Note that at our face-to-face review two weeks ago, we decided to > DELETE > entirely the former sections: > > - 5.5 Accounting Metrics - to be DELETED > - 6 Other Considerations - to be DELETED > > Thus, the two replacement sections now are: > > - 5.4 Security > - 5.5 Discovery > > Cheers, > - Ira McDonald > High North Inc > > ------------------------------------------------------------------------ > > > 5.4 Security > > The PSI shall select one or more existing standard end-to-end security > protocols. The selected PSI security protocol(s) shall be specified as > optional to use for all PSI implementations, but mandatory to support for > all PSI implementations. The selected PSI security protocol(s) shall > support: > > (1) Client Authentication - protection from PSI service access by any > unauthenticated client system or process. > > (2) Server Authentication - protection from PSI service offering by any > unauthenticated server system or process. > > (3) Data Integrity - protection from PSI message insertion, message > deletion, or message modification by any intermediate system. > > (4) Data Privacy - protection from PSI message content disclosure to > any intermediate system. > > The PSI shall NOT specify or encourage the use of any hop-by-hop (link or > network layer) security protocols, because they do not offer any > end-to-end (application, session, or transport layer) security. > > > 5.5 Discovery > > The PSI should select and recommend one or more existing standard > discovery protocols. The selected PSI disovery protocol(s) should > support: > > (1) Service advertising > > (2) Service type discovery > > (3) Service capabilities discovery > > (4) Device advertising > > (5) Device type discovery > > (6) Device capabilities discovery > > Ira McDonald (Musician / Network Software Architect) > Blue Roof Music / High North Inc > PO Box 221 > Grand Marais, MI 49839 > Phone: +1-906-494-2434 > Email: imcdonald@sharplabs.com From alan.berkema at hp.com Fri Oct 24 12:38:09 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:11 2009 Subject: PS> PSI 10/7/03 F2F Mtg Mins & Slides Message-ID: <7A371016E109114EA47C89370296278B2FD167@xrose01.rose.hp.com> Skipped content of type multipart/alternative-------------- next part -------------- PSI F2F Meeting Minutes 10/07/2003 (New York,NY) I. Attendees. Lee Farrell Yiruo Yang Alan Berkema Bob Taylor Dave Hall (via phone) Ira McDonald (via phone) Harry Lewis Jerry Thrasher Alain Regnier Fumio Nagasaka Hiroshi Shiraku II. Review Agenda (see Alan's PPT) A. Introductions B. Call For Intellectual Property C. Review and Approve Minutes from June Meeting. D. Review Agenda E. PSI History/Overview F. Review Requirements Document G. Review PSI Spec. III. Review and approve minutes from June Meeting. No changes (Approved) IV. PSI History/Overview/Objectives (see Alan's presentation) V. Schedule Going Forward 10/07/03 F2F review of PSI spec. and MRD 10/17/03 10 Day Last Call 10/31/03 End date goal for initiation of formal vote to Candidate Standard Status VI. MRD Review Updated Contributor List Section 1. Overview: Section 2. Introduction: Comment: Need to update the section numbers in the first paragraph (off by one section number) Comment: Need to update the language for each section description to match what's actually in each section... Section 3. Scope of the Print Service Interoperability Spec. Section 4. Print Service Interface Use Models Comment: Remove "informative" from section title as well as throughout... Comment: Editorial (TargetDevice ==> Target Device throughout...) Comment: Clarify the meaning of the "dashed" lines in the data flows Comment: Explain the meaning of the "dotted" lines/ovals around the admin' domains. Comment: Explain the meaning of the "solid" lines in the data flows.... 4.1 Comment: In 4.1 (clarify that the step 6 transfer from the Print Service to the Target Device is a "new" print job) Comment: 4.1.1 Change 1. Printer knowledge or discovery... to Printer configuration or discover.... (comment applies to other sub-sections as well) 4.2 Comment: In Req. 3 need to mention capabilities discovery (mobile-PS-TD) comment applies throughout... Comment: Data flow 6 in picture needs to clarify that it's a "new" job. 4.3 4.4 4.5 Comment: Need the "real world" use case story that illuminates the use model. Comment: Need to make sure that the Un-formatted Data and the Application Data data flows are properly linked/explained in the data flow diagram. Comment: Need to clarify requirement 7 to clarify that the data may be either pushed to the Printer/TD or pulled by the Printer/TD.... Comment: Need to standardize on Printer or Target Device for referring to the Target Device in the text (description and requirments) Section 5. Print Service Interface Requirments Comment: Last sentence in first paragraph (issues ==> requirments) Comment: Same sentence (billing ==> accounting) 5.2 Comment: Need to mention the transfer of data from client to Print Service as well as just a reference... 5.3 Comment: Need to add "Print Service" to first sentence... Comment: Remove "may" from second sentence (is a requirement) Comment: Need to reword or remove text in this section to remove any implied solution or implementation....(see updated MRD) Need a section added that addresses discovery (move Section 6 text to Section 5) 5.4 Comment: Need to rework the security sub-section (Ira todo) 5.5 Comment: Need to reword section to remove references to any particular accounting metric requirements (refer to semantic model document) Comment: Need to remove the work "Metrics" from the sub-section title (Accounting Attributes). Comment/Action Item: Implementers guide needs to contain section describing the appropriate accounting attributes from the PWG semantic model. Section 6. Comment: Move to section 5 and reword (Ira todo). (remove section 6) *************************** End of MRD Review *************************** VII. PSI Specification Review (version 2003/09/26) Reviewed the issues and questions in the latest version of the spec. (see updated specification) Section 5 Issue 1: Toolkits/editors for WSDL aren't currently to a level to be able to correctly or consistently validate the wsdl files. Resolution: Clarify that the wsdl files are for "reference" designs only (i.e., informative). However the PSI spec. can't become a full PWG standard without normative wsdl files. Section 5.3 Issue 2: Resolve the above namespace. Resolution/Discussion: Need to move the "normative" namespace declaration discussion to the beginning of Section 5 before the discussion about the wsdl documents. (Namespace is normative, wsdl files are currently informative pending the resolution of Issue 1.) Comment: Now that there as an independent conformance section, the detailed method/parameter conformance requirements statements that are currently in each method description need to be moved to a table (or something) in the conformance section. Resolution: Dave todo, create the table..... Section 6 Issue: Client needs ability to determine the mode of the Print Service. Need semantic model attribute (autoSelectTargetDevice_supported boolean),(TargetDeviceIdentifier_supported boolean) or equivalent multivalue attribute(s)........(see updated specification) Section 10 Discussed the three conformance questions/issues (see updated spec) Action Item: (Last Call Reviewers) The conformance section should be reviewed closely to make sure it accurately summarizes the requirments of the PSI specification. Section 13 and 14 ToDo (Ira to provide standard text for these sections) Section 15 (Security Model Considerations) Ira continuing to develop the text for the Security section. *************************** End of PSI Spec. Review *************************** VII. Brief discussion of the results of the interop event. Basic operations (Createjob etc) seemed to work, however toolkit issues caused the need for extensive hand coding of the interfaces to get basic interoperability....Toolkit interoperability is still a continuing issue. VIII. There will be no PSI phone conference on October 14, 2003. Move out original "schedule going forward" dates by a week..... Next Phone conference Call on Tuesday October 21, 2003. Details will be sent to the reflector. Meeting adjourned....... -------------- next part -------------- A non-text attachment was scrubbed... Name: psi_pwg_overview.pdf Type: application/octet-stream Size: 139973 bytes Desc: not available Url : http://www.pwg.org/archives/ps/attachments/20031024/176e5791/psi_pwg_overview.obj From imcdonald at sharplabs.com Mon Oct 27 12:05:51 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:11 2009 Subject: PS> PSI tomorrow (28 OCt)? Message-ID: <116DB56CD7DED511BC7800508B2CA537B001FF@mailsrvnt02.enet.sharplabs.com> Hi Alan and Dave, Are we meeting tomorrow morning (Tues 28 October)? Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com From alan.berkema at hp.com Mon Oct 27 15:07:11 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:11 2009 Subject: PS> [PSI] Next Call 10/28/03 Message-ID: <7A371016E109114EA47C89370296278B2FD174@xrose01.rose.hp.com> Teleconference details: NEXT: Tuesday Time: 8:00AM (US PDT) Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Review Requirements Doc Changes 20 Tech Spec Update for Last Call? ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting number: 743057814 Meeting password: newpsi-1 Host: Alan Berkema 1(916)7855605 From imcdonald at sharplabs.com Tue Oct 28 12:37:45 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:11 2009 Subject: PS> Next calls and PSI Spec schedules Message-ID: <116DB56CD7DED511BC7800508B2CA537B00202@mailsrvnt02.enet.sharplabs.com> Hi folks, We completed a pretty thorough pass through Alan's last-call version of PSI Requirements spec this morning. Only editorial changes (for clarity or consistency) were found. Next steps: * Fri 31 Oct - new version of PSI Protocol spec to be posted for two-week last call * Tue 4 Nov - PSI telecon - address any further last-call comments on PSI Requirements spec (Alan will lead). * Fri 7 Nov - last-call ends on PSI Requirements spec * Tue 11 Nov - PSI telecon - address any last-call comments on PSI Protocol spec (Dave will lead - Alan on vacation). * Fri 14 Nov - last-call ends on PSI Protocol spec (if Dave and I got it out by Fri 31 Oct). * ??? Nov - call for Formal Vote on PSI Requirements spec * ??? Nov - call for Formal Vote on PSI Protocol spec Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com From alan.berkema at hp.com Tue Oct 28 16:15:43 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:11 2009 Subject: PS> [PSI] Next Call 11/04/03 Message-ID: <7A371016E109114EA47C89370296278B2FD187@xrose01.rose.hp.com> I know some of you said you are out we will still try to make whatever progress we can towards Last Call, Thanks Alan Teleconference details: NEXT: Tuesday Time: 8:00AM (US PDT) Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Review Tech Spec Updates 2) Requirements Doc Status ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting number: 743057814 Meeting password: newpsi-1 Host: Alan Berkema 1(916)7855605 From imcdonald at sharplabs.com Mon Nov 10 10:56:07 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:11 2009 Subject: PS> ?? PSI call on Nov 11 ?? Message-ID: <116DB56CD7DED511BC7800508B2CA537B0022A@mailsrvnt02.enet.sharplabs.com> Hi Dave, Are you planning to host a PSI telecon tomorrow morning? Alan is on vacation this week (I believe). He said last week we'd have a call if you (Dave) wanted to host it. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com From dhall at hp.com Wed Nov 26 16:58:27 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:11 2009 Subject: PS> Updated Specification wd-psi10-20031126.doc Message-ID: <4EB310FE4410BB4B8E981C67B275BC4F014735BD@xvan01.vcd.hp.com> The latest revision of the PSI specification can now be found at: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20031126.doc ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20031126.pdf It includes all of the modifications from the last F2F and the new sections from Ira. (Many apologies for disappearing! Things have been really busy in my new position in HP...) (Ira, can I get you to turn the DOC into a PDF and publish it? Thanks!) Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/ps/attachments/20031126/7c020684/attachment.html From imcdonald at sharplabs.com Wed Nov 26 18:16:04 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:11 2009 Subject: PS> [PDF & ZIP] Updated Specification wd-psi10-20031126.doc Message-ID: <116DB56CD7DED511BC7800508B2CA537B0027B@mailsrvnt02.enet.sharplabs.com> Hi, Converted to PDF (244 KB) and stored at: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20031126.pdf Also MS Word source (1.4 MB) packed into ZIP (261 KB): ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20031126.zip Here's a directory listing excerpt: -rw-r--r-- 1 pwg staff 1428480 Nov 26 16:50 wd-psi10-20031126.doc -rw-r--r-- 1 pwg staff 249359 Nov 26 18:07 wd-psi10-20031126.pdf -rw-r--r-- 1 pwg staff 266919 Nov 26 18:13 wd-psi10-20031126.zip Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Wednesday, November 26, 2003 4:58 PM To: 'ps@pwg.org' Subject: PS> Updated Specification wd-psi10-20031126.doc The latest revision of the PSI specification can now be found at: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20031126.doc ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20031126.pdf It includes all of the modifications from the last F2F and the new sections from Ira. (Many apologies for disappearing! Things have been really busy in my new position in HP...) (Ira, can I get you to turn the DOC into a PDF and publish it? Thanks!) Dave From Ide.Kentaro at exc.epson.co.jp Tue Dec 2 14:04:40 2003 From: Ide.Kentaro at exc.epson.co.jp (Ide Kentaro) Date: Wed May 6 14:02:11 2009 Subject: FW: Re: PS> Updated Specification wd-psi10-20031126.doc Message-ID: <56DBC1B7ACBDAE45AB2858C17E2F5B2C0E01827B@hroaex2.hro.epson.co.jp> Hi folks, Because Nagasaka's mail had lost from mailing list, I resend. Kentaro Ide IJP Design Dept. Imaging & Information Products Operations Div.. SEIKO EPSON Corp Tel 81-263-5603 / Fax 81-263-5613 > -----Original Message----- >From: Nagasaka Fumio >Sent: Friday, November 28, 2003 8:11 PM >To: 'ps@pwg.org' >Subject: Re: PS> Updated Specification wd-psi10-20031126.doc > >Hi folks, > >After I reviewed the PSI specification Ver. 1.0 Working Draft, I have three comments here. > >Issue 1, >The specification does not tell what shall be defined for the documentFilterElements. > >>5.5.8 GetJobs - Specifies the elements used as a filter when creating the Job list that is returned. > >Our implementation has been confused what is doable to keep interoperability with other implementation. >Still FilterElements seems to be nebulous and there shall be an example or some descriptions. > >Issue 2, >The specification does not clear what shall a client do to detect a requested job has been completed. >The client cannot estimate how soon the service done, then the client will be required to do polling-like >method to know whether the job completed or not. > >> <<...OLE_Obj...>> > >Issue 3, >There are few method to retrieve files from the single document when a client uses AddDocumentByPush. >In this case the single document may have multiple files. >The specification says in 5.5.5. "..if a ZIP file, or a multi-part mime Document can be delivered..", >however FetchDocumentByValue can specify a file at once. There shall be an enumerating >method to let the client to know how many times to invoke FetchDocumentByValue. > >> <<...OLE_Obj...>> > >------------------------------- >Fumio Nagasaka / IJP Design Dept. >Imaging & Information Products Operations Div.. > SEIKO EPSON Corp >Tel 81-263-5603 / Fax 81-263-5613 > > >>The latest revision of the PSI specification can now be found at: >> >> >><> >> >><> >> >>It includes all of the modifications from the last F2F and the new sections >>from Ira. >> >>(Many apologies for disappearing! Things have been really busy in my new >>position in HP...) >>(Ira, can I get you to turn the DOC into a PDF and publish it? Thanks!) >> >>Dave From imcdonald at sharplabs.com Tue Dec 2 15:10:03 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:11 2009 Subject: PS> Thu 4 Dec - PSI and IPPFAX Phone Bridge number for Provo meeting Message-ID: <116DB56CD7DED511BC7800508B2CA537B0028C@mailsrvnt02.enet.sharplabs.com> Hi, Alan and Dave - please note the phone bridge and passcode below for the Thursday morning (4 Dec) PSI telecon. Gail and Rick - we should also use this phone bridge and passcode for the Thursday afternoon (4 Dec) IPPFAX telecon. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -----Original Message----- From: Zehler, Peter [mailto:PZehler@crt.xerox.com] Sent: Tuesday, December 02, 2003 11:38 AM To: PWG Announce (pwg-announce@pwg.org) Subject: PWG-ANNOUNCE> WBMM Phone Bridge number for Provo meeting All, Today's meeting has a phone bridge which is (866) 365-4406 with a passcode of 2635888#. This number will be used for today, Thursday and Friday. The PWG Semantic Model and PWG Plenary (Wednesday) will use the previously announced number and webex included below. Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 Meeting Date: 12/3/2003 Meeting Time: 9:00 AM MST (UTC -7:00) (11:00 AM EST) Instant Net Conference Details: ------------------------------- Meeting Number: 747275324 Meeting Passcode: PwgSm Meeting Host: Pete Zehler Join Instructions for Instant Net Conference: REPEAT USERS 1. Join the meeting now: http://www.mymeetings.com/nc/join.php?i=747275324&p=PwgSm&t=c 2. Enter your name 3. Agree to the Terms & Conditions and click Proceed. NEW USERS 1. Go to http://www.mymeetings.com/nc/ 2. Type in the Meeting Number 3. Type in the Meeting Passcode (if one was provided) 4. Choose "Conference" and click Proceed 5. If you are a new user, click on "New Users" to check your system and download the software and go back to Join Net Conference page 6. Enter your name 7. Agree to the Terms & Conditions and click Proceed. Dial in Info: Phone Number:(877) 707-6056 (Phone Number for Xerox Employees: 8*594-0077) PARTICIPANT PASSCODE: 437874# From alan.berkema at hp.com Tue Dec 2 16:03:52 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:11 2009 Subject: PS> Thu 4 Dec - PSI webex Info and Phone Bridge number for Provo meet ing Message-ID: <7A371016E109114EA47C89370296278B2FD259@xrose01.rose.hp.com> West Coast Folks please note the 7:30AM start time! Agenda: 1) Review PSI Spec for Last Call ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20031126.pdf Also MS Word source (1.4 MB) packed into ZIP (261 KB): ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20031126.zip PSI - Thursday morning -- 8:30am - Noon MST (7:30-11am PST) Phone bridge (866) 365-4406 with a passcode 2635888# ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 7:30AM, (GMT -08:00) Pacific Time, USA & Canada Meeting number: 748017768 Meeting password: provopsi-99 Host: Alan Berkema 1(916)7855605 From Ide.Kentaro at exc.epson.co.jp Tue Dec 2 21:59:50 2003 From: Ide.Kentaro at exc.epson.co.jp (Ide Kentaro) Date: Wed May 6 14:02:11 2009 Subject: PS> Updated Specification wd-psi10-20031126.doc Message-ID: <56DBC1B7ACBDAE45AB2858C17E2F5B2C0E018478@hroaex2.hro.epson.co.jp> Hi folks, I'm sorry for miss-attached figures. Attached two figures to this mail. | -----Original Message----- | From: owner-ps@pwg.org [mailto:owner-ps@pwg.org]On Behalf Of | Ide Kentaro | Sent: Wednesday, December 03, 2003 4:05 AM | To: ps@pwg.org | Subject: FW: Re: PS> Updated Specification wd-psi10-20031126.doc | | | Hi folks, | | Because Nagasaka's mail had lost from mailing list, I resend. | | Kentaro Ide | IJP Design Dept. | Imaging & Information Products Operations Div.. | SEIKO EPSON Corp | Tel 81-263-5603 / Fax 81-263-5613 | | > -----Original Message----- | >From: Nagasaka Fumio | >Sent: Friday, November 28, 2003 8:11 PM | >To: 'ps@pwg.org' | >Subject: Re: PS> Updated Specification wd-psi10-20031126.doc | > | >Hi folks, | > | >After I reviewed the PSI specification Ver. 1.0 Working | Draft, I have three comments here. | > | >Issue 1, | >The specification does not tell what shall be defined for | the documentFilterElements. | > | >>5.5.8 GetJobs - Specifies the elements used as a filter | when creating the Job list that is returned. | > | >Our implementation has been confused what is doable to keep | interoperability with other implementation. | >Still FilterElements seems to be nebulous and there shall | be an example or some descriptions. | > | >Issue 2, | >The specification does not clear what shall a client do to | detect a requested job has been completed. | >The client cannot estimate how soon the service done, then | the client will be required to do polling-like | >method to know whether the job completed or not. | > | >> <<...OLE_Obj...>> | > | >Issue 3, | >There are few method to retrieve files from the single | document when a client uses AddDocumentByPush. | >In this case the single document may have multiple files. | >The specification says in 5.5.5. "..if a ZIP file, or a | multi-part mime Document can be delivered..", | >however FetchDocumentByValue can specify a file at once. | There shall be an enumerating | >method to let the client to know how many times to invoke | FetchDocumentByValue. | > | >> <<...OLE_Obj...>> | > | >------------------------------- | >Fumio Nagasaka / IJP Design Dept. | >Imaging & Information Products Operations Div.. | > SEIKO EPSON Corp | >Tel 81-263-5603 / Fax 81-263-5613 | > | > | >>The latest revision of the PSI specification can now be found at: | >> | >> | >><> | >> | >><> | >> | >>It includes all of the modifications from the last F2F and | the new sections | >>from Ira. | >> | >>(Many apologies for disappearing! Things have been really | busy in my new | >>position in HP...) | >>(Ira, can I get you to turn the DOC into a PDF and publish | it? Thanks!) | >> | >>Dave | -------------- next part -------------- A non-text attachment was scrubbed... Name: psi_pointout.pdf Type: application/octet-stream Size: 11978 bytes Desc: not available Url : http://www.pwg.org/archives/ps/attachments/20031203/366ef7be/psi_pointout.obj From imcdonald at sharplabs.com Thu Dec 4 14:39:45 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:11 2009 Subject: PS> RE: IFX> Today 1pm MST (12pm PST / 3pm EST) - agenda and info for Provo Message-ID: <116DB56CD7DED511BC7800508B2CA537B0029D@mailsrvnt02.enet.sharplabs.com> Hi folks, Today's meeting has a phone bridge which is (866) 365-4406 with a passcode of 2635888#. This number will be used for today (Thursday) and tomorrow (Friday) sessions at PWG Provo. Suggested Agenda: (1) Introductions (2) Agenda Review (3) IPPFAX Status Review Slides - available at ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-status-20031204.htm (4) IPPFAX Protocol Spec Review - available at ftp://ftp.pwg.org/pub/pwg/QUALDOCS/wd-ifx10-20031105.pdf (5) Next steps - action items, working group future, etc. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Tuesday, December 02, 2003 3:10 PM To: 'ps@pwg.org'; 'ifx@pwg.org' Subject: IFX> Thu 4 Dec - PSI and IPPFAX Phone Bridge number for Provo meeting Hi, Alan and Dave - please note the phone bridge and passcode below for the Thursday morning (4 Dec) PSI telecon. Gail and Rick - we should also use this phone bridge and passcode for the Thursday afternoon (4 Dec) IPPFAX telecon. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -----Original Message----- From: Zehler, Peter [mailto:PZehler@crt.xerox.com] Sent: Tuesday, December 02, 2003 11:38 AM To: PWG Announce (pwg-announce@pwg.org) Subject: PWG-ANNOUNCE> WBMM Phone Bridge number for Provo meeting All, Today's meeting has a phone bridge which is (866) 365-4406 with a passcode of 2635888#. This number will be used for today, Thursday and Friday. The PWG Semantic Model and PWG Plenary (Wednesday) will use the previously announced number and webex included below. Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 Meeting Date: 12/3/2003 Meeting Time: 9:00 AM MST (UTC -7:00) (11:00 AM EST) Instant Net Conference Details: ------------------------------- Meeting Number: 747275324 Meeting Passcode: PwgSm Meeting Host: Pete Zehler Join Instructions for Instant Net Conference: REPEAT USERS 1. Join the meeting now: http://www.mymeetings.com/nc/join.php?i=747275324&p=PwgSm&t=c 2. Enter your name 3. Agree to the Terms & Conditions and click Proceed. NEW USERS 1. Go to http://www.mymeetings.com/nc/ 2. Type in the Meeting Number 3. Type in the Meeting Passcode (if one was provided) 4. Choose "Conference" and click Proceed 5. If you are a new user, click on "New Users" to check your system and download the software and go back to Join Net Conference page 6. Enter your name 7. Agree to the Terms & Conditions and click Proceed. Dial in Info: Phone Number:(877) 707-6056 (Phone Number for Xerox Employees: 8*594-0077) PARTICIPANT PASSCODE: 437874# From imcdonald at sharplabs.com Thu Dec 4 14:41:57 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:11 2009 Subject: PS> RE: IFX> [Fix URL]Today 1pm MST (12pm PST / 3pm EST) - agenda and info for Provo Message-ID: <116DB56CD7DED511BC7800508B2CA537B0029E@mailsrvnt02.enet.sharplabs.com> Hi, Oops! The slides are actually at: ftp://ftp.pwg.org/pub/pwg/QUALDOCS/slides/ifx-status-20031204.htm Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -----Original Message----- From: McDonald, Ira Sent: Thursday, December 04, 2003 2:40 PM To: McDonald, Ira; 'ps@pwg.org'; 'ifx@pwg.org' Subject: RE: IFX> Today 1pm MST (12pm PST / 3pm EST) - agenda and info for Provo Hi folks, Today's meeting has a phone bridge which is (866) 365-4406 with a passcode of 2635888#. This number will be used for today (Thursday) and tomorrow (Friday) sessions at PWG Provo. Suggested Agenda: (1) Introductions (2) Agenda Review (3) IPPFAX Status Review Slides - available at ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-status-20031204.htm (4) IPPFAX Protocol Spec Review - available at ftp://ftp.pwg.org/pub/pwg/QUALDOCS/wd-ifx10-20031105.pdf (5) Next steps - action items, working group future, etc. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Tuesday, December 02, 2003 3:10 PM To: 'ps@pwg.org'; 'ifx@pwg.org' Subject: IFX> Thu 4 Dec - PSI and IPPFAX Phone Bridge number for Provo meeting Hi, Alan and Dave - please note the phone bridge and passcode below for the Thursday morning (4 Dec) PSI telecon. Gail and Rick - we should also use this phone bridge and passcode for the Thursday afternoon (4 Dec) IPPFAX telecon. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -----Original Message----- From: Zehler, Peter [mailto:PZehler@crt.xerox.com] Sent: Tuesday, December 02, 2003 11:38 AM To: PWG Announce (pwg-announce@pwg.org) Subject: PWG-ANNOUNCE> WBMM Phone Bridge number for Provo meeting All, Today's meeting has a phone bridge which is (866) 365-4406 with a passcode of 2635888#. This number will be used for today, Thursday and Friday. The PWG Semantic Model and PWG Plenary (Wednesday) will use the previously announced number and webex included below. Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 Meeting Date: 12/3/2003 Meeting Time: 9:00 AM MST (UTC -7:00) (11:00 AM EST) Instant Net Conference Details: ------------------------------- Meeting Number: 747275324 Meeting Passcode: PwgSm Meeting Host: Pete Zehler Join Instructions for Instant Net Conference: REPEAT USERS 1. Join the meeting now: http://www.mymeetings.com/nc/join.php?i=747275324&p=PwgSm&t=c 2. Enter your name 3. Agree to the Terms & Conditions and click Proceed. NEW USERS 1. Go to http://www.mymeetings.com/nc/ 2. Type in the Meeting Number 3. Type in the Meeting Passcode (if one was provided) 4. Choose "Conference" and click Proceed 5. If you are a new user, click on "New Users" to check your system and download the software and go back to Join Net Conference page 6. Enter your name 7. Agree to the Terms & Conditions and click Proceed. Dial in Info: Phone Number:(877) 707-6056 (Phone Number for Xerox Employees: 8*594-0077) PARTICIPANT PASSCODE: 437874# From alan.berkema at hp.com Mon Dec 8 13:14:16 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:11 2009 Subject: PS> FW: Provo PSI meeting minutes Message-ID: <7A371016E109114EA47C89370296278B2FD274@xrose01.rose.hp.com> Thanks Jerry! -------------- next part -------------- A non-text attachment was scrubbed... Name: PSI Meeting Minutes Provo.txt Type: application/octet-stream Size: 4177 bytes Desc: not available Url : http://www.pwg.org/archives/ps/attachments/20031208/2a2af3ff/PSIMeetingMinutesProvo.obj From dhall at hp.com Mon Jan 6 16:23:44 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:16 2009 Subject: PS> 0.94b Spec available Message-ID: <77261E830267D411BD4D00902740AC250DB4C3E0@xvan01.vcd.hp.com> Hey All... The 0.94b specification is available. I have split out the relevant sections into a separate developers guide. Also, we have created a usage overview document. ftp://ftp.pwg.org/pub/pwg/ps/psi-spec-latest.pdf ftp://ftp.pwg.org/pub/pwg/ps/psi-devl-latest.pdf ftp://ftp.pwg.org/pub/pwg/ps/psi-interface-usage-latest.pdf We have a goal of having 0.95 complete by Monday the 13th, so please review and provide comments and feedback. Dave From dhall at hp.com Tue Jan 7 18:34:56 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:16 2009 Subject: PS> Union construct for 0.95 Message-ID: <77261E830267D411BD4D00902740AC250DB4C400@xvan01.vcd.hp.com> Hey All During todays PSI meeting, the issue of toolkit support for the union construct in schema definitions came up. In general, one of our goals for the PSI spec is to provide a specification that has a high probability of interoperatibility between different vendors. There are three options available to address the union construct: 1) Leave it as it is, and deal with the toolkits lack of support on a case by case basis. This has the advantage of keeping the specification "pure", but has the dis-advantage of near term interop problems. 2) For the interim, modify the Common Semantic Model to not utilize the union construct. As the toolkits add support, eventually roll the union construct back into the semantic model. This gets us better interop in the near term, but may add turmoil when we re-introduce the union construce. 3) In PSI, duplicate the object defnintions that contain the element refences to the types that are defined by union, and define them directly as an NMTOKEN. In otherwords, create a PSI_DocumentDescription.xsd that has: instead of: This has the advantage of keeping the semantic model "pure", but has the dis-advantage of duplicated container object definitions.. Thoughts / Opinions? Dave From imcdonald at sharplabs.com Tue Jan 7 18:38:51 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:16 2009 Subject: PS> RE: LDAP Printer Schema - lost in the woods? Message-ID: <116DB56CD7DED511BC7800508B2CA53735CE72@mailsrvnt02.enet.sharplabs.com> Hi folks, OK - our concensus is that Pat Fleming and I should work with Tom Hastings and convert the latest IETF Internet-Draft of the IETF Informative LDAP Printer Schema (not IETF 'standards track') to an IEEE/ISTO PWG draft of a PWG Proposed Standard LDAP Printer Schema (PWG 'standards track'). As we discussed during our weekly PWG PSI telecon this morning, PSI needs to eventually make NORMATIVE references to both the IANA-registered SLP Printer Template v2.0 and our semantically equivalent LDAP Printer Schema for service discovery. Cheers, - Ira McDonald, co-editor of LDAP Printer Schema High North Inc PS - I've copied the open PWG PSI list, since we've reached concensus among the document editors and IETF IPP (Carl-Uno Manros) and IEEE/ISTO PWG (Harry Lewis) officers. -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, January 07, 2003 10:27 AM To: Pat Fleming Cc: 'carl@manros.com'; 'Hastings, Tom N'; McDonald, Ira Subject: RE: LDAP Printer Schema - lost in the woods? Sorry I'm still catching up from the holiday. I agree... let's quit dragging out feet with the IETF. Unfortunate... but reality. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- Pat Fleming 01/02/2003 09:19 AM To: "McDonald, Ira" cc: "'carl@manros.com'" , Harry Lewis/Boulder/IBM@IBMUS, "'Hastings, Tom N'" , "McDonald, Ira" From: Pat Fleming/Rochester/IBM@IBMUS Subject: RE: LDAP Printer Schema - lost in the woods?Link Ira, I'm ok with your suggestion. Pat Fleming, STSM, WebSphere Architecture, Directory and Web Services, Websphere Technology CEM for iSeries Phone: 507-253-7583 (T/L 553-7583) Dept 45E/Bldg 015-2 / F111 flemingp@us.ibm.com "McDonald, Ira" 01/01/2003 01:27 PM To: "'carl@manros.com'" , "McDonald, Ira" cc: Pat Fleming/Rochester/IBM@IBMUS, "'Hastings, Tom N'" , Harry Lewis/Boulder/IBM@IBMUS Subject: RE: LDAP Printer Schema - lost in the woods? Hi Carl-Uno, Thanks - your suggestion (some future Informational RFC that points to the IEEE/ISTO PWG 510x.y standard LDAP Printer Schema) makes perfect sense to me. Harry and Pat - comments? opinions? I suggest that Pat and I publish one FINAL I-D version (to replace the existing one at ftp.ietf.org), with an empty body and an Abstract that says (something like): "Work on this LDAP Printer Schema has been withdrawn from the IETF process. See IEEE/ISTO Printer Working Group 'work-in-progress' on this topic at 'http://www.pwg.org'." Then we send your suggested note to RFC Editor (the documents in the RFC queue), IETF Secretary, and IETF Applications ADs. Cheers, - Ira PS - At least the PSI and FSG folks are quite happy to make MUST requirements for implementations that elect to support LDAP and/or SLP service discovery - the problem of options is getting more attention in the next generation of printing protocol standards. -----Original Message----- From: Carl [mailto:carl@manros.com] Sent: Tuesday, December 31, 2002 8:36 PM To: McDonald, Ira Cc: Carl-Uno Manros; 'Pat Fleming'; 'Hastings, Tom N'; 'Harry Lewis' Subject: RE: LDAP Printer Schema - lost in the woods? Ira, This is such a long and sad story. As you might remember, the original idea was to have this informatiuon as an appendix to the IPP Model document, but then we decided to break it out and make it into a separate document, etc. etc. and then it has been going on for several years... I think you are right. I suggest that you and Pat as authors of the latest draft write to the IETF Editor and Patrik, informing them that you want to withdraw the current version of the document. Once it has been published by the PWG, you can still re-enter an updated version as an Informational RFC in the IETF, but then with the remark that it is a published standard in the PWG and is only offered to the IETF for pure information. Does this make sense? Carl-Uno Carl-Uno Manros 10701 S Eastern Ave #1117 Henderson, NV 89052, USA Tel +1-702-617-9414 Fax +1-702-617-9417 Mob +1-702-525-0727 Email carl@manros.com > -----Original Message----- > From: McDonald, Ira [mailto:imcdonald@sharplabs.com] > Sent: Tuesday, December 31, 2002 12:25 PM > To: 'carl@manros.com'; McDonald, Ira > Cc: 'Harry Lewis'; 'Hastings, Tom N'; 'Pat Fleming' > Subject: RE: LDAP Printer Schema - lost in the woods? > > > Hi Carl-Uno, > > My mistake - this LDAP Printer Schema was for IETF Informational > status. The fact that a non-IETF standard (in fact quite a few of > them) will make a Normative reference is perhaps the BEST reason > to just withdraw the document and publish it from the PWG. > > Background: > > We agreed (at Harry Lewis' urging) to try and get it published as > an RFC - but two more years have gone past, and a lot of products > have shipped with this LDAP Printer Schema (from IBM, Sun, and > others). > > So let's just withdraw this document as an IETF product and > publish it as IEEE/ISTO PWG Proposed Standard, OK? > > Cheers, > - Ira McDonald > > > > -----Original Message----- > From: Carl [mailto:carl@manros.com] > Sent: Saturday, December 28, 2002 2:04 AM > To: McDonald, Ira > Cc: Carl-Uno Manros > Subject: RE: LDAP Printer Schema - lost in the woods? > > > Ira, > > Before I ping Patrik, can you remind me what status this document > will have > in the IETF? > > If it is not standards track, it will be politically incorrect to > talk about > other standads documents as referencing it as a normative reference, just > trying to not word this wrongly. > > Carl-Uno > > Carl-Uno Manros > 10701 S Eastern Ave #1117 > Henderson, NV 89052, USA > Tel +1-702-617-9414 > Fax +1-702-617-9417 > Mob +1-702-525-0727 > Email carl@manros.com > > > -----Original Message----- > > From: McDonald, Ira [mailto:imcdonald@sharplabs.com] > > Sent: Friday, December 27, 2002 4:33 PM > > To: 'Carl'; 'Harry Lewis'; 'Hastings, Tom N'; 'Pat Fleming'; McDonald, > > Ira > > Subject: LDAP Printer Schema - lost in the woods? > > Importance: High > > > > > > Hi Carl-Uno, > > > > Would you please ping Patrik Faltstrom about the status of this > > document? > > > > The soon-to-be-completed IEEE/ISTO PWG Print Systems Interface > > (PSI, printer over WSDL/SOAP) will have a Normative section on > > print server and target device service discovery via: > > (1) Multicast DNS -- vis SRV record search > > (2) SLPv2 -- via IANA-registered SLP Printer Template v2.0 > > (3) LDAPv3 -- draft-fleming-ldap-printer-schema-02.txt, June 2002 > > > > Patrik has never answered any of the notes that Pat Fleming (my > > co-author) and I have sent since July 2002. The IETF DataTracker > > shows that this item was last updated in July -- when it was first > > _added_ to the IESG DataTracker. > > > > If this document is not published quite soon as an RFC (Q1 2003), > > for PSI we need to: > > (1) _withdraw_ it as an IETF document -- via a new I-D version > > (2) _adopt_ it as a stable IEEE/ISTO PWG Proposed Standard > > > > Free Software Group (FSG) Open Printing standards for Linux will > > also have several Normative references to this LDAP Printer Schema. > > > > Cheers, > > - Ira McDonald, co-author of LDAP Printer Schema > > High North Inc > > > From PZehler at crt.xerox.com Wed Jan 8 07:44:25 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:02:16 2009 Subject: PS> SLP (srvloc) discussion on sourceforge Message-ID: All, Here is one of the notes from the SLP conversation on co-resident services. At the end is the URL to where you can join or look through the archive. Pete Peter Zehler XEROX Xerox Architecture Center Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 265-8871 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-30E Webster NY, 14580-9701 -----Original Message----- From: Erik Guttman [mailto:Erik.Guttman@Sun.COM] Sent: Wednesday, January 08, 2003 5:34 AM To: Mayer, Jim Cc: 'Erik Guttman'; Dan Nuffer; mdday@us.ibm.com; srvloc-discuss@lists.sourceforge.net; Matt Peterson Subject: RE: [Srvloc-discuss] Re: your view on draft-guttman-svrloc-servic eid-02.txt On Mon, 6 Jan 2003, Mayer, Jim wrote: > One of the issues that the serviceid scheme was (I thought) going to help > address was the proliferation of service advertisements. For folks using SLP to contact management devices, it was simpler to group attributes by the access point. The only thing they required was to know, definitively, that a set of service access points were in fact accessing the same service, over time, irrespective of change in address and independent of access mechanism. Once we start down the path of a general service record, we have to seriously bend the text based SLP attribute mechanism. Either we should *break AttrRply* and allow record based attributes, or I believe we should stick with the simpler approach of adding a serviceid attribute for collating different service replies. > The multiplexing is necessary because the URI, transport, and security > protocol may all be tightly associated with each other. Either by (a) separate responses (my current proposal) Simple to explain and use, a bit heavy on the network (b) complex attribute lists embedded in attributes (serviceid-02) Which is really nasty to explain and use (c) breaking attribute lists, changing SLP itself, etc Will take a long time to get adopted, if it gets adopted. > I would really like to avoid having to make a seperate advertisement for > every possible combination of transport and access security, which is where > the proposal seems to be going. I understand that, but there is a trade-off of complexity given SLP's constraints and verbosity. > Things I'd like to be discoverable for a multi-function device include: > > 1) Find me the adminstration service for the device that supports this > printer (or scanner, etc.) > 2) Find me the services supported by this device. > 3) Find me the printer(s) (scanner(s), etc.) supported by this device. > > Perhaps "device" should be generalized to multple "groups"? Just a thought. A fruitful direction would be to define a device advertisement. One could list device characteristics, even serviceids of services the device supports. Anyone want to take a stab at that template? Some will view this as going pretty far down the road of using SLP as a management protocol, but so what. Erik ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Srvloc-discuss mailing list Srvloc-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/srvloc-discuss From alan.berkema at hp.com Wed Jan 8 12:33:09 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:16 2009 Subject: PS> [PSI]: minutes 01/07/03 Message-ID: <499DC368E25AD411B3F100902740AD650E6AD55C@xrose03.rose.hp.com> PSI Working Group: *Alan Berkema *Dave Hall Gail Songer *Jerry Thasher *Harry Lewis Ted Tronson *Peter Mierau *Peter Zehler Paul Tykodi Bob Taylor Don Levinstone Lee Farrell Don Wright Kirk Ocke *Ira Mcdonald Amir Shahindoust * = attendance 01/07/03 Agenda 1) Discovery - Finalize: SLPv2 and LDAPv3 examples for spec, SSDP examples for spec. 2) Look at mDNS-SD examples 3) Spec review topics 01/07/03 Minutes: 0) Rev 0.94x (candidate for 0.95) will be delivered on the morning of January 13 2003. This gives us a week to review before the start of the week of PWG F2F meetings. Planning page turner review at PSI F2F January 24 2003. Ideally, at the F2F we will identify what needs to be fixed to have a last call for comments before we promote the spec to revision 0.95 At 0.95 the spec will be theoretically frozen. Changes to the spec will be conducted via an errata process. One exception is the WSDL itself. The WSDL will evolve through versioning since an errata process does not really make sense for WSDL, we really want an entire latest greatest version of the WSDL which includes all bug fixes. Need all input by Thursday afternoon 01/09/03 for inclusion in 01/13/03 rev 0.95 candidate. 1) Re visit SSDP examples Decided that psi:rootdevice, is needed for compatibility for a device that uses SSDP for both PSI and UPnP. Action: Send SSDP example to Dave Owner: Alan Status: Open Action: Investigate what needs to be done for UPnP-dev device description via UPnP Print Device documentation. Owner: Alan Status: Open Action: Send latest SLPv2 LDAPv3 examples to Dave Owner: Ira Status: Open Action: Send new proposals for Reference and Target Device by afternoon of 01/09/03 Owner: Ira Status: Open Action: e-mail discussion of state of current tool kit issues Owner: Dave Status: Done Action: Determine if Web Sphere tools have similar limitations Owner: Alan Status: Open General spec discussion: Need some Normative statements on authentication: Discovery? Normative part of spec or developer's guide? I think discovery is what Bluetooth calls "process mandatory" This means that, if a feature (such as a discovery protocol) is used, it is used in the specified manner. Interop events? As soon as we have a few companies that are ready HP will host an event, off cycle from PWG meetings. How many devices do we need? Need interop test criteria such as what features will be supported what discovery is used etc. From imcdonald at sharplabs.com Thu Jan 9 12:32:55 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:16 2009 Subject: PS> Final SLP and LDAP examples for PSI spec Message-ID: <116DB56CD7DED511BC7800508B2CA53735CE79@mailsrvnt02.enet.sharplabs.com> Hi Dave and Alan, Thursday (9 January 2003) Per my action item from this week's PSI Telecon (7 January 2003), below are revised examples and details for PSI discovery via SLPv2 (RFC 2608) and LDAPv3 (RFC 2251). Standard PSI URL scheme names (defined below) are REQUIRED for PSI discovery via SLPv2 and LDAPv3. But, new attributes do NOT need to be added to the existing standard printer schema for PSI discovery. URL scheme registration in the IETF tree (without embedded hyphen '-') is very slow - currently several _years_ before acceptance and RFC publication. We should register an alternate tree with "pwg-" prefix for use with PSI and (probably) also IPPFAX. Cheers, - Ira McDonald, co-editor of SLPv2 and LDAPv3 Printer Schemas High North Inc imcdonald@sharplabs.com ------------------------------------------------------------------------ PSI URL Schemes --------------- Conformant to "Registration Procedures for URL Scheme Names" (RFC 2717), the PSI standard URL schemes are: pwg-psips: - PSI Print Service pwg-psitd: - PSI Target Device Conforming PSI Clients MUST convert PSI standard URLs to session-level HTTP URLs by: (a) Replacing the PSI scheme name with "http:"; (b) Adding explicitly the IANA-registered PSI standard port. Conforming PSI Print Services and PSI Target Devices: (a) MUST only use the (future) IANA-registered PSI port; (b) MUST NOT use "http:" port 80 for their WSDL/SOAP interface; (c) MUST advertise using PSI standard URL schemes. Printer Schema Locations ------------------------ The IANA-registered SLPv2 Printer Template v2.0 is in the directory: ftp://ftp.iana.org/assignments/svrloc-templates/ in the file: printer.2.0.en (8 March 2000) The latest draft of the LDAPv3 Printer Schema is in the directory: ftp://ftp.pwg.org/pub/pwg/ipp/new_LDAP in the file: draft-fleming-ldap-printer-schema-02.txt (30 June 2002) Note: The LDAP Printer Schema has been withdrawn from the IETF process and will be published in a future IEEE/ISTO PWG Proposed Standard. The content of the LDAP Printer Schema has been stable for two years, with the ASN.1 OIDs assigned in the IBM namespace, NOT in the IETF namespace. SLPv2 Discovery --------------- A conforming PSI Print Service or PSI Target Device that supports SLPv2 (RFC 2608) MUST advertise using the IANA-registered standard SLPv2 Printer Template v2.0. ABNF for PSI standard SLPv2 service URLs is: service:printer:pwg-psips://hostport[abs_path] service:printer:pwg-psitd://hostport[abs_path] hostport = host [ ":" port ] host = IPv6reference / IPv4address / hostname port = *DIGIT abs_path = "/" path_segments SLPv2 Service Request --------------------- A conforming PSI Client that supports SLPv2 (RFC 2608) MUST discover available PSI Print Services or PSI Target Devices, acting in the role of an SLPv2 User Agent (UA), by sending an SLPv2 Service Request (see section 8.1 of RFC 2608) of the form: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Location header (function = SrvRqst = 1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of | String \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of | String \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of | String \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of predicate string | Service Request \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of string | String \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The MUST be either "service:printer:pwg-psips" or "service:printer:pwg-psitd". Note that the final ":" MUST NOT be included in the value. The (without prior administrative configuration) MUST be "DEFAULT" (the standard SLPv2 scope). Note that SLPv2 scopes are case-sensitive, so the value "DEFAULT" MUST be in uppercase. The (optional) MAY specify any LDAPv3 valid search filter (see "The String Representation of LDAP Search Filters", RFC 2254). For example a PSI printer that supports color can be discovered using a value of: "printer-color-supported=true" SLPv2 Service Reply ------------------- The presence or absence of network infrastructure is invisible to the PSI Client - SLPv2 discovery uses identical SLPv2 requests and replies in either case. When operating in a managed environment (with infrastructure), an SLPv2 Directory Agent (DA) will reply to a PSI Client (on behalf of registered PSI Print Services and PSI Target Devices). When operating in a zero configuration environment (no infrastructure), a conforming PSI Print Service or PSI Target Device that supports SLPv2, acting in the role of an SLPv2 Service Agent (UA), MUST reply directly to SLPv2 Service Requests received from a PSI Client, by sending an SLPv2 Service Reply (see section 8.2 of RFC 2608) of the form: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Location header (function = SrvRply = 2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Code | URL Entry count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Each returned PSI Print Service URL MUST specify either an IPv4/IPv6 address (directly usable) or a hostname (which must be resolved by DNS or mDNS lookup). SLPv2 DA Discovery ------------------ The DHCP option (decimal) 78 may be used, to find an SLPv2 Directory Agent (DA), per "DHCP Options for Service Location Protocol" (RFC 2610). LDAPv3 Discovery ---------------- Conforming PSI Clients that support LDAPv3 (RFC 2251) MUST use the (future) IEEE/ISTO PWG Proposed Standard LDAPv3 Printer Schema to search for the LDAPv3 object class "printerService" (a base class) or "printerServiceAuxClass" (may be attached, for example, to a DMTF CIM printer object class - same content as "printerService") to discover PSI standard URLs (values of the "printer-uri" attribute) of the form: pwg-psips://hostport[abs_path] pwg-psitd://hostport[abs_path] Also, an LDAPv3 search filter may be used (as with SLPv2) to find the substring "pwg-psips" or "pwg-psitd" in the "printer-xri-supported" attribute. LDAPv3 Search Request --------------------- A conforming PSI Client that supports LDAPv3 (RFC 2251) MUST discover available PSI Print Services or PSI Target Devices by sending an LDAPv3 Search Request (see section 4.5.1 of RFC 2251) of the form: SearchRequest ::= [APPLICATION 3] SEQUENCE { baseObject LDAPDN, scope ENUMERATED { baseObject (0), singleLevel (1), wholeSubtree (2) }, derefAliases ENUMERATED { neverDerefAliases (0), derefInSearching (1), derefFindingBaseObj (2), derefAlways (3) }, sizeLimit INTEGER (0 .. maxInt), timeLimit INTEGER (0 .. maxInt), typesOnly BOOLEAN, filter Filter, attributes AttributeDescriptionList } Filter ::= CHOICE { and [0] SET OF Filter, or [1] SET OF Filter, not [2] Filter, equalityMatch [3] AttributeValueAssertion, substrings [4] SubstringFilter, greaterOrEqual [5] AttributeValueAssertion, lessOrEqual [6] AttributeValueAssertion, present [7] AttributeDescription, approxMatch [8] AttributeValueAssertion, extensibleMatch [9] MatchingRuleAssertion } SubstringFilter ::= SEQUENCE { type AttributeDescription, -- at least one must be present substrings SEQUENCE OF CHOICE { initial [0] LDAPString, any [1] LDAPString, final [2] LDAPString } } MatchingRuleAssertion ::= SEQUENCE { matchingRule [1] MatchingRuleId OPTIONAL, type [2] AttributeDescription OPTIONAL, matchValue [3] AssertionValue, matchValue [3] AssertionValue, LDAPv3 Search Result -------------------- When operating in a managed environment (with infrastructure), an LDAPv3 Server will reply to a PSI Client (on behalf of registered PSI Print Services and PSI Target Devices), by sending an LDAPv3 Search Result (see section 4.5.2 of RFC 2251) of the form: SearchResultEntry ::= [APPLICATION 4] SEQUENCE { objectName LDAPDN, attributes PartialAttributeList } PartialAttributeList ::= SEQUENCE OF SEQUENCE { type AttributeDescription, vals SET OF AttributeValue } -- implementors should note that the PartialAttributeList may -- have zero elements (if none of the attributes of that entry -- were requested, or could be returned), and that the vals set -- may also have zero elements (if types only was requested, or -- all values were excluded from the result.) SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL -- at least one LDAPURL element must be present SearchResultDone ::= [APPLICATION 5] LDAPResult LDAPv3 Server Discovery ----------------------- The DHCP option (decimal) 95 may be used, to find an LDAPv3 Server. See the definition in the directory: ftp://ftp.iana.org/assignments/bootp-dhcp-extensions/ DNS Server Discovery -------------------- The DHCP option (decimal) 6 may be used to find a DNS server address. See "DHCP Options and BOOTP Vendor Extensions" (RFC 2132). The DHCP option (decimal) 117 may also be used to find a DNS server. See "The Name Service Search Option for DHCP" (RFC 2937). From imcdonald at sharplabs.com Thu Jan 9 18:02:30 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:16 2009 Subject: PS> Protocol Stack and 'targetDevice.xsd' to simple URLs Message-ID: <116DB56CD7DED511BC7800508B2CA53735CE7C@mailsrvnt02.enet.sharplabs.com> Hi Dave, Thursday (9 January 2003) Below is a a PSI protocol stack diagram to disambiguate our terminology and my best effort to replace the PSI-specific 'targetDevice.xsd' with simple URLs (with examples and notes). Cheers, - Ira McDonald High North Inc ---------------------------------------- * PSI Protocol Stack |-------------------------| |7 - Application Layer | |PSI Client or PSI Server | |-------------------------| |6 - Presentation Layer | |WSDL/SOAP | |-------------------------| |5 - Session Layer | |HTTP | |-------------------------| |4 - Transport Layer | |[TLS] | |TCP | |-------------------------| |3 - Network Layer | |IP | |-------------------------| |2 - Datalink Layer | |Ethernet, Bluetooth, etc.| |-------------------------| |1 - Physical Layer | |Wire, light, radio, etc. | |-------------------------| ---------------------------------------- * Replace 'targetDevice.xsd' with simple URLs TCP Port -------- Example: raw-tcp://somehost.com:9100 Notes: (1) REQUIRED 'host' or 'ip-addr' MUST be specified (1) REQUIRED 'port' MUST be specified (cannot be defaulted) Background: See the "raw-tcp:" URL scheme defined in the IANA-registered SLPv2 "direct print" template in the directory: ftp://ftp.iana.org/assignments/svrloc-templates in the file: printer_raw-tcp.1.0.en which extends the base SLPv2 Printer Template v2.0 Fax --- Example: fax:+358.555.1234567 Background: See "fax:" URL scheme defined in "URLs for Telephone Calls" (RFC 2806). UNC --- Example: pwg-unc:\\myprintserver\myprinter Notes: (1) Proposed new PWG standard URL scheme for UNC encapsulation (2) ALL printable ASCII characters are legal in the UNC, including the BACKSLASH (0x5C) Background: Microsoft uses UNC identifiers in Windows environments. PSI Service Endpoint -------------------- Example: pwg-psitd://mypsitarget.mydomain.com:3700/psitd Notes: (1) REQUIRED 'host' or 'ip-addr' MUST be specified (2) OPTIONAL 'port' MUST default to IANA-assigned value (example assumes port '3700') Background: PSI standard URL schemes are defined elsewhere in this PSI spec. From imcdonald at sharplabs.com Thu Jan 9 18:04:10 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:16 2009 Subject: PS> 'reference.xsd' to simple URLs Message-ID: <116DB56CD7DED511BC7800508B2CA53735CE7D@mailsrvnt02.enet.sharplabs.com> Hi Dave, Thursday (9 January 2003) Below is my best effort to replace the PSI 'reference.xsd' with simple URLs (with a few query part parameters). More work is still needed on the RFC 2822 (SMTP) format for references to specific messages and body parts and attachments of those messages, for POP3 (see IMAP4 below). Cheers, - Ira McDonald High North Inc ---------------------------------------- * Convert current "reference.xsd" to use _only_ URLs URL --- Background: See "Uniform Resource Identifiers (URI): Generic Syntax" (RFC 2396). FTP --- Example: ftp://joe:blues@myhost.com:21/somefile.txt?passive=true;mode=binary Notes: (1) OPTIONAL 'user' here is 'joe' (2) OPTIONAL 'password' here is 'blues' (3) REQUIRED 'host' here is 'myhost.com' (4) OPTIONAL 'port' here is '21' (the default for FTP) (5) OPTIONAL 'fpath' here is 'somefile.txt' (6) PSI-defined query extension 'passive' here is 'true' (7) PSI-defined query extension 'mode' here is 'binary' (as opposed to 'text') Background: >From section 5 of "Uniform Resource Locators (URL)" (RFC 1738): ftpurl = "ftp://" login [ "/" fpath [ ";type=" ftptype ]] fpath = fsegment *[ "/" fsegment ] fsegment = *[ uchar | "?" | ":" | "@" | "&" | "=" ] ftptype = "A" | "I" | "D" | "a" | "i" | "d" login = [ user [ ":" password ] "@" ] hostport hostport = host [ ":" port ] FILE ---- Example: file://myhost.com/myreference.pdf Notes: (1) OPTIONAL 'host' can be empty of "localhost" (but this is not a safe reference to pass over the network) (2) REQUIRED 'path' MUST specify a specific file Background: >From section 3.10 of "Uniform Resource Locators (URL)" (RFC 1738): The file URL scheme is used to designate files accessible on a particular host computer. This scheme, unlike most other URL schemes, does not designate a resource that is universally accessible over the Internet. A file URL takes the form: file:/// where is the fully qualified domain name of the system on which the is accessible, and is a hierarchical directory path of the form //.../. POP3 ---- Example: pop://joe;auth=@mailhost.com:110 (1) (2) (3) (4) Notes: (1) OPTIONAL 'user' parameter MUST be specified for PSI usage (2) OPTIONAL 'auth' parameter MAY be specified for APOP or SASL info (3) REQUIRED 'host' parameter SHOULD NOT be for PSI usage (4) OPTIONAL 'port' parameter defaults to 110 Background: >From section 3 of "POP URL Scheme", RFC 2384, August 1998: "The POP URL scheme designates a POP server, and optionally a port number, authentication mechanism, authentication ID, and/or authorization ID. The POP URL follows the common Internet scheme syntax as defined in RFC 1738 [BASIC-URL] except that clear text passwords are not permitted. If : is omitted, the port defaults to 110. The POP URL is described using [ABNF] in Section 8. A POP URL is of the general form: pop://;auth=@: Where , , and are as defined in RFC 1738, and some or all of the elements, except "pop://" and , may be omitted." >From section 8 of "POP URL Scheme", RFC 2384, August 1998: "The POP URL scheme is described using [ABNF]: achar = uchar / "&" / "=" / "~" ; see [BASIC-URL] for "uchar" definition auth = ";AUTH=" ( "*" / enc-auth-type ) enc-auth-type = enc-sasl / enc-ext enc-ext = "+" ("APOP" / 1*achar) ;APOP or encoded extension mechanism name enc-sasl = 1*achar ;encoded version of [SASL] "auth_type" enc-user = 1*achar ;encoded version of [POP3] mailbox pop-url = "pop://" server server = [user-auth "@"] hostport ;See [BASIC-URL] for "hostport" definition user-auth = enc-user [auth] IMAP4 ----- Example: >From section 10 of "IMAP URL Scheme", RFC 2192, September 1997: The IMAP URL: Results in the following client commands: C: A001 LOGIN ANONYMOUS sheridan@babylon5.org C: A002 SELECT gray-council C: A003 UID FETCH 20 BODY.PEEK[] Notes: Background: >From section 2 of "IMAP URL Scheme", RFC 2192, September 1997: "The IMAP URL scheme is used to designate IMAP servers, mailboxes, messages, MIME bodies [MIME], and search programs on Internet hosts accessible using the IMAP protocol. The IMAP URL follows the common Internet scheme syntax as defined in RFC 1738 [BASIC-URL] except that clear text passwords are not permitted. If : is omitted, the port defaults to 143. An IMAP URL takes one of the following forms: imap:/// imap:///;TYPE= imap:///[uidvalidity][?] imap:///[uidvalidity][isection] The first form is used to refer to an IMAP server, the second form refers to a list of mailboxes, the third form refers to the contents of a mailbox or a set of messages resulting from a search, and the final form refers to a specific message or message part. Note that the syntax here is informal. The authoritative formal syntax for IMAP URLs is defined in section 11." >From section 12 of "IMAP URL Scheme", RFC 2192, September 1997: "This uses ABNF as defined in RFC 822 [IMAIL]. Terminals from the BNF for IMAP [IMAP4] and URLs [BASIC-URL] are also used. Strings are not case sensitive and free insertion of linear-white-space is not permitted. achar = uchar / "&" / "=" / "~" ; see [BASIC-URL] for "uchar" definition bchar = achar / ":" / "@" / "/" enc_auth_type = 1*achar ; encoded version of [IMAP-AUTH] "auth_type" enc_list_mailbox = 1*bchar ; encoded version of [IMAP4] "list_mailbox" enc_mailbox = 1*bchar ; encoded version of [IMAP4] "mailbox" enc_search = 1*bchar ; encoded version of search_program below enc_section = 1*bchar ; encoded version of section below enc_user = 1*achar ; encoded version of [IMAP4] "userid" imapurl = "imap://" iserver "/" [ icommand ] iauth = ";AUTH=" ( "*" / enc_auth_type ) icommand = imailboxlist / imessagelist / imessagepart imailboxlist = [enc_list_mailbox] ";TYPE=" list_type imessagelist = enc_mailbox [ "?" enc_search ] [uidvalidity] imessagepart = enc_mailbox [uidvalidity] iuid [isection] isection = "/;SECTION=" enc_section iserver = [iuserauth "@"] hostport ; See [BASIC-URL] for "hostport" definition iuid = "/;UID=" nz_number ; See [IMAP4] for "nz_number" definition iuserauth = enc_user [iauth] / [enc_user] iauth list_type = "LIST" / "LSUB" search_program = ["CHARSET" SPACE astring SPACE] search_key *(SPACE search_key) ; IMAP4 literals may not be used ; See [IMAP4] for "astring" and "search_key" section = section_text / (nz_number *["." nz_number] ["." (section_text / "MIME")]) ; See [IMAP4] for "section_text" and "nz_number" uidvalidity = ";UIDVALIDITY=" nz_number ; See [IMAP4] for "nz_number" definition UNC --- Example: pwg-unc:\\myprintserver\myprinter Notes: (1) Proposed new PWG standard URL scheme for UNC encapsulation (2) ALL printable ASCII characters are legal in the UNC, including the BACKSLASH (0x5C) Background: Microsoft uses UNC identifiers in Windows environments. From alan.berkema at hp.com Fri Jan 10 14:13:51 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:16 2009 Subject: PS> [PSI]: Spec contributors Message-ID: <499DC368E25AD411B3F100902740AD650E6AD56A@xrose03.rose.hp.com> Please let me know if you would like you name included as a contributor, if you are not already on the list. Thanks, Alan From alan.berkema at hp.com Fri Jan 10 20:08:41 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:16 2009 Subject: PS> [PSI]: next call 01/14/03 Message-ID: <499DC368E25AD411B3F100902740AD650E6AD57A@xrose03.rose.hp.com> Teleconference details: NEXT: Tuesday January 14 2003 (USA) NO CALL: - Tuesday January 21 NEXT: Tuesday January 28 2003 USA) Time: 8 AM (US PST) Number: 404-774-4112(T774-4112) ID: 55605 Agenda: 1) Discovery - upnp-dev 2) Look at mDNS-SD examples 3) Spec review topics WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 21643883 Meeting Password: newpsi Host: Alan Berkema 1(916)7855605 From dhall at hp.com Mon Jan 13 12:28:23 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:16 2009 Subject: PS> Latest PSI Documents (95a) Message-ID: <77261E830267D411BD4D00902740AC250DB4C466@xvan01.vcd.hp.com> Hi All.. I have them ready, but the FTP server is down! Sorry about blasting the list, but I'm not sure exactly who to notify. As soon as it is up, I will publish documents and re-notify the list. Dave From dhall at hp.com Mon Jan 13 13:47:16 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:16 2009 Subject: PS> 0.95 PSI Specifcation available for Review Message-ID: <77261E830267D411BD4D00902740AC250DB4C46A@xvan01.vcd.hp.com> Hi All.. The 0.95a PSI Specification is available for review at: ftp://ftp.pwg.org/pub/pwg/ps/psi-spec95a.pdf and ftp://ftp.pwg.org/pub/pwg/ps/psi-spec95a.doc This is the specification that we will perform a page-turner at the Jan PWG meeting. Thanks! Dave From dhall at hp.com Tue Jan 14 10:59:40 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:16 2009 Subject: PS> New WebEx Info for 1/14 Message-ID: <77261E830267D411BD4D00902740AC250DB4C47C@xvan01.vcd.hp.com> New meeting info: Meeting ID: 24004938 Password: newpsi Dave From imcdonald at sharplabs.com Tue Jan 14 13:00:10 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:16 2009 Subject: PS> SSL/3.0 and TLS/1.0 details and references Message-ID: <116DB56CD7DED511BC7800508B2CA53735CE80@mailsrvnt02.enet.sharplabs.com> Hi folks, Tuesday (14 January 2003) At today's PSI Telecon, we agreed that a conforming PSI Client, Print Service, or Target Device that claims to support secure operation MUST support either: (a) Netscape SSL 3.0; or (b) IETF TLS 1.0 (version "3.1" over-the-wire). I further propose that a conforming PSI Client, Print Service, or Target Device that claims to support secure operation MUST NOT negotiate down to Netscape SSL 2.0 (to avoid compromised session security). Per my action item from today's PSI Telecon, below are some details from the IETF TLS 1.0 spec (RFC 2246) about fallback to Netscape SSL 3.0. Cheers, - Ira McDonald High North Inc ------------------------------------------------------------------------ References for SSL and TLS specs: [SSL2] Hickman, Kipp, "The SSL Protocol", Netscape Communications Corp., Feb 9, 1995. [SSL3] Frier, Karlton, Kocher, "The SSL 3.0 Protocol", Netscape Communications Corp., Nov 18, 1996. [TLS10] Dierks, Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. - version "3.1" over-the-wire ftp://ftp.isi.edu/in-notes/rfc2246.txt [TLS11] Dierks, Rescorla, "The TLS Protocol Version 1.1", work-in-progress, October 2002. - version "3.2" over-the-wire ftp://ftp.ietf.org/internet-drafts/ draft-ietf-tls-rfc2246-bis-02.txt ------------------------------------------------------------------------ Excerpt from "The TLS Protocol Version 1.0" (RFC 2246, January 1999): E. Backward Compatibility With SSL For historical reasons and in order to avoid a profligate consumption of reserved port numbers, application protocols which are secured by TLS 1.0, SSL 3.0, and SSL 2.0 all frequently share the same connection port: for example, the https protocol (HTTP secured by SSL or TLS) uses port 443 regardless of which security protocol it is using. Thus, some mechanism must be determined to distinguish and negotiate among the various protocols. TLS version 1.0 and SSL 3.0 are very similar; thus, supporting both is easy. TLS clients who wish to negotiate with SSL 3.0 servers should send client hello messages using the SSL 3.0 record format and client hello structure, sending {3, 1} for the version field to note that they support TLS 1.0. If the server supports only SSL 3.0, it will respond with an SSL 3.0 server hello; if it supports TLS, with a TLS server hello. The negotiation then proceeds as appropriate for the negotiated protocol. Similarly, a TLS server which wishes to interoperate with SSL 3.0 clients should accept SSL 3.0 client hello messages and respond with an SSL 3.0 server hello if an SSL 3.0 client hello is received which has a version field of {3, 0}, denoting that this client does not support TLS. Whenever a client already knows the highest protocol known to a server (for example, when resuming a session), it should initiate the connection in that native protocol. TLS 1.0 clients that support SSL Version 2.0 servers must send SSL Version 2.0 client hello messages [SSL2]. TLS servers should accept either client hello format if they wish to support SSL 2.0 clients on the same connection port. The only deviations from the Version 2.0 specification are the ability to specify a version with a value of three and the support for more ciphering types in the CipherSpec. Warning: The ability to send Version 2.0 client hello messages will be phased out with all due haste. Implementors should make every effort to move forward as quickly as possible. Version 3.0 provides better mechanisms for moving to newer versions. The following cipher specifications are carryovers from SSL Version 2.0. These are assumed to use RSA for key exchange and authentication. V2CipherSpec TLS_RC4_128_WITH_MD5 = { 0x01,0x00,0x80 }; V2CipherSpec TLS_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 }; V2CipherSpec TLS_RC2_CBC_128_CBC_WITH_MD5 = { 0x03,0x00,0x80 }; V2CipherSpec TLS_RC2_CBC_128_CBC_EXPORT40_WITH_MD5 = { 0x04,0x00,0x80 }; V2CipherSpec TLS_IDEA_128_CBC_WITH_MD5 = { 0x05,0x00,0x80 }; V2CipherSpec TLS_DES_64_CBC_WITH_MD5 = { 0x06,0x00,0x40 }; V2CipherSpec TLS_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 }; Cipher specifications native to TLS can be included in Version 2.0 client hello messages using the syntax below. Any V2CipherSpec element with its first byte equal to zero will be ignored by Version 2.0 servers. Clients sending any of the above V2CipherSpecs should also include the TLS equivalent (see Appendix A.5): V2CipherSpec (see TLS name) = { 0x00, CipherSuite }; From alan.berkema at hp.com Tue Jan 14 23:22:37 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:16 2009 Subject: PS> [PSI]: minutes 01/14/03 Message-ID: <499DC368E25AD411B3F100902740AD65163FAA7D@xrose03.rose.hp.com> PSI Working Group: *Alan Berkema *Dave Hall Gail Songer Jerry Thasher *Harry Lewis *Ted Tronson *Peter Mierau Peter Zehler Paul Tykodi Bob Taylor Don Levinstone Lee Farrell Don Wright Kirk Ocke *Ira Mcdonald Amir Shahindoust *Alain Regnier * = attendance 01/14/03 Agenda 1) Discovery - upnp-dev 2) Look at mDNS-SD examples 3) Spec review topics 01/14/03 Minutes: 0) Rev 0.95a (candidate for 0.95) was posted on the morning of January 13 2003. This gives us a week to review before the start of the week of PWG F2F meetings. Page turner review at PSI F2F January 24 2003. When reviewing this spec for the F2F please think about practical implementation details such as how many Jobs a Target Device should be able to support concurrently. Ideally, at the F2F we will identify what needs to be fixed to have a last call for comments before we promote the spec to revision 0.95 At 0.95 the spec will be theoretically frozen. Changes to the spec will be conducted via an errata process. One exception is the WSDL itself. The WSDL will evolve through versioning since an errata process does not really make sense for WSDL, we really want an entire latest greatest version of the WSDL which includes all bug fixes. 1) Looked at the upnp-dev from: http://www.upnp.org/download/Printer_Definition_v1_020808.pdfII.pdf The Device Description is described in section 3. We need to define the mandatory fields for both upnp-dev and for LDAPv3. 2) mDNS-Sd examples at F2F 3) What do we need for the HTTPS port? psi-port+1 is no longer being approved by the IESG. A different path is recommended. Dave captured the ideas as proposed changes to psi-spec rev 0.95a (in a separate document). Part of this approach uses an HTTP layer header for security "upgrade" need more details here. ---------------------------- Action: Status from 01/07/03 Action: Send SSDP example to Dave Owner: Alan Status: Done Action: Investigate what needs to be done for UPnP-dev device description via UPnP Print Device documentation. Owner: Alan Status: Done Action: Send latest SLPv2 LDAPv3 examples to Dave Owner: Ira Status: Done Action: Send new proposals for Reference and Target Device by afternoon of 01/09/03 Owner: Ira Status: Done Action: e-mail discussion of state of current tool kit issues Owner: Dave Status: Done Action: Determine if Web Sphere tools have similar limitations Owner: Alan Status: Open >From 01/07/03 General spec discussion: Need some Normative statements on authentication: Discovery? Normative part of spec or developer's guide? I think discovery is what Bluetooth calls "process mandatory" This means that, if a feature (such as a discovery protocol) is used, it is used in the specified manner. Interop events? As soon as we have a few companies that are ready HP will host an event, off cycle from PWG meetings. How many devices do we need? Need interop test criteria such as what features will be supported what discovery is used etc. From alan.berkema at hp.com Thu Jan 16 18:07:41 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:16 2009 Subject: PS> [PSI]: Process Change Proposal Message-ID: <499DC368E25AD411B3F100902740AD650E6AD591@xrose03.rose.hp.com> all, Please see attached for discussion at F2F Mahalo, Alan <> -------------- next part -------------- A non-text attachment was scrubbed... Name: agenda_012403.pdf Type: application/octet-stream Size: 92974 bytes Desc: not available Url : http://www.pwg.org/archives/ps/attachments/20030116/2754c5a8/agenda_012403-0001.obj From imcdonald at sharplabs.com Thu Jan 23 16:22:58 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:16 2009 Subject: PS> RFC 3470 (BCP 70) Guidelines for use of XML in IETF Protocols Message-ID: <116DB56CD7DED511BC7800508B2CA53735CE91@mailsrvnt02.enet.sharplabs.com> Hi folks, Excellent reading. ftp://ftp.isi.edu/in-notes/rfc3470.txt I particularly enjoyed the discussion of XML validation using ISO SGML DTD, W3C XML Schema, and OASIS RELAX-NG in section 4.7. Cheers, - Ira McDonald High North Inc ---------------------------------- [excerpts from RFC 3470] Abstract The Extensible Markup Language (XML) is a framework for structuring data. While it evolved from Standard Generalized Markup Language (SGML) -- a markup language primarily focused on structuring documents -- XML has evolved to be a widely-used mechanism for representing structured data. There are a wide variety of Internet protocols being developed; many have need for a representation for structured data relevant to their application. There has been much interest in the use of XML as a representation method. This document describes basic XML concepts, analyzes various alternatives in the use of XML, and provides guidelines for the use of XML within IETF standards-track protocols. Table of Contents Conventions Used In This Document . . . . . . . . . . . . . . . . 2 1. Introduction and Overview . . . . . . . . . . . . . . . . . 2 1.1 Intended Audience. . . . . . . . . . . . . . . . . . . 3 1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 XML Evolution . . . . . . . . . . . . . . . . . . . . 3 1.4 XML Users, Support Groups, and Additional Information. . . . . . . . . . . . . . . . . . . . . . 4 2. XML Selection Considerations . . . . . . . . . . . . . . . . 4 3. XML Alternatives . . . . . . . . . . . . . . . . . . . . . . 5 4. XML Use Considerations and Recommendations . . . . . . . . . 7 4.1 XML Syntax and Well-Formedness . . . . . . . . . . . . 7 4.2 XML Information Set . . . . . . . . . . . . . . . . . 7 4.3 Syntactic Restrictions . . . . . . . . . . . . . . . . 8 4.4 XML Declarations . . . . . . . . . . . . . . . . . . . 9 4.5 XML Processing Instructions . . . . . . . . . . . . . 9 4.6 XML Comments . . . . . . . . . . . . . . . . . . . . . 10 4.7 Validity and Extensibility . . . . . . . . . . . . . . 10 4.8 Semantics as Well as Syntax. . . . . . . . . . . . . . 12 4.9 Namespaces . . . . . . . . . . . . . . . . . . . . . . 12 4.9.1 Namespaces and Attributes. . . . . . . . . . . . 13 4.10 Element and Attribute Design Considerations. . . . . . 14 4.11 Binary Data and Text with Control Characters . . . . . 16 4.12 Incremental Processing . . . . . . . . . . . . . . . . 16 4.13 Entity Declarations and Entity References . . . . . . 16 4.14 External References . . . . . . . . . . . . . . . . . 17 4.15 URI Processing . . . . . . . . . . . . . . . . . . . . 17 4.16 White Space . . . . . . . . . . . . . . . . . . . . . 18 4.17 Interaction with the IANA . . . . . . . . . . . . . . 19 5. Internationalization Considerations . . . . . . . . . . . . 19 5.1 Character Sets and Encodings . . . . . . . . . . . . . 19 5.2 Language Declaration . . . . . . . . . . . . . . . . . 20 5.3 Other Internationalization Considerations . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21 7. Security Considerations . . . . . . . . . . . . . . . . . . 21 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 9. Normative References . . . . . . . . . . . . . . . . . . . . 22 10. Informative References . . . . . . . . . . . . . . . . . . . 23 11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 27 12. Full Copyright Statement . . . . . . . . . . . . . . . . . . 28 From imcdonald at sharplabs.com Sat Jan 25 14:29:54 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:16 2009 Subject: PS> FW: Secure / Unsecure on one port. Message-ID: <116DB56CD7DED511BC7800508B2CA53735CE96@mailsrvnt02.enet.sharplabs.com> Hi folks, See below for clarification of how a single port works just fine (with HTTP/1.1 or any other session protocol) for upgrade in the same connection to TLS mode (always secure, optionally encrypted). Cheers, - Ira McDonald High North Inc -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Friday, January 24, 2003 4:04 PM To: McDonald, Ira Subject: RE: Secure / Unsecure on one port. Ira, thanks for the response. We just reviewed it at the f2f and switched our position which, earlier today, was 2 ports. OK if I forward your note to the PSI reflector as it captures the topic better than anything I'v seen. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "McDonald, Ira" 01/24/2003 01:22 PM To: Harry Lewis/Boulder/IBM@IBMUS, "McDonald, Ira" cc: Subject: RE: Secure / Unsecure on one port. Hi Harry, Works exactly like shipping 'ipp:' implementations today. You come in on the standard PSI port (e.g., '3700' - some port that is NOT a kernel-mode port less than '1024' decimal) with an HTTP request (e.g., read capabilities of PSI service) and the server replies with '426 Upgrade Required' (see below). The client then MUST initiate the TLS upgrade (see below). The details for all generic HTTP applications are spelled out in the 'standards track' RFC 2817 "Upgrading to TLS Within HTTP/1.1". See section 3 'Client Requested Upgrade to HTTP over TLS' and section 4 'Server Requested Upgrade to HTTP over TLS' and section 5 'Upgrade across Proxies' of RFC 2817. Cheers, - Ira ------------------------------------------ [excerpts from RFC 2817] 1. Motivation The historical practice of deploying HTTP over SSL3 [3] has distinguished the combination from HTTP alone by a unique URI scheme and the TCP port number. The scheme 'http' meant the HTTP protocol alone on port 80, while 'https' meant the HTTP protocol over SSL on port 443. Parallel well-known port numbers have similarly been requested -- and in some cases, granted -- to distinguish between secured and unsecured use of other application protocols (e.g. snews, ftps). This approach effectively halves the number of available well known ports. At the Washington DC IETF meeting in December 1997, the Applications Area Directors and the IESG reaffirmed that the practice of issuing parallel "secure" port numbers should be deprecated. The HTTP/1.1 Upgrade mechanism can apply Transport Layer Security [6] to an open HTTP connection. In the nearly two years since, there has been broad acceptance of the concept behind this proposal, but little interest in implementing alternatives to port 443 for generic Web browsing. In fact, nothing in this memo affects the current interpretation of https: URIs. However, new application protocols built atop HTTP, such as the Internet Printing Protocol [7], call for just such a mechanism in order to move ahead in the IETF standards process. The Upgrade mechanism also solves the "virtual hosting" problem. Rather than allocating multiple IP addresses to a single host, an HTTP/1.1 server will use the Host: header to disambiguate the intended web service. As HTTP/1.1 usage has grown more prevalent, more ISPs are offering name-based virtual hosting, thus delaying IP address space exhaustion. TLS (and SSL) have been hobbled by the same limitation as earlier versions of HTTP: the initial handshake does not specify the intended hostname, relying exclusively on the IP address. Using a cleartext HTTP/1.1 Upgrade: preamble to the TLS handshake -- choosing the certificates based on the initial Host: header -- will allow ISPs to provide secure name-based virtual hosting as well. ... 4.2 Mandatory Advertisement A server MAY indicate that a client request can not be completed without TLS using the "426 Upgrade Required" status code, which MUST include an an Upgrade header field specifying the token of the required TLS version. HTTP/1.1 426 Upgrade Required Upgrade: TLS/1.0, HTTP/1.1 Connection: Upgrade The server SHOULD include a message body in the 426 response which indicates in human readable form the reason for the error and describes any alternative courses which may be available to the user. Note that even if a client is willing to use TLS, it must use the operations in Section 3 to proceed; the TLS handshake cannot begin immediately after the 426 response. -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Friday, January 24, 2003 1:29 PM To: McDonald, Ira Subject: Secure / Unsecure on one port. Ira, we're having difficulty in the f2f discussions with the concept of 1 vs 2 ports for secure and unsecure connections. I recall, in a phone conv, that you described a method for coming in on (port 3700 ex.) unsecure and negotiating, immediately, to secure. Don't think anyone here knows how this works. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- From alan.berkema at hp.com Mon Jan 27 12:29:34 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:16 2009 Subject: PS> [PSI]: ?? next call 01/28/03 Message-ID: <499DC368E25AD411B3F100902740AD650E6AD5B0@xrose03.rose.hp.com> Hey all, This is a place holder for tomorrow's call. I can't get at the web sites to confirm the call info though I think it is still accurate. Seems web access is being affected by that worm thing. I'll update when I can. Also, I may have jury duty :) Thanks, Alan ---- Teleconference details: NEXT: Tuesday January 28 2003 (USA) Time: 8 AM (US PST) Number: 404-774-4112(T774-4112) ID: 55605 Agenda: 1) TBD WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 21643883 Meeting Password: newpsi Host: Alan Berkema 1(916)7855605 From harryl at us.ibm.com Mon Jan 27 16:01:29 2003 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:02:16 2009 Subject: PS> Possible Interop Timeframes Message-ID: I'm getting my constraints in as early as possible into the interop scheduling equation. After returning from Maui and talking with my team we would prefer f2f Inerop dates in the following priority August Late June Early May April We would strongly like to avoid Late May, Early June. Key developers who will participate in interop event will be unavailable. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/ps/attachments/20030127/fc1319d3/attachment-0001.html From alan.berkema at hp.com Mon Jan 27 18:21:39 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:16 2009 Subject: PS> [PSI]:next call 01/28/03 info OK Message-ID: <499DC368E25AD411B3F100902740AD650E6AD5BE@xrose03.rose.hp.com> I'm back on the web info is correct. Just got to worry about jury duty. Alan > > Hey all, > > This is a place holder for tomorrow's call. > I can't get at the web sites to confirm > the call info though I think it is still > accurate. Seems web access is being affected > by that worm thing. I'll update when I can. > > Also, I may have jury duty :) > > Thanks, > Alan > ---- > > Teleconference details: > > NEXT: Tuesday January 28 2003 (USA) > > Time: 8 AM (US PST) > Number: 404-774-4112(T774-4112) > ID: 55605 > > Agenda: > 1) TBD > > WebEx info: > ------------------------- > FIRST TIME USERS > ------------------------- > For fully interactive meetings, including the ability > to present your documents and applications, a one-time > setup takes less than 10 minutes. Click this URL to set up now: > https://hp.webex.com/join/ > Then click New User. > ------------------------- > MEETING SUMMARY > ------------------------- > Name: PSI > Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada > Meeting Number: 21643883 > Meeting Password: newpsi > Host: Alan Berkema > 1(916)7855605 > From dhall at hp.com Mon Jan 27 18:31:23 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:16 2009 Subject: PS> Tomorrow's PSI Meeting Agenda Message-ID: <77261E830267D411BD4D00902740AC250DB4C66C@xvan01.vcd.hp.com> Hey All.. I would like to review the following two things at tomorrows conference call. We missed reviewing them on Friday... Thanks! Dave Section 6.1 TargetDeviceIdentifier - Change the introductory paragraph to be: The Target Device Identifier allows for Clients to specify legacy Target Devices as well as new PSI capable Target Devices. It is up to the Print Service to provide the proxy support for that legacy device if it so chooses. The TargetDeviceIdentifier is specified by a URL. The client is allowed to specify any existing, or yet to be defined URL schemes that refer to a potential Target Device. Below is a list of existing URL schemes that should be taken into consideration when implementing a Print Service. A Print Service must support the PSI Service Root URL Target Device Identifier. <-- do we need a statement to this effect? Section 6.1.4: Should be named psiServiceRootURL Examples: pwg-psips://MyPsiServiceTarget.mydomain.com:psi-port/psi/ pwg-psitd://MyPsiTargetDeviceTarget.mydomain.com:psi-port/psi/ Notes: (1) REQUIRED 'host' or 'ip-addr' MUST be specified (2) REQUIRED 'port' MUST default to PWG PSI IANA-assigned value (example assumes port 'psi-port') If a Print Services whishes to expose a proxy PSI TargetDevice for a legacy Target Device, it may do so by adding appropriate query parameters to the psiServiceRootURL which would allow the Print Service to identify that the client has discovered, and is wishing to utilize the legacy Target Device. This query parameter is: * LegacyTargetDeviceID Example: pwg-psitd://mypsitarget.mydomain.com:psi-port/psi/?LegacyTargetDevi ceID=132452523 From alan.berkema at hp.com Fri Jan 31 13:44:18 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:16 2009 Subject: PS> [PSI]: next call 02/04/03 Message-ID: <499DC368E25AD411B3F100902740AD650E6AD5FE@xrose03.rose.hp.com> Teleconference details: NEXT: Tuesday February 04 2003 (USA) Time: 8 AM (US PST) Number: 404-774-4112(T774-4112) ID: 55605 Agenda: 1) TBD WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 21643883 Meeting Password: newpsi Host: Alan Berkema 1(916)7855605 From imcdonald at sharplabs.com Mon Feb 3 19:43:58 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:16 2009 Subject: PS> [PSI]: next call 02/04/03 [versions] Message-ID: <116DB56CD7DED511BC7800508B2CA53735CEA6@mailsrvnt02.enet.sharplabs.com> Hi Alan, An obvious agenda topic is a discussion of: (a) concrete protocol versions over-the-wire (in protocol operations and envelopes) (b) concrete WSDL interface versions (in URLs of component schemas) (c) abstract protocol spec versions (on cover pages and in the URLs of spec documents) See Dave Hall's note today on the pwg@pwg.org mailing list. Cheers, - Ira McDonald High North Inc -----Original Message----- From: BERKEMA,ALAN C (HP-Roseville,ex1) [mailto:alan.berkema@hp.com] Sent: Friday, January 31, 2003 12:44 PM To: 'a PSI pwg.org' Subject: PS> [PSI]: next call 02/04/03 Teleconference details: NEXT: Tuesday February 04 2003 (USA) Time: 8 AM (US PST) Number: 404-774-4112(T774-4112) ID: 55605 Agenda: 1) TBD WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 21643883 Meeting Password: newpsi Host: Alan Berkema 1(916)7855605 From dhall at hp.com Tue Feb 4 10:50:09 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:16 2009 Subject: PS> PSI WebEx Info and Versioning Discussion Material Message-ID: <77261E830267D411BD4D00902740AC250DB4C779@xvan01.vcd.hp.com> ------------------------- MEETING SUMMARY ------------------------- Name: psi Date: 2/4/2003 Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 21865515 Meeting Password: newpsi Things we need to track: Specification Document Version - (IPP 1.0, IPP 1.1, PSI 1.0, PSI 1.1, etc) Specification Document Revision - (Date?) Specification Goodness - (3 states, with ability to differentiate a document that has just been published from one that has been accepted) - States: (a) Draft, (b) Proposal, (c) Standard - Acceptance: (1) Working, (2) Accepted Individual Interface Version - (0.01 - 0.99, 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.1.0, 1.1.1, 1.1.2, etc) Individual Interface Revision - (1, 2, 3, 4, 5...) Individual Interface Namespace - (?) Schema Revision - (0.01 - 0.99, 1.0.0, 1.0.1, 1.0.2, etc) Schema Namespace - (?) Requirements: Published WSDL and Schema needs to remain accessible. A Specification Document should be able to refer to different Interface Revisions. (i.e. 1.1 of the PSI Specification should be able to reference QueryEndPointsInterface v1.0.5 if we don't need to change it for 1.1) Reference: Versioning Everyone who developed COM applications: How many of you remember the golden rules of versioning? Okay, hands down. As a quick review, here are the rules: 1. Always increment the version number. 2. Freeze the interface on the previous version. All new features should go into a new interface. 3. Freeze all structures used on the previous version. Any enhancements to those structures should show up in new structures. WSDL version indication is done via the targetNamespace attribute of the definitions element. This namespace gives the SOAP messages meaning by relating the messages to a specific bit of code implemented somewhere on the server. The targetNamespace attribute has an XSD type of anyURI. This attribute could be used in a large number of ways to indicate the version. For a service named Foo that was hosted at msdn.microsoft.com, a few options exist for the first version. Option 1: The targetNamespace could be named http://msdn.microsoft.com/foo. This works by giving the interface a unique namespace name. This option does not fit our needs, however, because it does not include an obvious mechanism for indicating whether one version is earlier or later than another. I suppose you could follow up later versions of the interface with namespaces such as http://msdn.microsoft.com/foo1 and http://msdn.microsoft.com/foo2, but that seems silly. Option 2: The targetNamespace could be named http://msdn.microsoft.com/1.0/foo. Again, this gives the interface a unique namespace identifier. This option fits our needs, because it gives us an obvious indicator of version as well as a place to increment that version in a way people are used to seeing. As we are dealing with an XML-centric world, however, we might do well to follow the lead of the newer XML specifications, such as SOAP 1.2, XML Schema, and XSLT. While this option is viable, it does not follow this lead. Option 3: Call the targetNamespace http://msdn.microsoft.com/2002/04/foo. This has a few small advantages over option 2. For one, this is the versioning scheme employed by the newer XML specifications. People who are used to looking at XML will find versioning by date more familiar. As an added bonus, versioning by date allows a person or machine to easily figure out when the version was released. You can increase the resolution of the version to reflect the frequency of releases. A resolution down to the hour would indicate that releases are coming out far too frequently. If your team does nightly builds, extend the interim granularity of the version to the date of the build. Regardless of what you do, don't be cute and use zero-based month and day-of-month numbers. It's counterintuitive. Of the above options, both 2 and 3 fit the bill, with 3 being the versioning option that many XML users I have talked to like the best. An added advantage of date-based versioning is that you will know how long the interface has been available. When changing an XSD type, create a brand new type in a brand new namespace. This new namespace should still stick with your versioning model. If the first version was in a namespace such as http://foo.org/bar/2001/11/20/types, the new namespace should only change the date information. That new type, if published on April 5, 2002, should be in the namespace http://foo.org/bar/2002/04/05/types. Any related sub-types should remain in the old namespace and simply get imported into the new one. Here, no wishy-washy answers. To sum things up, here are the guidelines to use when updating an interface: * The changes always go into a new namespace. * The new interface should be a superset of the old one. * It is a good idea to keep the data model the same when versioning the interface. * Never revise data structures. Instead, add new ones as needed. From imcdonald at sharplabs.com Tue Feb 4 10:56:26 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:16 2009 Subject: PS> PSI WebEx Info and Versioning Discussion Material Message-ID: <116DB56CD7DED511BC7800508B2CA53735CEA8@mailsrvnt02.enet.sharplabs.com> Hi Dave, You've just shown an example of why I urged that we reduce the PWG 'standards track' to two states last Thursday. The IETF (and current PWG) 'standards track' states are: (a) Proposed (b) Draft (c) Standard. The overloading of 'draft' in both Working-Draft and the MIDDLE state of the 'standards track' is a bad problem. Also, the IETF actually VERY rarely advances a document all the way to 'Standard'. Mostly, they struggle to get to 'Draft Standard'. Cheers, - Ira McDonald High North Inc -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Tuesday, February 04, 2003 9:50 AM To: 'ps@pwg.org' Subject: PS> PSI WebEx Info and Versioning Discussion Material ------------------------- MEETING SUMMARY ------------------------- Name: psi Date: 2/4/2003 Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 21865515 Meeting Password: newpsi Things we need to track: Specification Document Version - (IPP 1.0, IPP 1.1, PSI 1.0, PSI 1.1, etc) Specification Document Revision - (Date?) Specification Goodness - (3 states, with ability to differentiate a document that has just been published from one that has been accepted) - States: (a) Draft, (b) Proposal, (c) Standard - Acceptance: (1) Working, (2) Accepted Individual Interface Version - (0.01 - 0.99, 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.1.0, 1.1.1, 1.1.2, etc) Individual Interface Revision - (1, 2, 3, 4, 5...) Individual Interface Namespace - (?) Schema Revision - (0.01 - 0.99, 1.0.0, 1.0.1, 1.0.2, etc) Schema Namespace - (?) Requirements: Published WSDL and Schema needs to remain accessible. A Specification Document should be able to refer to different Interface Revisions. (i.e. 1.1 of the PSI Specification should be able to reference QueryEndPointsInterface v1.0.5 if we don't need to change it for 1.1) Reference: Versioning Everyone who developed COM applications: How many of you remember the golden rules of versioning? Okay, hands down. As a quick review, here are the rules: 1. Always increment the version number. 2. Freeze the interface on the previous version. All new features should go into a new interface. 3. Freeze all structures used on the previous version. Any enhancements to those structures should show up in new structures. WSDL version indication is done via the targetNamespace attribute of the definitions element. This namespace gives the SOAP messages meaning by relating the messages to a specific bit of code implemented somewhere on the server. The targetNamespace attribute has an XSD type of anyURI. This attribute could be used in a large number of ways to indicate the version. For a service named Foo that was hosted at msdn.microsoft.com, a few options exist for the first version. Option 1: The targetNamespace could be named http://msdn.microsoft.com/foo. This works by giving the interface a unique namespace name. This option does not fit our needs, however, because it does not include an obvious mechanism for indicating whether one version is earlier or later than another. I suppose you could follow up later versions of the interface with namespaces such as http://msdn.microsoft.com/foo1 and http://msdn.microsoft.com/foo2, but that seems silly. Option 2: The targetNamespace could be named http://msdn.microsoft.com/1.0/foo. Again, this gives the interface a unique namespace identifier. This option fits our needs, because it gives us an obvious indicator of version as well as a place to increment that version in a way people are used to seeing. As we are dealing with an XML-centric world, however, we might do well to follow the lead of the newer XML specifications, such as SOAP 1.2, XML Schema, and XSLT. While this option is viable, it does not follow this lead. Option 3: Call the targetNamespace http://msdn.microsoft.com/2002/04/foo. This has a few small advantages over option 2. For one, this is the versioning scheme employed by the newer XML specifications. People who are used to looking at XML will find versioning by date more familiar. As an added bonus, versioning by date allows a person or machine to easily figure out when the version was released. You can increase the resolution of the version to reflect the frequency of releases. A resolution down to the hour would indicate that releases are coming out far too frequently. If your team does nightly builds, extend the interim granularity of the version to the date of the build. Regardless of what you do, don't be cute and use zero-based month and day-of-month numbers. It's counterintuitive. Of the above options, both 2 and 3 fit the bill, with 3 being the versioning option that many XML users I have talked to like the best. An added advantage of date-based versioning is that you will know how long the interface has been available. When changing an XSD type, create a brand new type in a brand new namespace. This new namespace should still stick with your versioning model. If the first version was in a namespace such as http://foo.org/bar/2001/11/20/types, the new namespace should only change the date information. That new type, if published on April 5, 2002, should be in the namespace http://foo.org/bar/2002/04/05/types. Any related sub-types should remain in the old namespace and simply get imported into the new one. Here, no wishy-washy answers. To sum things up, here are the guidelines to use when updating an interface: * The changes always go into a new namespace. * The new interface should be a superset of the old one. * It is a good idea to keep the data model the same when versioning the interface. * Never revise data structures. Instead, add new ones as needed. From don at lexmark.com Tue Feb 4 11:19:26 2003 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:02:16 2009 Subject: PS> PSI WebEx Info and Versioning Discussion Material Message-ID: Gee, I wonder if a "Working Draft" is different from a "Draft Standard" ??????? Of course, I have trouble telling a "Surf Board" from a "School Board" because they both have the word "Board" in them. Maybe it's just me. Perhaps if we skip the short cuts and called a working draft a working draft (and not a draft) we wouldn't have this confusion. ********************************************** Don Wright don@lexmark.com Chair, IEEE SA Standards Board Member, IEEE-ISTO Board of Directors f.wright@ieee.org / f.wright@computer.org Director, Alliances & Standards Lexmark International 740 New Circle Rd Lexington, Ky 40550 859-825-4808 (phone) 603-963-8352 (fax) ********************************************** "McDonald, Ira" @pwg.org on 02/04/2003 10:56:26 AM Sent by: owner-ps@pwg.org To: "'HALL,DAVID (HP-Vancouver,ex1)'" , "'ps@pwg.org'" cc: Subject: RE: PS> PSI WebEx Info and Versioning Discussion Material Hi Dave, You've just shown an example of why I urged that we reduce the PWG 'standards track' to two states last Thursday. The IETF (and current PWG) 'standards track' states are: (a) Proposed (b) Draft (c) Standard. The overloading of 'draft' in both Working-Draft and the MIDDLE state of the 'standards track' is a bad problem. Also, the IETF actually VERY rarely advances a document all the way to 'Standard'. Mostly, they struggle to get to 'Draft Standard'. Cheers, - Ira McDonald High North Inc -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Tuesday, February 04, 2003 9:50 AM To: 'ps@pwg.org' Subject: PS> PSI WebEx Info and Versioning Discussion Material ------------------------- MEETING SUMMARY ------------------------- Name: psi Date: 2/4/2003 Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 21865515 Meeting Password: newpsi Things we need to track: Specification Document Version - (IPP 1.0, IPP 1.1, PSI 1.0, PSI 1.1, etc) Specification Document Revision - (Date?) Specification Goodness - (3 states, with ability to differentiate a document that has just been published from one that has been accepted) - States: (a) Draft, (b) Proposal, (c) Standard - Acceptance: (1) Working, (2) Accepted Individual Interface Version - (0.01 - 0.99, 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.1.0, 1.1.1, 1.1.2, etc) Individual Interface Revision - (1, 2, 3, 4, 5...) Individual Interface Namespace - (?) Schema Revision - (0.01 - 0.99, 1.0.0, 1.0.1, 1.0.2, etc) Schema Namespace - (?) Requirements: Published WSDL and Schema needs to remain accessible. A Specification Document should be able to refer to different Interface Revisions. (i.e. 1.1 of the PSI Specification should be able to reference QueryEndPointsInterface v1.0.5 if we don't need to change it for 1.1) Reference: < http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnservice/ html/service04032002.asp> Versioning Everyone who developed COM applications: How many of you remember the golden rules of versioning? Okay, hands down. As a quick review, here are the rules: 1. Always increment the version number. 2. Freeze the interface on the previous version. All new features should go into a new interface. 3. Freeze all structures used on the previous version. Any enhancements to those structures should show up in new structures. WSDL version indication is done via the targetNamespace attribute of the definitions element. This namespace gives the SOAP messages meaning by relating the messages to a specific bit of code implemented somewhere on the server. The targetNamespace attribute has an XSD type of anyURI. This attribute could be used in a large number of ways to indicate the version. For a service named Foo that was hosted at msdn.microsoft.com, a few options exist for the first version. Option 1: The targetNamespace could be named http://msdn.microsoft.com/foo. This works by giving the interface a unique namespace name. This option does not fit our needs, however, because it does not include an obvious mechanism for indicating whether one version is earlier or later than another. I suppose you could follow up later versions of the interface with namespaces such as http://msdn.microsoft.com/foo1 and http://msdn.microsoft.com/foo2, but that seems silly. Option 2: The targetNamespace could be named http://msdn.microsoft.com/1.0/foo. Again, this gives the interface a unique namespace identifier. This option fits our needs, because it gives us an obvious indicator of version as well as a place to increment that version in a way people are used to seeing. As we are dealing with an XML-centric world, however, we might do well to follow the lead of the newer XML specifications, such as SOAP 1.2, XML Schema, and XSLT. While this option is viable, it does not follow this lead. Option 3: Call the targetNamespace http://msdn.microsoft.com/2002/04/foo. This has a few small advantages over option 2. For one, this is the versioning scheme employed by the newer XML specifications. People who are used to looking at XML will find versioning by date more familiar. As an added bonus, versioning by date allows a person or machine to easily figure out when the version was released. You can increase the resolution of the version to reflect the frequency of releases. A resolution down to the hour would indicate that releases are coming out far too frequently. If your team does nightly builds, extend the interim granularity of the version to the date of the build. Regardless of what you do, don't be cute and use zero-based month and day-of-month numbers. It's counterintuitive. Of the above options, both 2 and 3 fit the bill, with 3 being the versioning option that many XML users I have talked to like the best. An added advantage of date-based versioning is that you will know how long the interface has been available. When changing an XSD type, create a brand new type in a brand new namespace. This new namespace should still stick with your versioning model. If the first version was in a namespace such as http://foo.org/bar/2001/11/20/types, the new namespace should only change the date information. That new type, if published on April 5, 2002, should be in the namespace http://foo.org/bar/2002/04/05/types. Any related sub-types should remain in the old namespace and simply get imported into the new one. Here, no wishy-washy answers. To sum things up, here are the guidelines to use when updating an interface: * The changes always go into a new namespace. * The new interface should be a superset of the old one. * It is a good idea to keep the data model the same when versioning the interface. * Never revise data structures. Instead, add new ones as needed. From dhall at hp.com Tue Feb 4 13:06:32 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:16 2009 Subject: PS> PSI WebEx Info and Versioning Discussion Material Message-ID: <77261E830267D411BD4D00902740AC250DB4C783@xvan01.vcd.hp.com> Hehehe.. :) Actually, that is were we ended up... Working Draft, Candidate Standard, Standard... Look for a document shortly that describes this in detail.. Dave -----Original Message----- From: don@lexmark.com [mailto:don@lexmark.com] Sent: Tuesday, February 04, 2003 8:19 AM To: McDonald, Ira Cc: 'HALL,DAVID (HP-Vancouver,ex1)'; 'ps@pwg.org' Subject: RE: PS> PSI WebEx Info and Versioning Discussion Material Gee, I wonder if a "Working Draft" is different from a "Draft Standard" ??????? Of course, I have trouble telling a "Surf Board" from a "School Board" because they both have the word "Board" in them. Maybe it's just me. Perhaps if we skip the short cuts and called a working draft a working draft (and not a draft) we wouldn't have this confusion. ********************************************** Don Wright don@lexmark.com Chair, IEEE SA Standards Board Member, IEEE-ISTO Board of Directors f.wright@ieee.org / f.wright@computer.org Director, Alliances & Standards Lexmark International 740 New Circle Rd Lexington, Ky 40550 859-825-4808 (phone) 603-963-8352 (fax) ********************************************** "McDonald, Ira" @pwg.org on 02/04/2003 10:56:26 AM Sent by: owner-ps@pwg.org To: "'HALL,DAVID (HP-Vancouver,ex1)'" , "'ps@pwg.org'" cc: Subject: RE: PS> PSI WebEx Info and Versioning Discussion Material Hi Dave, You've just shown an example of why I urged that we reduce the PWG 'standards track' to two states last Thursday. The IETF (and current PWG) 'standards track' states are: (a) Proposed (b) Draft (c) Standard. The overloading of 'draft' in both Working-Draft and the MIDDLE state of the 'standards track' is a bad problem. Also, the IETF actually VERY rarely advances a document all the way to 'Standard'. Mostly, they struggle to get to 'Draft Standard'. Cheers, - Ira McDonald High North Inc -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Tuesday, February 04, 2003 9:50 AM To: 'ps@pwg.org' Subject: PS> PSI WebEx Info and Versioning Discussion Material ------------------------- MEETING SUMMARY ------------------------- Name: psi Date: 2/4/2003 Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 21865515 Meeting Password: newpsi Things we need to track: Specification Document Version - (IPP 1.0, IPP 1.1, PSI 1.0, PSI 1.1, etc) Specification Document Revision - (Date?) Specification Goodness - (3 states, with ability to differentiate a document that has just been published from one that has been accepted) - States: (a) Draft, (b) Proposal, (c) Standard - Acceptance: (1) Working, (2) Accepted Individual Interface Version - (0.01 - 0.99, 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.1.0, 1.1.1, 1.1.2, etc) Individual Interface Revision - (1, 2, 3, 4, 5...) Individual Interface Namespace - (?) Schema Revision - (0.01 - 0.99, 1.0.0, 1.0.1, 1.0.2, etc) Schema Namespace - (?) Requirements: Published WSDL and Schema needs to remain accessible. A Specification Document should be able to refer to different Interface Revisions. (i.e. 1.1 of the PSI Specification should be able to reference QueryEndPointsInterface v1.0.5 if we don't need to change it for 1.1) Reference: < http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnservice/ html/service04032002.asp> Versioning Everyone who developed COM applications: How many of you remember the golden rules of versioning? Okay, hands down. As a quick review, here are the rules: 1. Always increment the version number. 2. Freeze the interface on the previous version. All new features should go into a new interface. 3. Freeze all structures used on the previous version. Any enhancements to those structures should show up in new structures. WSDL version indication is done via the targetNamespace attribute of the definitions element. This namespace gives the SOAP messages meaning by relating the messages to a specific bit of code implemented somewhere on the server. The targetNamespace attribute has an XSD type of anyURI. This attribute could be used in a large number of ways to indicate the version. For a service named Foo that was hosted at msdn.microsoft.com, a few options exist for the first version. Option 1: The targetNamespace could be named http://msdn.microsoft.com/foo. This works by giving the interface a unique namespace name. This option does not fit our needs, however, because it does not include an obvious mechanism for indicating whether one version is earlier or later than another. I suppose you could follow up later versions of the interface with namespaces such as http://msdn.microsoft.com/foo1 and http://msdn.microsoft.com/foo2, but that seems silly. Option 2: The targetNamespace could be named http://msdn.microsoft.com/1.0/foo. Again, this gives the interface a unique namespace identifier. This option fits our needs, because it gives us an obvious indicator of version as well as a place to increment that version in a way people are used to seeing. As we are dealing with an XML-centric world, however, we might do well to follow the lead of the newer XML specifications, such as SOAP 1.2, XML Schema, and XSLT. While this option is viable, it does not follow this lead. Option 3: Call the targetNamespace http://msdn.microsoft.com/2002/04/foo. This has a few small advantages over option 2. For one, this is the versioning scheme employed by the newer XML specifications. People who are used to looking at XML will find versioning by date more familiar. As an added bonus, versioning by date allows a person or machine to easily figure out when the version was released. You can increase the resolution of the version to reflect the frequency of releases. A resolution down to the hour would indicate that releases are coming out far too frequently. If your team does nightly builds, extend the interim granularity of the version to the date of the build. Regardless of what you do, don't be cute and use zero-based month and day-of-month numbers. It's counterintuitive. Of the above options, both 2 and 3 fit the bill, with 3 being the versioning option that many XML users I have talked to like the best. An added advantage of date-based versioning is that you will know how long the interface has been available. When changing an XSD type, create a brand new type in a brand new namespace. This new namespace should still stick with your versioning model. If the first version was in a namespace such as http://foo.org/bar/2001/11/20/types, the new namespace should only change the date information. That new type, if published on April 5, 2002, should be in the namespace http://foo.org/bar/2002/04/05/types. Any related sub-types should remain in the old namespace and simply get imported into the new one. Here, no wishy-washy answers. To sum things up, here are the guidelines to use when updating an interface: * The changes always go into a new namespace. * The new interface should be a superset of the old one. * It is a good idea to keep the data model the same when versioning the interface. * Never revise data structures. Instead, add new ones as needed. From rseeler at adobe.com Tue Feb 4 13:13:11 2003 From: rseeler at adobe.com (Rick Seeler) Date: Wed May 6 14:02:16 2009 Subject: PS> PSI WebEx Info and Versioning Discussion Material In-Reply-To: <77261E830267D411BD4D00902740AC250DB4C783@xvan01.vcd.hp.com> Message-ID: <003701c2cc79$13e09670$21972099@rseeler1> So, you're saying we have a working draft of a proposal for a standard for proposing working drafts, proposals, and standards? ;-) -Rick > -----Original Message----- > From: owner-ps@pwg.org [mailto:owner-ps@pwg.org] On Behalf Of > HALL,DAVID (HP-Vancouver,ex1) > Sent: Tuesday, February 04, 2003 10:07 AM > To: 'don@lexmark.com'; McDonald, Ira > Cc: HALL,DAVID (HP-Vancouver,ex1); 'ps@pwg.org' > Subject: RE: PS> PSI WebEx Info and Versioning Discussion Material > > > Hehehe.. :) > > Actually, that is were we ended up... > > Working Draft, Candidate Standard, Standard... > > Look for a document shortly that describes this in detail.. > > Dave > > -----Original Message----- > From: don@lexmark.com [mailto:don@lexmark.com] > Sent: Tuesday, February 04, 2003 8:19 AM > To: McDonald, Ira > Cc: 'HALL,DAVID (HP-Vancouver,ex1)'; 'ps@pwg.org' > Subject: RE: PS> PSI WebEx Info and Versioning Discussion Material > > > > > Gee, I wonder if a "Working Draft" is different from a "Draft > Standard" ??????? > > Of course, I have trouble telling a "Surf Board" from a > "School Board" because they both have the word "Board" in them. > > Maybe it's just me. > > > > Perhaps if we skip the short cuts and called a working draft > a working draft (and not a draft) we wouldn't have this confusion. > > ********************************************** > Don Wright don@lexmark.com > > Chair, IEEE SA Standards Board > Member, IEEE-ISTO Board of Directors > f.wright@ieee.org / f.wright@computer.org > > Director, Alliances & Standards > Lexmark International > 740 New Circle Rd > Lexington, Ky 40550 > 859-825-4808 (phone) 603-963-8352 (fax) > ********************************************** > > > > > "McDonald, Ira" @pwg.org on > 02/04/2003 10:56:26 AM > > Sent by: owner-ps@pwg.org > > > To: "'HALL,DAVID (HP-Vancouver,ex1)'" , > "'ps@pwg.org'" > > cc: > Subject: RE: PS> PSI WebEx Info and Versioning Discussion Material > > > Hi Dave, > > You've just shown an example of why I urged that we reduce > the PWG 'standards track' to two states last Thursday. > > The IETF (and current PWG) 'standards track' states are: > (a) Proposed (b) Draft (c) Standard. > > The overloading of 'draft' in both Working-Draft and the > MIDDLE state of the 'standards track' is a bad problem. > > Also, the IETF actually VERY rarely advances a document > all the way to 'Standard'. Mostly, they struggle to > get to 'Draft Standard'. > > Cheers, > - Ira McDonald > High North Inc > > > -----Original Message----- > From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] > Sent: Tuesday, February 04, 2003 9:50 AM > To: 'ps@pwg.org' > Subject: PS> PSI WebEx Info and Versioning Discussion Material > > > ------------------------- > MEETING SUMMARY > ------------------------- > Name: psi > Date: 2/4/2003 > Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada > Meeting Number: 21865515 > Meeting Password: newpsi > > > Things we need to track: > > Specification Document Version - (IPP 1.0, IPP 1.1, PSI 1.0, > PSI 1.1, etc) Specification Document Revision - (Date?) > Specification Goodness - (3 states, with ability to > differentiate a document that has just been published from > one that has been accepted) > - States: (a) Draft, (b) Proposal, (c) Standard > - Acceptance: (1) Working, (2) Accepted > Individual Interface Version - (0.01 - 0.99, 1.0.0, 1.0.1, > 1.0.2, 1.0.3, 1.1.0, 1.1.1, 1.1.2, etc) Individual Interface > Revision - (1, 2, 3, 4, 5...) Individual Interface Namespace > - (?) Schema Revision - (0.01 - 0.99, 1.0.0, 1.0.1, 1.0.2, > etc) Schema Namespace - (?) > > Requirements: > Published WSDL and Schema needs to remain accessible. > A Specification Document should be able to refer to different > Interface Revisions. (i.e. 1.1 of the PSI Specification > should be able to reference QueryEndPointsInterface v1.0.5 if > we don't need to change it for 1.1) > > Reference: > < > http://msdn.microsoft.com/library/default.asp?url=/library/en- > us/dnservice/ > html/service04032002.asp> > > Versioning > Everyone who developed COM applications: How many of you > remember the golden rules of versioning? Okay, hands down. As > a quick review, here are the > rules: > 1. Always increment the version number. > 2. Freeze the interface on the previous version. All new features > should go into a new interface. > 3. Freeze all structures used on the previous version. Any > enhancements > to those structures should show up in new structures. > WSDL version indication is done via the targetNamespace > attribute of the definitions element. This namespace gives > the SOAP messages meaning by relating the messages to a > specific bit of code implemented somewhere on the server. The > targetNamespace attribute has an XSD type of anyURI. This > attribute could be used in a large number of ways to indicate > the version. For a service named Foo that was hosted at > msdn.microsoft.com, a few options exist for the first > version. Option 1: The targetNamespace could be named > http://msdn.microsoft.com/foo. This works by giving the > interface a unique namespace name. This option does not fit > our needs, however, because it does not include an obvious > mechanism for indicating whether one version is earlier or > later than another. I suppose you could follow up later > versions of the interface with namespaces such as > http://msdn.microsoft.com/foo1 and > http://msdn.microsoft.com/foo2, but that seems silly. Option > 2: The targetNamespace could be named > http://msdn.microsoft.com/1.0/foo. > Again, > this gives the interface a unique namespace identifier. This > option fits our needs, because it gives us an obvious > indicator of version as well as a place to increment that > version in a way people are used to seeing. As we are dealing > with an XML-centric world, however, we might do well to > follow the lead of the newer XML specifications, such as SOAP > 1.2, XML Schema, and XSLT. While this option is viable, it > does not follow this lead. Option 3: Call the targetNamespace > http://msdn.microsoft.com/2002/04/foo. > This has a few small > advantages over option 2. For one, this is the versioning > scheme employed by the newer XML specifications. People who > are used to looking at XML will find versioning by date more > familiar. As an added bonus, versioning by date allows a > person or machine to easily figure out when the version was > released. You can increase the resolution of the version to > reflect the frequency of releases. A resolution down to the > hour would indicate that releases are coming out far too > frequently. If your team does nightly builds, extend the > interim granularity of the version to the date of the build. > Regardless of what you do, don't be cute and use zero-based > month and day-of-month numbers. It's counterintuitive. Of the > above options, both 2 and 3 fit the bill, with 3 being the > versioning option that many XML users I have talked to like > the best. An added advantage of date-based versioning is that > you will know how long the interface has been available. When > changing an XSD type, create a brand new type in a brand new > namespace. This new namespace should still stick with your > versioning model. If the first version was in a namespace > such as http://foo.org/bar/2001/11/20/types, the new > namespace should only change the date information. That new > type, if published on April 5, 2002, should be in the > namespace http://foo.org/bar/2002/04/05/types. Any related > sub-types should remain in the old namespace and simply get > imported into the new one. Here, no wishy-washy answers. To > sum things up, here are the guidelines to use when updating an > interface: > > * The changes always go into a new namespace. > * The new interface should be a superset of the old one. > * It is a good idea to keep the data model the same when > versioning > the interface. > * Never revise data structures. Instead, add new ones as needed. > > > > From alan.berkema at hp.com Fri Feb 7 17:07:31 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:16 2009 Subject: PS> [PSI]: next call 02/11/03 Message-ID: <499DC368E25AD411B3F100902740AD650E6AD63E@xrose03.rose.hp.com> Teleconference details: NEXT: Tuesday February 11 2003 (USA) Time: 8 AM (US PST) Number: 650-690-9367(T348-9367) ID: 55605 Agenda: 1) Status code alignment with semantic model 2) New Go Get Print Job Method ideas? Used with Firewall use model when client initiates a print job to a Print Service and then the printer must get the Print Job. Previously this was called "out of band" or Ira's "and then a miracle happens " Dave Hall will send Webex info since I may not have web access, also chance that I will have trouble calling in. Thanks, Alan WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 21643883 Meeting Password: newpsi Host: Alan Berkema 1(916)7855605 From imcdonald at sharplabs.com Mon Feb 10 12:15:54 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:16 2009 Subject: PS> FW: [relax-ng] Topologi Collaborative Markup Editor version 1.1.1 Message-ID: <116DB56CD7DED511BC7800508B2CA53735CEBE@mailsrvnt02.enet.sharplabs.com> Hi folks, Note the XML interactive editing and many schema/DTD validation features of this XML/HTML collaborative editor. Cheers, - Ira McDonald High North Inc -----Original Message----- From: Rick Jelliffe [mailto:ricko@topologi.com] Sent: Monday, February 10, 2003 10:50 AM To: relax-ng-comment@lists.oasis-open.org Subject: [relax-ng-comment] ANN: Topologi Collaborative Markup Editor version 1.1.1 I am happy to announce the release of the latest version of Topologi's Collaborative Markup Editor. Visit http://www.topologi.com/ The editor has been designed to address many of the issues that other editors ignore: * special tools for marking up non-WF document fast and productively * special tools for manipulating whitespace and breaks * immediate feedback on XML syntax makes the editor good for training * immediate feedback on regular expression syntax helps tame even complicated search patterns * documents up to 8 meg * open and start editing any document immediately: does not require configuration * fast search and replace: what one famous competitor takes 16 minutes to do, we take 8 seconds! * extra help for Unicode and encoding problems * clean-up HTML with bundled Tidy * Schematron, RELAX NG, WXS, XML DTD and SGML DTD validation * read and and write to ZIP files * view and sort all validation results * built-in peer-to-peer networking helps teamwork: workers can exchange and annotate screenshots, send messages, and view each other's directory diaries Version 1.1.1 adds support for RELAX NG compact syntax and Examplotron schemas, upgrades some libraries, and has some fixes. The editor has introductory pricing of $59-95 for unsupported individual licenses, and $5,000 for supported-site licenses. A free 30-day evaluation version is available. A free license is available for use in training courses and for charities. The Windows version of 1.1.1 is online now. Versions for other platforms will appear in the next few days. Cheers Rick Jelliffe Topologi Pty. Ltd. ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: From dhall at hp.com Mon Feb 10 15:20:01 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:16 2009 Subject: PS> WebEx Info for 2/11/03 Message-ID: <77261E830267D411BD4D00902740AC250DB4C7EF@xvan01.vcd.hp.com> ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: psi Date: 2/11/2003 Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 21880808 Meeting Password: temppsi Dave From dhall at hp.com Mon Feb 10 16:36:02 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:16 2009 Subject: PS> PSI 1.0 20030210 Available for Review Message-ID: <77261E830267D411BD4D00902740AC250DB4C7F2@xvan01.vcd.hp.com> Hey All.. The latest working draft of the PSI 1.0 Specification is available at: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030210.doc ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030210.pdf This revision is not the document for the Last Call, but really close to it - I need to get the WSDL cleaned up and referenced to from the document, as well as get a few more target device examples incorporated. Dave From dhall at hp.com Tue Feb 11 11:02:31 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:16 2009 Subject: PS> New telecon # Message-ID: <77261E830267D411BD4D00902740AC250DB4C80B@xvan01.vcd.hp.com> 1-866-639-4756 #2124228 From imcdonald at sharplabs.com Sun Feb 16 16:38:09 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:17 2009 Subject: PS> FW: [relax-ng-comment] InstanceToSchema 1.0 Message-ID: <116DB56CD7DED511BC7800508B2CA53735CEDD@mailsrvnt02.enet.sharplabs.com> Hi, Folks now prototyping PSI might want to play with the tool below. Cheers, - Ira McDonald High North Inc -----Original Message----- From: Didier DEMANY [mailto:didier.demany@xmloperator.net] Sent: Thursday, February 13, 2003 3:08 PM To: relax-ng-comment@lists.oasis-open.org Subject: [relax-ng-comment] InstanceToSchema 1.0 Hi, I am pleased to announce InstanceToSchema 1.0 [1] InstanceToSchema is a RELAX NG schema generator from XML instances. It is a command line tool, written in java. It needs J2SE 1.3 or 1.4 and a JAXP compliant SAX parser for running. InstanceToSchema is developed inside the xmloperator project [2] and shares its BSD style license but is packaged and can be used independently from the XML editor. The software is based on pattern categories. A pattern category represents a set of RELAX NG patterns. The tool work consists in building for each element name a pattern category that is compatible with all the input XML instances and is as precise as possible. The following pattern category types are implemented : * An EmptyPatternCategory represents contents with no element. There may be only attributes and/or text. * An (OptionalRepeatable)ElementPatternCategory represents contents with one element or several elements but with the same name. There may also be attributes and/or texts. * A GroupPatternCategory represents ordered contents or choice between ordered contents. There may also be attributes and/or texts. * An InterleavePatternCategory represents unordered contents. Some element names may appear several times, some others may not. There may also be attributes and/or texts. All these pattern categories consider elements and attributes as independent. However the tool framework doesn't require that. New pattern categories could correlate elements and attributes. Another thing the tool does not is inferencing datatypes. The tool is suitable for processing large documents. It uses only one SAX parsing pass. The required memory space depends on the element name count and the complexity of patterns, not the document size. The set of pairs (element name, pattern category) is translated to a RELAX NG simple syntax data model (the same is used by the XML editor), which is converted to a more readable full syntax and writed out with indentation. A typical use case consists to obtain a description of the structure of one or several (combined) XML files. From my point of view, such a schema is not suitable for validating or for guiding editing some document. I hope that this tool can be usefull or incite some developer to do better. I would welcome any comment. Regards, Didier Demany didier.demany@xmloperator.net The_xmloperator_project [1] http://www.xmloperator.net/i2s/ [2] http://www.xmloperator.net/ ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: From imcdonald at sharplabs.com Mon Feb 17 21:34:18 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:17 2009 Subject: PS> FW: [URI, IRI, and Schemes] Message-ID: <116DB56CD7DED511BC7800508B2CA53735CEE4@mailsrvnt02.enet.sharplabs.com> Hi, See below for the latest on revisions and clarifications to RFC 2396 (Generic URI Syntax) and IRI (Internationalized Resource Identifiers - using full Unicode charset) and URI Scheme registration process. Cheers, - Ira McDonald High North Inc -----Original Message----- From: Martin Duerst [mailto:duerst@w3.org] Sent: Monday, February 17, 2003 3:05 PM To: www-international@w3.org Subject: Fwd: (slightly) request for URI BOF scheduling FYI. >From: "Larry Masinter" >To: >Cc: "'Patrik F?tstr?'" ,"'Lisa Dusseault'" >,"Jim Whitehead" ,"'Roy Fielding'" >, ,"Martin J. D?st" >Subject: (slightly) request for URI BOF scheduling >Date: Mon, 17 Feb 2003 12:31:59 -0800 >I've updated the proposed "agenda" to improve the 'goals' >of the various sessions. > >Because of various individual constraints, the request >is for a BOF for URI at the next IETF on Thursday >(preferably in the morning) and also that >WebDAV be scheduled close (the same or adjacent day). > >================================================ >Agenda and goals: > >* 30 minutes (Roy Fielding) > Review plans for revising RFC 3696 (URI) to Standard > http://www.apache.org/?fielding/uri/rev-2002/issues.html > Goal: disseminate information about activity > encourage focus on issues in issue list > create schedule & milestones > >* 15 minutes (Martin Duerst) > Review plans for IRI (as Proposed Standard) > Discussion of current state, IAB concerns > Goal: review IAB issues & coordination with DNS I18N > review process & mailing list > establish schedule & milestones > >* 15 minutes (Patrik F?tstr?) > Discuss "process for registering new URI schemes" > Review mailing list, process, and 'experts' for URI > scheme registration. > Goal: refine process to insure timely and complete feedback > > > > From alan.berkema at hp.com Tue Feb 18 09:25:02 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:17 2009 Subject: PS> [PSI]: next call 02/18/03 Message-ID: <499DC368E25AD411B3F100902740AD650E6AD651@xrose03.rose.hp.com> Teleconference details: NEXT: Tuesday February 18 2003 (USA) Time: 8 AM (US PST) Number: 866-639-4738 Participant PIN: 7855605 Agenda: 1) TBD WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Date: 2/18/2003 Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 27995593 Meeting Password: newpsi Host: Alan Berkema 1(916)7855605 From dhall at hp.com Tue Feb 18 16:05:25 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:17 2009 Subject: PS> FW: Web Services Interoperability guidelines - PSI WSDL Implicati ons Message-ID: <77261E830267D411BD4D00902740AC250DB4C91C@xvan01.vcd.hp.com> > Hey All... > > In developing the WSDL for the PSI specification, we have been running > into many problems trying to implement a multi-parameter document-literal > encoding. > > What the below mentioned WSI interop guideline implies is that we should > NOT have multi-parameter messages. Rather we should have what I've seen > termed "Wrapped" document-literal. > > Essentially, in the WSDL we need to add an additional layer of "wrapping" > of the parameters. So for example, the CreatJob method would have a > CreateJob parameter that has all of our current parameters encapsulated > within it. > > I'll move ahead with this additional layer of encapsulation (wrapping) for > the PSI WSDL unless there is more discussion or comments. > > Comments? > > Dave > > -----Original Message----- > From: REVEL,DAN (HP-Vancouver,ex1) > Sent: Friday, February 14, 2003 3:47 PM > To: HALL,DAVID (HP-Vancouver,ex1) > Subject: Web Services Interoperability guidelines > > Dave, > > Here's a link to an Interoperabilty profile that we should consider when > constructing the WSDL for the PSI interface: > > http://www.ws-i.org/Profiles/Basic/2002-10/BasicProfile-1.0-WGD.htm > > Two things that caught my attention (and which will require changing the > current WSDL) are: > > R1000 When a MESSAGE contains a soap:Fault element, that element MUST NOT > have element children other than faultcode, faultstring, faultactor and > detail. > This seems to go against the inclusion of objects which you told me was > being proposed. > > and: > > R2201 If style="document" and use="literal" at the SOAP binding level, a > DESCRIPTION MUST have zero or one part in a wsdl:message element that > forms the soap:body. > R2204 If the style="document" and use="literal" at the SOAP binding level, > a DESCRIPTION MUST use the element attribute to define the single part in > a message. > This implies the wrapped behavior for the Axis toolkit. > From the Axis WSDL2Java reference guide: > > -W, --noWrapped > This turns off the special treatment of what is called "wrapped" > document/literal style operations. By default, WSDL2Java will recognize > the following conditions: > * If an input message has is a single part. > * The part is an element. > * The element has the same name as the operation > * The element's complex type has no attributes > When it sees this, WSDL2Java will 'unwrap' the top level element, and > treat each of the components of the element as arguments to the operation. > This type of WSDL is the default for Microsoft .NET web services, which > wrap up RPC style arguments in this top level schema element. > > Note the above description places a naming restriction on the single > element included in an input message, essentially the element name maps to > the operation/methed being called... > > Dan > From imcdonald at sharplabs.com Tue Feb 18 17:46:18 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:17 2009 Subject: PS> FW: Web Services Interoperability guidelines - PSI WSDL I mplicati ons Message-ID: <116DB56CD7DED511BC7800508B2CA53735CEEA@mailsrvnt02.enet.sharplabs.com> Hi Dave, I agree that it would be safer and better to add the extra "wrapping". Cheers, - Ira -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Tuesday, February 18, 2003 3:05 PM To: 'ps@pwg.org' Subject: PS> FW: Web Services Interoperability guidelines - PSI WSDL Implicati ons > Hey All... > > In developing the WSDL for the PSI specification, we have been running > into many problems trying to implement a multi-parameter document-literal > encoding. > > What the below mentioned WSI interop guideline implies is that we should > NOT have multi-parameter messages. Rather we should have what I've seen > termed "Wrapped" document-literal. > > Essentially, in the WSDL we need to add an additional layer of "wrapping" > of the parameters. So for example, the CreatJob method would have a > CreateJob parameter that has all of our current parameters encapsulated > within it. > > I'll move ahead with this additional layer of encapsulation (wrapping) for > the PSI WSDL unless there is more discussion or comments. > > Comments? > > Dave > > -----Original Message----- > From: REVEL,DAN (HP-Vancouver,ex1) > Sent: Friday, February 14, 2003 3:47 PM > To: HALL,DAVID (HP-Vancouver,ex1) > Subject: Web Services Interoperability guidelines > > Dave, > > Here's a link to an Interoperabilty profile that we should consider when > constructing the WSDL for the PSI interface: > > http://www.ws-i.org/Profiles/Basic/2002-10/BasicProfile-1.0-WGD.htm > > Two things that caught my attention (and which will require changing the > current WSDL) are: > > R1000 When a MESSAGE contains a soap:Fault element, that element MUST NOT > have element children other than faultcode, faultstring, faultactor and > detail. > This seems to go against the inclusion of objects which you told me was > being proposed. > > and: > > R2201 If style="document" and use="literal" at the SOAP binding level, a > DESCRIPTION MUST have zero or one part in a wsdl:message element that > forms the soap:body. > R2204 If the style="document" and use="literal" at the SOAP binding level, > a DESCRIPTION MUST use the element attribute to define the single part in > a message. > This implies the wrapped behavior for the Axis toolkit. > From the Axis WSDL2Java reference guide: > > -W, --noWrapped > This turns off the special treatment of what is called "wrapped" > document/literal style operations. By default, WSDL2Java will recognize > the following conditions: > * If an input message has is a single part. > * The part is an element. > * The element has the same name as the operation > * The element's complex type has no attributes > When it sees this, WSDL2Java will 'unwrap' the top level element, and > treat each of the components of the element as arguments to the operation. > This type of WSDL is the default for Microsoft .NET web services, which > wrap up RPC style arguments in this top level schema element. > > Note the above description places a naming restriction on the single > element included in an input message, essentially the element name maps to > the operation/methed being called... > > Dan > From alan.berkema at hp.com Wed Feb 19 18:32:40 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:17 2009 Subject: PS> [PSI]: Washington Meeting Message-ID: <499DC368E25AD411B3F100902740AD650E6AD66A@xrose03.rose.hp.com> Hey all, We have had a few requests to finish the PSI meeting by 3:00PM on 4/4/03. So that will be our official stop time. Alan > -----Original Message----- > From: Farrell, Lee [mailto:Lee.Farrell@cda.canon.com] > Sent: Tuesday, February 18, 2003 2:03 PM > To: Alan Berkema (E-mail); HALL,DAVID (HP-Vancouver,ex1) > Subject: Washington meeting > > > Hi Alan, Dave, > > Do you guys have a sense of the meeting duration in Washington? > > I'm trying to arrange flights, and it looks like I'll need to > leave the meeting around 3:00pm if I fly home on Friday. > > But if you think there will be a full day agenda, I should > look into staying until Saturday. > > Any thoughts? > > [Sorry if this was discussed at today's telecon. I had a conflict.] > > lee > =========================== > Lee Farrell > Canon Development Americas > 110 Innovation Drive > Irvine, CA 92612 > (949) 856-7163 - voice > (949) 856-7510 - fax > lee.farrell@cda.canon.com > =========================== > > From alan.berkema at hp.com Thu Feb 20 12:08:41 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:17 2009 Subject: PS> [PSI]: NO CALL 02/25/03 Message-ID: <499DC368E25AD411B3F100902740AD650E6AD66E@xrose03.rose.hp.com> Teleconference details: NEXT: Tuesday March 4 2003 (USA) Time: 8 AM (US PST) Number: 866-639-4738 Participant PIN: 7855605 Agenda: 1) TBD WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Date: 2/18/2003 Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 27995593 Meeting Password: newpsi Host: Alan Berkema 1(916)7855605 From dhall at hp.com Mon Feb 24 12:26:28 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:17 2009 Subject: PS> PSI 1.0 Working Draft 20030221 Available Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAA4A@xvan01.vcd.hp.com> Hi All! The PSI 1.0 Working Draft 20030221 is now available at: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030221.doc ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030221.pdf ftp://ftp.pwg.org/pub/pwg/ps/psi-spec-latest.pdf The PSI WSDL has been updated as well, and includes the new Wrapped Document-Literal encoding, but does not reference the new Semantic Model Schemas yet. http://www.pwg.org/schemas/ps/20030221/QueryEndPointsInterface.wsdl http://www.pwg.org/schemas/ps/20030221/ServiceCapabilitiesInterface.wsdl http://www.pwg.org/schemas/ps/20030221/JobControlInterface.wsdl http://www.pwg.org/schemas/ps/20030221/TargetDeviceSupportInterface.wsdl Dave Hall From WWagner at NetSilicon.com Mon Feb 24 15:56:23 2003 From: WWagner at NetSilicon.com (Wagner,William) Date: Wed May 6 14:02:17 2009 Subject: PS> PSI Port Message-ID: <7F2C5DA4096E9D44B70E967CB54EEEDB0E85A3@mamail.digi.com> In discussing WBMM (which has some similarities to PSI), I advanced the premise that Web Based management would use the infrastructure (access path, proxies etc) that enterprises have established for user web access. I suggested that this was parallel to what PSI was doing, since I thought that that indeed, was the way that PSI would allow deployment without requiring firewall reprogramming, special proxy setups, etc. However, Ira corrected me and observed that: PSI implementations MUST ONLY use the (future) IANA-assigned PSI "registered port" (a number greater than 1024 for a vendor defined protocol). PSI implementations (even by administrator configuration) MUST NOT ever use port 80. and further indicted that to use port 80 for things other than human driven browser clients would violate guidelines being established by IETF/DMTF/W3C. However, this non use of port 80 for PSI is not clear in the specifications. There is a statement relative to URL examples to the effect that the port 80 indicated would be replaced by an IANA to be assigned number; but that does not appear to be a ban on the use of port 80. And the section on firewalls in the Application Guide is empty. I believe that requiring any location that is to support a PSI Client or PSI Target Device create a new path through the firewall will serious affect the potential adoption of PSI. One may observe that assigning port 631 to IPP did very little to allow its use as an Internet Printing Protocol. In presenting PSI to NetSilicon customers, the ability to use the existing port 80 facility is a very important factor. Therefore, I would like some clarification about what the intent in specification really is, and what the position of the working group is. Many thanks. Bill Wagner, NetSilicon/A Digi International Company From imcdonald at sharplabs.com Tue Feb 25 18:43:38 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:17 2009 Subject: PS> RE: PWG-ANNOUNCE> Print Services Web Page Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF01@mailsrvnt02.enet.sharplabs.com> Hi, Actually, PSI is what you want. Several vendors have working PSI prototypes. Products can be expected in the quite near future. PSI itself does not do discovery. But PSI specifies (in some detail) how to do device discovery by wireless (BlueTooth), by SSDP (part of Microsoft's UPnP), by SLPv2 (RFC 2608), by LDAPv3 (RFC 2251), by DNS-SD (RFC 2782), or by UDDI (Web Services) in the "PSI Developers Guide" in section 6 'Print Service Discovery and Deployment'. ftp://ftp.pwg.org/pub/pwg/ps/psi-devl-latest.pdf (most recently v0.95a 13 January 2003) PSI is intended to be (relatively) lightweight. It is a series of WSDL (Web Services Definition Language) SOAP (Simple Object Access Protocol) operations, using the attributes defined in the common XML schema of the IEEE/ISTO PWG Semantic Model. I hope this helps. Cheers, - Ira McDonald, contributing PSI editor High North Inc -----Original Message----- From: Clem McDonald [mailto:cmcdonald@regenstrief.org] Sent: Monday, February 24, 2003 4:18 PM To: imcdonald@sharplabs.com Subject: Re: PS> RE: PWG-ANNOUNCE> Print Services Web Page I have just discovered the PSI working group activity. We have developed a network that includes all of the major hospitals in Indianapolis and captures in a secure way clinical information from all of these institutions. We are working on ways to provide physician access to the data they can properly see, via a wireless PDA (or cell phone) using technology like the Black Berry. For a smallish prespecified list of patients , this system will work very well because the cellular system can push the data to the PDA. The physician will face different issues when he/she wants to look at a broad spectrum of information about a patient that had not been pre-defined. It will likely be slow to load (pull) information on demand about a specific pattient. Furthermore ,even for patients whose data has been pushed to the PDA- some kinds of informatio (E.g EKG tracings and Chest xrays) will not fit very well, and in many cases the physciain would rather review the informaiton on paper. Hence the need for a printer connection. I read the plan for PSI written (I think in 2000). The diagram showing acellular phone or cellular connected PDA sending a URL to a network for printing is exactly what we need. I gather that PSI is just being proposed so there is not likely to be any way for us to take advantage of it. However we don't need the full boat. What we would love to have , would be for a PDA/cellular to be able to discover the Internet address (or URL) of the printer near by. (Ideally this would be by probing it through infrared or blue tooth but doubt that is feasible), and then send a URL from the network to it. Do you know of any implementation of the capabilty that would allow discovery of printer locations and then directing something accross a wider area network to that printer. ( Lots of issues and problemS) Would love to explore anything that was out there that was lightweight Many thanks -- Director, Regenstrief Institute Regenstrief Professor of Medical Informatics Distinguished Professor of Medicine Indiana University School of Medicine 1050 Wishard Blvd RG5 Indianapolis IN 46202-2872 Phone: 317/630-7070 Fax: 317/630-6962 URL: www.regenstrief.org From imcdonald at sharplabs.com Wed Feb 26 17:52:13 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:17 2009 Subject: PS> RE: PWG-ANNOUNCE> Print Services Web Page Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF02@mailsrvnt02.enet.sharplabs.com> Hi folks, Anyone care to respond to Clem's interest in collaborating on a vendor prototype of PSI (see his note below)? Cheers, - Ira McDonald High North Inc -----Original Message----- From: Clem McDonald [mailto:cmcdonald@regenstrief.org] Sent: Wednesday, February 26, 2003 9:28 AM To: McDonald, Ira Subject: Re: PS> RE: PWG-ANNOUNCE> Print Services Web Page wow, that could be just what the doctor ordered. Is there any way to get info on who has these prototypes and how we might be able to get involved. We are working to get federal funding for the second phase of a city wide (indianapolis) linkage of all of the major hospitals. want to be able to request clinical reports via a cellular phone and send the request via cellular to the network and have hte reports print out near the provider. But will need more detaila about the implementation and how it works with blue tooth to sell this. We would be a good demo site. Would love to be ableto contact the folks who are working on prtotypes and understand the context. Does bluetooth sitting on a printer (or the printers internet port) the ability to tell a near by device the internet address of the printer. If so that would be perfect (maybe) Will follow up on the documents you have specified. "McDonald, Ira" wrote: > Hi, > > Actually, PSI is what you want. Several vendors have working PSI > prototypes. Products can be expected in the quite near future. > > PSI itself does not do discovery. > > But PSI specifies (in some detail) how to do device discovery > by wireless (BlueTooth), by SSDP (part of Microsoft's UPnP), > by SLPv2 (RFC 2608), by LDAPv3 (RFC 2251), by DNS-SD (RFC 2782), > or by UDDI (Web Services) in the "PSI Developers Guide" in > section 6 'Print Service Discovery and Deployment'. > > ftp://ftp.pwg.org/pub/pwg/ps/psi-devl-latest.pdf > (most recently v0.95a 13 January 2003) > > PSI is intended to be (relatively) lightweight. It is a series > of WSDL (Web Services Definition Language) SOAP (Simple Object > Access Protocol) operations, using the attributes defined in the > common XML schema of the IEEE/ISTO PWG Semantic Model. > > I hope this helps. > > Cheers, > - Ira McDonald, contributing PSI editor > High North Inc > > -----Original Message----- > From: Clem McDonald [mailto:cmcdonald@regenstrief.org] > Sent: Monday, February 24, 2003 4:18 PM > To: imcdonald@sharplabs.com > Subject: Re: PS> RE: PWG-ANNOUNCE> Print Services Web Page > > I have just discovered the PSI working group activity. We have > developed a network that includes all of the major hospitals in > Indianapolis and captures in a secure way clinical information from all > of these institutions. We are working on ways to provide physician > access to the data they can properly see, via a wireless PDA (or cell > phone) using technology like the Black Berry. > > For a smallish prespecified list of patients , this system will work > very well because the cellular system can push the data to the PDA. The > physician will face different issues when he/she wants to look at a > broad spectrum of information about a patient that had not been > pre-defined. It will likely be slow to load (pull) information on > demand about a specific pattient. Furthermore ,even for patients whose > data has been pushed to the PDA- some kinds of informatio (E.g EKG > tracings and Chest xrays) will not fit very well, and in many cases the > physciain would rather review the informaiton on paper. Hence the need > for a printer connection. I read the plan for PSI written (I think in > 2000). The diagram showing acellular phone or cellular connected PDA > sending a URL to a network for printing is exactly what we need. I > gather that PSI is just being proposed so there is not likely to be any > way for us to take advantage of it. > > However we don't need the full boat. What we would love to have , would > be for a PDA/cellular to be able to discover the Internet address (or > URL) of the printer near by. (Ideally this would be by probing it > through infrared or blue tooth but doubt that is feasible), and then > send a URL from the network to it. > > Do you know of any implementation of the capabilty that would allow > discovery of printer locations and then directing something accross a > wider area network to that printer. ( Lots of issues and problemS) > > Would love to explore anything that was out there that was lightweight > > Many thanks > > -- > Director, Regenstrief Institute > Regenstrief Professor of Medical Informatics > Distinguished Professor of Medicine > Indiana University School of Medicine > 1050 Wishard Blvd RG5 > Indianapolis IN 46202-2872 > Phone: 317/630-7070 > Fax: 317/630-6962 > URL: www.regenstrief.org -- Director, Regenstrief Institute Regenstrief Professor of Medical Informatics Distinguished Professor of Medicine Indiana University School of Medicine 1050 Wishard Blvd RG5 Indianapolis IN 46202-2872 Phone: 317/630-7070 Fax: 317/630-6962 URL: www.regenstrief.org From dhall at hp.com Fri Feb 28 09:50:45 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:17 2009 Subject: PS> PSI and Port 80, and printers traversing the firewall Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAADC@xvan01.vcd.hp.com> Hi Bill... A couple of questions for you... You mentioned the following with regards to PSI and port 80: I am very sad to hear that PSI will not use port 80; I think that will very much handicap the potential of what is an excellent capability. Of course, IPP was assigned port 631, but many implementations still listen on port 80 as well. In consideration of this, Ira and I spent some time looking at PSI, and the use of port 80, and port 3700 (psi-port), and came up with the following proposal: * A Print Service shall implement PSI on psi-port, and port 80 (and thus, the path to ALL psi interfaces must be of the form pwg-psips://server/psi/...) * A Target Device shall implement PSI only on port psi-port * A Client shall always try to communicate with a Print Service on psi-port first, and if that fails, then utilize port 80. We believe that this reasoning enables the following requirements: 1) A company can deploy a PSI Print Service on their normal, publically exposed web-server on port 80. 2) All communication to a Target Device is on port 3700 for network monitoring purposes. 3) Within and enterprise, communication between a client and a Print Service is on 3700 for network monitoring purposes. 4) If an administrator chooses to expose their print service on port 3700, then all traffic to it will be on 3700... Do you feel that this addresses your concerns? (And your customers?) Second: Having been though this at various places. Asking if they would allow a printer that talks to an external server, without adding more restrictions, will get a very quick NO. This model is very important for many of the PSI firewall traversing use models! I do think that implementers of Target Devices should not have their printers come configured "out of the box" with the ability to go and fetch data from an external server. This should probably be something that the administrator needs to enable for particular printers within their enterprise. However, once allowed by the administrator, these "public printers" would then be able to retrieve publically initiated print jobs. Another option is to only allow "authorized users" to initiate these out-bound requests. This would be accomplished by authenticating the user via http, and then the Target Device would need to authorize the user against an acl.. Comments?? Dave From mike.haller at attbi.com Fri Feb 28 10:07:58 2003 From: mike.haller at attbi.com (Mike Haller) Date: Wed May 6 14:02:17 2009 Subject: PS> Difficulty with AddDocumentByPost Message-ID: <002301c2df3b$2dd4f1f0$0200a8c0@boulder.ibm.com> I have an implementation of the job control interface circa last November, and am finally getting around to updating it to something more modern (20030221), but I am finding the new AddDocumentByPost difficult to implement. First, making the option mandatory will make it unnecessarily difficult to support an SMTP-bound SOAP implementation, since it forces an HTTP server implementation. Second, allowing the lastDocument on this call means that heavy-duty coupling must be done between the JCI implementation and whatever implementation receives the SOAP calls, since the lastDocument = true must effectively be deferred until after the post has successfully completed. This implies that whatever receives the post must communicate with the JCI implementation when it has been received successfully. And of course, the JCI implementation already has to know all about whatever receives the post so that it can know how to create a new sink URL and go collect the data when it is done. It is also unclear what the implementation should do if the post fails for some reason, or in what order the implementation can expect to receive the posts. For example, it now seems the client could: 1. CreateJob 2. AddDocumentByPost last = false 3. AddDocumentByPost last = true 4. Post document 2 5. Post document 1 This makes the implementation difficult, without really seeming to buy anything useful for the client. If the lastDocument flag were removed from the AddDocumentByPost call, and if the additional requirement were made that the client could not perform any additional AddDocumentByReference or AddDocumentByPost calls until either the post was complete, or a CancelDocument call were made for the pending document, then the implementation would be much simpler. Then the example above would be: 1. CreateJob 2. AddDocumentByPost 3. Post document 1 4. AddDocumentByPost 5. Post document 2 6. AddDocumentByReference last = true reference = null Though I can't seem to find where AddDocumentByReference with a null reference and attributes is actually allowed (it is, isn't it?) Maybe it's not to late for a completeJob( jobURI ) call? Mike Haller From dhall at hp.com Fri Feb 28 11:48:32 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:17 2009 Subject: PS> Difficulty with AddDocumentByPost Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAAE1@xvan01.vcd.hp.com> Hey Mike... Thanks for the input! See my comments inline... Would you be interested in attending some of our public interop events with your implementation? We plann on having some teleconference interops before a Face 2 Face event as well. Dave -----Original Message----- From: Mike Haller [mailto:mike.haller@attbi.com] Sent: Friday, February 28, 2003 7:08 AM To: ps@pwg.org Subject: PS> Difficulty with AddDocumentByPost I have an implementation of the job control interface circa last November, and am finally getting around to updating it to something more modern (20030221), but I am finding the new AddDocumentByPost difficult to implement. First, making the option mandatory will make it unnecessarily difficult to support an SMTP-bound SOAP implementation, since it forces an HTTP server implementation. Which option in particular are you refering to? Second, allowing the lastDocument on this call means that heavy-duty coupling must be done between the JCI implementation and whatever implementation receives the SOAP calls, since the lastDocument = true must effectively be deferred until after the post has successfully completed. This implies that whatever receives the post must communicate with the JCI implementation when it has been received successfully. And of course, the JCI implementation already has to know all about whatever receives the post so that it can know how to create a new sink URL and go collect the data when it is done. Yep, this is very true, and I can't think of an easy way to decouple the JCI implementation from whatever receives the post. I think inherently that whatever receives the post needs to then add the data to the document that was created in the original AddDocumentByPost SOAP call. - I've managed this my placing a query parameter on the URL that is returned to the client as follows: We have a servlet that is listening on a particular path. The AddDocumentByPost returns the following: http://mypsiserver/axis/servlet/PSIPostServlet/urn:uuid:143832734-2340342-34 34-3 Basically, we encode the DocumentURI on the return path. This allows the servlet that receives the post to make the association with the appropriate internal JCI document as follows: protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { try { String documentURI = req.getPathInfo().substring(1); // Find the appropriate document from our PSIDocument hash PSIDocument doc = PSIDocument.getDocumentByURI(documentURI); InputStream requestInputStream = req.getInputStream(); //Let the document object know about the input stream... doc.post(requestInputStream); // what do we return? resp.setContentLength(0); resp.getWriter().close(); } catch (Exception e) { e.printStackTrace(); throw new ServletException(e); // ??? } } It is also unclear what the implementation should do if the post fails for some reason, or in what order the implementation can expect to receive the posts. For example, it now seems the client could: 1. CreateJob 2. AddDocumentByPost last = false 3. AddDocumentByPost last = true 4. Post document 2 5. Post document 1 This makes the implementation difficult, without really seeming to buy anything useful for the client. This is also true. Right now I have solved this by deferring processing of the job untill all of the document data has been received. There are some gating factors as to what allows a job to be processed: lastDocument == true AllDocumentDataReceived == true If the lastDocument flag were removed from the AddDocumentByPost call, and if the additional requirement were made that the client could not perform any additional AddDocumentByReference or AddDocumentByPost calls until either the post was complete, or a CancelDocument call were made for the pending document, then the implementation would be much simpler. Then the example above would be: 1. CreateJob 2. AddDocumentByPost 3. Post document 1 4. AddDocumentByPost 5. Post document 2 6. AddDocumentByReference last = true reference = null I like the idea of adding the requirement that the data MUST be posted directly after the AddDocumentByPost, and before any other AddDocumentBy* methods are called. I'll add it to the latest rev of the spec, and see if the working group approves. I don't like overloading the AddDocumentByReference to indicate the "I'm Done". Hopefully adding the interleaving requirement is sufficient for you needs. Though I can't seem to find where AddDocumentByReference with a null reference and attributes is actually allowed (it is, isn't it?) Maybe it's not to late for a completeJob( jobURI ) call? Mike Haller From alan.berkema at hp.com Fri Feb 28 12:58:57 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:17 2009 Subject: PS> [PSI]: next call 03/04/03 Message-ID: <499DC368E25AD411B3F100902740AD650E6AD6C9@xrose03.rose.hp.com> Teleconference details: NEXT: Tuesday March 04 2003 (USA) Time: 8 AM (US PST) Number: 866-639-4738 Participant PIN: 7855605 Agenda: 1) PSI Port 2) Difficulty with AddDocumentByPost 3) Ready for Last Call 4) ? WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 27995593 Meeting Password: newpsi Host: Alan Berkema 1(916)7855605 From mhaller at us.ibm.com Fri Feb 28 15:53:25 2003 From: mhaller at us.ibm.com (Mike Haller) Date: Wed May 6 14:02:17 2009 Subject: PS> Difficulty with AddDocumentByPost In-Reply-To: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAAE1@xvan01.vcd.hp.com> Message-ID: <000d01c2df6b$7024a660$0200a8c0@boulder.ibm.com> Dave, Thanks for the speedy reply. Response below. > > Hey Mike... > > Thanks for the input! See my comments inline... > > Would you be interested in attending some of our public > interop events with your implementation? We plann on having > some teleconference interops before a Face 2 Face event as well. > Harry has been talking to us about this, and we are definitely interested. It will mostly be a question of whether we can catch up by then. > First, making the option mandatory will make it unnecessarily > difficult to support an SMTP-bound SOAP implementation, since > it forces an HTTP server implementation. > > > Which option in particular are you refering to? > Well, I guess it's not really an option if it's mandatory :) I was referring to the call AddDocumentByPost, which is listed as mandatory for both a print service and a target device. Since it is required and there is no fault for "operation not supported", then even a non-HTTP SOAP implementation is forced to coordinate with an HTTP server. I understand that the focus was on HTTP implementations, but this seems to effectively preclude anything else. > > Second, allowing the lastDocument on this call means that > heavy-duty coupling must be done between the JCI > implementation and whatever implementation receives the SOAP > calls, since the lastDocument = true must effectively be > deferred until after the post has successfully completed. > This implies that whatever receives the post must communicate > with the JCI implementation when it has been received > successfully. And of course, the JCI implementation already > has to know all about whatever receives the post so that it > can know how to create a new sink URL and go collect the data > when it is done. > > > Yep, this is very true, and I can't think of an easy way to > decouple the JCI implementation from whatever receives the > post. I think inherently that whatever receives the post > needs to then add the data to the document that was created > in the original AddDocumentByPost SOAP call. - I've managed > this my placing a query parameter on the URL that is returned > to the client as > follows: > > We have a servlet that is listening on a particular path. > The AddDocumentByPost returns the following: > http://mypsiserver/axis/servlet/PSIPostServlet/urn:uuid:143832 > 734-2340342-34 > 34-3 > > Basically, we encode the DocumentURI on the return path. > This allows the servlet that receives the post to make the > association with the appropriate internal JCI document as follows: > > protected void doPost(HttpServletRequest req, > HttpServletResponse resp) throws ServletException, IOException { > try > { > String documentURI = req.getPathInfo().substring(1); > // Find the appropriate document from our > PSIDocument hash > PSIDocument doc = > PSIDocument.getDocumentByURI(documentURI); > InputStream requestInputStream = req.getInputStream(); > > //Let the document object know about the input > stream... doc.post(requestInputStream); > > // what do we return? > resp.setContentLength(0); > resp.getWriter().close(); > } > catch (Exception e) > { > e.printStackTrace(); > throw new ServletException(e); // ??? > } > } > > > It is also unclear what the implementation should do if the > post fails for some reason, or in what order the > implementation can expect to receive the posts. For example, > it now seems the client could: > > 1. CreateJob > 2. AddDocumentByPost last = false > 3. AddDocumentByPost last = true > 4. Post document 2 > 5. Post document 1 > > This makes the implementation difficult, without really > seeming to buy anything useful for the client. > > > This is also true. Right now I have solved this by deferring > processing of the job untill all of the document data has > been received. There are some gating factors as to what > allows a job to be processed: lastDocument == true > AllDocumentDataReceived == true Technically this problem has a solution, even in the out-of-order case. I think the real question is whether all the service implementors should be burdened with this additional coupling when it can be fairly easily be avoided without unduly limiting the client implementation (I think). > If the lastDocument flag were removed from the > AddDocumentByPost call, and if the additional requirement > were made that the client could not perform any additional > AddDocumentByReference or AddDocumentByPost calls until > either the post was complete, or a CancelDocument call were > made for the pending document, then the implementation would > be much simpler. Then the example above would be: > > 1. CreateJob > 2. AddDocumentByPost > 3. Post document 1 > 4. AddDocumentByPost > 5. Post document 2 > 6. AddDocumentByReference last = true reference = null > > > I like the idea of adding the requirement that the data MUST > be posted directly after the AddDocumentByPost, and before > any other AddDocumentBy* methods are called. I'll add it to > the latest rev of the spec, and see if the working group approves. > > I don't like overloading the AddDocumentByReference to > indicate the "I'm Done". Hopefully adding the interleaving > requirement is sufficient for you needs. Then such an overloading does not already exist? That would seem to be a problem, since you may not know at the time the last document is started if it is the last document. I had assumed that PSI was similar to IPP in that one of the AddDocumentByPost and AddDocumentByReference was overloaded and could be used to end the job, but I did not find a reference to this. Is there any way to do this, or is it always necessary to know that a job will be complete at the commencement of the last document? Regards, Mike > Though I can't seem to find where AddDocumentByReference with > a null reference and attributes is actually allowed (it is, > isn't it?) Maybe it's not to late for a completeJob( jobURI ) call? > > Mike Haller > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2342 bytes Desc: not available Url : http://www.pwg.org/archives/ps/attachments/20030228/ceef466c/smime-0001.bin From imcdonald at sharplabs.com Fri Feb 28 17:44:44 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:17 2009 Subject: PS> Difficulty with AddDocumentByPost Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF10@mailsrvnt02.enet.sharplabs.com> Hi Mike, The 'last-document' flag in PSI is a legacy of IPP. It's a kludge. A much cleaner solution is a distinct operation "CloseJob" that is sent AFTER the last document is added by Post (by value) or by Reference. I'd much prefer that we corrected this mistake in IPP and (therefore) the PWG Semantic Model. Forcing mandatory support for AddDocumentByPost (and thus an HTTP transport) is a bad mistake. PSI should define clean WSDL/SOAP operations that can use any transport binding of SOAP - SOAP over SMTP, or SOAP over Blocks (RFC 3288), or whatever. Cheers, - Ira McDonald High North Inc PS - When we originally developed IPP/1.0, Microsoft only wanted Print-Job (sends print data by value). Later, Microsoft and many others realized that we SHOULD have made support for Print-URI (sends print data by reference) Mandatory and made Print-Job Optional. -----Original Message----- From: Mike Haller [mailto:mhaller@us.ibm.com] Sent: Friday, February 28, 2003 2:53 PM To: ps@pwg.org Subject: RE: PS> Difficulty with AddDocumentByPost Dave, Thanks for the speedy reply. Response below. > > Hey Mike... > > Thanks for the input! See my comments inline... > > Would you be interested in attending some of our public > interop events with your implementation? We plann on having > some teleconference interops before a Face 2 Face event as well. > Harry has been talking to us about this, and we are definitely interested. It will mostly be a question of whether we can catch up by then. > First, making the option mandatory will make it unnecessarily > difficult to support an SMTP-bound SOAP implementation, since > it forces an HTTP server implementation. > > > Which option in particular are you refering to? > Well, I guess it's not really an option if it's mandatory :) I was referring to the call AddDocumentByPost, which is listed as mandatory for both a print service and a target device. Since it is required and there is no fault for "operation not supported", then even a non-HTTP SOAP implementation is forced to coordinate with an HTTP server. I understand that the focus was on HTTP implementations, but this seems to effectively preclude anything else. > > Second, allowing the lastDocument on this call means that > heavy-duty coupling must be done between the JCI > implementation and whatever implementation receives the SOAP > calls, since the lastDocument = true must effectively be > deferred until after the post has successfully completed. > This implies that whatever receives the post must communicate > with the JCI implementation when it has been received > successfully. And of course, the JCI implementation already > has to know all about whatever receives the post so that it > can know how to create a new sink URL and go collect the data > when it is done. > > > Yep, this is very true, and I can't think of an easy way to > decouple the JCI implementation from whatever receives the > post. I think inherently that whatever receives the post > needs to then add the data to the document that was created > in the original AddDocumentByPost SOAP call. - I've managed > this my placing a query parameter on the URL that is returned > to the client as > follows: > > We have a servlet that is listening on a particular path. > The AddDocumentByPost returns the following: > http://mypsiserver/axis/servlet/PSIPostServlet/urn:uuid:143832 > 734-2340342-34 > 34-3 > > Basically, we encode the DocumentURI on the return path. > This allows the servlet that receives the post to make the > association with the appropriate internal JCI document as follows: > > protected void doPost(HttpServletRequest req, > HttpServletResponse resp) throws ServletException, IOException { > try > { > String documentURI = req.getPathInfo().substring(1); > // Find the appropriate document from our > PSIDocument hash > PSIDocument doc = > PSIDocument.getDocumentByURI(documentURI); > InputStream requestInputStream = req.getInputStream(); > > //Let the document object know about the input > stream... doc.post(requestInputStream); > > // what do we return? > resp.setContentLength(0); > resp.getWriter().close(); > } > catch (Exception e) > { > e.printStackTrace(); > throw new ServletException(e); // ??? > } > } > > > It is also unclear what the implementation should do if the > post fails for some reason, or in what order the > implementation can expect to receive the posts. For example, > it now seems the client could: > > 1. CreateJob > 2. AddDocumentByPost last = false > 3. AddDocumentByPost last = true > 4. Post document 2 > 5. Post document 1 > > This makes the implementation difficult, without really > seeming to buy anything useful for the client. > > > This is also true. Right now I have solved this by deferring > processing of the job untill all of the document data has > been received. There are some gating factors as to what > allows a job to be processed: lastDocument == true > AllDocumentDataReceived == true Technically this problem has a solution, even in the out-of-order case. I think the real question is whether all the service implementors should be burdened with this additional coupling when it can be fairly easily be avoided without unduly limiting the client implementation (I think). > If the lastDocument flag were removed from the > AddDocumentByPost call, and if the additional requirement > were made that the client could not perform any additional > AddDocumentByReference or AddDocumentByPost calls until > either the post was complete, or a CancelDocument call were > made for the pending document, then the implementation would > be much simpler. Then the example above would be: > > 1. CreateJob > 2. AddDocumentByPost > 3. Post document 1 > 4. AddDocumentByPost > 5. Post document 2 > 6. AddDocumentByReference last = true reference = null > > > I like the idea of adding the requirement that the data MUST > be posted directly after the AddDocumentByPost, and before > any other AddDocumentBy* methods are called. I'll add it to > the latest rev of the spec, and see if the working group approves. > > I don't like overloading the AddDocumentByReference to > indicate the "I'm Done". Hopefully adding the interleaving > requirement is sufficient for you needs. Then such an overloading does not already exist? That would seem to be a problem, since you may not know at the time the last document is started if it is the last document. I had assumed that PSI was similar to IPP in that one of the AddDocumentByPost and AddDocumentByReference was overloaded and could be used to end the job, but I did not find a reference to this. Is there any way to do this, or is it always necessary to know that a job will be complete at the commencement of the last document? Regards, Mike > Though I can't seem to find where AddDocumentByReference with > a null reference and attributes is actually allowed (it is, > isn't it?) Maybe it's not to late for a completeJob( jobURI ) call? > > Mike Haller > From mhaller at us.ibm.com Sat Mar 1 12:48:18 2003 From: mhaller at us.ibm.com (Mike Haller) Date: Wed May 6 14:02:17 2009 Subject: PS> Difficulty with AddDocumentByPost In-Reply-To: <116DB56CD7DED511BC7800508B2CA53735CF10@mailsrvnt02.enet.sharplabs.com> Message-ID: <002601c2e01a$be8d54a0$0200a8c0@boulder.ibm.com> Hello Ira, I just can't help but agree with all of your points. Regards, Mike > -----Original Message----- > From: owner-ps@pwg.org [mailto:owner-ps@pwg.org] On Behalf Of > McDonald, Ira > Sent: Friday, February 28, 2003 3:45 PM > To: 'Mike Haller'; ps@pwg.org > Subject: RE: PS> Difficulty with AddDocumentByPost > > > Hi Mike, > > The 'last-document' flag in PSI is a legacy of IPP. It's > a kludge. A much cleaner solution is a distinct operation > "CloseJob" that is sent AFTER the last document is added by > Post (by value) or by Reference. > > I'd much prefer that we corrected this mistake in IPP and > (therefore) the PWG Semantic Model. > > Forcing mandatory support for AddDocumentByPost (and thus > an HTTP transport) is a bad mistake. > > PSI should define clean WSDL/SOAP operations that can use > any transport binding of SOAP - SOAP over SMTP, or SOAP > over Blocks (RFC 3288), or whatever. > > Cheers, > - Ira McDonald > High North Inc > > PS - When we originally developed IPP/1.0, Microsoft only > wanted Print-Job (sends print data by value). Later, > Microsoft and many others realized that we SHOULD have made > support for Print-URI (sends print data by reference) > Mandatory and made Print-Job Optional. > > > -----Original Message----- > From: Mike Haller [mailto:mhaller@us.ibm.com] > Sent: Friday, February 28, 2003 2:53 PM > To: ps@pwg.org > Subject: RE: PS> Difficulty with AddDocumentByPost > > > Dave, > > Thanks for the speedy reply. Response below. > > > > > Hey Mike... > > > > Thanks for the input! See my comments inline... > > > > Would you be interested in attending some of our public > > interop events with your implementation? We plann on having > > some teleconference interops before a Face 2 Face event as well. > > > > Harry has been talking to us about this, and we are > definitely interested. It will mostly be a question of > whether we can catch up by then. > > > First, making the option mandatory will make it unnecessarily > > difficult to support an SMTP-bound SOAP implementation, since > > it forces an HTTP server implementation. > > > > > > Which option in particular are you refering to? > > > > Well, I guess it's not really an option if it's mandatory :) > I was referring to the call AddDocumentByPost, which is > listed as mandatory for both a print service and a target > device. Since it is required and there is no fault for > "operation not supported", then even a non-HTTP SOAP > implementation is forced to coordinate with an HTTP server. > I understand that the focus was on HTTP implementations, but > this seems to effectively preclude anything else. > > > > > Second, allowing the lastDocument on this call means that > > heavy-duty coupling must be done between the JCI > > implementation and whatever implementation receives the SOAP > > calls, since the lastDocument = true must effectively be > > deferred until after the post has successfully completed. > > This implies that whatever receives the post must communicate > > with the JCI implementation when it has been received > > successfully. And of course, the JCI implementation already > > has to know all about whatever receives the post so that it > > can know how to create a new sink URL and go collect the data > > when it is done. > > > > > > Yep, this is very true, and I can't think of an easy way to > > decouple the JCI implementation from whatever receives the > > post. I think inherently that whatever receives the post > > needs to then add the data to the document that was created > > in the original AddDocumentByPost SOAP call. - I've managed > > this my placing a query parameter on the URL that is returned > > to the client as > > follows: > > > > We have a servlet that is listening on a particular path. > > The AddDocumentByPost returns the following: > > http://mypsiserver/axis/servlet/PSIPostServlet/urn:uuid:143832 > > 734-2340342-34 > > 34-3 > > > > Basically, we encode the DocumentURI on the return path. > > This allows the servlet that receives the post to make the > > association with the appropriate internal JCI document as follows: > > > > protected void doPost(HttpServletRequest req, > > HttpServletResponse resp) throws ServletException, IOException { > > try > > { > > String documentURI = req.getPathInfo().substring(1); > > // Find the appropriate document from our > > PSIDocument hash > > PSIDocument doc = > > PSIDocument.getDocumentByURI(documentURI); > > InputStream requestInputStream = req.getInputStream(); > > > > //Let the document object know about the input > > stream... doc.post(requestInputStream); > > > > // what do we return? > > resp.setContentLength(0); > > resp.getWriter().close(); > > } > > catch (Exception e) > > { > > e.printStackTrace(); > > throw new ServletException(e); // ??? > > } > > } > > > > > > It is also unclear what the implementation should do if the > > post fails for some reason, or in what order the > > implementation can expect to receive the posts. For example, > > it now seems the client could: > > > > 1. CreateJob > > 2. AddDocumentByPost last = false > > 3. AddDocumentByPost last = true > > 4. Post document 2 > > 5. Post document 1 > > > > This makes the implementation difficult, without really > > seeming to buy anything useful for the client. > > > > > > This is also true. Right now I have solved this by deferring > > processing of the job untill all of the document data has > > been received. There are some gating factors as to what > > allows a job to be processed: lastDocument == true > > AllDocumentDataReceived == true > > Technically this problem has a solution, even in the > out-of-order case. I think the real question is whether all > the service implementors should be burdened with this > additional coupling when it can be fairly easily be avoided > without unduly limiting the client implementation (I think). > > > If the lastDocument flag were removed from the > > AddDocumentByPost call, and if the additional requirement > > were made that the client could not perform any additional > > AddDocumentByReference or AddDocumentByPost calls until > > either the post was complete, or a CancelDocument call were > > made for the pending document, then the implementation would > > be much simpler. Then the example above would be: > > > > 1. CreateJob > > 2. AddDocumentByPost > > 3. Post document 1 > > 4. AddDocumentByPost > > 5. Post document 2 > > 6. AddDocumentByReference last = true reference = null > > > > > > I like the idea of adding the requirement that the data MUST > > be posted directly after the AddDocumentByPost, and before > > any other AddDocumentBy* methods are called. I'll add it to > > the latest rev of the spec, and see if the working group approves. > > > > I don't like overloading the AddDocumentByReference to > > indicate the "I'm Done". Hopefully adding the interleaving > > requirement is sufficient for you needs. > > Then such an overloading does not already exist? That would > seem to be a problem, since you may not know at the time the > last document is started if it is the last document. I had > assumed that PSI was similar to IPP in that one of the > AddDocumentByPost and AddDocumentByReference was overloaded > and could be used to end the job, but I did not find a > reference to this. Is there any way to do this, or is it > always necessary to know that a job will be complete at the > commencement of the last document? > > Regards, > Mike > > > Though I can't seem to find where AddDocumentByReference with > > a null reference and attributes is actually allowed (it is, > > isn't it?) Maybe it's not to late for a completeJob( jobURI ) call? > > > > Mike Haller > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2342 bytes Desc: not available Url : http://www.pwg.org/archives/ps/attachments/20030301/c9af197b/smime-0001.bin From WWagner at NetSilicon.com Mon Mar 3 11:19:39 2003 From: WWagner at NetSilicon.com (Wagner,William) Date: Wed May 6 14:02:17 2009 Subject: PS> RE: PSI and Port 80, and printers traversing the firewall Message-ID: <7F2C5DA4096E9D44B70E967CB54EEEDB0E85BF@mamail.digi.com> David, Many thanks for the consideration. 1. I may be getting confused with the terminology. PSI defines three types of entities all of which have "Client" capability. From Figure 1 in the Developer's Guide, lets call the user client the "Mobile Device". So one has: Mobile Device - with a client capability Print Service - Client Capability QueryEndpointsInterface ServiceCapabilitiesInterface JobControlInterface TargetDeviceSupportInterface TargetDevice- Client Capability JobControlInterface QueryEndpointsInterface ServiceCapabilitiesInterface a. if there are no firewalls (or all components are inside a common network), there should be no problem using the psi-port communicating from any client to any interface b. in any case involving firewalls, any "server" interface needs special firewall handling, regardless of what port is used. c. a mobile device may very well be trying to communicate to the Print Service through a foreign firewall, which does not support the PSI Port. So allowing the Mobile client a port 80 backup is highly desirable. d. it would seem that a target device might want to operate in only the client mode. (This appears to be in violation of the requirement that the target device support all interfaces, but it is an attractive capability regardless) The target therefore could pull jobs from a internet Print Service to which it subscribed. This would allow "internet printing" without needing special firewall handling for the Target Device. The need to provide special firewall handing is one reason why IPP has not become a widely used "internet" printing protocol. Allowing the target device to pull jobs from a server that can be accessed via the internet would resolve this problem. But from your statement that "A Target Device shall implement PSI only on port psi-port", it is not clear to me that you are allowing the client in the target device to initiate a connection on port 80. I also do not understand your statement that: "If an administrator chooses to expose their print service on port 3700, then all traffic to it will be on 3700." 2. With respect to my comment about MIS not allowing a printer to communicate with an external server, the operative words here are "without adding more restrictions". And when I made the statement, I did indicate the restrictions that were required in the WBMM context. I believe that in defining the interface that the printer will use in this context, you are defining the restrictions. That is, you are limiting the printer contacts and what can transpire between the printer and the service or client. I believe that this will be acceptable to most enterprises, although it may be necessary in some implementations to allow configuration of more constraints, such as not supporting some interfaces, requiring authentication or encryption and possibly disallowing certain operations. Regards, Bill Wagner/NetSilicon. -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Friday, February 28, 2003 9:51 AM To: 'imcdonald@sharplabs.com'; Wagner,William; BERKEMA,ALAN C (HP-Roseville,ex1) Cc: 'ps@pwg.org' Subject: PSI and Port 80, and printers traversing the firewall Hi Bill... A couple of questions for you... You mentioned the following with regards to PSI and port 80: I am very sad to hear that PSI will not use port 80; I think that will very much handicap the potential of what is an excellent capability. Of course, IPP was assigned port 631, but many implementations still listen on port 80 as well. In consideration of this, Ira and I spent some time looking at PSI, and the use of port 80, and port 3700 (psi-port), and came up with the following proposal: * A Print Service shall implement PSI on psi-port, and port 80 (and thus, the path to ALL psi interfaces must be of the form pwg-psips://server/psi/...) * A Target Device shall implement PSI only on port psi-port * A Client shall always try to communicate with a Print Service on psi-port first, and if that fails, then utilize port 80. We believe that this reasoning enables the following requirements: 1) A company can deploy a PSI Print Service on their normal, publically exposed web-server on port 80. 2) All communication to a Target Device is on port 3700 for network monitoring purposes. 3) Within and enterprise, communication between a client and a Print Service is on 3700 for network monitoring purposes. 4) If an administrator chooses to expose their print service on port 3700, then all traffic to it will be on 3700... Do you feel that this addresses your concerns? (And your customers?) Second: Having been though this at various places. Asking if they would allow a printer that talks to an external server, without adding more restrictions, will get a very quick NO. This model is very important for many of the PSI firewall traversing use models! I do think that implementers of Target Devices should not have their printers come configured "out of the box" with the ability to go and fetch data from an external server. This should probably be something that the administrator needs to enable for particular printers within their enterprise. However, once allowed by the administrator, these "public printers" would then be able to retrieve publically initiated print jobs. Another option is to only allow "authorized users" to initiate these out-bound requests. This would be accomplished by authenticating the user via http, and then the Target Device would need to authorize the user against an acl.. Comments?? Dave From dhall at hp.com Mon Mar 3 11:37:50 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:17 2009 Subject: PS> RE: PSI and Port 80, and printers traversing the firewall Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAB25@xvan01.vcd.hp.com> Hi Bill and All... See comments inline below.. Dave David, Many thanks for the consideration. 1. I may be getting confused with the terminology. PSI defines three types of entities all of which have "Client" capability. From Figure 1 in the Developer's Guide, lets call the user client the "Mobile Device". So one has: Mobile Device - with a client capability Print Service - Client Capability QueryEndpointsInterface ServiceCapabilitiesInterface JobControlInterface TargetDeviceSupportInterface TargetDevice- Client Capability JobControlInterface QueryEndpointsInterface ServiceCapabilitiesInterface Yep, the client term is difficult to nail down. I'll see if I can be more explicit in the following comments.. a. if there are no firewalls (or all components are inside a common network), there should be no problem using the psi-port communicating from any client to any interface b. in any case involving firewalls, any "server" interface needs special firewall handling, regardless of what port is used. Yep, exactly - the PSI "server" interfaces on a Print Service, and the PSI "server" interfaces on a Target Device. c. a mobile device may very well be trying to communicate to the Print Service through a foreign firewall, which does not support the PSI Port. So allowing the Mobile client a port 80 backup is highly desirable. This is the hope that by allowing a PSI Print Service to also expose PSI "server" interfaces over port 80 will allow for more deployment scenarios that if we restricted it to only 3700 d. it would seem that a target device might want to operate in only the client mode. (This appears to be in violation of the requirement that the target device support all interfaces, but it is an attractive capability regardless) The target therefore could pull jobs from a internet Print Service to which it subscribed. This would allow "internet printing" without needing special firewall handling for the Target Device. The need to provide special firewall handing is one reason why IPP has not become a widely used "internet" printing protocol. Allowing the target device to pull jobs from a server that can be accessed via the internet would resolve this problem. A true PSI Target Device does indeed need to implement the "server" interfaces. However, I don't believe that there is anything precluding vendors from implementing only the "client" side of a Target Device. This implementation of a Target Device simply makes the Target Device look like it is behind a firewall from the Print Services "client" perspective. This is a similiar situation to the "Bluetooth Target Device Proxy" where the handheld pretends to be a "Target Device" and pulls the data from the Print Service, and then pushes it to the printer via BlueTooth. But from your statement that "A Target Device shall implement PSI only on port psi-port", it is not clear to me that you are allowing the client in the target device to initiate a connection on port 80. I think that the intention here is that a Target Device shall implement the PSI "server" set of interfaces only on port psi-port. The "client" side of the Target Device should behaive as per the client rules - try 3700 first, then 80. I also do not understand your statement that: "If an administrator chooses to expose their print service on port 3700, then all traffic to it will be on 3700." Give the client "rule" that clients must try 3700 first, and then 80 - if a Print Service is exposed on 3700, then all PSI method invocations from clients will be on port 3700. I added this comment into the specification so that implementers / deployers understand that 3700 may be the only thing available. 2. With respect to my comment about MIS not allowing a printer to communicate with an external server, the operative words here are "without adding more restrictions". And when I made the statement, I did indicate the restrictions that were required in the WBMM context. I believe that in defining the interface that the printer will use in this context, you are defining the restrictions. That is, you are limiting the printer contacts and what can transpire between the printer and the service or client. I believe that this will be acceptable to most enterprises, although it may be necessary in some implementations to allow configuration of more constraints, such as not supporting some interfaces, requiring authentication or encryption and possibly disallowing certain operations. Yep, exactly. This makes a lot of sense. Regards, Bill Wagner/NetSilicon. -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Friday, February 28, 2003 9:51 AM To: 'imcdonald@sharplabs.com'; Wagner,William; BERKEMA,ALAN C (HP-Roseville,ex1) Cc: 'ps@pwg.org' Subject: PSI and Port 80, and printers traversing the firewall Hi Bill... A couple of questions for you... You mentioned the following with regards to PSI and port 80: I am very sad to hear that PSI will not use port 80; I think that will very much handicap the potential of what is an excellent capability. Of course, IPP was assigned port 631, but many implementations still listen on port 80 as well. In consideration of this, Ira and I spent some time looking at PSI, and the use of port 80, and port 3700 (psi-port), and came up with the following proposal: * A Print Service shall implement PSI on psi-port, and port 80 (and thus, the path to ALL psi interfaces must be of the form pwg-psips://server/psi/...) * A Target Device shall implement PSI only on port psi-port * A Client shall always try to communicate with a Print Service on psi-port first, and if that fails, then utilize port 80. We believe that this reasoning enables the following requirements: 1) A company can deploy a PSI Print Service on their normal, publically exposed web-server on port 80. 2) All communication to a Target Device is on port 3700 for network monitoring purposes. 3) Within and enterprise, communication between a client and a Print Service is on 3700 for network monitoring purposes. 4) If an administrator chooses to expose their print service on port 3700, then all traffic to it will be on 3700... Do you feel that this addresses your concerns? (And your customers?) Second: Having been though this at various places. Asking if they would allow a printer that talks to an external server, without adding more restrictions, will get a very quick NO. This model is very important for many of the PSI firewall traversing use models! I do think that implementers of Target Devices should not have their printers come configured "out of the box" with the ability to go and fetch data from an external server. This should probably be something that the administrator needs to enable for particular printers within their enterprise. However, once allowed by the administrator, these "public printers" would then be able to retrieve publically initiated print jobs. Another option is to only allow "authorized users" to initiate these out-bound requests. This would be accomplished by authenticating the user via http, and then the Target Device would need to authorize the user against an acl.. Comments?? Dave From dhall at hp.com Mon Mar 3 11:44:19 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:17 2009 Subject: PS> PSI Spec wd-psi10-20030303 available Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAB28@xvan01.vcd.hp.com> Hey All.. The latest working draft of the PSI 1.0 Specification is available at: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030303.doc ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030303.pdf It includes a new JobControl method - CloseJob. Also included is the new psi-port / port 80 discussion. Please review these for tomorrows teleconference. Thanks! Dave From WWagner at NetSilicon.com Mon Mar 3 11:49:32 2003 From: WWagner at NetSilicon.com (Wagner,William) Date: Wed May 6 14:02:17 2009 Subject: PS> RE: PSI and Port 80, and printers traversing the firewall Message-ID: <7F2C5DA4096E9D44B70E967CB54EEEDB0E85C0@mamail.digi.com> Dave, The clarification is appreciated. However, I still seem to be missing something on: "If an administrator chooses to expose their print service on port 3700, then all traffic to it will be on 3700." Give the client "rule" that clients must try 3700 first, and then 80 - if a Print Service is exposed on 3700, then all PSI method invocations from clients will be on port 3700. I added this comment into the specification so that implementers / deployers understand that 3700 may be the only thing available. Doesn't that conflict with the proposal that "A Print Service shall implement PSI on psi-port, and port 80 ", which suggests that the print service must listen on both ports. And, given the instance where the mobile client cannot get through the firewall at his location via the PSI-port, should not the print service also listen on port 80? Thanks, Bill Wagner -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Monday, March 03, 2003 11:38 AM To: Wagner,William; HALL,DAVID (HP-Vancouver,ex1); imcdonald@sharplabs.com; BERKEMA,ALAN C (HP-Roseville,ex1) Cc: ps@pwg.org Subject: RE: PSI and Port 80, and printers traversing the firewall Hi Bill and All... See comments inline below.. Dave David, Many thanks for the consideration. 1. I may be getting confused with the terminology. PSI defines three types of entities all of which have "Client" capability. From Figure 1 in the Developer's Guide, lets call the user client the "Mobile Device". So one has: Mobile Device - with a client capability Print Service - Client Capability QueryEndpointsInterface ServiceCapabilitiesInterface JobControlInterface TargetDeviceSupportInterface TargetDevice- Client Capability JobControlInterface QueryEndpointsInterface ServiceCapabilitiesInterface Yep, the client term is difficult to nail down. I'll see if I can be more explicit in the following comments.. a. if there are no firewalls (or all components are inside a common network), there should be no problem using the psi-port communicating from any client to any interface b. in any case involving firewalls, any "server" interface needs special firewall handling, regardless of what port is used. Yep, exactly - the PSI "server" interfaces on a Print Service, and the PSI "server" interfaces on a Target Device. c. a mobile device may very well be trying to communicate to the Print Service through a foreign firewall, which does not support the PSI Port. So allowing the Mobile client a port 80 backup is highly desirable. This is the hope that by allowing a PSI Print Service to also expose PSI "server" interfaces over port 80 will allow for more deployment scenarios that if we restricted it to only 3700 d. it would seem that a target device might want to operate in only the client mode. (This appears to be in violation of the requirement that the target device support all interfaces, but it is an attractive capability regardless) The target therefore could pull jobs from a internet Print Service to which it subscribed. This would allow "internet printing" without needing special firewall handling for the Target Device. The need to provide special firewall handing is one reason why IPP has not become a widely used "internet" printing protocol. Allowing the target device to pull jobs from a server that can be accessed via the internet would resolve this problem. A true PSI Target Device does indeed need to implement the "server" interfaces. However, I don't believe that there is anything precluding vendors from implementing only the "client" side of a Target Device. This implementation of a Target Device simply makes the Target Device look like it is behind a firewall from the Print Services "client" perspective. This is a similiar situation to the "Bluetooth Target Device Proxy" where the handheld pretends to be a "Target Device" and pulls the data from the Print Service, and then pushes it to the printer via BlueTooth. But from your statement that "A Target Device shall implement PSI only on port psi-port", it is not clear to me that you are allowing the client in the target device to initiate a connection on port 80. I think that the intention here is that a Target Device shall implement the PSI "server" set of interfaces only on port psi-port. The "client" side of the Target Device should behaive as per the client rules - try 3700 first, then 80. I also do not understand your statement that: "If an administrator chooses to expose their print service on port 3700, then all traffic to it will be on 3700." Give the client "rule" that clients must try 3700 first, and then 80 - if a Print Service is exposed on 3700, then all PSI method invocations from clients will be on port 3700. I added this comment into the specification so that implementers / deployers understand that 3700 may be the only thing available. 2. With respect to my comment about MIS not allowing a printer to communicate with an external server, the operative words here are "without adding more restrictions". And when I made the statement, I did indicate the restrictions that were required in the WBMM context. I believe that in defining the interface that the printer will use in this context, you are defining the restrictions. That is, you are limiting the printer contacts and what can transpire between the printer and the service or client. I believe that this will be acceptable to most enterprises, although it may be necessary in some implementations to allow configuration of more constraints, such as not supporting some interfaces, requiring authentication or encryption and possibly disallowing certain operations. Yep, exactly. This makes a lot of sense. Regards, Bill Wagner/NetSilicon. -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Friday, February 28, 2003 9:51 AM To: 'imcdonald@sharplabs.com'; Wagner,William; BERKEMA,ALAN C (HP-Roseville,ex1) Cc: 'ps@pwg.org' Subject: PSI and Port 80, and printers traversing the firewall Hi Bill... A couple of questions for you... You mentioned the following with regards to PSI and port 80: I am very sad to hear that PSI will not use port 80; I think that will very much handicap the potential of what is an excellent capability. Of course, IPP was assigned port 631, but many implementations still listen on port 80 as well. In consideration of this, Ira and I spent some time looking at PSI, and the use of port 80, and port 3700 (psi-port), and came up with the following proposal: * A Print Service shall implement PSI on psi-port, and port 80 (and thus, the path to ALL psi interfaces must be of the form pwg-psips://server/psi/...) * A Target Device shall implement PSI only on port psi-port * A Client shall always try to communicate with a Print Service on psi-port first, and if that fails, then utilize port 80. We believe that this reasoning enables the following requirements: 1) A company can deploy a PSI Print Service on their normal, publically exposed web-server on port 80. 2) All communication to a Target Device is on port 3700 for network monitoring purposes. 3) Within and enterprise, communication between a client and a Print Service is on 3700 for network monitoring purposes. 4) If an administrator chooses to expose their print service on port 3700, then all traffic to it will be on 3700... Do you feel that this addresses your concerns? (And your customers?) Second: Having been though this at various places. Asking if they would allow a printer that talks to an external server, without adding more restrictions, will get a very quick NO. This model is very important for many of the PSI firewall traversing use models! I do think that implementers of Target Devices should not have their printers come configured "out of the box" with the ability to go and fetch data from an external server. This should probably be something that the administrator needs to enable for particular printers within their enterprise. However, once allowed by the administrator, these "public printers" would then be able to retrieve publically initiated print jobs. Another option is to only allow "authorized users" to initiate these out-bound requests. This would be accomplished by authenticating the user via http, and then the Target Device would need to authorize the user against an acl.. Comments?? Dave From dhall at hp.com Mon Mar 3 11:58:58 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:17 2009 Subject: PS> RE: PSI and Port 80, and printers traversing the firewall Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAB2D@xvan01.vcd.hp.com> Let see.. The "expose their print service on port 3700" means that the admin has installed a Print Service on a machine behind his firewall, and then "port forwarded" port 3700 to that machine, then the external clients will end up connecting to the Print Service on port 3700, not port 80. So while the physical Print Service box will be available on both 3700 and 80 internally, the administrator can still chose to expose only port 3700 beyond the firewall. Make sense? Dave -----Original Message----- From: Wagner,William [mailto:WWagner@NetSilicon.com] Sent: Monday, March 03, 2003 8:50 AM To: HALL,DAVID (HP-Vancouver,ex1); imcdonald@sharplabs.com; BERKEMA,ALAN C (HP-Roseville,ex1) Cc: ps@pwg.org Subject: RE: PSI and Port 80, and printers traversing the firewall Dave, The clarification is appreciated. However, I still seem to be missing something on: "If an administrator chooses to expose their print service on port 3700, then all traffic to it will be on 3700." Give the client "rule" that clients must try 3700 first, and then 80 - if a Print Service is exposed on 3700, then all PSI method invocations from clients will be on port 3700. I added this comment into the specification so that implementers / deployers understand that 3700 may be the only thing available. Doesn't that conflict with the proposal that "A Print Service shall implement PSI on psi-port, and port 80 ", which suggests that the print service must listen on both ports. And, given the instance where the mobile client cannot get through the firewall at his location via the PSI-port, should not the print service also listen on port 80? Thanks, Bill Wagner -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Monday, March 03, 2003 11:38 AM To: Wagner,William; HALL,DAVID (HP-Vancouver,ex1); imcdonald@sharplabs.com; BERKEMA,ALAN C (HP-Roseville,ex1) Cc: ps@pwg.org Subject: RE: PSI and Port 80, and printers traversing the firewall Hi Bill and All... See comments inline below.. Dave David, Many thanks for the consideration. 1. I may be getting confused with the terminology. PSI defines three types of entities all of which have "Client" capability. From Figure 1 in the Developer's Guide, lets call the user client the "Mobile Device". So one has: Mobile Device - with a client capability Print Service - Client Capability QueryEndpointsInterface ServiceCapabilitiesInterface JobControlInterface TargetDeviceSupportInterface TargetDevice- Client Capability JobControlInterface QueryEndpointsInterface ServiceCapabilitiesInterface Yep, the client term is difficult to nail down. I'll see if I can be more explicit in the following comments.. a. if there are no firewalls (or all components are inside a common network), there should be no problem using the psi-port communicating from any client to any interface b. in any case involving firewalls, any "server" interface needs special firewall handling, regardless of what port is used. Yep, exactly - the PSI "server" interfaces on a Print Service, and the PSI "server" interfaces on a Target Device. c. a mobile device may very well be trying to communicate to the Print Service through a foreign firewall, which does not support the PSI Port. So allowing the Mobile client a port 80 backup is highly desirable. This is the hope that by allowing a PSI Print Service to also expose PSI "server" interfaces over port 80 will allow for more deployment scenarios that if we restricted it to only 3700 d. it would seem that a target device might want to operate in only the client mode. (This appears to be in violation of the requirement that the target device support all interfaces, but it is an attractive capability regardless) The target therefore could pull jobs from a internet Print Service to which it subscribed. This would allow "internet printing" without needing special firewall handling for the Target Device. The need to provide special firewall handing is one reason why IPP has not become a widely used "internet" printing protocol. Allowing the target device to pull jobs from a server that can be accessed via the internet would resolve this problem. A true PSI Target Device does indeed need to implement the "server" interfaces. However, I don't believe that there is anything precluding vendors from implementing only the "client" side of a Target Device. This implementation of a Target Device simply makes the Target Device look like it is behind a firewall from the Print Services "client" perspective. This is a similiar situation to the "Bluetooth Target Device Proxy" where the handheld pretends to be a "Target Device" and pulls the data from the Print Service, and then pushes it to the printer via BlueTooth. But from your statement that "A Target Device shall implement PSI only on port psi-port", it is not clear to me that you are allowing the client in the target device to initiate a connection on port 80. I think that the intention here is that a Target Device shall implement the PSI "server" set of interfaces only on port psi-port. The "client" side of the Target Device should behaive as per the client rules - try 3700 first, then 80. I also do not understand your statement that: "If an administrator chooses to expose their print service on port 3700, then all traffic to it will be on 3700." Give the client "rule" that clients must try 3700 first, and then 80 - if a Print Service is exposed on 3700, then all PSI method invocations from clients will be on port 3700. I added this comment into the specification so that implementers / deployers understand that 3700 may be the only thing available. 2. With respect to my comment about MIS not allowing a printer to communicate with an external server, the operative words here are "without adding more restrictions". And when I made the statement, I did indicate the restrictions that were required in the WBMM context. I believe that in defining the interface that the printer will use in this context, you are defining the restrictions. That is, you are limiting the printer contacts and what can transpire between the printer and the service or client. I believe that this will be acceptable to most enterprises, although it may be necessary in some implementations to allow configuration of more constraints, such as not supporting some interfaces, requiring authentication or encryption and possibly disallowing certain operations. Yep, exactly. This makes a lot of sense. Regards, Bill Wagner/NetSilicon. -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Friday, February 28, 2003 9:51 AM To: 'imcdonald@sharplabs.com'; Wagner,William; BERKEMA,ALAN C (HP-Roseville,ex1) Cc: 'ps@pwg.org' Subject: PSI and Port 80, and printers traversing the firewall Hi Bill... A couple of questions for you... You mentioned the following with regards to PSI and port 80: I am very sad to hear that PSI will not use port 80; I think that will very much handicap the potential of what is an excellent capability. Of course, IPP was assigned port 631, but many implementations still listen on port 80 as well. In consideration of this, Ira and I spent some time looking at PSI, and the use of port 80, and port 3700 (psi-port), and came up with the following proposal: * A Print Service shall implement PSI on psi-port, and port 80 (and thus, the path to ALL psi interfaces must be of the form pwg-psips://server/psi/...) * A Target Device shall implement PSI only on port psi-port * A Client shall always try to communicate with a Print Service on psi-port first, and if that fails, then utilize port 80. We believe that this reasoning enables the following requirements: 1) A company can deploy a PSI Print Service on their normal, publically exposed web-server on port 80. 2) All communication to a Target Device is on port 3700 for network monitoring purposes. 3) Within and enterprise, communication between a client and a Print Service is on 3700 for network monitoring purposes. 4) If an administrator chooses to expose their print service on port 3700, then all traffic to it will be on 3700... Do you feel that this addresses your concerns? (And your customers?) Second: Having been though this at various places. Asking if they would allow a printer that talks to an external server, without adding more restrictions, will get a very quick NO. This model is very important for many of the PSI firewall traversing use models! I do think that implementers of Target Devices should not have their printers come configured "out of the box" with the ability to go and fetch data from an external server. This should probably be something that the administrator needs to enable for particular printers within their enterprise. However, once allowed by the administrator, these "public printers" would then be able to retrieve publically initiated print jobs. Another option is to only allow "authorized users" to initiate these out-bound requests. This would be accomplished by authenticating the user via http, and then the Target Device would need to authorize the user against an acl.. Comments?? Dave From alan.berkema at hp.com Mon Mar 3 12:40:09 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:17 2009 Subject: PS> [PSI]: minutes 2/18; next call 03/04/03 Message-ID: <499DC368E25AD411B3F100902740AD650E6AD6E5@xrose03.rose.hp.com> Teleconference details: NEXT: Tuesday March 04 2003 (USA) Time: 8 AM (US PST) Number: 866-639-4738 Participant PIN: 7855605 Agenda: 1) PSI Port 2) Difficulty with AddDocumentByPost 3) Ready for Last Call 4) ? Meeting 02/18/03 PSI Working Group: *Alan Berkema *Dave Hall Gail Songer Jerry Thasher *Harry Lewis Ted Tronson Peter Mierau Peter Zehler Paul Tykodi *Bob Taylor Don Levinstone Lee Farrell Don Wright Kirk Ocke *Ira Mcdonald Amir Shahindoust Alain Regnier * = attendance Agenda: 1) Review Create Fetch Job 2) Schedule Update Brief Minutes 02/18/03 Minutes: 1) This is the function that is intended to solve the "and then a Miracle happens" when a client originates a job directly to the PS when the PS cannot contact the Target. Looking at this method lead to lots of good discussion around some of the methods that have not to date been scrutinized as closely as the main stream methods. Summary: 1) Create does not make sense in the method name, job was already created this just says go get it. Method name changed to just fetchJob. 2) This kicks off the getJobs method 3) Followed by getNextJob 0) Another out come was that associateTargetDevice was sorta half baked and we really only need registerTargetDevice. Lots of detail in latest rev. ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030303.doc ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030303.pdf 2) Schedule will discuss "last call" readiness at next call ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 27995593 Meeting Password: newpsi Host: Alan Berkema 1(916)7855605 From alan.berkema at hp.com Mon Mar 3 13:32:31 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:17 2009 Subject: PS> [PSI]: January 03 F2F Minutes Message-ID: <499DC368E25AD411B3F100902740AD650E6AD6E9@xrose03.rose.hp.com> Proposed meeting minutes have been posted ftp://ftp.pwg.org/pub/pwg/ps/wd/PSIMeetingMinutes0103.pdf Thanks Jerry, Alan From imcdonald at sharplabs.com Mon Mar 3 16:48:24 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:17 2009 Subject: PS> [PSI]: [corrected URL] January 03 F2F Minutes Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF19@mailsrvnt02.enet.sharplabs.com> Hi, The URL below is incorrect. The actual location is: ftp://ftp.pwg.org/pub/pwg/ps/PSIMeetingMinutes0103.pdf Thanks again Jerry, - Ira McDonald High North Inc -----Original Message----- From: BERKEMA,ALAN C (HP-Roseville,ex1) [mailto:alan.berkema@hp.com] Sent: Monday, March 03, 2003 12:33 PM To: 'a PSI pwg.org' Subject: PS> [PSI]: January 03 F2F Minutes Proposed meeting minutes have been posted ftp://ftp.pwg.org/pub/pwg/ps/wd/PSIMeetingMinutes0103.pdf Thanks Jerry, Alan From alain at tpo.ussj.ricoh.com Mon Mar 3 21:12:08 2003 From: alain at tpo.ussj.ricoh.com (Alain Regnier) Date: Wed May 6 14:02:17 2009 Subject: PS> a few questions about the current specification Message-ID: <60B6A4FA4A8CBC47A9B8B7DA28655C0C04C8AD@w2ksvr.tpo.ussj.ricoh.com> What is meant exactly by Method Support in the specification? Do we talk about the "implementation" or the "utilization" of an interface or a method? If we talk about the implementation, I don't really see why "CreateJob" and "CloseJob" are mandatory for Clients. (Why should Clients implement these methods?) 5.5.6 Regarding the filtering criteria of GetJobs, I'm not sure why we have to support element by element filtering. Isn't "group of elements" filtering enough? Do we really need such a granularity? It makes implementation more complex, and I'm not sure the gain in term of bandwidth, or XML processing is that good. (and you have to process the XML document anyway) 5.12 for FetchJobs, what else than JobURI, JobAccountingUserID and JobPassword might be needed in the jobFilter? Do we expect the Print Service to do any kind of filtering on other elements? Alain Regnier Ricoh Corp From dhall at hp.com Tue Mar 4 15:46:17 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:17 2009 Subject: PS> Separating WSDL into 3 files Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAB49@xvan01.vcd.hp.com> Hey All.. Does anyone know the syntatically correct way to do this? I'm in the JobCntrolBinding.wsdl, trying to figure out how to include the JobControlInterface.wsdl Dave From dhall at hp.com Tue Mar 4 18:25:03 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:17 2009 Subject: PS> PSI wd-psi10-20030304 Available Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAB4E@xvan01.vcd.hp.com> Hey All.. The latest working draft of the PSI 1.0 Specification is available at: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030304.doc ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030304.pdf It includes a new JobControl method - PushDocument, and the change of AddDocumentByPost to AddDocumentByPush. Thanks! Dave From dhall at hp.com Wed Mar 5 14:55:08 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:17 2009 Subject: PS> Successful PSI SOAP conversation! :) Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAB58@xvan01.vcd.hp.com> Hey All! We've gotten our first successful SOAP interaction between our JUnit test harness and our server! :) Here's a dump of the conversation. There is some clean-up to do to make it fully PSI spec compliant, but it should give you an idea of the client -> server interaction. (Note that this box is not publicly accessible. We hope to have a public ally accessible deployment for preliminary interops sometime in the next couple of weeks.) The basic set of calls are as follows: 1. HTTP request on PSI ServiceRootURL returns http://vcsdhall4.vcd.hp.com:3701/axis/services/QueryEndPointsInterface 2. QueryInterfaceDefinition(JobControlInterface) returns http://vcsdhall4.vcd.hp.com:3701/axis/services/JobControlInterface 3. CreateJob, AddDocumentByReference 4. Go into polling loop, calling GetJobElements, looking for completed state Dave tcpTrace version 0.6.0.648 Copyright 2000-2001 Simon Fell & Matt Humphrey. All rights reserved. Log Started, 03/05/2003 11:16:55:0484 Logged at, 03/05/2003 11:17:01:0671 GET /psi/0.95 HTTP/1.1 User-Agent: Java/1.4.1_01 Host: localhost:3701 Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2 Connection: keep-alive HTTP/1.1 200 OK Content-Type: text/plain Content-Length: 70 Date: Wed, 05 Mar 2003 19:17:01 GMT Server: Apache Coyote/1.0 http://vcsdhall4.vcd.hp.com:3701/axis/services/QueryEndPointsInterface Connection Opened, 03/05/2003 11:17:01:0640 Connection Closed, 03/05/2003 11:17:01:0671 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 950 # Bytes Server -> Client, 766 Client Data, POST /axis/services/QueryEndPointsInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "QueryInterfaceDefinition" Content-Length: 618 JobControlInterface 0.95 pwg-sm false Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:01 GMT Server: Apache Coyote/1.0 Connection: close http://vcsdhall4.vcd.hp.com:3701/axis/services/JobControlInterface< /InterfaceEndPointURI> http://vcsdhall4.vcd.hp.com:3701/axis/services/JobControlInterface/ wsdl Logged at, 03/05/2003 11:17:03:0671 Connection Opened, 03/05/2003 11:17:03:0359 Connection Closed, 03/05/2003 11:17:03:0671 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 1343 # Bytes Server -> Client, 601 Client Data, POST /axis/services/JobControlInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "CreateJob" Content-Length: 1029 pwg-unc://mep-print-serv/null true false Example PSI Job PSI User Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:03 GMT Server: Apache Coyote/1.0 Connection: close urn:uuid:61033211-f6e0-47fb-8eed-e4d864f4a25f Logged at, 03/05/2003 11:17:03:0781 Connection Opened, 03/05/2003 11:17:03:0703 Connection Closed, 03/05/2003 11:17:03:0781 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 986 # Bytes Server -> Client, 637 Client Data, POST /axis/services/JobControlInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "AddDocumentByReference" Content-Length: 660 urn:uuid:61033211-f6e0-47fb-8eed-e4d864f4a25f http://www.pwg.org/ps true Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:03 GMT Server: Apache Coyote/1.0 Connection: close urn:uuid:ad5309e1-cacf-46d5-a3ca-ea0cf0982177 Logged at, 03/05/2003 11:17:04:0218 Connection Opened, 03/05/2003 11:17:03:0843 Connection Closed, 03/05/2003 11:17:04:0218 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 927 # Bytes Server -> Client, 659 Client Data, POST /axis/services/JobControlInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "GetJobElements" Content-Length: 609 urn:uuid:61033211-f6e0-47fb-8eed-e4d864f4a25f processing Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:03 GMT Server: Apache Coyote/1.0 Connection: close pending Logged at, 03/05/2003 11:17:05:0265 Connection Opened, 03/05/2003 11:17:05:0234 Connection Closed, 03/05/2003 11:17:05:0265 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 927 # Bytes Server -> Client, 659 Client Data, POST /axis/services/JobControlInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "GetJobElements" Content-Length: 609 urn:uuid:61033211-f6e0-47fb-8eed-e4d864f4a25f processing Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:05 GMT Server: Apache Coyote/1.0 Connection: close pending Logged at, 03/05/2003 11:17:06:0312 Connection Opened, 03/05/2003 11:17:06:0265 Connection Closed, 03/05/2003 11:17:06:0312 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 927 # Bytes Server -> Client, 659 Client Data, POST /axis/services/JobControlInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "GetJobElements" Content-Length: 609 urn:uuid:61033211-f6e0-47fb-8eed-e4d864f4a25f processing Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:06 GMT Server: Apache Coyote/1.0 Connection: close pending Logged at, 03/05/2003 11:17:07:0421 Connection Opened, 03/05/2003 11:17:07:0375 Connection Closed, 03/05/2003 11:17:07:0421 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 927 # Bytes Server -> Client, 662 Client Data, POST /axis/services/JobControlInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "GetJobElements" Content-Length: 609 urn:uuid:61033211-f6e0-47fb-8eed-e4d864f4a25f processing Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:07 GMT Server: Apache Coyote/1.0 Connection: close processing Logged at, 03/05/2003 11:17:08:0468 Connection Opened, 03/05/2003 11:17:08:0421 Connection Closed, 03/05/2003 11:17:08:0468 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 927 # Bytes Server -> Client, 662 Client Data, POST /axis/services/JobControlInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "GetJobElements" Content-Length: 609 urn:uuid:61033211-f6e0-47fb-8eed-e4d864f4a25f processing Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:08 GMT Server: Apache Coyote/1.0 Connection: close processing Logged at, 03/05/2003 11:17:09:0531 Connection Opened, 03/05/2003 11:17:09:0484 Connection Closed, 03/05/2003 11:17:09:0531 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 927 # Bytes Server -> Client, 662 Client Data, POST /axis/services/JobControlInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "GetJobElements" Content-Length: 609 urn:uuid:61033211-f6e0-47fb-8eed-e4d864f4a25f processing Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:09 GMT Server: Apache Coyote/1.0 Connection: close processing Logged at, 03/05/2003 11:17:10:0593 Connection Opened, 03/05/2003 11:17:10:0546 Connection Closed, 03/05/2003 11:17:10:0593 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 927 # Bytes Server -> Client, 662 Client Data, POST /axis/services/JobControlInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "GetJobElements" Content-Length: 609 urn:uuid:61033211-f6e0-47fb-8eed-e4d864f4a25f processing Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:10 GMT Server: Apache Coyote/1.0 Connection: close processing Logged at, 03/05/2003 11:17:11:0562 Connection Opened, 03/05/2003 11:17:01:0562 Connection Closed, 03/05/2003 11:17:11:0562 Source, 127.0.0.1 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 161 # Bytes Server -> Client, 199 Client Data, GET /psi/0.95 HTTP/1.1 User-Agent: Java/1.4.1_01 Host: localhost:3701 Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2 Connection: keep-alive Server Data, HTTP/1.1 200 OK Content-Type: text/plain Content-Length: 70 Date: Wed, 05 Mar 2003 19:17:01 GMT Server: Apache Coyote/1.0 http://vcsdhall4.vcd.hp.com:3701/axis/services/QueryEndPointsInterface Logged at, 03/05/2003 11:17:11:0687 Connection Opened, 03/05/2003 11:17:11:0656 Connection Closed, 03/05/2003 11:17:11:0687 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 927 # Bytes Server -> Client, 662 Client Data, POST /axis/services/JobControlInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "GetJobElements" Content-Length: 609 urn:uuid:61033211-f6e0-47fb-8eed-e4d864f4a25f processing Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:11 GMT Server: Apache Coyote/1.0 Connection: close processing Logged at, 03/05/2003 11:17:12:0750 Connection Opened, 03/05/2003 11:17:12:0703 Connection Closed, 03/05/2003 11:17:12:0750 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 927 # Bytes Server -> Client, 662 Client Data, POST /axis/services/JobControlInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "GetJobElements" Content-Length: 609 urn:uuid:61033211-f6e0-47fb-8eed-e4d864f4a25f processing Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:12 GMT Server: Apache Coyote/1.0 Connection: close processing Logged at, 03/05/2003 11:17:13:0796 Connection Opened, 03/05/2003 11:17:13:0750 Connection Closed, 03/05/2003 11:17:13:0796 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 927 # Bytes Server -> Client, 662 Client Data, POST /axis/services/JobControlInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "GetJobElements" Content-Length: 609 urn:uuid:61033211-f6e0-47fb-8eed-e4d864f4a25f processing Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:13 GMT Server: Apache Coyote/1.0 Connection: close processing Logged at, 03/05/2003 11:17:14:0859 Connection Opened, 03/05/2003 11:17:14:0812 Connection Closed, 03/05/2003 11:17:14:0859 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 927 # Bytes Server -> Client, 662 Client Data, POST /axis/services/JobControlInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "GetJobElements" Content-Length: 609 urn:uuid:61033211-f6e0-47fb-8eed-e4d864f4a25f processing Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:14 GMT Server: Apache Coyote/1.0 Connection: close processing Logged at, 03/05/2003 11:17:15:0906 Connection Opened, 03/05/2003 11:17:15:0859 Connection Closed, 03/05/2003 11:17:15:0906 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 927 # Bytes Server -> Client, 662 Client Data, POST /axis/services/JobControlInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "GetJobElements" Content-Length: 609 urn:uuid:61033211-f6e0-47fb-8eed-e4d864f4a25f processing Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:15 GMT Server: Apache Coyote/1.0 Connection: close processing Logged at, 03/05/2003 11:17:17:0031 Connection Opened, 03/05/2003 11:17:16:0984 Connection Closed, 03/05/2003 11:17:17:0031 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 927 # Bytes Server -> Client, 662 Client Data, POST /axis/services/JobControlInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "GetJobElements" Content-Length: 609 urn:uuid:61033211-f6e0-47fb-8eed-e4d864f4a25f processing Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:17 GMT Server: Apache Coyote/1.0 Connection: close processing Logged at, 03/05/2003 11:17:18:0078 Connection Opened, 03/05/2003 11:17:18:0046 Connection Closed, 03/05/2003 11:17:18:0078 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 927 # Bytes Server -> Client, 662 Client Data, POST /axis/services/JobControlInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "GetJobElements" Content-Length: 609 urn:uuid:61033211-f6e0-47fb-8eed-e4d864f4a25f processing Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:18 GMT Server: Apache Coyote/1.0 Connection: close processing Logged at, 03/05/2003 11:17:19:0125 Connection Opened, 03/05/2003 11:17:19:0093 Connection Closed, 03/05/2003 11:17:19:0125 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 927 # Bytes Server -> Client, 662 Client Data, POST /axis/services/JobControlInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "GetJobElements" Content-Length: 609 urn:uuid:61033211-f6e0-47fb-8eed-e4d864f4a25f processing Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:19 GMT Server: Apache Coyote/1.0 Connection: close processing Logged at, 03/05/2003 11:17:20:0312 Connection Opened, 03/05/2003 11:17:20:0281 Connection Closed, 03/05/2003 11:17:20:0312 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 927 # Bytes Server -> Client, 662 Client Data, POST /axis/services/JobControlInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "GetJobElements" Content-Length: 609 urn:uuid:61033211-f6e0-47fb-8eed-e4d864f4a25f processing Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:20 GMT Server: Apache Coyote/1.0 Connection: close processing Logged at, 03/05/2003 11:17:21:0343 Connection Opened, 03/05/2003 11:17:21:0312 Connection Closed, 03/05/2003 11:17:21:0343 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 927 # Bytes Server -> Client, 662 Client Data, POST /axis/services/JobControlInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "GetJobElements" Content-Length: 609 urn:uuid:61033211-f6e0-47fb-8eed-e4d864f4a25f processing Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:21 GMT Server: Apache Coyote/1.0 Connection: close processing Logged at, 03/05/2003 11:17:22:0375 Connection Opened, 03/05/2003 11:17:22:0359 Connection Closed, 03/05/2003 11:17:22:0375 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 927 # Bytes Server -> Client, 662 Client Data, POST /axis/services/JobControlInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "GetJobElements" Content-Length: 609 urn:uuid:61033211-f6e0-47fb-8eed-e4d864f4a25f processing Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:22 GMT Server: Apache Coyote/1.0 Connection: close processing Logged at, 03/05/2003 11:17:23:0437 Connection Opened, 03/05/2003 11:17:23:0390 Connection Closed, 03/05/2003 11:17:23:0437 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 927 # Bytes Server -> Client, 662 Client Data, POST /axis/services/JobControlInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "GetJobElements" Content-Length: 609 urn:uuid:61033211-f6e0-47fb-8eed-e4d864f4a25f processing Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:23 GMT Server: Apache Coyote/1.0 Connection: close processing Logged at, 03/05/2003 11:17:24:0531 Connection Opened, 03/05/2003 11:17:24:0515 Connection Closed, 03/05/2003 11:17:24:0531 Source, 15.252.61.72 Destination, vcsdhall4.vcd.hp.com:3700 # Bytes Client -> Server, 927 # Bytes Server -> Client, 661 Client Data, POST /axis/services/JobControlInterface HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC1 Host: vcsdhall4.vcd.hp.com:3701 Cache-Control: no-cache Pragma: no-cache SOAPAction: "GetJobElements" Content-Length: 609 urn:uuid:61033211-f6e0-47fb-8eed-e4d864f4a25f processing Server Data, HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Date: Wed, 05 Mar 2003 19:17:24 GMT Server: Apache Coyote/1.0 Connection: close completed From alan.berkema at hp.com Wed Mar 5 18:44:35 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:17 2009 Subject: PS> [PSI]: minutes03/04/03; next call 03/11/03 Message-ID: <499DC368E25AD411B3F100902740AD650E6AD716@xrose03.rose.hp.com> Teleconference details: NEXT: Tuesday March 11 2003 (USA) Time: 8 AM (US PST) Number: 866-639-4738 Participant PIN: 7855605 Agenda: 1) Alain's e-mail Questions 2) addDocumnetByPush review 3) Ready for Last Call 4) ? Meeting 03/04/03 PSI Working Group: *Alan Berkema *Dave Hall Gail Songer -Jerry Thasher *Harry Lewis *Ted Tronson *Peter Mierau *Peter Zehler Paul Tykodi Bob Taylor Don Levinstone Lee Farrell Don Wright Kirk Ocke *Ira Mcdonald Amir Shahindoust *Alain Regnier *Mike Haller * = attendance Agenda: 1) PSI Port vs. Port 80 2) Difficulty with AddDocumentByPost 3) Alternate transport? 4) Alain's questions 5) Ready for Last Call Minutes: 1) Some desire to use PSI over port 80, some existing web servers and small office may only expose port 80. The psiport allows all trafiic to routed through this port and has load balancing advantages. Seperate accounting and security is also an advantage. See Ira's past discussion on Dynamic vs. Static ports at the end of these minutes for additional info. Summary: PSI devices will try the psiport first and this is the preffered port. Port 80 may be used as a last resort if the psiport fails. Port number 55559 will be used as the proto type port until we get an IANA number. 2 & 3) addDocumentByPost was changed to addDocumentByPush. This is followed by an HTTP PUT for data transfer *OR* a pushDocument method which passes the data by value, the data type is restricted to bin64 encoding PushDocument (documentURI : URI, documentData : base64Binary) : void The closeJob() method will replace the lastDocument flag in the addDocument* methods. This fixes a lot of logical holes. Much discussion about the error code for when a closeJob() occurs before all data has actually been transferred. I think "clientErrorDataPending" may be in the lead however, sequence error was a contender at one point. Need to carefully review all exception codes. 4) Alain's questions Even after running over time by close to an hour we did not get to this, it's up first next time. 5) Schedule will discuss "last call" readiness at next call Not ready yet, however, the pending "last call" seems to be getting folks to voice some needed improvements. Thanks, Alan ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 27995593 Meeting Password: newpsi Host: Alan Berkema 1(916)7855605 ---------------------------------------------------------------------------- - PSI interfaces SHOULD have a static port (IANA-registered by vendor 'PWG') that is always the PSI listen port. PSI interfaces SHOULD NOT use dynamic ports (even by protocol agreement during PSI WSDL sessions), because: 1) Firewalls and NAT (Network Address Translator) systems assume that all protocols allowed to pass (traverse the domain boundary) use static IANA-registered ports (permission rules are normally based on a specific application protocol over a specific numbered port). Firewalls/NATs often implement ALGs (Application Layer Gateways) that enforce fine-grained permission rules. But the premise is always that the protocol on a given port is INVARIANT, and is determined by the port number (FTP proxies are fundamentally dangerous, for this reason). Dynamic ports completely defeat ALGs and firewall permissions (thus destroying the 'security perimeter' of the firewall). (There are a series of horrible exceptions in ALGs around HTTP port 80, due to other 'hidden' application protocols - PSI should not go there...) 2) Boundary routers (between enterprise and public networks) and core routers (within the Internet backbone) manage quality of service and packet delivery by 'aggregating' destinations (host/port pairs) for routing decisions. Dynamic ports completely defeat traffic 'aggregation' (because the router has no way to know that the alternate port traffic is associated with the original static port traffic). Routers also block all ports that are not specifically authorized to cross a domain boundary (in one direction or the other - not necessarily both) in their permission rules. Dynamic ports simply won't work in the general case. Hope this helps. Cheers, - Ira McDonald High North Inc From imcdonald at sharplabs.com Thu Mar 6 10:28:29 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:17 2009 Subject: PS> Rationale for interim psi-port Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF20@mailsrvnt02.enet.sharplabs.com> Hi folks, As we discussed briefly on Tuesday, our recommendation, until IANA gives us an official "registered port" (greater than 1024), is to use "ephemeral port" 55559 as the interim psi-port for our prototyping and early testing (see section 5.1.1 of the spec that Dave Hall just posted). I just pulled down a current copy of the IANA Port Registry and found: lrs-paging 3700/tcp LRS NetPage lrs-paging 3700/udp LRS NetPage # Geoffrey Wossum February 2003 Cheers, - Ira McDonald High North Inc PS - An "ephemeral" or "dynamic" port is one greater than 49151. Such ports are used (for example) for the data transfer port for FTP (the control port MUST be 21). No one can reliably use an "ephemeral" port long-term. From alan.berkema at hp.com Mon Mar 10 12:15:15 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:17 2009 Subject: PS> [PSI]: additional number; next call 03/11/03 Message-ID: <499DC368E25AD411B3F100902740AD650E6AD735@xrose03.rose.hp.com> -----Original Message----- From: BERKEMA,ALAN C (HP-Roseville,ex1) [mailto:alan.berkema@hp.com] Sent: Wednesday, March 05, 2003 3:45 PM To: 'a PSI pwg.org' Subject: PS> [PSI]: minutes03/04/03; next call 03/11/03 Teleconference details: NEXT: Tuesday March 11 2003 (USA) Time: 8 AM (US PST) Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Alain's e-mail Questions 2) addDocumnetByPush review 3) Ready for Last Call 4) ? Meeting 03/04/03 PSI Working Group: *Alan Berkema *Dave Hall Gail Songer -Jerry Thasher *Harry Lewis *Ted Tronson *Peter Mierau *Peter Zehler Paul Tykodi Bob Taylor Don Levinstone Lee Farrell Don Wright Kirk Ocke *Ira Mcdonald Amir Shahindoust *Alain Regnier *Mike Haller * = attendance Agenda: 1) PSI Port vs. Port 80 2) Difficulty with AddDocumentByPost 3) Alternate transport? 4) Alain's questions 5) Ready for Last Call Minutes: 1) Some desire to use PSI over port 80, some existing web servers and small office may only expose port 80. The psiport allows all trafiic to routed through this port and has load balancing advantages. Seperate accounting and security is also an advantage. See Ira's past discussion on Dynamic vs. Static ports at the end of these minutes for additional info. Summary: PSI devices will try the psiport first and this is the preffered port. Port 80 may be used as a last resort if the psiport fails. Port number 55559 will be used as the proto type port until we get an IANA number. 2 & 3) addDocumentByPost was changed to addDocumentByPush. This is followed by an HTTP PUT for data transfer *OR* a pushDocument method which passes the data by value, the data type is restricted to bin64 encoding PushDocument (documentURI : URI, documentData : base64Binary) : void The closeJob() method will replace the lastDocument flag in the addDocument* methods. This fixes a lot of logical holes. Much discussion about the error code for when a closeJob() occurs before all data has actually been transferred. I think "clientErrorDataPending" may be in the lead however, sequence error was a contender at one point. Need to carefully review all exception codes. 4) Alain's questions Even after running over time by close to an hour we did not get to this, it's up first next time. 5) Schedule will discuss "last call" readiness at next call Not ready yet, however, the pending "last call" seems to be getting folks to voice some needed improvements. Thanks, Alan ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 27995593 Meeting Password: newpsi Host: Alan Berkema 1(916)7855605 ---------------------------------------------------------------------------- - PSI interfaces SHOULD have a static port (IANA-registered by vendor 'PWG') that is always the PSI listen port. PSI interfaces SHOULD NOT use dynamic ports (even by protocol agreement during PSI WSDL sessions), because: 1) Firewalls and NAT (Network Address Translator) systems assume that all protocols allowed to pass (traverse the domain boundary) use static IANA-registered ports (permission rules are normally based on a specific application protocol over a specific numbered port). Firewalls/NATs often implement ALGs (Application Layer Gateways) that enforce fine-grained permission rules. But the premise is always that the protocol on a given port is INVARIANT, and is determined by the port number (FTP proxies are fundamentally dangerous, for this reason). Dynamic ports completely defeat ALGs and firewall permissions (thus destroying the 'security perimeter' of the firewall). (There are a series of horrible exceptions in ALGs around HTTP port 80, due to other 'hidden' application protocols - PSI should not go there...) 2) Boundary routers (between enterprise and public networks) and core routers (within the Internet backbone) manage quality of service and packet delivery by 'aggregating' destinations (host/port pairs) for routing decisions. Dynamic ports completely defeat traffic 'aggregation' (because the router has no way to know that the alternate port traffic is associated with the original static port traffic). Routers also block all ports that are not specifically authorized to cross a domain boundary (in one direction or the other - not necessarily both) in their permission rules. Dynamic ports simply won't work in the general case. Hope this helps. Cheers, - Ira McDonald High North Inc From dhall at hp.com Mon Mar 10 12:45:53 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:17 2009 Subject: PS> New PSI 1.0 Working Draft 20030310 Available Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAB71@xvan01.vcd.hp.com> Hey All... The latest version of the PSI specification is available. It includes references to new WSDL, and the new WSDL points to the latest semantic model schema definitions. ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030310.doc ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030310.pdf Schemas: http://www.pwg.org/schemas/ps/20030310/QueryEndPointsInterface.wsdl http://www.pwg.org/schemas/ps/20030310/ServiceCapabilitiesInterface.wsdl http://www.pwg.org/schemas/ps/20030310/JobControlInterface.wsdl http://www.pwg.org/schemas/ps/20030310/TargetDeviceSupportInterface.wsdl Dave From dhall at hp.com Mon Mar 10 16:24:00 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:17 2009 Subject: FW: PS> New PSI 1.0 Working Draft 20030310 Available Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAB7B@xvan01.vcd.hp.com> Also... It includes the new definitions for the interfaces AddDocumentBy*, PushDocument Dave -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Monday, March 10, 2003 9:46 AM To: 'ps@pwg.org' Subject: PS> New PSI 1.0 Working Draft 20030310 Available Hey All... The latest version of the PSI specification is available. It includes references to new WSDL, and the new WSDL points to the latest semantic model schema definitions. ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030310.doc ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030310.pdf Schemas: http://www.pwg.org/schemas/ps/20030310/QueryEndPointsInterface.wsdl http://www.pwg.org/schemas/ps/20030310/ServiceCapabilitiesInterface.wsdl http://www.pwg.org/schemas/ps/20030310/JobControlInterface.wsdl http://www.pwg.org/schemas/ps/20030310/TargetDeviceSupportInterface.wsdl Dave From alan.berkema at hp.com Thu Mar 13 18:03:43 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:17 2009 Subject: PS> [PSI]: next call 03/18/03 mins 3/11 Message-ID: <499DC368E25AD411B3F100902740AD650E6AD772@xrose03.rose.hp.com> Teleconference details: NEXT: Tuesday March 18 2003 (USA) Time: 8 AM (US PST) Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) closeDocument 2) The Mandatory vs. Supported language action (see 1.1 below) 3) FetchJobs filter example note (see 1.3 below) 4) Other Spec. Changes Review 5) Ready for Last Call Meeting 03/04/03 PSI Working Group: *Alan Berkema *Dave Hall *Gail Songer *Jerry Thasher Harry Lewis *Ted Tronson Peter Mierau Peter Zehler Paul Tykodi *Bob Taylor Don Levinstone Lee Farrell Don Wright Kirk Ocke *Ira Mcdonald Amir Shahindoust Alain Regnier Mike Haller *Darrell Hopp * = attendance Minutes: Agenda: 1) Alain's e-mail Questions 2) addDocumnetByPush review 3) Ready for Last Call 4) ? 2) Once addDocumnetByPush is submitted no more addDoc operations permitted until data has completed. Other methods such as cancel or status are OK. closeDocument indicates that the data transfer has completed. Still some discussion pending on this method. 1) Alain's questions 1.1) What is meant exactly by Method Support in the specification? Do we talk about the "implementation" or the "utilization" of an interface or a method? If we talk about the implementation, I don't really see why "CreateJob" and "CloseJob" are mandatory for Clients. (Why should Clients implement these methods?) Method support means the method shall be implemented. Dave will fix the specfifcation to state the intent more clearly in terms of shall be implemented and client is required to call etc. 1.2) 5.5.6 Regarding the filtering criteria of GetJobs, I'm not sure why we have to support element by element filtering. Isn't "group of elements" filtering enough? Do we really need such a granularity? It makes implementation more complex, and I'm not sure the gain in term of bandwidth, or XML processing is that good. (and you have to process the XML document anyway) Believe that the level of filtering is appropriate. The complexity is in the Sevice and having less granularity may actually make it more complex for the Client. 1.3) 5.12 for FetchJobs, what else than JobURI, JobAccountingUserID and JobPassword might be needed in the jobFilter? Do we expect the Print Service to do any kind of filtering on other elements? These are not the only possibilities. The example should note that these values are the only possibilities. 3) Determine if the spec is ready to begin a 4 week last call cycle F2F April 4 2003 Line by line editorial review Last Call Straw Vote - need concrete comments to vote against Interop Proto testing plans and schedule 3/24 is the last date to post slides other presentations for F2F Action: Prepare PSI presentation for FSG F2F Owner: Dave & Alan Status: 4) Get Jobs - improved language Only the jobs that the user is authorized to view shall be returned. From dhall at hp.com Fri Mar 14 11:11:39 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:17 2009 Subject: PS> PSI 1.0 Working Draft 20030221 Available Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAB94@xvan01.vcd.hp.com> Hey All.. The latest updated doc is available at: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030313.doc ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030313.pdf It includes the new ClosePushDocument method. (Renamed from CloseDocument, since it is only utilized after AddDocumentByPush) Dave From dhall at hp.com Mon Mar 17 20:06:15 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:17 2009 Subject: PS> Please Review!: PSI Spec wd-psi10-20030317 Available Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FABA9@xvan01.vcd.hp.com> Hey All.. The latest Spec is available at: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030317.doc ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030317.pdf In finishing up the ClosePushDocument method, I realized that we needed to consider the parallel methods in the TargetDeviceSupport interface. To this end, I have made the following changes to the specification. Please review and be ready to comment in tomorrows phone conference. (Sorry for the late notice!) New TargetDeviceSupportIInterface Methods: CloseJob... (Mirrors JobControl CloseJob) PullDocument... (Mirrors JobControl PushDocument in band data) ClosePullDocument... (Mirrors JobControl ClosePushDocument) Changed methods in TargetDeviceSupportInterface: GetNextDocument -> Now returns a DataSourceURIs - a container of URI's of which the client can choose which one to pull the data from. Thanks! Dave From harryl at us.ibm.com Tue Mar 18 12:58:36 2003 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:02:17 2009 Subject: PS> Soap with attachments - relation to SOAP 1.1 Message-ID: See http://www.w3.org/TR/SOAP-attachments section 4. Seems this has been around for quite a while. I suspect we'd have better interop than we anticipate. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/ps/attachments/20030318/769bc084/attachment-0001.html From dan_revel at hp.com Wed Mar 19 12:21:35 2003 From: dan_revel at hp.com (REVEL,DAN (HP-Vancouver,ex1)) Date: Wed May 6 14:02:17 2009 Subject: PS> Soap with attachments - relation to SOAP 1.1 Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF92E828@xvan01.vcd.hp.com> SOAP-attachments was a W3C submission, Microsoft et al. made a competing proposal, DIME, that seems to have more momentum: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwebsrv/ht ml/dimewsattch.asp -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, March 18, 2003 9:59 AM To: ps@pwg.org Subject: PS> Soap with attachments - relation to SOAP 1.1 See http://www.w3.org/TR/SOAP-attachments section 4. Seems this has been around for quite a while. I suspect we'd have better interop than we anticipate. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/ps/attachments/20030319/d9aa445c/attachment-0001.html From imcdonald at sharplabs.com Wed Mar 19 13:36:13 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:17 2009 Subject: PS> Soap with attachments - relation to SOAP 1.1 Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF3A@mailsrvnt02.enet.sharplabs.com> Hi Dan, We're aware of DIME. But the concensus of the PSI working group members is that the in-band transmission of document data MUST always be Base64 wrapped binary data. PSI (like IPP) identifies authoritatively, in the separate "document-format" attribute, the wrapped binary data format, using an IANA-registered MIME type. In PSI, this method is called "AddDocumentByValue". In PSI, two other methods exist: - "AddDocumentByPush" RETURNS a list of data sink URIs. The PSI client selects a data sink URI (for example "http:...") and pushes the document data out-of-band and then calls the in-band method "PushDocumentDataDelivered" (to avoid the PSI server having to poll the repository to see when the out-of-band document data has been delivered). - "AddDocumentByReference" SENDS an out-of-band reference to the document data. But since PSI messages are transferred in SOAP message envelopes, the reference MAY point to the IN-BAND document data later in the same SOAP message. Thus the discussion of the support (or lack of it) for the original "SOAP with Attachments". If many/any of the deployed proxies or intermediaries do NOT support this flavor of "SOAP with Attachments" then we want to deprecate such a use of "AddDocumentByReference" in the parallel PSI Developers Guide (the implementors guide for PSI). Note that because of the DIME versus MIME nonsense, the PSI method "AddDocumentByValue" MUST always wrap the binary data in Base64 and MUST NOT wrap the data in any other format (although the wrapped data may be MIME, DIME, or doorknobs). Hope that clarifies the context a little. Cheers, - Ira McDonald, contributing editor for PSI spec High North Inc -----Original Message----- From: REVEL,DAN (HP-Vancouver,ex1) [mailto:dan_revel@hp.com] Sent: Wednesday, March 19, 2003 11:22 AM To: 'Harry Lewis'; ps@pwg.org Subject: RE: PS> Soap with attachments - relation to SOAP 1.1 SOAP-attachments was a W3C submission, Microsoft et al. made a competing proposal, DIME, that seems to have more momentum: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwebsrv/ht ml/dimewsattch.asp -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, March 18, 2003 9:59 AM To: ps@pwg.org Subject: PS> Soap with attachments - relation to SOAP 1.1 See http://www.w3.org/TR/SOAP-attachments section 4. Seems this has been around for quite a while. I suspect we'd have better interop than we anticipate. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- From fujisawa.jun at canon.co.jp Thu Mar 20 08:25:29 2003 From: fujisawa.jun at canon.co.jp (Jun Fujisawa) Date: Wed May 6 14:02:17 2009 Subject: PS> Soap with attachments - relation to SOAP 1.1 In-Reply-To: References: Message-ID: Hello Harry, At 10:58 AM -0700 03.3.18, Harry Lewis wrote: >See http://www.w3.org/TR/SOAP-attachments section 4. Seems this has been >around for quite a while. I suspect we'd have better interop than we >anticipate. Just a quick note. This W3C Note is a submission from HP and Microsoft over 2 years ago. The W3C XML Protocol WG has then published a Working Draft for the abstract specification of SOAP 1.2 Attachment Feature and is expected to continue working on to have a new concrete specification of SOAP binary attachments. -- Jun Fujisawa From dhall at hp.com Fri Mar 21 12:21:33 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:17 2009 Subject: PS> PSI wd-psi10-20030321 available. Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FABC1@xvan01.vcd.hp.com> Hi All! The latest PSI specification is now available at: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030321.doc ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030321.pdf The corresponding WSDL is also availble at: http://www.pwg.org/schemas/ps/20030321/ Dave From alan.berkema at hp.com Mon Mar 24 18:18:27 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:17 2009 Subject: PS> [PSI]: next call 03/25/03 Message-ID: <499DC368E25AD411B3F100902740AD650E6AD7CC@xrose03.rose.hp.com> Teleconference details: NEXT: Tuesday March 25 2003 (USA) Time: 8 AM (US PST) Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Plan a call in place of F2F 2) Early review comments? ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 27995593 Meeting Password: newpsi Host: Alan Berkema 1(916)7855605 From alan.berkema at hp.com Mon Mar 24 19:26:27 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:17 2009 Subject: PS> FW: [PSI]: F2F Canceled Message-ID: <499DC368E25AD411B3F100902740AD650E6AD7D0@xrose03.rose.hp.com> Second try. -----Original Message----- From: BERKEMA,ALAN C (HP-Roseville,ex1) Sent: Monday, March 24, 2003 2:25 PM To: 'pwg-announce@pwg.org' Subject: [PSI]: F2F Canceled Hi all, Unfortunately Dave Hall and I have been forced to cancel our travel to the Washington DC PSI meeting on April 4th 2003. With out the chair and the editor I do not think it makes sense to have this meeting and it is officially canceled. Since it is on the last day and the airlines are not charging a penalty, hopefully, you can just return a day sooner. In April we will hold a Last Call Comment Resolution meeting which might be F2F, or via phone conference. At tomorrows PSI call we will attempt to schedule a phone conference/WeBex to take the place of the F2F. Thanks for your understanding, Alan From imcdonald at sharplabs.com Tue Mar 25 12:18:24 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:17 2009 Subject: PS> document-id-uri semantics Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF47@mailsrvnt02.enet.sharplabs.com> Hi, The current "document-id-uri" in the IPP Document Object spec clearly that states that it is an opaque identifier, and cannot be used as the target of an operation (unlike the "job-uri" in RFC 2911). And it gives an example of an 'ipp:' schemed URI. I think I should write an Appendix to the Document Object that: (1) extends the IPP URL Scheme (adopted last month by the IETF for RFC publication as an IETF Proposed Standard) to apply to Document objects as well, (2) specifies the opaque identifier limitation, (3) is normatively referenced by the "document-id-uri" attribute definition in the main spec. As we discussed on the PSI telecon this morning, PSI doesn't care what the URL scheme is in the DocumentURI, just that it be unique within a print server. Comments? Cheers, - Ira McDonald, co-editor of IPP URL Scheme High North Inc From hastings at cp10.es.xerox.com Tue Mar 25 16:48:30 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:02:17 2009 Subject: PS> RE: SM> document-id-uri semantics Message-ID: Is there any experimental scheme that we could use, so we don't have to muck with the "ipp:" scheme? If there is, we could just mention what that scheme is in the spec. Or since this is a URI data type, is there some URN form that we could use to give each document a unique identifiers? All we want is a unique identifier across that one Printer. Its doesn't have to be unique across all Printers, right? We also need to agree as to over what time period the ID has to be unique? If the Printer is powered off and comes back again, does it have to continue to generate unique URIs that it never generated before? Or don't we have to be that strict. Tom -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Tuesday, March 25, 2003 09:18 To: 'sm@pwg.org'; 'ps@pwg.org' Subject: SM> document-id-uri semantics Hi, The current "document-id-uri" in the IPP Document Object spec clearly that states that it is an opaque identifier, and cannot be used as the target of an operation (unlike the "job-uri" in RFC 2911). And it gives an example of an 'ipp:' schemed URI. I think I should write an Appendix to the Document Object that: (1) extends the IPP URL Scheme (adopted last month by the IETF for RFC publication as an IETF Proposed Standard) to apply to Document objects as well, (2) specifies the opaque identifier limitation, (3) is normatively referenced by the "document-id-uri" attribute definition in the main spec. As we discussed on the PSI telecon this morning, PSI doesn't care what the URL scheme is in the DocumentURI, just that it be unique within a print server. Comments? Cheers, - Ira McDonald, co-editor of IPP URL Scheme High North Inc From hastings at cp10.es.xerox.com Tue Mar 25 17:31:30 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:02:17 2009 Subject: PS> Improvements of the IPP "document-format-version" and JDF MimeOfF ileTypeVersion attributes Message-ID: Today on the FSG Job Ticket API, Ira, Claudia, Till, and I were discussion the current IPP "document-format-version" attribute in the IPP Document Object spec Working Draft, dated March 24, 2003 and the JDF MimeOfFileTypeVersion attribute in the JDF FIleSpec proposal, dated March 21, 2003. This mail note has two specific proposals: 1. Put the version strings into a flat file that can be updated and used by implementers. The respective specs can have an initial sets of strings for the flat file. 2. Make the verson strings self-identifying. Both of these specs are to be discussed on Thursday, March 27, (PWG Semantic Model WG and CIP4 System Behaviour and Interoperability WG). The current text for the IPP "document-format-version" attribute is: 6.1.2.7 document-format-version (text(127)) This REQUIRED member Operation attribute contains the level or version of the document format identified by the "document-format" member attribute. The client MAY supply and the Printer MUST support this member attribute. Possible values are the same as the Printer MIB [rfc1759] prtInterpreterLangLevel (not prtInterpreterLangVersion), such as: '3': For Postscript level 3 [rfc1759]. '5e': For PCL 5e [rfc1759]. Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as:: 'PDF/X-1:2001': For PDF/X-1 [iso15930]. "? 'PDF/X-1.2001': For PDF/X-1a [iso15930] 'TIFF/IT-FP:1998': TIFF/IT [iso12639] - Full Page - baseline. 'TIFF/IT-CT:1998': TIFF/IT [iso12639] - Continuous Tone picture data - baseline 'TIFF/IT-FP/P1:1998': TIFF/IT [iso12639] - Full Page - profile 1 'TIFF/IT-CT/P1:1998': TIFF/IT [iso12639] - Continuous Tone picture data - profile 1 The current text for the JDF MimeOfFileTypeVersion attribute is: The level or version of the file format identified by MimeType or, FileType. Some example values are the same as the Printer MIB [rfc1759] prtInterpreterLangLevel, such as: "1", "2", "3" for MimeType = "application/postscript" "3", "4", "5", "5e" for MimeType = "application/vnd.hp-PCL" Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as: "5.0", "6.0", "2000", "XP" for MimeType = "application/msword" "1.3", "1.4", "PDF/X-1:2001", "PDF/X-1a:2001" for MimeType = "application/pdf" "2.0" for FileType = "DCS" "???" for FileType = "ICC Profile" ISSUE (Ann): What versions for ICC Profiles? "TIFF-IT/FP:1998", "TIFF-IT/CT:1998", "TIFF-IT/LW:1998" for FileType = "TIFF/IT" See Appendix A.1 "FileSpec Resource examples for MimeType, FileType, MimeOrFileTypeVersion attributes" for additional examples in common use by JDF applications. The two suggestions for improvement is: 1. Put the version strings into a flat file so that implementers can get them, so that new values can be added to easily, after appropriate review, without having to republish either the IPP Document Object spec or the CIP4 JDF spec. ISSUE: Whether both the PWG and CIP4 would have their own flat files that they would co-ordinate is an issue to be discussed. 2. The version string should be self identifying, e.g., PDF/1.3, not just 1.3, PS/3, not just 3, PCL/5e, not just 5e. And to build more on the Printer MIB, RFC 1759 (and soon to be published Printer MIBv2) use both the Language Family and the Language Level attributes for the version. The Language Families for PostScript is PS, for PCL is PCL, for PDF is PDF. In the Printer MIB there are two attributes (MIBs call them "objects"): prtInterpreterLangFamily OBJECT-TYPE -- NOTE: In RFC 1759, the enumeration values were implicitly -- defined by this object. SYNTAX PrtInterpreterLangFamilyTC MAX-ACCESS read-only STATUS current DESCRIPTION "The family name of a Page Description Language (PDL) or control language which this interpreter in the printer can interpret or emulate. NOTE: The above description has been modified from RFC 1759 for clarification." prtInterpreterLangLevel OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..31)) MAX-ACCESS read-only STATUS current DESCRIPTION "The level of the language which this interpreter is interpreting or emulating. This might contain a value like '5e'for an interpreter which is emulating level 5e of the PCL language. It might contain '2' for an interpreter which is emulating level 2 of the PostScript language. Similarly it might contain '2' for an interpreter which is emulating level 2 of the HPGL language." The prtInterpreterLangFamily has a Textual Convention for the assignment of about 62 printer languages. The symbolic names are of the form: langXxxx For example there are the following: langPCL(3), -- PCL. Starting with PCL version 5, -- HP-GL/2 is included as part of the -- PCL language. -- PCL and HP-GL/2 are registered -- trademarks of Hewlett-Packard -- Company. langHPGL(4), -- Hewlett-Packard Graphics Language. -- HP-GL is a registered trademark of -- Hewlett-Packard Company. langPJL(5), -- Peripheral Job Language. Appears in -- the data stream between data intended -- for a page description language. -- Hewlett-Packard Co. langPS(6), -- PostScript (tm) Language -- Postscript - a trademark of Adobe -- Systems Incorporated which may be -- registered in certain jurisdictions langIPDS(7), -- Intelligent Printer Data Stream -- Bi-directional print data stream for -- documents consisting of data objects -- (text, image, graphics, bar codes), -- resources (fonts, overlays) and page, -- form and finishing instructions. -- Facilitates system level device -- control, document tracking and error -- recovery throughout the print -- process. -- IBM Corporation. ... langPDF(54), -- Not in RFC 1759 -- Adobe Portable Document Format -- Adobe Systems, Inc. langRPDL(55), -- Not in RFC 1759 -- Ricoh Page Description Language for -- printers. -- Technical manual "RPDL command -- reference" No.307029 -- RICOH, Co. LTD langIntermecIPL(56), -- Not in RFC 1759 -- Intermec Printer Language for label -- printers. -- Technical Manual: "IPL Programmers -- Reference Manual" -- Intermec Corporation langUBIFingerprint(57), -- Not in RFC 1759 -- An intelligent basic-like programming -- language for label printers. -- Reference Manual: "UBI Fingerprint -- 7.1", No. 1-960434-00 -- United Barcode Industries langUBIDirectProtocol(58), -- Not in RFC 1759 -- An intelligent control language for -- label printers. -- Programmers guide: " UBI Direct -- Protocol", No. 1-960419-00 -- United Barcode Industries langFujitsu(59), -- Not in RFC 1759 -- Fujitsu Printer Language -- Reference Manual: -- "FM Printer Sequence" No. 80HP-0770 -- FUJITSU LIMITED langCGM(60), -- Not in RFC 1759 -- Computer Graphics Metafile -- MIME type 'image/cgm' langJPEG(61), -- Not in RFC 1759 -- Joint Photographic Experts Group -- MIME type 'image/jpeg' langCALS1(62), -- Not in RFC 1759 -- US DOD CALS1 (see MIL-STD-1840) -- MIME type 'application/cals-1840' langCALS2(63), -- Not in RFC 1759 -- US DOD CALS2 (see MIL-STD-1840) -- MIME type 'application/cals-1840' langNIRS(64), -- Not in RFC 1759 -- US DOD NIRS (see MIL-STD-1840) -- MIME type 'application/cals-1840' langC4(65) -- Not in RFC 1759 -- US DOD C4 (see MIL-STD-1840) -- MIME type 'application/cals-1840' So take the prtInterpreterLangFamily textual convention after the "lang", follow it with a "/" and then have the prtInterpreterLangLevel. So the updated IPP "document-format-version" member attribute would become: 6.1.2.7 document-format-version (text(127)) This REQUIRED member Operation attribute contains the level or version of the document format identified by the "document-format" member attribute. The client MAY supply and the Printer MUST support this member attribute. Possible values are the same as the Printer MIB [rfc1759] prtInterpreterLangFamily textual convention (minus the "lang" prefix) and prtInterpreterLangLevel (not prtInterpreterLangVersion) separated by a "/", such as: 'PS/3': For Postscript level 3 [rfc1759]. 'PCL/5e': For PCL 5e [rfc1759]. Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such a: 'PDF/X-1:2001': For PDF/X-1 [iso15930]. "? 'PDF/X-1.2001': For PDF/X-1a [iso15930] 'TIFF/IT-FP:1998': TIFF/IT [iso12639] - Full Page - baseline. 'TIFF/IT-CT:1998': TIFF/IT [iso12639] - Continuous Tone picture data - baseline 'TIFF/IT-FP/P1:1998': TIFF/IT [iso12639] - Full Page - profile 1 'TIFF/IT-CT/P1:1998': TIFF/IT [iso12639] - Continuous Tone picture data - profile 1 See PWG www.pwg.org [need URL] for a flat file list of the version strings currently recognized for use in the PWG Semantic Model and derivative protocols, such as IPP and PSI. and the updated JDF MimeOrFileTypeVersion attribute would become: The level or version of the file format identified by MimeType or, FileType. Some example values are the same as the Printer MIB [rfc1759] prtInterpreterLangFamily textual convention (minus the "lang" prefix) and prtInterpreterLangLevel, such as: "PS/1", "PS/2", "PS/3" for MimeType = "application/postscript" "PCL/3", "PDL/4", "PCL/5", "PCL/5e" for MimeType = "application/vnd.hp-PCL" Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as: "MSWORD/5.0", "MSWORD/6.0", "MSWORD/2000", "MSWORD/XP" for MimeType = "application/msword" "PDF/1.3", "PDF/1.4", "PDF/X-1:2001", "PDF/X-1a:2001" for MimeType = "application/pdf" "DCS/2.0" for FileType = "DCS" "???" for FileType = "ICC Profile" ISSUE (Ann): What versions for ICC Profiles? "TIFF-IT/FP:1998", "TIFF-IT/CT:1998", "TIFF-IT/LW:1998" for FileType = "TIFF/IT" See CIP4 www.cip4.org [need URL] for the flat text file that contains the version strings currently recognized for the "FileSpec Resource attributes: MimeType, FileType, MimeOrFileTypeVersion in common use by JDF applications. Comments? Tom From dhall at hp.com Wed Mar 26 17:44:48 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:17 2009 Subject: PS> HP PSI Server available Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FABDF@xvan01.vcd.hp.com> Hey All.. We have a 20030321 PSI 1.0 implementation available at the following PSI Service Root URL: pwg-psips://hpps.vcd.hwp6.net:55558/psi/1.0 (55558 is redirected to 55559 through a tcp trace... Put an http in place of pwg-psips and paste it into your browser... Let me know if you are interested in doing a phone conference interop sometime in the next couple of weeks... (Or after that!) It is still under development, so your mileage may vary! :) Dave From hastings at cp10.es.xerox.com Wed Mar 26 18:05:00 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:02:17 2009 Subject: PS> More improvements to the IPP "document-format-version" and JDF Mi meOrFileTypeVersion attributes [4 ISSUES] Message-ID: Ira and I had even further thoughts about the IPP "document-format-version" (wihch don't affect the corresponding JDF MimeOrFileTypeVersion attributes since it is a top level attribute in the FileSpec resource): The proposal from yesterday is to make the values of IPP "docuent-format-version" and JDF MimeOrFileTypeVersion attributes be self-identifying, because they start with a prefix that identifies the format: "PDF/", "PS/", "PCL/", "TIFF/IT-", "DCS/", "MSWORD/", etc. ISSUE 01: OK to add the prefix values as proposed yesterday to the IPP "docuent-format-version" and JDF MimeOrFileTypeVersion attributes to make the values self identifying indendent of the correspoding IPP "document-format" and JDF MimeType attributes? Today's further thought is that we can now promote the IPP "document-format-version" member Operation attribute back to being a top level Document object attribute to accompany the existing "document-format" Operation attribute. This is because "document-format-version-supported" attribute now makes sense as a Printer Descrition attribute on its own, since the values would be things like: "PDF/1.3", "PDF/X-1:2001", "PS/3", "PCL/5e", "TIFF/IT-FP/P1:1998", "DCS/2.0", "MSWORD/2000" and don't need to be paired up with the correspoding "document-format-supported" Printer attribute values: "applicaition/pdf", "application/postscript", "application/vnd.hp-PCL", and "application/msword" MIME type values. ISSUE 02: OK to add a "document-format-version" operation and Document Description attribute to the IPP Document object spec? Just like the "document-format" Operation attribute which is also a member attribute of the "document-format-details" (1setOf collection) Operation/Document Description attribute, we'd keep "document-format-version" as a member attribute as well with the same prefixed values. This now means that "document-format" and "document-format-version" have all parallel construction: a. They are both operation attributes. b. They both have correspoding Document Description attributes that the Printer copies to. c. They both have "xxx-supported" Printer attributes. d. There is a "document-format-default" which now can have a corresponding "document-format-version-default" Printer attribute. ISSUE 03: OK to add "document-format-default" printer attribute? e. The Printer MUST reject the request if the "document-format" isn't supported. ISSUE 04: Do we want to make the same rule for the "document-format-version" or keep it as a Best Effort, unless the client supplies "ipp-attribute-fidelity"='true' or "job-mandatory-attributes"='document-format-version'? Comments? Thanks, Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, March 25, 2003 14:32 To: sm@pwg.org; ps@pwg.org Cc: CIP4 System Behaviour and Interoperability WG [system_behaviour@cip4.org]; CIP4 Capabilities WG [capabilities@cip4.org] Subject: SM> Improvements of the IPP "document-format-version" and JDF MimeOfF ileTypeVersion attributes Today on the FSG Job Ticket API, Ira, Claudia, Till, and I were discussion the current IPP "document-format-version" attribute in the IPP Document Object spec Working Draft, dated March 24, 2003 and the JDF MimeOfFileTypeVersion attribute in the JDF FIleSpec proposal, dated March 21, 2003. This mail note has two specific proposals: 1. Put the version strings into a flat file that can be updated and used by implementers. The respective specs can have an initial sets of strings for the flat file. 2. Make the verson strings self-identifying. Both of these specs are to be discussed on Thursday, March 27, (PWG Semantic Model WG and CIP4 System Behaviour and Interoperability WG). The current text for the IPP "document-format-version" attribute is: 6.1.2.7 document-format-version (text(127)) This REQUIRED member Operation attribute contains the level or version of the document format identified by the "document-format" member attribute. The client MAY supply and the Printer MUST support this member attribute. Possible values are the same as the Printer MIB [rfc1759] prtInterpreterLangLevel (not prtInterpreterLangVersion), such as: '3': For Postscript level 3 [rfc1759]. '5e': For PCL 5e [rfc1759]. Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as:: 'PDF/X-1:2001': For PDF/X-1 [iso15930]. "? 'PDF/X-1.2001': For PDF/X-1a [iso15930] 'TIFF/IT-FP:1998': TIFF/IT [iso12639] - Full Page - baseline. 'TIFF/IT-CT:1998': TIFF/IT [iso12639] - Continuous Tone picture data - baseline 'TIFF/IT-FP/P1:1998': TIFF/IT [iso12639] - Full Page - profile 1 'TIFF/IT-CT/P1:1998': TIFF/IT [iso12639] - Continuous Tone picture data - profile 1 The current text for the JDF MimeOfFileTypeVersion attribute is: The level or version of the file format identified by MimeType or, FileType. Some example values are the same as the Printer MIB [rfc1759] prtInterpreterLangLevel, such as: "1", "2", "3" for MimeType = "application/postscript" "3", "4", "5", "5e" for MimeType = "application/vnd.hp-PCL" Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as: "5.0", "6.0", "2000", "XP" for MimeType = "application/msword" "1.3", "1.4", "PDF/X-1:2001", "PDF/X-1a:2001" for MimeType = "application/pdf" "2.0" for FileType = "DCS" "???" for FileType = "ICC Profile" ISSUE (Ann): What versions for ICC Profiles? "TIFF-IT/FP:1998", "TIFF-IT/CT:1998", "TIFF-IT/LW:1998" for FileType = "TIFF/IT" See Appendix A.1 "FileSpec Resource examples for MimeType, FileType, MimeOrFileTypeVersion attributes" for additional examples in common use by JDF applications. The two suggestions for improvement is: 1. Put the version strings into a flat file so that implementers can get them, so that new values can be added to easily, after appropriate review, without having to republish either the IPP Document Object spec or the CIP4 JDF spec. ISSUE: Whether both the PWG and CIP4 would have their own flat files that they would co-ordinate is an issue to be discussed. 2. The version string should be self identifying, e.g., PDF/1.3, not just 1.3, PS/3, not just 3, PCL/5e, not just 5e. And to build more on the Printer MIB, RFC 1759 (and soon to be published Printer MIBv2) use both the Language Family and the Language Level attributes for the version. The Language Families for PostScript is PS, for PCL is PCL, for PDF is PDF. In the Printer MIB there are two attributes (MIBs call them "objects"): prtInterpreterLangFamily OBJECT-TYPE -- NOTE: In RFC 1759, the enumeration values were implicitly -- defined by this object. SYNTAX PrtInterpreterLangFamilyTC MAX-ACCESS read-only STATUS current DESCRIPTION "The family name of a Page Description Language (PDL) or control language which this interpreter in the printer can interpret or emulate. NOTE: The above description has been modified from RFC 1759 for clarification." prtInterpreterLangLevel OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..31)) MAX-ACCESS read-only STATUS current DESCRIPTION "The level of the language which this interpreter is interpreting or emulating. This might contain a value like '5e'for an interpreter which is emulating level 5e of the PCL language. It might contain '2' for an interpreter which is emulating level 2 of the PostScript language. Similarly it might contain '2' for an interpreter which is emulating level 2 of the HPGL language." The prtInterpreterLangFamily has a Textual Convention for the assignment of about 62 printer languages. The symbolic names are of the form: langXxxx For example there are the following: langPCL(3), -- PCL. Starting with PCL version 5, -- HP-GL/2 is included as part of the -- PCL language. -- PCL and HP-GL/2 are registered -- trademarks of Hewlett-Packard -- Company. langHPGL(4), -- Hewlett-Packard Graphics Language. -- HP-GL is a registered trademark of -- Hewlett-Packard Company. langPJL(5), -- Peripheral Job Language. Appears in -- the data stream between data intended -- for a page description language. -- Hewlett-Packard Co. langPS(6), -- PostScript (tm) Language -- Postscript - a trademark of Adobe -- Systems Incorporated which may be -- registered in certain jurisdictions langIPDS(7), -- Intelligent Printer Data Stream -- Bi-directional print data stream for -- documents consisting of data objects -- (text, image, graphics, bar codes), -- resources (fonts, overlays) and page, -- form and finishing instructions. -- Facilitates system level device -- control, document tracking and error -- recovery throughout the print -- process. -- IBM Corporation. ... langPDF(54), -- Not in RFC 1759 -- Adobe Portable Document Format -- Adobe Systems, Inc. langRPDL(55), -- Not in RFC 1759 -- Ricoh Page Description Language for -- printers. -- Technical manual "RPDL command -- reference" No.307029 -- RICOH, Co. LTD langIntermecIPL(56), -- Not in RFC 1759 -- Intermec Printer Language for label -- printers. -- Technical Manual: "IPL Programmers -- Reference Manual" -- Intermec Corporation langUBIFingerprint(57), -- Not in RFC 1759 -- An intelligent basic-like programming -- language for label printers. -- Reference Manual: "UBI Fingerprint -- 7.1", No. 1-960434-00 -- United Barcode Industries langUBIDirectProtocol(58), -- Not in RFC 1759 -- An intelligent control language for -- label printers. -- Programmers guide: " UBI Direct -- Protocol", No. 1-960419-00 -- United Barcode Industries langFujitsu(59), -- Not in RFC 1759 -- Fujitsu Printer Language -- Reference Manual: -- "FM Printer Sequence" No. 80HP-0770 -- FUJITSU LIMITED langCGM(60), -- Not in RFC 1759 -- Computer Graphics Metafile -- MIME type 'image/cgm' langJPEG(61), -- Not in RFC 1759 -- Joint Photographic Experts Group -- MIME type 'image/jpeg' langCALS1(62), -- Not in RFC 1759 -- US DOD CALS1 (see MIL-STD-1840) -- MIME type 'application/cals-1840' langCALS2(63), -- Not in RFC 1759 -- US DOD CALS2 (see MIL-STD-1840) -- MIME type 'application/cals-1840' langNIRS(64), -- Not in RFC 1759 -- US DOD NIRS (see MIL-STD-1840) -- MIME type 'application/cals-1840' langC4(65) -- Not in RFC 1759 -- US DOD C4 (see MIL-STD-1840) -- MIME type 'application/cals-1840' So take the prtInterpreterLangFamily textual convention after the "lang", follow it with a "/" and then have the prtInterpreterLangLevel. So the updated IPP "document-format-version" member attribute would become: 6.1.2.7 document-format-version (text(127)) This REQUIRED member Operation attribute contains the level or version of the document format identified by the "document-format" member attribute. The client MAY supply and the Printer MUST support this member attribute. Possible values are the same as the Printer MIB [rfc1759] prtInterpreterLangFamily textual convention (minus the "lang" prefix) and prtInterpreterLangLevel (not prtInterpreterLangVersion) separated by a "/", such as: 'PS/3': For Postscript level 3 [rfc1759]. 'PCL/5e': For PCL 5e [rfc1759]. Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such a: 'PDF/X-1:2001': For PDF/X-1 [iso15930]. "? 'PDF/X-1.2001': For PDF/X-1a [iso15930] 'TIFF/IT-FP:1998': TIFF/IT [iso12639] - Full Page - baseline. 'TIFF/IT-CT:1998': TIFF/IT [iso12639] - Continuous Tone picture data - baseline 'TIFF/IT-FP/P1:1998': TIFF/IT [iso12639] - Full Page - profile 1 'TIFF/IT-CT/P1:1998': TIFF/IT [iso12639] - Continuous Tone picture data - profile 1 See PWG www.pwg.org [need URL] for a flat file list of the version strings currently recognized for use in the PWG Semantic Model and derivative protocols, such as IPP and PSI. and the updated JDF MimeOrFileTypeVersion attribute would become: The level or version of the file format identified by MimeType or, FileType. Some example values are the same as the Printer MIB [rfc1759] prtInterpreterLangFamily textual convention (minus the "lang" prefix) and prtInterpreterLangLevel, such as: "PS/1", "PS/2", "PS/3" for MimeType = "application/postscript" "PCL/3", "PDL/4", "PCL/5", "PCL/5e" for MimeType = "application/vnd.hp-PCL" Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as: "MSWORD/5.0", "MSWORD/6.0", "MSWORD/2000", "MSWORD/XP" for MimeType = "application/msword" "PDF/1.3", "PDF/1.4", "PDF/X-1:2001", "PDF/X-1a:2001" for MimeType = "application/pdf" "DCS/2.0" for FileType = "DCS" "???" for FileType = "ICC Profile" ISSUE (Ann): What versions for ICC Profiles? "TIFF-IT/FP:1998", "TIFF-IT/CT:1998", "TIFF-IT/LW:1998" for FileType = "TIFF/IT" See CIP4 www.cip4.org [need URL] for the flat text file that contains the version strings currently recognized for the "FileSpec Resource attributes: MimeType, FileType, MimeOrFileTypeVersion in common use by JDF applications. Comments? Tom From imcdonald at sharplabs.com Sun Mar 30 19:38:37 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:17 2009 Subject: PS> PWG PSI Fri 4 April 10:30am PST Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF5B@mailsrvnt02.enet.sharplabs.com> Hi, Phone numbers and Web-Ex info (to watch the slides) will follow. I took the schedule from Gail Songer's Web info from Amy Patel. Dave Hall and Alan Berkema - where's the announcement of the PSI special telecon this coming Friday? Cheers, - Ira McDonald High North Inc From alan.berkema at hp.com Mon Mar 31 11:19:22 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:17 2009 Subject: PS> [PSI]: Friday Phone & Webex Message-ID: <499DC368E25AD411B3F100902740AD650E6AD819@xrose03.rose.hp.com> PSI Call 10:00AM - 12noon 1:00PM - 3:00PM Dial-In #: +1 719-457-0335 Participant Password: 400908# Will begin with an overview for FSG folks Next page turner for Last Call Comments Dave can you pass this along to FSG? FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. Meeting Summary Meeting Name: PSI Last Call Review I Scheduled Time: 4/4/2003 at 10:00AM (GMT -08:00) Pacific Time, USA & Canada. Meeting Number: 21659206 Any meeting attendee can use this number to join the meeting, at https://hp.webex.com/join/ Password: newpsi ---------------------------------------------------------------------------- ------------------------------------------------------------------- Meeting Summary Meeting Name: PSI Last Call Review II Scheduled Time: 4/4/2003 at 1:00PM (GMT -08:00) Pacific Time, USA & Canada. Meeting Number: 26342152 Any meeting attendee can use this number to join the meeting, at https://hp.webex.com/join/ Password: newpsi From dhall at hp.com Mon Mar 31 18:08:30 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:17 2009 Subject: PS> Updated PSI Documents Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FABF8@xvan01.vcd.hp.com> Hi All! I've updated the developers guide and the interface usage presentation to be up to date with the latest PSI specification. They are available at the following: ftp://ftp.pwg.org/pub/pwg/ps/psi10-devl-20030328.doc ftp://ftp.pwg.org/pub/pwg/ps/psi10-devl-20030328.pdf ftp://ftp.pwg.org/pub/pwg/ps/psi10-usage-20030327.ppt ftp://ftp.pwg.org/pub/pwg/ps/psi10-usage-20030327.pdf Please take a look at them before Friday's PSI teleconference, as we will be reviewing these documents during the first hour as a PSI overview for the freesoftware group, and others that haven't seen PSI yet. (Ira, can you forward to the freesoftware group? Thanks!) Dave From imcdonald at sharplabs.com Tue Apr 1 12:25:41 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:17 2009 Subject: PS> RE: IPv6 RFCs? [searching for RFCs] Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF69@mailsrvnt02.enet.sharplabs.com> Hi Alan, [I copied the PSI list, because below is an FAQ answer]. First your question - yes RFC 2461 is what IPv6 uses to replace ARP (and quite few other protocols). With RFC 2461 you can resolve a neighbor's IPv6 network layer address into the corresponding datalink layer address (for example the IEEE 802.x 48-bit or 64-bit address). To Web search for RFCs, go the RFC Editor's home page http://www.rfc-editor.org and select the 'RFC Search' button. There are several IETF mechanisms for finding RFCs. The simplest is the RFC Index (titles, authors, dates, only): ftp://ftp.isi.edu/in-notes/rfc-index.txt Another is that (once your interested in a given RFC by title), every even-numbered century RFC (3100, 3200, etc.) is the complete latest version of "Internet Official Protocol Standards" (also called STD 1). According to a copy of the RFC Index that I just fetched, the latest that has been published is: 3300 Internet Official Protocol Standards. J. Reynolds, R. Braden, S. Ginoza, A. De La Cruz. November 2002. (Format: TXT=127805 bytes) (Obsoletes RFC3000) (Also STD0001) (Status: STANDARD) ftp://ftp.isi.edu/in-notes/rfc3300.txt Further, every century minus one (3099 , 3199, etc.) is the "RFC Summary" for that century (3099 is 3000 to 3099), containing the Title and Abstract of each hundred RFCs. These are the best for a detailed topic search (although their publication lags a bit behind the latest published RFCs). Hope all this helps. Cheers, - Ira -----Original Message----- From: BERKEMA,ALAN C (HP-Roseville,ex1) [mailto:alan.berkema@hp.com] Sent: Tuesday, April 01, 2003 10:45 AM To: 'McDonald, Ira' Subject: IPv6 RFCs? Hi Ira, This is off topic from PSI, but you really seem to have your RFCs down. How do I find what IPv6 is using for ARP? I found RFC 2461 neighbor Discovery, is that it? Is there an IETF way of finding the latest RFC's without resorting to Google? RFC1883 - The IPv6 base protocol. RFC1884 - The address specification. RFC1885 - Description of the control protocol, known as ICMP. RFC1886 - Addressing the problems of an enhanced Domain Name Service (DNS). RFC1933 - The transition mechanism. Thanks in adavance Alan From hastings at cp10.es.xerox.com Tue Apr 1 21:46:05 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:02:17 2009 Subject: PS> Summary of 9 recent ISSUES/fixes for the IPP Document object tele con, Thur, 4/3/03, 12-3 EST (9-12 PST) Message-ID: The 2nd and 3rd hours will be reviewing the IPP Document Object spec (sent out March 25: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324.pdf.zip (1,225 KB) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324.doc.zip (294 KB) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324-rev.pdf.zip (649 KB) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324-rev.doc.zip (309 KB) This note summarizes the suggestions that have been and issues raised since the document was sent out, including discussions in CIP4 about the JDF/FileSpec resource and the SM telecon March 27. The first part of this mail note is a summary of the issues and point to earlier mail messages that are appended for more detail and rationale. 1. Close-Job operation needs the same timeout Printer requirements as RFC 2911 has for Send-Document. 2. Remove "document-id-uri" Document Description attribute. PSI agreed last week that they can use the IPP "document-number" (integer(1:MAX)) Document Description attribute to identify documents within a job. 3. Add a "document-format-version" (text(127)) operation/Document Description attribute with self-identifing values, such as 'PS/3.0', 'PCL/5e', 'PDF/1.4', 'PDF/X-1a:2001' (See ISSUES 01 and 02 below for more details). The prefix is from the Printer MIB langTC values used in the prtInterpretedLangFamily object and the version after the "/" can be used in the Printer MIB prtInterpreterLangLevel object. 4. Add a "document-format-version-default" (text(127)) and "document-format-version-supported" (1setOf text(127)) Printer Description attributes to describe the default and supported values. (See ISSUES 03 below for more details). So "document-format-version" and "document-format" would have parallel semantics, including also being member attributes of "document-format-details" (1setOf collection). 5. ISSUE 04 (repeat of below): Is "document-format-version" a Best Effort (hint) unless "ipp-attribute-fidelity" = 'true" or "job-mandatory-attributes" = 'document-format-version' or do we make "document-format-version" be like "document-format" in that the Printer MUST reject the job if the Printer doesn't support the version? 6. Put the version strings into a flat text file that implementers and implementations can access on the PWG FTP site. Adding new values is simply done whenever they are registered or standardized with some recognized body, such as IANA, CIP4, ISO, etc. ISSUE 05: We need to convince CIP4 to use the same flat file for their FileSpec/@MimeOrFileTypeVersion attribute and/or have each of them shadow the other. 7. Add a "document-natural-language" (naturalLanguage) operation/Document Description attribute and a "document-natural-language-supported" (1setOf naturalLanguage) Printer Description attribute. The "document-natural-language" operation attribute is already defined in RFC 2911 for use with Print-Job, Send-Document, and Send-URI, so we are just continuing this RFC 2911 attribute for the Create-Document operation and making it a Document Description attribute as well, so that it can be queried. Also keep "document-natural-language" (naturalLanguage) as a member attribute of "document-format-details" for describing packages. The "document-natural-language" is needed in order to know how to display characters that depend on language. ISSUE 06: What about multiple languages in a single document for the top level attribute? ISSUE 06a: What about for the member attribute of "document-format-details"? 8. Add a "document-charset" (charset) operation/Document Description attribute and a "docuemnt-charset-supported" (1setOf charset) Printer Descrition attribute. This attribute is needed for the many plain text and markup languages in which the charset is not embedded in the data. For example, PCL often doesn't have the charset escape sequence in the data. Also many files use the various 8-bit ISO 8859 charsets in which the lower half is US-ASCII and the upper half is various Latin sets (about 8 or 9), Greek, Cyrllic, Hebrew, and Arabic. Shift JIS is another example where the left half is US-ASCII, but the right half can be one of a number of things. But if the data doesn't contain the charset escape sequences, this attribute can help the Printer know what the charset is in the Document. 9. There is one issue embedded in the Document Object spec: 6.1.2.2 document-creator-application-version (text(127)) This OPTIONAL member Operation attribute identifies the version number of the application that created the document. The intent of this attribute is for display to a human being, rather than being parsed by the Printer for purpose of affecting the interpreting by the Printer and so may also include the name of the application, as well as build or service pack numbers. Examples: "Winzip? 8.1 (4331)", "Acrobat 5.0.5 10/26/2001", "Microsoft? Word 2000 (9.0.4119 SR-1)" ISSUE: OK that the purpose is human consumption, instead of program consumption and that it be the same as the application shows in its help message? The two other version attribute: "document-format-version" and "document-format-os-version" are intended for program consumption, not human consumption. Its possible that CIP4 will want to have both types of versions for: applications, operating systems, and documet-formats. Tom Here is last week's thread with more details: -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, March 26, 2003 15:05 To: sm@pwg.org; ps@pwg.org Cc: CIP4 System Behaviour and Interoperability WG [system_behaviour@cip4.org]; CIP4 Capabilities WG [capabilities@cip4.org] Subject: SM> More improvements to the IPP "document-format-version" and JDF Mi meOrFileTypeVersion attributes [4 ISSUES] Ira and I had even further thoughts about the IPP "document-format-version" (wihch don't affect the corresponding JDF MimeOrFileTypeVersion attributes since it is a top level attribute in the FileSpec resource): The proposal from yesterday is to make the values of IPP "docuent-format-version" and JDF MimeOrFileTypeVersion attributes be self-identifying, because they start with a prefix that identifies the format: "PDF/", "PS/", "PCL/", "TIFF/IT-", "DCS/", "MSWORD/", etc. ISSUE 01: OK to add the prefix values as proposed yesterday to the IPP "docuent-format-version" and JDF MimeOrFileTypeVersion attributes to make the values self identifying indendent of the correspoding IPP "document-format" and JDF MimeType attributes? Today's further thought is that we can now promote the IPP "document-format-version" member Operation attribute back to being a top level Document object attribute to accompany the existing "document-format" Operation attribute. This is because "document-format-version-supported" attribute now makes sense as a Printer Descrition attribute on its own, since the values would be things like: "PDF/1.3", "PDF/X-1:2001", "PS/3", "PCL/5e", "TIFF/IT-FP/P1:1998", "DCS/2.0", "MSWORD/2000" and don't need to be paired up with the correspoding "document-format-supported" Printer attribute values: "applicaition/pdf", "application/postscript", "application/vnd.hp-PCL", and "application/msword" MIME type values. ISSUE 02: OK to add a "document-format-version" operation and Document Description attribute to the IPP Document object spec? Just like the "document-format" Operation attribute which is also a member attribute of the "document-format-details" (1setOf collection) Operation/Document Description attribute, we'd keep "document-format-version" as a member attribute as well with the same prefixed values. This now means that "document-format" and "document-format-version" have all parallel construction: a. They are both operation attributes. b. They both have correspoding Document Description attributes that the Printer copies to. c. They both have "xxx-supported" Printer attributes. d. There is a "document-format-default" which now can have a corresponding "document-format-version-default" Printer attribute. ISSUE 03: OK to add "document-format-default" printer attribute? e. The Printer MUST reject the request if the "document-format" isn't supported. ISSUE 04: Do we want to make the same rule for the "document-format-version" or keep it as a Best Effort, unless the client supplies "ipp-attribute-fidelity"='true' or "job-mandatory-attributes"='document-format-version'? Comments? Thanks, Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, March 25, 2003 14:32 To: sm@pwg.org; ps@pwg.org Cc: CIP4 System Behaviour and Interoperability WG [system_behaviour@cip4.org]; CIP4 Capabilities WG [capabilities@cip4.org] Subject: SM> Improvements of the IPP "document-format-version" and JDF MimeOfF ileTypeVersion attributes Today on the FSG Job Ticket API, Ira, Claudia, Till, and I were discussion the current IPP "document-format-version" attribute in the IPP Document Object spec Working Draft, dated March 24, 2003 and the JDF MimeOfFileTypeVersion attribute in the JDF FIleSpec proposal, dated March 21, 2003. This mail note has two specific proposals: 1. Put the version strings into a flat file that can be updated and used by implementers. The respective specs can have an initial sets of strings for the flat file. 2. Make the verson strings self-identifying. Both of these specs are to be discussed on Thursday, March 27, (PWG Semantic Model WG and CIP4 System Behaviour and Interoperability WG). The current text for the IPP "document-format-version" attribute is: 6.1.2.7 document-format-version (text(127)) This REQUIRED member Operation attribute contains the level or version of the document format identified by the "document-format" member attribute. The client MAY supply and the Printer MUST support this member attribute. Possible values are the same as the Printer MIB [rfc1759] prtInterpreterLangLevel (not prtInterpreterLangVersion), such as: '3': For Postscript level 3 [rfc1759]. '5e': For PCL 5e [rfc1759]. Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as:: 'PDF/X-1:2001': For PDF/X-1 [iso15930]. "? 'PDF/X-1.2001': For PDF/X-1a [iso15930] 'TIFF/IT-FP:1998': TIFF/IT [iso12639] - Full Page - baseline. 'TIFF/IT-CT:1998': TIFF/IT [iso12639] - Continuous Tone picture data - baseline 'TIFF/IT-FP/P1:1998': TIFF/IT [iso12639] - Full Page - profile 1 'TIFF/IT-CT/P1:1998': TIFF/IT [iso12639] - Continuous Tone picture data - profile 1 The current text for the JDF MimeOfFileTypeVersion attribute is: The level or version of the file format identified by MimeType or, FileType. Some example values are the same as the Printer MIB [rfc1759] prtInterpreterLangLevel, such as: "1", "2", "3" for MimeType = "application/postscript" "3", "4", "5", "5e" for MimeType = "application/vnd.hp-PCL" Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as: "5.0", "6.0", "2000", "XP" for MimeType = "application/msword" "1.3", "1.4", "PDF/X-1:2001", "PDF/X-1a:2001" for MimeType = "application/pdf" "2.0" for FileType = "DCS" "???" for FileType = "ICC Profile" ISSUE (Ann): What versions for ICC Profiles? "TIFF-IT/FP:1998", "TIFF-IT/CT:1998", "TIFF-IT/LW:1998" for FileType = "TIFF/IT" See Appendix A.1 "FileSpec Resource examples for MimeType, FileType, MimeOrFileTypeVersion attributes" for additional examples in common use by JDF applications. The two suggestions for improvement is: 1. Put the version strings into a flat file so that implementers can get them, so that new values can be added to easily, after appropriate review, without having to republish either the IPP Document Object spec or the CIP4 JDF spec. ISSUE: Whether both the PWG and CIP4 would have their own flat files that they would co-ordinate is an issue to be discussed. 2. The version string should be self identifying, e.g., PDF/1.3, not just 1.3, PS/3, not just 3, PCL/5e, not just 5e. And to build more on the Printer MIB, RFC 1759 (and soon to be published Printer MIBv2) use both the Language Family and the Language Level attributes for the version. The Language Families for PostScript is PS, for PCL is PCL, for PDF is PDF. In the Printer MIB there are two attributes (MIBs call them "objects"): prtInterpreterLangFamily OBJECT-TYPE -- NOTE: In RFC 1759, the enumeration values were implicitly -- defined by this object. SYNTAX PrtInterpreterLangFamilyTC MAX-ACCESS read-only STATUS current DESCRIPTION "The family name of a Page Description Language (PDL) or control language which this interpreter in the printer can interpret or emulate. NOTE: The above description has been modified from RFC 1759 for clarification." prtInterpreterLangLevel OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..31)) MAX-ACCESS read-only STATUS current DESCRIPTION "The level of the language which this interpreter is interpreting or emulating. This might contain a value like '5e'for an interpreter which is emulating level 5e of the PCL language. It might contain '2' for an interpreter which is emulating level 2 of the PostScript language. Similarly it might contain '2' for an interpreter which is emulating level 2 of the HPGL language." The prtInterpreterLangFamily has a Textual Convention for the assignment of about 62 printer languages. The symbolic names are of the form: langXxxx For example there are the following: langPCL(3), -- PCL. Starting with PCL version 5, -- HP-GL/2 is included as part of the -- PCL language. -- PCL and HP-GL/2 are registered -- trademarks of Hewlett-Packard -- Company. langHPGL(4), -- Hewlett-Packard Graphics Language. -- HP-GL is a registered trademark of -- Hewlett-Packard Company. langPJL(5), -- Peripheral Job Language. Appears in -- the data stream between data intended -- for a page description language. -- Hewlett-Packard Co. langPS(6), -- PostScript (tm) Language -- Postscript - a trademark of Adobe -- Systems Incorporated which may be -- registered in certain jurisdictions langIPDS(7), -- Intelligent Printer Data Stream -- Bi-directional print data stream for -- documents consisting of data objects -- (text, image, graphics, bar codes), -- resources (fonts, overlays) and page, -- form and finishing instructions. -- Facilitates system level device -- control, document tracking and error -- recovery throughout the print -- process. -- IBM Corporation. ... langPDF(54), -- Not in RFC 1759 -- Adobe Portable Document Format -- Adobe Systems, Inc. langRPDL(55), -- Not in RFC 1759 -- Ricoh Page Description Language for -- printers. -- Technical manual "RPDL command -- reference" No.307029 -- RICOH, Co. LTD langIntermecIPL(56), -- Not in RFC 1759 -- Intermec Printer Language for label -- printers. -- Technical Manual: "IPL Programmers -- Reference Manual" -- Intermec Corporation langUBIFingerprint(57), -- Not in RFC 1759 -- An intelligent basic-like programming -- language for label printers. -- Reference Manual: "UBI Fingerprint -- 7.1", No. 1-960434-00 -- United Barcode Industries langUBIDirectProtocol(58), -- Not in RFC 1759 -- An intelligent control language for -- label printers. -- Programmers guide: " UBI Direct -- Protocol", No. 1-960419-00 -- United Barcode Industries langFujitsu(59), -- Not in RFC 1759 -- Fujitsu Printer Language -- Reference Manual: -- "FM Printer Sequence" No. 80HP-0770 -- FUJITSU LIMITED langCGM(60), -- Not in RFC 1759 -- Computer Graphics Metafile -- MIME type 'image/cgm' langJPEG(61), -- Not in RFC 1759 -- Joint Photographic Experts Group -- MIME type 'image/jpeg' langCALS1(62), -- Not in RFC 1759 -- US DOD CALS1 (see MIL-STD-1840) -- MIME type 'application/cals-1840' langCALS2(63), -- Not in RFC 1759 -- US DOD CALS2 (see MIL-STD-1840) -- MIME type 'application/cals-1840' langNIRS(64), -- Not in RFC 1759 -- US DOD NIRS (see MIL-STD-1840) -- MIME type 'application/cals-1840' langC4(65) -- Not in RFC 1759 -- US DOD C4 (see MIL-STD-1840) -- MIME type 'application/cals-1840' So take the prtInterpreterLangFamily textual convention after the "lang", follow it with a "/" and then have the prtInterpreterLangLevel. So the updated IPP "document-format-version" member attribute would become: 6.1.2.7 document-format-version (text(127)) This REQUIRED member Operation attribute contains the level or version of the document format identified by the "document-format" member attribute. The client MAY supply and the Printer MUST support this member attribute. Possible values are the same as the Printer MIB [rfc1759] prtInterpreterLangFamily textual convention (minus the "lang" prefix) and prtInterpreterLangLevel (not prtInterpreterLangVersion) separated by a "/", such as: 'PS/3': For Postscript level 3 [rfc1759]. 'PCL/5e': For PCL 5e [rfc1759]. Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such a: 'PDF/X-1:2001': For PDF/X-1 [iso15930]. "? 'PDF/X-1.2001': For PDF/X-1a [iso15930] 'TIFF/IT-FP:1998': TIFF/IT [iso12639] - Full Page - baseline. 'TIFF/IT-CT:1998': TIFF/IT [iso12639] - Continuous Tone picture data - baseline 'TIFF/IT-FP/P1:1998': TIFF/IT [iso12639] - Full Page - profile 1 'TIFF/IT-CT/P1:1998': TIFF/IT [iso12639] - Continuous Tone picture data - profile 1 See PWG www.pwg.org [need URL] for a flat file list of the version strings currently recognized for use in the PWG Semantic Model and derivative protocols, such as IPP and PSI. and the updated JDF MimeOrFileTypeVersion attribute would become: The level or version of the file format identified by MimeType or, FileType. Some example values are the same as the Printer MIB [rfc1759] prtInterpreterLangFamily textual convention (minus the "lang" prefix) and prtInterpreterLangLevel, such as: "PS/1", "PS/2", "PS/3" for MimeType = "application/postscript" "PCL/3", "PDL/4", "PCL/5", "PCL/5e" for MimeType = "application/vnd.hp-PCL" Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as: "MSWORD/5.0", "MSWORD/6.0", "MSWORD/2000", "MSWORD/XP" for MimeType = "application/msword" "PDF/1.3", "PDF/1.4", "PDF/X-1:2001", "PDF/X-1a:2001" for MimeType = "application/pdf" "DCS/2.0" for FileType = "DCS" "???" for FileType = "ICC Profile" ISSUE (Ann): What versions for ICC Profiles? "TIFF-IT/FP:1998", "TIFF-IT/CT:1998", "TIFF-IT/LW:1998" for FileType = "TIFF/IT" See CIP4 www.cip4.org [need URL] for the flat text file that contains the version strings currently recognized for the "FileSpec Resource attributes: MimeType, FileType, MimeOrFileTypeVersion in common use by JDF applications. Comments? Tom From harryl at us.ibm.com Wed Apr 2 18:43:16 2003 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:02:17 2009 Subject: PS> Soap with attachments - relation to SOAP 1.1 In-Reply-To: <6F2B25E1D54DA6428013E7FB7CD84EBF92E828@xvan01.vcd.hp.com> Message-ID: Actually, I think that DIME had more momentum at one point but I believe the focus is now on SOAP w/attachments (including Microsoft and IBM). > > http://www.gotdotnet.com/team/jeffsch/paswa/paswa61.html > > http://www.gotdotnet.com/team/jeffsch/paswa/paswa61.pdf > > http://www.gotdotnet.com/team/jeffsch/paswa/paswa62.doc ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "REVEL,DAN (HP-Vancouver,ex1)" 03/19/2003 10:21 AM To: Harry Lewis/Boulder/IBM@IBMUS, ps@pwg.org cc: Subject: RE: PS> Soap with attachments - relation to SOAP 1.1 SOAP-attachments was a W3C submission, Microsoft et al. made a competing proposal, DIME, that seems to have more momentum: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwebsrv/html/dimewsattch.asp -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, March 18, 2003 9:59 AM To: ps@pwg.org Subject: PS> Soap with attachments - relation to SOAP 1.1 See http://www.w3.org/TR/SOAP-attachments section 4. Seems this has been around for quite a while. I suspect we'd have better interop than we anticipate. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/ps/attachments/20030402/fe0e51ca/attachment-0001.html From hastings at cp10.es.xerox.com Wed Apr 2 21:23:31 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:02:17 2009 Subject: PS> RE: SM> Summary of 9 recent ISSUES/fixes for the IPP Document obj ect tele con, Thur, 4/3/03, 12-3 EST (9-12 PST) Message-ID: And a 10th issue for the Document Object spec: 10. At today's IPPFAX telecon, we discussed the following IPPFAX Printer Description attribute: digital-signatures-supported (1setOf type2 keyword) This attribute identifies which digital signatures technologies are supported by the Receiver. A Receiver MUST support this Printer Description attribute. TODO: Get list of keywords; can be found in "IPP driver install" spec We agreed that it should go in the IPP Document object spec, and that it should have a "digital-signature" (type2 keyword) operation/Document Description attribute that the client submits in a Document Creation operation as well. And therefore, the spelling of the corresponding "digital-signature-supported" (1setOf type2 keyword) Printer Description attribute should be without the "s". The description from the "IPP Driver Install" (IPP Printer Installation Extension) spec is: "digital-signature" One REQUIRED LOWER-CASE 'keyword' string identifying the mechanism used to ensure the integrity and authenticity of this set of Client Print Support Files. Standard values are: 'smime', 'pgp', 'dss', and 'xmldsig' which are defined in [RFC2634], [RFC1991], [dss], and [xmldsig], respectively. In addition, the special keyword value: 'none' is valid. The 'none' value MUST be supported if this attribute is supported. Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, April 01, 2003 18:46 To: sm@pwg.org Cc: ps@pwg.org Subject: SM> Summary of 9 recent ISSUES/fixes for the IPP Document object tele con, Thur, 4/3/03, 12-3 EST (9-12 PST) The 2nd and 3rd hours will be reviewing the IPP Document Object spec (sent out March 25: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324.pdf.zip (1,225 KB) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324.doc.zip (294 KB) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324-rev.pdf.zip (649 KB) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324-rev.doc.zip (309 KB) This note summarizes the suggestions that have been and issues raised since the document was sent out, including discussions in CIP4 about the JDF/FileSpec resource and the SM telecon March 27. The first part of this mail note is a summary of the issues and point to earlier mail messages that are appended for more detail and rationale. 1. Close-Job operation needs the same timeout Printer requirements as RFC 2911 has for Send-Document. 2. Remove "document-id-uri" Document Description attribute. PSI agreed last week that they can use the IPP "document-number" (integer(1:MAX)) Document Description attribute to identify documents within a job. 3. Add a "document-format-version" (text(127)) operation/Document Description attribute with self-identifing values, such as 'PS/3.0', 'PCL/5e', 'PDF/1.4', 'PDF/X-1a:2001' (See ISSUES 01 and 02 below for more details). The prefix is from the Printer MIB langTC values used in the prtInterpretedLangFamily object and the version after the "/" can be used in the Printer MIB prtInterpreterLangLevel object. 4. Add a "document-format-version-default" (text(127)) and "document-format-version-supported" (1setOf text(127)) Printer Description attributes to describe the default and supported values. (See ISSUES 03 below for more details). So "document-format-version" and "document-format" would have parallel semantics, including also being member attributes of "document-format-details" (1setOf collection). 5. ISSUE 04 (repeat of below): Is "document-format-version" a Best Effort (hint) unless "ipp-attribute-fidelity" = 'true" or "job-mandatory-attributes" = 'document-format-version' or do we make "document-format-version" be like "document-format" in that the Printer MUST reject the job if the Printer doesn't support the version? 6. Put the version strings into a flat text file that implementers and implementations can access on the PWG FTP site. Adding new values is simply done whenever they are registered or standardized with some recognized body, such as IANA, CIP4, ISO, etc. ISSUE 05: We need to convince CIP4 to use the same flat file for their FileSpec/@MimeOrFileTypeVersion attribute and/or have each of them shadow the other. 7. Add a "document-natural-language" (naturalLanguage) operation/Document Description attribute and a "document-natural-language-supported" (1setOf naturalLanguage) Printer Description attribute. The "document-natural-language" operation attribute is already defined in RFC 2911 for use with Print-Job, Send-Document, and Send-URI, so we are just continuing this RFC 2911 attribute for the Create-Document operation and making it a Document Description attribute as well, so that it can be queried. Also keep "document-natural-language" (naturalLanguage) as a member attribute of "document-format-details" for describing packages. The "document-natural-language" is needed in order to know how to display characters that depend on language. ISSUE 06: What about multiple languages in a single document for the top level attribute? ISSUE 06a: What about for the member attribute of "document-format-details"? 8. Add a "document-charset" (charset) operation/Document Description attribute and a "docuemnt-charset-supported" (1setOf charset) Printer Descrition attribute. This attribute is needed for the many plain text and markup languages in which the charset is not embedded in the data. For example, PCL often doesn't have the charset escape sequence in the data. Also many files use the various 8-bit ISO 8859 charsets in which the lower half is US-ASCII and the upper half is various Latin sets (about 8 or 9), Greek, Cyrllic, Hebrew, and Arabic. Shift JIS is another example where the left half is US-ASCII, but the right half can be one of a number of things. But if the data doesn't contain the charset escape sequences, this attribute can help the Printer know what the charset is in the Document. 9. There is one issue embedded in the Document Object spec: 6.1.2.2 document-creator-application-version (text(127)) This OPTIONAL member Operation attribute identifies the version number of the application that created the document. The intent of this attribute is for display to a human being, rather than being parsed by the Printer for purpose of affecting the interpreting by the Printer and so may also include the name of the application, as well as build or service pack numbers. Examples: "Winzip? 8.1 (4331)", "Acrobat 5.0.5 10/26/2001", "Microsoft? Word 2000 (9.0.4119 SR-1)" ISSUE: OK that the purpose is human consumption, instead of program consumption and that it be the same as the application shows in its help message? The two other version attribute: "document-format-version" and "document-format-os-version" are intended for program consumption, not human consumption. Its possible that CIP4 will want to have both types of versions for: applications, operating systems, and documet-formats. Tom Here is last week's thread with more details: -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, March 26, 2003 15:05 To: sm@pwg.org; ps@pwg.org Cc: CIP4 System Behaviour and Interoperability WG [system_behaviour@cip4.org]; CIP4 Capabilities WG [capabilities@cip4.org] Subject: SM> More improvements to the IPP "document-format-version" and JDF Mi meOrFileTypeVersion attributes [4 ISSUES] Ira and I had even further thoughts about the IPP "document-format-version" (wihch don't affect the corresponding JDF MimeOrFileTypeVersion attributes since it is a top level attribute in the FileSpec resource): The proposal from yesterday is to make the values of IPP "docuent-format-version" and JDF MimeOrFileTypeVersion attributes be self-identifying, because they start with a prefix that identifies the format: "PDF/", "PS/", "PCL/", "TIFF/IT-", "DCS/", "MSWORD/", etc. ISSUE 01: OK to add the prefix values as proposed yesterday to the IPP "docuent-format-version" and JDF MimeOrFileTypeVersion attributes to make the values self identifying indendent of the correspoding IPP "document-format" and JDF MimeType attributes? Today's further thought is that we can now promote the IPP "document-format-version" member Operation attribute back to being a top level Document object attribute to accompany the existing "document-format" Operation attribute. This is because "document-format-version-supported" attribute now makes sense as a Printer Descrition attribute on its own, since the values would be things like: "PDF/1.3", "PDF/X-1:2001", "PS/3", "PCL/5e", "TIFF/IT-FP/P1:1998", "DCS/2.0", "MSWORD/2000" and don't need to be paired up with the correspoding "document-format-supported" Printer attribute values: "applicaition/pdf", "application/postscript", "application/vnd.hp-PCL", and "application/msword" MIME type values. ISSUE 02: OK to add a "document-format-version" operation and Document Description attribute to the IPP Document object spec? Just like the "document-format" Operation attribute which is also a member attribute of the "document-format-details" (1setOf collection) Operation/Document Description attribute, we'd keep "document-format-version" as a member attribute as well with the same prefixed values. This now means that "document-format" and "document-format-version" have all parallel construction: a. They are both operation attributes. b. They both have correspoding Document Description attributes that the Printer copies to. c. They both have "xxx-supported" Printer attributes. d. There is a "document-format-default" which now can have a corresponding "document-format-version-default" Printer attribute. ISSUE 03: OK to add "document-format-default" printer attribute? e. The Printer MUST reject the request if the "document-format" isn't supported. ISSUE 04: Do we want to make the same rule for the "document-format-version" or keep it as a Best Effort, unless the client supplies "ipp-attribute-fidelity"='true' or "job-mandatory-attributes"='document-format-version'? Comments? Thanks, Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, March 25, 2003 14:32 To: sm@pwg.org; ps@pwg.org Cc: CIP4 System Behaviour and Interoperability WG [system_behaviour@cip4.org]; CIP4 Capabilities WG [capabilities@cip4.org] Subject: SM> Improvements of the IPP "document-format-version" and JDF MimeOfF ileTypeVersion attributes Today on the FSG Job Ticket API, Ira, Claudia, Till, and I were discussion the current IPP "document-format-version" attribute in the IPP Document Object spec Working Draft, dated March 24, 2003 and the JDF MimeOfFileTypeVersion attribute in the JDF FIleSpec proposal, dated March 21, 2003. This mail note has two specific proposals: 1. Put the version strings into a flat file that can be updated and used by implementers. The respective specs can have an initial sets of strings for the flat file. 2. Make the verson strings self-identifying. Both of these specs are to be discussed on Thursday, March 27, (PWG Semantic Model WG and CIP4 System Behaviour and Interoperability WG). The current text for the IPP "document-format-version" attribute is: 6.1.2.7 document-format-version (text(127)) This REQUIRED member Operation attribute contains the level or version of the document format identified by the "document-format" member attribute. The client MAY supply and the Printer MUST support this member attribute. Possible values are the same as the Printer MIB [rfc1759] prtInterpreterLangLevel (not prtInterpreterLangVersion), such as: '3': For Postscript level 3 [rfc1759]. '5e': For PCL 5e [rfc1759]. Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as:: 'PDF/X-1:2001': For PDF/X-1 [iso15930]. "? 'PDF/X-1.2001': For PDF/X-1a [iso15930] 'TIFF/IT-FP:1998': TIFF/IT [iso12639] - Full Page - baseline. 'TIFF/IT-CT:1998': TIFF/IT [iso12639] - Continuous Tone picture data - baseline 'TIFF/IT-FP/P1:1998': TIFF/IT [iso12639] - Full Page - profile 1 'TIFF/IT-CT/P1:1998': TIFF/IT [iso12639] - Continuous Tone picture data - profile 1 The current text for the JDF MimeOfFileTypeVersion attribute is: The level or version of the file format identified by MimeType or, FileType. Some example values are the same as the Printer MIB [rfc1759] prtInterpreterLangLevel, such as: "1", "2", "3" for MimeType = "application/postscript" "3", "4", "5", "5e" for MimeType = "application/vnd.hp-PCL" Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as: "5.0", "6.0", "2000", "XP" for MimeType = "application/msword" "1.3", "1.4", "PDF/X-1:2001", "PDF/X-1a:2001" for MimeType = "application/pdf" "2.0" for FileType = "DCS" "???" for FileType = "ICC Profile" ISSUE (Ann): What versions for ICC Profiles? "TIFF-IT/FP:1998", "TIFF-IT/CT:1998", "TIFF-IT/LW:1998" for FileType = "TIFF/IT" See Appendix A.1 "FileSpec Resource examples for MimeType, FileType, MimeOrFileTypeVersion attributes" for additional examples in common use by JDF applications. The two suggestions for improvement is: 1. Put the version strings into a flat file so that implementers can get them, so that new values can be added to easily, after appropriate review, without having to republish either the IPP Document Object spec or the CIP4 JDF spec. ISSUE: Whether both the PWG and CIP4 would have their own flat files that they would co-ordinate is an issue to be discussed. 2. The version string should be self identifying, e.g., PDF/1.3, not just 1.3, PS/3, not just 3, PCL/5e, not just 5e. And to build more on the Printer MIB, RFC 1759 (and soon to be published Printer MIBv2) use both the Language Family and the Language Level attributes for the version. The Language Families for PostScript is PS, for PCL is PCL, for PDF is PDF. In the Printer MIB there are two attributes (MIBs call them "objects"): prtInterpreterLangFamily OBJECT-TYPE -- NOTE: In RFC 1759, the enumeration values were implicitly -- defined by this object. SYNTAX PrtInterpreterLangFamilyTC MAX-ACCESS read-only STATUS current DESCRIPTION "The family name of a Page Description Language (PDL) or control language which this interpreter in the printer can interpret or emulate. NOTE: The above description has been modified from RFC 1759 for clarification." prtInterpreterLangLevel OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..31)) MAX-ACCESS read-only STATUS current DESCRIPTION "The level of the language which this interpreter is interpreting or emulating. This might contain a value like '5e'for an interpreter which is emulating level 5e of the PCL language. It might contain '2' for an interpreter which is emulating level 2 of the PostScript language. Similarly it might contain '2' for an interpreter which is emulating level 2 of the HPGL language." The prtInterpreterLangFamily has a Textual Convention for the assignment of about 62 printer languages. The symbolic names are of the form: langXxxx For example there are the following: langPCL(3), -- PCL. Starting with PCL version 5, -- HP-GL/2 is included as part of the -- PCL language. -- PCL and HP-GL/2 are registered -- trademarks of Hewlett-Packard -- Company. langHPGL(4), -- Hewlett-Packard Graphics Language. -- HP-GL is a registered trademark of -- Hewlett-Packard Company. langPJL(5), -- Peripheral Job Language. Appears in -- the data stream between data intended -- for a page description language. -- Hewlett-Packard Co. langPS(6), -- PostScript (tm) Language -- Postscript - a trademark of Adobe -- Systems Incorporated which may be -- registered in certain jurisdictions langIPDS(7), -- Intelligent Printer Data Stream -- Bi-directional print data stream for -- documents consisting of data objects -- (text, image, graphics, bar codes), -- resources (fonts, overlays) and page, -- form and finishing instructions. -- Facilitates system level device -- control, document tracking and error -- recovery throughout the print -- process. -- IBM Corporation. ... langPDF(54), -- Not in RFC 1759 -- Adobe Portable Document Format -- Adobe Systems, Inc. langRPDL(55), -- Not in RFC 1759 -- Ricoh Page Description Language for -- printers. -- Technical manual "RPDL command -- reference" No.307029 -- RICOH, Co. LTD langIntermecIPL(56), -- Not in RFC 1759 -- Intermec Printer Language for label -- printers. -- Technical Manual: "IPL Programmers -- Reference Manual" -- Intermec Corporation langUBIFingerprint(57), -- Not in RFC 1759 -- An intelligent basic-like programming -- language for label printers. -- Reference Manual: "UBI Fingerprint -- 7.1", No. 1-960434-00 -- United Barcode Industries langUBIDirectProtocol(58), -- Not in RFC 1759 -- An intelligent control language for -- label printers. -- Programmers guide: " UBI Direct -- Protocol", No. 1-960419-00 -- United Barcode Industries langFujitsu(59), -- Not in RFC 1759 -- Fujitsu Printer Language -- Reference Manual: -- "FM Printer Sequence" No. 80HP-0770 -- FUJITSU LIMITED langCGM(60), -- Not in RFC 1759 -- Computer Graphics Metafile -- MIME type 'image/cgm' langJPEG(61), -- Not in RFC 1759 -- Joint Photographic Experts Group -- MIME type 'image/jpeg' langCALS1(62), -- Not in RFC 1759 -- US DOD CALS1 (see MIL-STD-1840) -- MIME type 'application/cals-1840' langCALS2(63), -- Not in RFC 1759 -- US DOD CALS2 (see MIL-STD-1840) -- MIME type 'application/cals-1840' langNIRS(64), -- Not in RFC 1759 -- US DOD NIRS (see MIL-STD-1840) -- MIME type 'application/cals-1840' langC4(65) -- Not in RFC 1759 -- US DOD C4 (see MIL-STD-1840) -- MIME type 'application/cals-1840' So take the prtInterpreterLangFamily textual convention after the "lang", follow it with a "/" and then have the prtInterpreterLangLevel. So the updated IPP "document-format-version" member attribute would become: 6.1.2.7 document-format-version (text(127)) This REQUIRED member Operation attribute contains the level or version of the document format identified by the "document-format" member attribute. The client MAY supply and the Printer MUST support this member attribute. Possible values are the same as the Printer MIB [rfc1759] prtInterpreterLangFamily textual convention (minus the "lang" prefix) and prtInterpreterLangLevel (not prtInterpreterLangVersion) separated by a "/", such as: 'PS/3': For Postscript level 3 [rfc1759]. 'PCL/5e': For PCL 5e [rfc1759]. Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such a: 'PDF/X-1:2001': For PDF/X-1 [iso15930]. "? 'PDF/X-1.2001': For PDF/X-1a [iso15930] 'TIFF/IT-FP:1998': TIFF/IT [iso12639] - Full Page - baseline. 'TIFF/IT-CT:1998': TIFF/IT [iso12639] - Continuous Tone picture data - baseline 'TIFF/IT-FP/P1:1998': TIFF/IT [iso12639] - Full Page - profile 1 'TIFF/IT-CT/P1:1998': TIFF/IT [iso12639] - Continuous Tone picture data - profile 1 See PWG www.pwg.org [need URL] for a flat file list of the version strings currently recognized for use in the PWG Semantic Model and derivative protocols, such as IPP and PSI. and the updated JDF MimeOrFileTypeVersion attribute would become: The level or version of the file format identified by MimeType or, FileType. Some example values are the same as the Printer MIB [rfc1759] prtInterpreterLangFamily textual convention (minus the "lang" prefix) and prtInterpreterLangLevel, such as: "PS/1", "PS/2", "PS/3" for MimeType = "application/postscript" "PCL/3", "PDL/4", "PCL/5", "PCL/5e" for MimeType = "application/vnd.hp-PCL" Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as: "MSWORD/5.0", "MSWORD/6.0", "MSWORD/2000", "MSWORD/XP" for MimeType = "application/msword" "PDF/1.3", "PDF/1.4", "PDF/X-1:2001", "PDF/X-1a:2001" for MimeType = "application/pdf" "DCS/2.0" for FileType = "DCS" "???" for FileType = "ICC Profile" ISSUE (Ann): What versions for ICC Profiles? "TIFF-IT/FP:1998", "TIFF-IT/CT:1998", "TIFF-IT/LW:1998" for FileType = "TIFF/IT" See CIP4 www.cip4.org [need URL] for the flat text file that contains the version strings currently recognized for the "FileSpec Resource attributes: MimeType, FileType, MimeOrFileTypeVersion in common use by JDF applications. Comments? Tom From alan.berkema at hp.com Thu Apr 3 16:42:35 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:17 2009 Subject: PS> [PSI]: Last Call Process Message-ID: <499DC368E25AD411B3F100902740AD650E6AD848@xrose03.rose.hp.com> At tomorrows call shall we collect comments separately like comments at an IEEE Letter Ballot and meet after April 21 to resolve the comments: Resolve means: 1) Accept as is 2) Reject 3) Accept with further discussion and re-work 4) ??? What do you think? Alan From imcdonald at sharplabs.com Fri Apr 4 11:35:22 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:18 2009 Subject: PS> [PSI]: Fri 4 April 10am PST - Telecon/WebEx Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF6E@mailsrvnt02.enet.sharplabs.com> Hi Alan and Dave, Nancy and I are headed out the door for three/four days on the road up north. Sorry I can't join the PSI telecon today. I'll see my mail again on Monday. Cheers, - Ira -----Original Message----- From: BERKEMA,ALAN C (HP-Roseville,ex1) [mailto:alan.berkema@hp.com] Sent: Monday, March 31, 2003 10:19 AM To: pwg-announce@pwg.org; 'a PSI pwg.org' Cc: pwg@pwg.org Subject: PS> [PSI]: Fri 4 April 12pm - Telecon/WebEx PSI Call 10:00AM - 12noon 1:00PM - 3:00PM Dial-In #: +1 719-457-0335 Participant Password: 400908# Will begin with an overview for FSG folks Next page turner for Last Call Comments Dave can you pass this along to FSG? FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. Meeting Summary Meeting Name: PSI Last Call Review I Scheduled Time: 4/4/2003 at 10:00AM (GMT -08:00) Pacific Time, USA & Canada. Meeting Number: 21659206 Any meeting attendee can use this number to join the meeting, at https://hp.webex.com/join/ Password: newpsi ---------------------------------------------------------------------------- ------------------------------------------------------------------- Meeting Summary Meeting Name: PSI Last Call Review II Scheduled Time: 4/4/2003 at 1:00PM (GMT -08:00) Pacific Time, USA & Canada. Meeting Number: 26342152 Any meeting attendee can use this number to join the meeting, at https://hp.webex.com/join/ Password: newpsi From alan.berkema at hp.com Fri Apr 4 18:42:27 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:18 2009 Subject: PS> [PSI]: next call 04/08/03- 2 hours Message-ID: <499DC368E25AD411B3F100902740AD650E6AD85C@xrose03.rose.hp.com> Teleconference details: NEXT: Tuesday April 08 2003 (USA) Time: 8:00AM (US PDT) Until: 10:00AM Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Brief Update of F2F 2) Continue Last Call Comment Process with the TargetDeviceInterface ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 27995593 Meeting Password: newpsi Host: Alan Berkema 1(916)7855605 From dhall at hp.com Fri Apr 4 18:51:18 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:18 2009 Subject: PS> Last Call Review Comments Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAC26@xvan01.vcd.hp.com> Hi All... The Last Call Review Comments from today's conference call are available at: ftp://ftp.pwg.org/pub/pwg/ps/wd/lcrc-psi10-20030404.doc ftp://ftp.pwg.org/pub/pwg/ps/wd/lcrc-psi10-20030404.pdf Note that the changes in the document are preliminary - they are used to capture Last Call Proposals. Each will need to be individually excepted or rejected. We will continue the review process on next Tuesday's teleconference. Dave From dhall at hp.com Mon Apr 7 12:19:06 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:18 2009 Subject: PS> Updated hpps trace Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAC2A@xvan01.vcd.hp.com> Hey All... I've update our external PSI server (pwg-psips://hpps.vcd.hwp6.net/psi/1.0) to the latest PSI WSDL (http://www.pwg.org/schemas/ps/20030411). Attached is a trace log for a simple AddDocumentByReference job. Dave <> -------------- next part -------------- A non-text attachment was scrubbed... Name: hpps20030411.log Type: application/octet-stream Size: 142346 bytes Desc: not available Url : http://www.pwg.org/archives/ps/attachments/20030407/ea439a5e/hpps20030411-0001.obj From alan.berkema at hp.com Tue Apr 8 17:56:48 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:18 2009 Subject: PS> [PSI]: next call 04/15/03- 2 hours Message-ID: <499DC368E25AD411B3F100902740AD650E6AD86B@xrose03.rose.hp.com> Teleconference details: NEXT: Tuesday April 15 2003 (USA) Time: 8:00AM (US PDT) Until: 10:00AM Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Continue Last Call Comment Process with the TargetDeviceInterface ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 27995593 Meeting Password: newpsi Host: Alan Berkema 1(916)7855605 From hastings at cp10.es.xerox.com Wed Apr 9 07:54:04 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:02:18 2009 Subject: PS> IPP Document Object Spec available for Thursday, April 10, SM Tel econ, 10-11 PDT (1-2 EDT) Message-ID: I've finished the editing on the IPP Document Object Spec and have down loaded it to: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip 1353 KB ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.doc.zip 326 KB This will be reviewed on Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT). Sorry for the short notice, but the editing took way more time than I thought. Version 0.9, 7 April 2003, agreements from the April 3 telecon: 1. Added "document-charset" (charset), "document-digital-signature" (type2 keyword), "document-format-version" (text(127)), and "document-natural-language" (naturalLanguage) Operation and Document Description attributes and corresponding "xxx-default" and "xxx-supported" Printer Description attributes. 2. Changed the "document-natural-language" member attribute of "document-format-details" (1setOf collection) operation attribute to be 1setOf, but kept the top level "document-natural-language" Operation attribute as single-valued. 3. Added Summary Table 2 of new Operation/Document Description attributes. 4. Defined CONDITIONALLY REQUIRED and CMUST Conformance Terms. 5. Deleted the "document-id-uri" Operation attribute no longer needed by PSI. 6. Changed "ipp-attribute-fidelity" so it doesn't affect operation attributes, so it is the same as in [RFC2911]. 7. Clarified the operation attributes supplied at the Job Level in Print-Job and Print-URI versus Create-Job by introducing the "p" notation in Table 7. 8. Added columns to Table 7 to show the corresponding Document Description attributes and the "xxx-default" and "xxx-supported" Printer Description attributes. 9. Clarified that all of the new Operation attributes are hints, except "document-charset" and "document-format" and that the client can turn them into Must Honor by supplying their keyword attribute names in the "job-mandatory-attributes Operation attribute. 10. Add the unique lang prefix from the Printer MIB to all "document-format-version" values, so that they can all be in a single flat list for the Printer's "document-format-version-supported" Printer Description attribute. There are four issues embedded in the document and a 5th from Dennis (see below): 6.1.1 document-charset (charset) ISSUE 01: Since we agreed that this attribute isn't a hint, OK to make it CONDITIONALLY REQUIRED for Printers that support charset-ambiguous document formats? If the Printer supports this "document-digital-signature" Operation attribute and the value supplied by the client, the Printer MUST verify the signature according to the rule for that signature format. If the signature does not verify, then the Printer MUST either (1) ignore the signature or (2) put the job on hold and wait for human intervention, depending on implementation. The Printer gives no additional indication to the client. ISSUE 02: Is either (1) ignore the signature or (2) put the job on hold the correct behavior for the Printer if the digital signature doesn't verify? This Printer behavior is backwards compatible with a Printer that doesn't support the "digital-signature" attribute. However, if the Printer supports the "job-mandatory-attributes" attribute (see section 8.1.2) and the client supplies the "job-mandatory-attribute" Operation attribute with the 'digital-signature' keyword value, then the Printer MUST reject the job if the "digital-signature" attribute is supplied with a value that isn't supported by the Printer (or the Printer doesn't support the "digital-signature" attribute at all). Thus the client can force the Printer to reject a signed document for a signature technology that the Printer does not support. ISSUE 03: What if the digital signature is supported, but the signature fails verification by the Printer when "job-mandatory-attributes" identifies 'document-digital-signature'? The values of the "document-format" and their corresponding "document-format-version" values will be kept in a flat text file on the PWG server for use by the PWG and CIP4. Implementers and implementations will be able to access this file at any time (at CD writing time, install time, vendor update time, and/or at power-up time, etc.). New values will be added to the flat file by its Maintainer after sending to the PWG list for a two week review whenever they are registered with or standardized by some recognized body, such as IANA, CIP4, ISO, etc. ACTION ITEM (Tom): Get CIP4 buy-in to use the same flat file (which will require an additional field for the JDF FileType attribute. ACTION ITEM (Tom and Ira): Propose a format for the file. The URL is: ftp://ftp.pwg.org/pub/pwg/???.txt ISSUE 04: What should the URL be for the flat file? What is the formatting conventions for the flat file. Is it a PWG Schema of sorts? and here is ISSUE 05 from Dennis Carney: - I brought this up on the call, but I'll mention it again, since I'm not sure whether it was resolved. You sell a printer. You happen to have found out that some specific thing goes wrong when a user uses Powerpoint 2000 on Windows NT 4.0, such that your printer always messes up the printout. How do you specify this in document-format-details-implemented? And a much simpler issue on these same lines: why would *anyone*, ever, return any values for the document-creator-application-name-implemented or document-creator-application-version-implemented member attributes--why would anyone want to try to list all applications they support? Similarly for the two "os" member attributes--I might know I don't provide special drivers for Macintosh, but anyone using an LPR utility on Macintosh, with a PDF file, *can* print to me from Macintosh. Even if there *were* some OSes I wanted to say I don't support (which seems doubtful), I have to do this by listing all *other* OSes? I guess in summary: I can see the use for the 5th-8th member attributes of document-format-details-implemented, but not for the 1st-4th. Tom From don at lexmark.com Wed Apr 9 16:07:59 2003 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:02:18 2009 Subject: PS> Dead-on-arrival proposal from "IPP Document Object Spec available for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)" Message-ID: In regards to issue 4 and some background preceding it: ---------------- The values of the "document-format" and their corresponding "document-format-version" values will be kept in a flat text file on the PWG server for use by the PWG and CIP4. Implementers and implementations will be able to access this file at any time (at CD writing time, install time, vendor update time, and/or at power-up time, etc.). New values will be added to the flat file by its Maintainer after sending to the PWG list for a two week review whenever they are registered with or standardized by some recognized body, such as IANA, CIP4, ISO, etc. ACTION ITEM (Tom): Get CIP4 buy-in to use the same flat file (which will require an additional field for the JDF FileType attribute. ACTION ITEM (Tom and Ira): Propose a format for the file. The URL is: ftp://ftp.pwg.org/pub/pwg/???.txt ISSUE 04: What should the URL be for the flat file? What is the formatting conventions for the flat file. Is it a PWG Schema of sorts? ---------------- I CANNOT SUPPORT USING THE PWG SERVER BY ANYTHING OTHER THAN HUMAN BEINGS!!!!! Any proposal that endorses or proposes access by machines "at install time" or "at power-up time" is simply not workable unless some other company wants to support what will become multiple machines with giant bandwidth pipes to the internet to support millions of printers and other devices. I suggest you find another solution. ******************************************* Don Wright don@lexmark.com Chair, IEEE SA Standards Board Member, IEEE-ISTO Board of Directors f.wright@ieee.org / f.wright@computer.org Director, Alliances and Standards Lexmark International 740 New Circle Rd C14/082-3 Lexington, Ky 40550 859-825-4808 (phone) 603-963-8352 (fax) ******************************************* ---------------------- Forwarded by Don Wright/Lex/Lexmark on 04/09/2003 04:01 PM --------------------------- "Hastings, Tom N" @pwg.org on 04/09/2003 07:54:04 AM Sent by: owner-ps@pwg.org To: sm@pwg.org cc: ps@pwg.org Subject: PS> IPP Document Object Spec available for Thursday, April 10, SM Tel econ, 10-11 PDT (1-2 EDT) I've finished the editing on the IPP Document Object Spec and have down loaded it to: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip 1353 KB ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.doc.zip 326 KB This will be reviewed on Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT). Sorry for the short notice, but the editing took way more time than I thought. Version 0.9, 7 April 2003, agreements from the April 3 telecon: 1. Added "document-charset" (charset), "document-digital-signature" (type2 keyword), "document-format-version" (text(127)), and "document-natural-language" (naturalLanguage) Operation and Document Description attributes and corresponding "xxx-default" and "xxx-supported" Printer Description attributes. 2. Changed the "document-natural-language" member attribute of "document-format-details" (1setOf collection) operation attribute to be 1setOf, but kept the top level "document-natural-language" Operation attribute as single-valued. 3. Added Summary Table 2 of new Operation/Document Description attributes. 4. Defined CONDITIONALLY REQUIRED and CMUST Conformance Terms. 5. Deleted the "document-id-uri" Operation attribute no longer needed by PSI. 6. Changed "ipp-attribute-fidelity" so it doesn't affect operation attributes, so it is the same as in [RFC2911]. 7. Clarified the operation attributes supplied at the Job Level in Print-Job and Print-URI versus Create-Job by introducing the "p" notation in Table 7. 8. Added columns to Table 7 to show the corresponding Document Description attributes and the "xxx-default" and "xxx-supported" Printer Description attributes. 9. Clarified that all of the new Operation attributes are hints, except "document-charset" and "document-format" and that the client can turn them into Must Honor by supplying their keyword attribute names in the "job-mandatory-attributes Operation attribute. 10. Add the unique lang prefix from the Printer MIB to all "document-format-version" values, so that they can all be in a single flat list for the Printer's "document-format-version-supported" Printer Description attribute. There are four issues embedded in the document and a 5th from Dennis (see below): 6.1.1 document-charset (charset) ISSUE 01: Since we agreed that this attribute isn't a hint, OK to make it CONDITIONALLY REQUIRED for Printers that support charset-ambiguous document formats? If the Printer supports this "document-digital-signature" Operation attribute and the value supplied by the client, the Printer MUST verify the signature according to the rule for that signature format. If the signature does not verify, then the Printer MUST either (1) ignore the signature or (2) put the job on hold and wait for human intervention, depending on implementation. The Printer gives no additional indication to the client. ISSUE 02: Is either (1) ignore the signature or (2) put the job on hold the correct behavior for the Printer if the digital signature doesn't verify? This Printer behavior is backwards compatible with a Printer that doesn't support the "digital-signature" attribute. However, if the Printer supports the "job-mandatory-attributes" attribute (see section 8.1.2) and the client supplies the "job-mandatory-attribute" Operation attribute with the 'digital-signature' keyword value, then the Printer MUST reject the job if the "digital-signature" attribute is supplied with a value that isn't supported by the Printer (or the Printer doesn't support the "digital-signature" attribute at all). Thus the client can force the Printer to reject a signed document for a signature technology that the Printer does not support. ISSUE 03: What if the digital signature is supported, but the signature fails verification by the Printer when "job-mandatory-attributes" identifies 'document-digital-signature'? The values of the "document-format" and their corresponding "document-format-version" values will be kept in a flat text file on the PWG server for use by the PWG and CIP4. Implementers and implementations will be able to access this file at any time (at CD writing time, install time, vendor update time, and/or at power-up time, etc.). New values will be added to the flat file by its Maintainer after sending to the PWG list for a two week review whenever they are registered with or standardized by some recognized body, such as IANA, CIP4, ISO, etc. ACTION ITEM (Tom): Get CIP4 buy-in to use the same flat file (which will require an additional field for the JDF FileType attribute. ACTION ITEM (Tom and Ira): Propose a format for the file. The URL is: ftp://ftp.pwg.org/pub/pwg/???.txt ISSUE 04: What should the URL be for the flat file? What is the formatting conventions for the flat file. Is it a PWG Schema of sorts? and here is ISSUE 05 from Dennis Carney: - I brought this up on the call, but I'll mention it again, since I'm not sure whether it was resolved. You sell a printer. You happen to have found out that some specific thing goes wrong when a user uses Powerpoint 2000 on Windows NT 4.0, such that your printer always messes up the printout. How do you specify this in document-format-details-implemented? And a much simpler issue on these same lines: why would *anyone*, ever, return any values for the document-creator-application-name-implemented or document-creator-application-version-implemented member attributes--why would anyone want to try to list all applications they support? Similarly for the two "os" member attributes--I might know I don't provide special drivers for Macintosh, but anyone using an LPR utility on Macintosh, with a PDF file, *can* print to me from Macintosh. Even if there *were* some OSes I wanted to say I don't support (which seems doubtful), I have to do this by listing all *other* OSes? I guess in summary: I can see the use for the 5th-8th member attributes of document-format-details-implemented, but not for the 1st-4th. Tom From harryl at us.ibm.com Wed Apr 9 18:45:51 2003 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:02:18 2009 Subject: PS> Re: SM> Dead-on-arrival proposal from "IPP Document Object Spec available for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)" In-Reply-To: Message-ID: We touched on this earlier in the year in the context of SM schemas. We backed off when we backed off the design point where devices would hit the server real-time. If we're drifting back in that direction, we'll have to develop our requirements in terms of bandwidth, QOS, and look for commercial solutions and determine how to fund this via ISTO PWG. I do think it should be feasible to find a commercial solution that meets our needs at an affordable price. I agree with Don that we can't expect a volunteer member to bear this responsibility! ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- don@lexmark.com Sent by: owner-sm@pwg.org 04/09/2003 02:07 PM To: sm@pwg.org, ps@pwg.org cc: Subject: SM> Dead-on-arrival proposal from "IPP Document Object Spec available for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)" In regards to issue 4 and some background preceding it: ---------------- The values of the "document-format" and their corresponding "document-format-version" values will be kept in a flat text file on the PWG server for use by the PWG and CIP4. Implementers and implementations will be able to access this file at any time (at CD writing time, install time, vendor update time, and/or at power-up time, etc.). New values will be added to the flat file by its Maintainer after sending to the PWG list for a two week review whenever they are registered with or standardized by some recognized body, such as IANA, CIP4, ISO, etc. ACTION ITEM (Tom): Get CIP4 buy-in to use the same flat file (which will require an additional field for the JDF FileType attribute. ACTION ITEM (Tom and Ira): Propose a format for the file. The URL is: ftp://ftp.pwg.org/pub/pwg/???.txt ISSUE 04: What should the URL be for the flat file? What is the formatting conventions for the flat file. Is it a PWG Schema of sorts? ---------------- I CANNOT SUPPORT USING THE PWG SERVER BY ANYTHING OTHER THAN HUMAN BEINGS!!!!! Any proposal that endorses or proposes access by machines "at install time" or "at power-up time" is simply not workable unless some other company wants to support what will become multiple machines with giant bandwidth pipes to the internet to support millions of printers and other devices. I suggest you find another solution. ******************************************* Don Wright don@lexmark.com Chair, IEEE SA Standards Board Member, IEEE-ISTO Board of Directors f.wright@ieee.org / f.wright@computer.org Director, Alliances and Standards Lexmark International 740 New Circle Rd C14/082-3 Lexington, Ky 40550 859-825-4808 (phone) 603-963-8352 (fax) ******************************************* ---------------------- Forwarded by Don Wright/Lex/Lexmark on 04/09/2003 04:01 PM --------------------------- "Hastings, Tom N" @pwg.org on 04/09/2003 07:54:04 AM Sent by: owner-ps@pwg.org To: sm@pwg.org cc: ps@pwg.org Subject: PS> IPP Document Object Spec available for Thursday, April 10, SM Tel econ, 10-11 PDT (1-2 EDT) I've finished the editing on the IPP Document Object Spec and have down loaded it to: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip 1353 KB ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.doc.zip 326 KB This will be reviewed on Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT). Sorry for the short notice, but the editing took way more time than I thought. Version 0.9, 7 April 2003, agreements from the April 3 telecon: 1. Added "document-charset" (charset), "document-digital-signature" (type2 keyword), "document-format-version" (text(127)), and "document-natural-language" (naturalLanguage) Operation and Document Description attributes and corresponding "xxx-default" and "xxx-supported" Printer Description attributes. 2. Changed the "document-natural-language" member attribute of "document-format-details" (1setOf collection) operation attribute to be 1setOf, but kept the top level "document-natural-language" Operation attribute as single-valued. 3. Added Summary Table 2 of new Operation/Document Description attributes. 4. Defined CONDITIONALLY REQUIRED and CMUST Conformance Terms. 5. Deleted the "document-id-uri" Operation attribute no longer needed by PSI. 6. Changed "ipp-attribute-fidelity" so it doesn't affect operation attributes, so it is the same as in [RFC2911]. 7. Clarified the operation attributes supplied at the Job Level in Print-Job and Print-URI versus Create-Job by introducing the "p" notation in Table 7. 8. Added columns to Table 7 to show the corresponding Document Description attributes and the "xxx-default" and "xxx-supported" Printer Description attributes. 9. Clarified that all of the new Operation attributes are hints, except "document-charset" and "document-format" and that the client can turn them into Must Honor by supplying their keyword attribute names in the "job-mandatory-attributes Operation attribute. 10. Add the unique lang prefix from the Printer MIB to all "document-format-version" values, so that they can all be in a single flat list for the Printer's "document-format-version-supported" Printer Description attribute. There are four issues embedded in the document and a 5th from Dennis (see below): 6.1.1 document-charset (charset) ISSUE 01: Since we agreed that this attribute isn't a hint, OK to make it CONDITIONALLY REQUIRED for Printers that support charset-ambiguous document formats? If the Printer supports this "document-digital-signature" Operation attribute and the value supplied by the client, the Printer MUST verify the signature according to the rule for that signature format. If the signature does not verify, then the Printer MUST either (1) ignore the signature or (2) put the job on hold and wait for human intervention, depending on implementation. The Printer gives no additional indication to the client. ISSUE 02: Is either (1) ignore the signature or (2) put the job on hold the correct behavior for the Printer if the digital signature doesn't verify? This Printer behavior is backwards compatible with a Printer that doesn't support the "digital-signature" attribute. However, if the Printer supports the "job-mandatory-attributes" attribute (see section 8.1.2) and the client supplies the "job-mandatory-attribute" Operation attribute with the 'digital-signature' keyword value, then the Printer MUST reject the job if the "digital-signature" attribute is supplied with a value that isn't supported by the Printer (or the Printer doesn't support the "digital-signature" attribute at all). Thus the client can force the Printer to reject a signed document for a signature technology that the Printer does not support. ISSUE 03: What if the digital signature is supported, but the signature fails verification by the Printer when "job-mandatory-attributes" identifies 'document-digital-signature'? The values of the "document-format" and their corresponding "document-format-version" values will be kept in a flat text file on the PWG server for use by the PWG and CIP4. Implementers and implementations will be able to access this file at any time (at CD writing time, install time, vendor update time, and/or at power-up time, etc.). New values will be added to the flat file by its Maintainer after sending to the PWG list for a two week review whenever they are registered with or standardized by some recognized body, such as IANA, CIP4, ISO, etc. ACTION ITEM (Tom): Get CIP4 buy-in to use the same flat file (which will require an additional field for the JDF FileType attribute. ACTION ITEM (Tom and Ira): Propose a format for the file. The URL is: ftp://ftp.pwg.org/pub/pwg/???.txt ISSUE 04: What should the URL be for the flat file? What is the formatting conventions for the flat file. Is it a PWG Schema of sorts? and here is ISSUE 05 from Dennis Carney: - I brought this up on the call, but I'll mention it again, since I'm not sure whether it was resolved. You sell a printer. You happen to have found out that some specific thing goes wrong when a user uses Powerpoint 2000 on Windows NT 4.0, such that your printer always messes up the printout. How do you specify this in document-format-details-implemented? And a much simpler issue on these same lines: why would *anyone*, ever, return any values for the document-creator-application-name-implemented or document-creator-application-version-implemented member attributes--why would anyone want to try to list all applications they support? Similarly for the two "os" member attributes--I might know I don't provide special drivers for Macintosh, but anyone using an LPR utility on Macintosh, with a PDF file, *can* print to me from Macintosh. Even if there *were* some OSes I wanted to say I don't support (which seems doubtful), I have to do this by listing all *other* OSes? I guess in summary: I can see the use for the 5th-8th member attributes of document-format-details-implemented, but not for the 1st-4th. Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/ps/attachments/20030409/e4cf8fd8/attachment-0001.html From hastings at cp10.es.xerox.com Thu Apr 10 11:59:48 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:02:18 2009 Subject: PS> RE: SM> Dead-on-arrival proposal from "IPP Document Object Spec a vailable for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)" Message-ID: Don, I think that you hit on the criteria that the file is intended for human use, not automatic machine use. So how about the idea that a human installer and/or administrator can go and fetch the flat file at any time. If the site isn't available, the human will have to try again later. Also I think that the scemas are only for human consumption. The URL is used as an ID to indicate version. Tom -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Wednesday, April 09, 2003 15:46 To: don@lexmark.com Cc: ps@pwg.org; sm@pwg.org Subject: Re: SM> Dead-on-arrival proposal from "IPP Document Object Spec available for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)" We touched on this earlier in the year in the context of SM schemas. We backed off when we backed off the design point where devices would hit the server real-time. If we're drifting back in that direction, we'll have to develop our requirements in terms of bandwidth, QOS, and look for commercial solutions and determine how to fund this via ISTO PWG. I do think it should be feasible to find a commercial solution that meets our needs at an affordable price. I agree with Don that we can't expect a volunteer member to bear this responsibility! ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- don@lexmark.com Sent by: owner-sm@pwg.org 04/09/2003 02:07 PM To: sm@pwg.org, ps@pwg.org cc: Subject: SM> Dead-on-arrival proposal from "IPP Document Object Spec available for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)" In regards to issue 4 and some background preceding it: ---------------- The values of the "document-format" and their corresponding "document-format-version" values will be kept in a flat text file on the PWG server for use by the PWG and CIP4. Implementers and implementations will be able to access this file at any time (at CD writing time, install time, vendor update time, and/or at power-up time, etc.). New values will be added to the flat file by its Maintainer after sending to the PWG list for a two week review whenever they are registered with or standardized by some recognized body, such as IANA, CIP4, ISO, etc. ACTION ITEM (Tom): Get CIP4 buy-in to use the same flat file (which will require an additional field for the JDF FileType attribute. ACTION ITEM (Tom and Ira): Propose a format for the file. The URL is: ftp://ftp.pwg.org/pub/pwg/???.txt ISSUE 04: What should the URL be for the flat file? What is the formatting conventions for the flat file. Is it a PWG Schema of sorts? ---------------- I CANNOT SUPPORT USING THE PWG SERVER BY ANYTHING OTHER THAN HUMAN BEINGS!!!!! Any proposal that endorses or proposes access by machines "at install time" or "at power-up time" is simply not workable unless some other company wants to support what will become multiple machines with giant bandwidth pipes to the internet to support millions of printers and other devices. I suggest you find another solution. ******************************************* Don Wright don@lexmark.com Chair, IEEE SA Standards Board Member, IEEE-ISTO Board of Directors f.wright@ieee.org / f.wright@computer.org Director, Alliances and Standards Lexmark International 740 New Circle Rd C14/082-3 Lexington, Ky 40550 859-825-4808 (phone) 603-963-8352 (fax) ******************************************* ---------------------- Forwarded by Don Wright/Lex/Lexmark on 04/09/2003 04:01 PM --------------------------- "Hastings, Tom N" @pwg.org on 04/09/2003 07:54:04 AM Sent by: owner-ps@pwg.org To: sm@pwg.org cc: ps@pwg.org Subject: PS> IPP Document Object Spec available for Thursday, April 10, SM Tel econ, 10-11 PDT (1-2 EDT) I've finished the editing on the IPP Document Object Spec and have down loaded it to: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip 1353 KB ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.doc.zip 326 KB This will be reviewed on Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT). Sorry for the short notice, but the editing took way more time than I thought. Version 0.9, 7 April 2003, agreements from the April 3 telecon: 1. Added "document-charset" (charset), "document-digital-signature" (type2 keyword), "document-format-version" (text(127)), and "document-natural-language" (naturalLanguage) Operation and Document Description attributes and corresponding "xxx-default" and "xxx-supported" Printer Description attributes. 2. Changed the "document-natural-language" member attribute of "document-format-details" (1setOf collection) operation attribute to be 1setOf, but kept the top level "document-natural-language" Operation attribute as single-valued. 3. Added Summary Table 2 of new Operation/Document Description attributes. 4. Defined CONDITIONALLY REQUIRED and CMUST Conformance Terms. 5. Deleted the "document-id-uri" Operation attribute no longer needed by PSI. 6. Changed "ipp-attribute-fidelity" so it doesn't affect operation attributes, so it is the same as in [RFC2911]. 7. Clarified the operation attributes supplied at the Job Level in Print-Job and Print-URI versus Create-Job by introducing the "p" notation in Table 7. 8. Added columns to Table 7 to show the corresponding Document Description attributes and the "xxx-default" and "xxx-supported" Printer Description attributes. 9. Clarified that all of the new Operation attributes are hints, except "document-charset" and "document-format" and that the client can turn them into Must Honor by supplying their keyword attribute names in the "job-mandatory-attributes Operation attribute. 10. Add the unique lang prefix from the Printer MIB to all "document-format-version" values, so that they can all be in a single flat list for the Printer's "document-format-version-supported" Printer Description attribute. There are four issues embedded in the document and a 5th from Dennis (see below): 6.1.1 document-charset (charset) ISSUE 01: Since we agreed that this attribute isn't a hint, OK to make it CONDITIONALLY REQUIRED for Printers that support charset-ambiguous document formats? If the Printer supports this "document-digital-signature" Operation attribute and the value supplied by the client, the Printer MUST verify the signature according to the rule for that signature format. If the signature does not verify, then the Printer MUST either (1) ignore the signature or (2) put the job on hold and wait for human intervention, depending on implementation. The Printer gives no additional indication to the client. ISSUE 02: Is either (1) ignore the signature or (2) put the job on hold the correct behavior for the Printer if the digital signature doesn't verify? This Printer behavior is backwards compatible with a Printer that doesn't support the "digital-signature" attribute. However, if the Printer supports the "job-mandatory-attributes" attribute (see section 8.1.2) and the client supplies the "job-mandatory-attribute" Operation attribute with the 'digital-signature' keyword value, then the Printer MUST reject the job if the "digital-signature" attribute is supplied with a value that isn't supported by the Printer (or the Printer doesn't support the "digital-signature" attribute at all). Thus the client can force the Printer to reject a signed document for a signature technology that the Printer does not support. ISSUE 03: What if the digital signature is supported, but the signature fails verification by the Printer when "job-mandatory-attributes" identifies 'document-digital-signature'? The values of the "document-format" and their corresponding "document-format-version" values will be kept in a flat text file on the PWG server for use by the PWG and CIP4. Implementers and implementations will be able to access this file at any time (at CD writing time, install time, vendor update time, and/or at power-up time, etc.). New values will be added to the flat file by its Maintainer after sending to the PWG list for a two week review whenever they are registered with or standardized by some recognized body, such as IANA, CIP4, ISO, etc. ACTION ITEM (Tom): Get CIP4 buy-in to use the same flat file (which will require an additional field for the JDF FileType attribute. ACTION ITEM (Tom and Ira): Propose a format for the file. The URL is: ftp://ftp.pwg.org/pub/pwg/???.txt ISSUE 04: What should the URL be for the flat file? What is the formatting conventions for the flat file. Is it a PWG Schema of sorts? and here is ISSUE 05 from Dennis Carney: - I brought this up on the call, but I'll mention it again, since I'm not sure whether it was resolved. You sell a printer. You happen to have found out that some specific thing goes wrong when a user uses Powerpoint 2000 on Windows NT 4.0, such that your printer always messes up the printout. How do you specify this in document-format-details-implemented? And a much simpler issue on these same lines: why would *anyone*, ever, return any values for the document-creator-application-name-implemented or document-creator-application-version-implemented member attributes--why would anyone want to try to list all applications they support? Similarly for the two "os" member attributes--I might know I don't provide special drivers for Macintosh, but anyone using an LPR utility on Macintosh, with a PDF file, *can* print to me from Macintosh. Even if there *were* some OSes I wanted to say I don't support (which seems doubtful), I have to do this by listing all *other* OSes? I guess in summary: I can see the use for the 5th-8th member attributes of document-format-details-implemented, but not for the 1st-4th. Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/ps/attachments/20030410/2bfcca2a/attachment-0001.html From don at lexmark.com Thu Apr 10 14:07:58 2003 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:02:18 2009 Subject: PS> RE: SM> Dead-on-arrival proposal from "IPP Document Object Spec a vailable for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)" Message-ID: Tom: ANY use of the PWG machines for "production" purposes by either the printer itself, an application running on a computer platform or by an end-user administrator/installer is not something we (me or Lexmark) can support. ********************************************** Don Wright don@lexmark.com Chair, IEEE SA Standards Board Member, IEEE-ISTO Board of Directors f.wright@ieee.org / f.wright@computer.org Director, Alliances & Standards Lexmark International 740 New Circle Rd Lexington, Ky 40550 859-825-4808 (phone) 603-963-8352 (fax) ********************************************** "Hastings, Tom N" on 04/10/2003 11:59:48 AM To: Harry Lewis , don@lexmark.com cc: ps@pwg.org, sm@pwg.org Subject: RE: SM> Dead-on-arrival proposal from "IPP Document Object Spec a vailable for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)" Don, I think that you hit on the criteria that the file is intended for human use, not automatic machine use. So how about the idea that a human installer and/or administrator can go and fetch the flat file at any time. If the site isn't available, the human will have to try again later. Also I think that the scemas are only for human consumption. The URL is used as an ID to indicate version. Tom -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Wednesday, April 09, 2003 15:46 To: don@lexmark.com Cc: ps@pwg.org; sm@pwg.org Subject: Re: SM> Dead-on-arrival proposal from "IPP Document Object Spec available for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)" We touched on this earlier in the year in the context of SM schemas. We backed off when we backed off the design point where devices would hit the server real-time. If we're drifting back in that direction, we'll have to develop our requirements in terms of bandwidth, QOS, and look for commercial solutions and determine how to fund this via ISTO PWG. I do think it should be feasible to find a commercial solution that meets our needs at an affordable price. I agree with Don that we can't expect a volunteer member to bear this responsibility! ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- don@lexmark.com Sent by: owner-sm@pwg.org 04/09/2003 02:07 PM To: sm@pwg.org, ps@pwg.org cc: Subject: SM> Dead-on-arrival proposal from "IPP Document Object Spec available for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)" In regards to issue 4 and some background preceding it: ---------------- The values of the "document-format" and their corresponding "document-format-version" values will be kept in a flat text file on the PWG server for use by the PWG and CIP4. Implementers and implementations will be able to access this file at any time (at CD writing time, install time, vendor update time, and/or at power-up time, etc.). New values will be added to the flat file by its Maintainer after sending to the PWG list for a two week review whenever they are registered with or standardized by some recognized body, such as IANA, CIP4, ISO, etc. ACTION ITEM (Tom): Get CIP4 buy-in to use the same flat file (which will require an additional field for the JDF FileType attribute. ACTION ITEM (Tom and Ira): Propose a format for the file. The URL is: ftp://ftp.pwg.org/pub/pwg/???.txt ISSUE 04: What should the URL be for the flat file? What is the formatting conventions for the flat file. Is it a PWG Schema of sorts? ---------------- I CANNOT SUPPORT USING THE PWG SERVER BY ANYTHING OTHER THAN HUMAN BEINGS!!!!! Any proposal that endorses or proposes access by machines "at install time" or "at power-up time" is simply not workable unless some other company wants to support what will become multiple machines with giant bandwidth pipes to the internet to support millions of printers and other devices. I suggest you find another solution. ******************************************* Don Wright don@lexmark.com Chair, IEEE SA Standards Board Member, IEEE-ISTO Board of Directors f.wright@ieee.org / f.wright@computer.org Director, Alliances and Standards Lexmark International 740 New Circle Rd C14/082-3 Lexington, Ky 40550 859-825-4808 (phone) 603-963-8352 (fax) ******************************************* ---------------------- Forwarded by Don Wright/Lex/Lexmark on 04/09/2003 04:01 PM --------------------------- "Hastings, Tom N" @pwg.org on 04/09/2003 07:54:04 AM Sent by: owner-ps@pwg.org To: sm@pwg.org cc: ps@pwg.org Subject: PS> IPP Document Object Spec available for Thursday, April 10, SM Tel econ, 10-11 PDT (1-2 EDT) I've finished the editing on the IPP Document Object Spec and have down loaded it to: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip 1353 KB ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.doc.zip 326 KB This will be reviewed on Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT). Sorry for the short notice, but the editing took way more time than I thought. Version 0.9, 7 April 2003, agreements from the April 3 telecon: 1. Added "document-charset" (charset), "document-digital-signature" (type2 keyword), "document-format-version" (text(127)), and "document-natural-language" (naturalLanguage) Operation and Document Description attributes and corresponding "xxx-default" and "xxx-supported" Printer Description attributes. 2. Changed the "document-natural-language" member attribute of "document-format-details" (1setOf collection) operation attribute to be 1setOf, but kept the top level "document-natural-language" Operation attribute as single-valued. 3. Added Summary Table 2 of new Operation/Document Description attributes. 4. Defined CONDITIONALLY REQUIRED and CMUST Conformance Terms. 5. Deleted the "document-id-uri" Operation attribute no longer needed by PSI. 6. Changed "ipp-attribute-fidelity" so it doesn't affect operation attributes, so it is the same as in [RFC2911]. 7. Clarified the operation attributes supplied at the Job Level in Print-Job and Print-URI versus Create-Job by introducing the "p" notation in Table 7. 8. Added columns to Table 7 to show the corresponding Document Description attributes and the "xxx-default" and "xxx-supported" Printer Description attributes. 9. Clarified that all of the new Operation attributes are hints, except "document-charset" and "document-format" and that the client can turn them into Must Honor by supplying their keyword attribute names in the "job-mandatory-attributes Operation attribute. 10. Add the unique lang prefix from the Printer MIB to all "document-format-version" values, so that they can all be in a single flat list for the Printer's "document-format-version-supported" Printer Description attribute. There are four issues embedded in the document and a 5th from Dennis (see below): 6.1.1 document-charset (charset) ISSUE 01: Since we agreed that this attribute isn't a hint, OK to make it CONDITIONALLY REQUIRED for Printers that support charset-ambiguous document formats? If the Printer supports this "document-digital-signature" Operation attribute and the value supplied by the client, the Printer MUST verify the signature according to the rule for that signature format. If the signature does not verify, then the Printer MUST either (1) ignore the signature or (2) put the job on hold and wait for human intervention, depending on implementation. The Printer gives no additional indication to the client. ISSUE 02: Is either (1) ignore the signature or (2) put the job on hold the correct behavior for the Printer if the digital signature doesn't verify? This Printer behavior is backwards compatible with a Printer that doesn't support the "digital-signature" attribute. However, if the Printer supports the "job-mandatory-attributes" attribute (see section 8.1.2) and the client supplies the "job-mandatory-attribute" Operation attribute with the 'digital-signature' keyword value, then the Printer MUST reject the job if the "digital-signature" attribute is supplied with a value that isn't supported by the Printer (or the Printer doesn't support the "digital-signature" attribute at all). Thus the client can force the Printer to reject a signed document for a signature technology that the Printer does not support. ISSUE 03: What if the digital signature is supported, but the signature fails verification by the Printer when "job-mandatory-attributes" identifies 'document-digital-signature'? The values of the "document-format" and their corresponding "document-format-version" values will be kept in a flat text file on the PWG server for use by the PWG and CIP4. Implementers and implementations will be able to access this file at any time (at CD writing time, install time, vendor update time, and/or at power-up time, etc.). New values will be added to the flat file by its Maintainer after sending to the PWG list for a two week review whenever they are registered with or standardized by some recognized body, such as IANA, CIP4, ISO, etc. ACTION ITEM (Tom): Get CIP4 buy-in to use the same flat file (which will require an additional field for the JDF FileType attribute. ACTION ITEM (Tom and Ira): Propose a format for the file. The URL is: ftp://ftp.pwg.org/pub/pwg/???.txt ISSUE 04: What should the URL be for the flat file? What is the formatting conventions for the flat file. Is it a PWG Schema of sorts? and here is ISSUE 05 from Dennis Carney: - I brought this up on the call, but I'll mention it again, since I'm not sure whether it was resolved. You sell a printer. You happen to have found out that some specific thing goes wrong when a user uses Powerpoint 2000 on Windows NT 4.0, such that your printer always messes up the printout. How do you specify this in document-format-details-implemented? And a much simpler issue on these same lines: why would *anyone*, ever, return any values for the document-creator-application-name-implemented or document-creator-application-version-implemented member attributes--why would anyone want to try to list all applications they support? Similarly for the two "os" member attributes--I might know I don't provide special drivers for Macintosh, but anyone using an LPR utility on Macintosh, with a PDF file, *can* print to me from Macintosh. Even if there *were* some OSes I wanted to say I don't support (which seems doubtful), I have to do this by listing all *other* OSes? I guess in summary: I can see the use for the 5th-8th member attributes of document-format-details-implemented, but not for the 1st-4th. Tom (See attached file: C.htm) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/ps/attachments/20030410/b322230e/iso-8859-1QC-0001.html From alan.berkema at hp.com Tue Apr 15 14:02:28 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:18 2009 Subject: PS> [PSI]: next call 04/22/03- 2 hours Message-ID: <6CD0BB10724459478066E90327DBB651204459@xrose01.rose.hp.com> Teleconference details: NEXT: Tuesday April 22 2003 (USA) Time: 8:00AM (US PDT) Until: 10:00AM Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Last Call Comment Resolution based on the spec that Dave will post soon. Only potential controversial items will be reviewed. Most of the language changes will be accepted at the prerogative of our editor. After this meeting the speciation will be submitted for a 10 day re-circulation Last Call. Comments may be submitted via e-mail. We do not plan another page turner. Thanks, Alan ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 27995593 Meeting Password: newpsi Host: Alan Berkema 1(916)7855605 From dhall at hp.com Wed Apr 16 13:53:38 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:18 2009 Subject: PS> Where to publish xsd / wsdl Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAC70@xvan01.vcd.hp.com> Hey All.. As we create new WSDL and XSD documents, and their "simple" counterparts, where should we publish the schemas? I would propose the following: * The schemas should have the EXACT SAME NAMESPACE - this is required if the "on the wire" envelopes should look the same. * The Full schemas should be published where they are currently being published: (http://www.pwg.org/schemas//) * The simple schemas should be published at: (http://www.pwg.org/schemas//) What do you think? Dave From imcdonald at sharplabs.com Thu Apr 17 10:57:41 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:18 2009 Subject: PS> FW: [Srvloc-discuss] SLP API for Java Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF86@mailsrvnt02.enet.sharplabs.com> -----Original Message----- From: Matt Peterson [mailto:mpeterson@center7.com] Sent: Wednesday, April 16, 2003 12:14 PM To: openslp-devel@lists.sourceforge.net; srvloc-discuss@lists.sourceforge.net; openslp-users@lists.sourceforge.net; openslp-announce@lists.sourceforge.net Subject: [Srvloc-discuss] SLP API for Java Hi, Thanks to Dave Cooper and Solars Corporation, the OpenSLP project is able to offer a pure Java implementation of the SLP API. has been posted on the OpenSLP web site. For more information see: http://www.openslp.org/download.html#java ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Srvloc-discuss mailing list Srvloc-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/srvloc-discuss From hastings at cp10.es.xerox.com Thu Apr 17 17:00:59 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:02:18 2009 Subject: PS> 4 significant proposed increases in conformance requirements for the IPP Document object spec Message-ID: Attendees: Harry Lewis, Bob Taylor, Dave Hall, Lee Farrell, Gail Songer, Ira McDonald, Peter Zehler, Tom Hastings (did I miss anyone?) At today's PWG Semantic Model telecon we did a page by page review of the IPP Document Object Spec in preparation for Last Call: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip This mail note contains several significant changes in Printer conformance requirements that we agreed to for the indicated reasons. However, because of their significance, we agreed to post these changes to the DL for a two week comment period. Objectsion and comments on these changes are due by Friday, May 2, end of business. Silence will be interpreted as approval, so if you object, please send email. The other less significant agreements will be posted in a separate mail note as minutes. We resolved all of the issues and did the page by page review up to page 42 Table 7. We will continue the page by page at another two hour telecon next Thursday, April 24, same time: 1-3 PM EDT (10-12 PDT) with the same version of the specification. Same call-in number and HP webex. Agreed to significant conformance requirements changes: 1. Change the Send-URI operation and the corresponding "reference-uri-schemes-supported" (1setOf uriScheme) Printer Description attribute from OPTIONAL to REQUIRED for a Printer to support. We agreed that a conforming implementation MAY have an empty list for the "reference-uri-schemes-supported" Printer Description attribute. Reason: PSI requires this operation (and has no OPTIONAL attributes). Optional operations are much less likely to get support by clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. 2. Change the Set-Document-Attributes operation from OPTIIOAL to REQUIRED for a Printer to support. Reason: This is the Document object spec and users should be able to modify a Document object after the job is submitted. Optional operations are much less likely to get support by users clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. 3. Change the Set-Job-Attributes operation from OPTIONAL to RECOMMENDED for a Printer to support. Reason: To go along with the change in the conformance requirements for the Set-Document-Attributes operation. However, don't REQUIRE Set-Job-Attributes, since most of the interesting attributes are document attributes, not job attributes. 4. Add an OPTIONAL 'guaranteed" value (see [ippsave] section 8.1) for the "pdl-overrides-supported" Printer Description attribute (REQUIRED in [rfc2911] section 4.4.28) to augment 'not-attempted', and 'attempted' values. Also add a REQUIRED "pdl-override-attributes-guaranteed" (1setOf type2 keyword) Printer Description attribute. The values indicate those Job Template and Document Template attributes for which the Printer guarrantees success in overriding the corresponding instruction in the PDL data. The values of this attribute returned in the Get-Printer-Attributes response MAY be colored by the "document-format" operation attribute supplied by the client in the request, if the Printer's guarrantee depends on the document format. A conforming Printer MAY return 'none' as the value. Reason: The IPPFAX needs the ability for the Printer to indicate which Job Template and Document Template attributes the Printer is able to guarantee success in overriding the PDL. Waiting for the Production Printing Set2 [ippsave] to be updated does meet the schedule for IPPFAX which is also trying to go out to last call. Also this extension is analoguous to our addition of "job-mandatory-attributes" to give a finer granularity to "ipp-attribute-fidelity" (boolean) operation attribute. Please send comments by Friday, May 2, 2003. Thanks, Tom From harryl at us.ibm.com Fri Apr 18 13:16:11 2003 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:02:18 2009 Subject: PS> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec In-Reply-To: Message-ID: I'm afraid we are 1. Over complicating the Document Object - This is really beginning to look like IPPv2 2. Risking lackluster adoption based on unnecessary mandatory operations Look at the premise behind (2), below. "... users should be able to modify a document object after the job is submitted...". This might be something nice for some users but there are simpler alternatives (such as canceling the job and resubmitting it).... that don't require an architectural mandate. As for (4) guaranteeing pdl-override... I've always been opposed to the concept of pdl-override... it's premise being that we can't keep ourselves from generating Postscript with embedded production instructions and even if we could there is a mass of Postscript (still) being used for interchange. This was not true when me made the error of specifying pdl-override in IPP and it is less true today. Separating content from production instruction via the use of a job ticket has always been the goal. That goal is now within reach. I think, then, it is time to consider deprecating pdl-override...certainly not elevating the "feature" by mandating further complexity. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Hastings, Tom N" Sent by: owner-ipp@pwg.org 04/17/2003 03:00 PM To: sm@pwg.org cc: ps@pwg.org, ipp@pwg.org Subject: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec Attendees: Harry Lewis, Bob Taylor, Dave Hall, Lee Farrell, Gail Songer, Ira McDonald, Peter Zehler, Tom Hastings (did I miss anyone?) At today's PWG Semantic Model telecon we did a page by page review of the IPP Document Object Spec in preparation for Last Call: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip This mail note contains several significant changes in Printer conformance requirements that we agreed to for the indicated reasons. However, because of their significance, we agreed to post these changes to the DL for a two week comment period. Objectsion and comments on these changes are due by Friday, May 2, end of business. Silence will be interpreted as approval, so if you object, please send email. The other less significant agreements will be posted in a separate mail note as minutes. We resolved all of the issues and did the page by page review up to page 42 Table 7. We will continue the page by page at another two hour telecon next Thursday, April 24, same time: 1-3 PM EDT (10-12 PDT) with the same version of the specification. Same call-in number and HP webex. Agreed to significant conformance requirements changes: 1. Change the Send-URI operation and the corresponding "reference-uri-schemes-supported" (1setOf uriScheme) Printer Description attribute from OPTIONAL to REQUIRED for a Printer to support. We agreed that a conforming implementation MAY have an empty list for the "reference-uri-schemes-supported" Printer Description attribute. Reason: PSI requires this operation (and has no OPTIONAL attributes). Optional operations are much less likely to get support by clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. 2. Change the Set-Document-Attributes operation from OPTIIOAL to REQUIRED for a Printer to support. Reason: This is the Document object spec and users should be able to modify a Document object after the job is submitted. Optional operations are much less likely to get support by users clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. 3. Change the Set-Job-Attributes operation from OPTIONAL to RECOMMENDED for a Printer to support. Reason: To go along with the change in the conformance requirements for the Set-Document-Attributes operation. However, don't REQUIRE Set-Job-Attributes, since most of the interesting attributes are document attributes, not job attributes. 4. Add an OPTIONAL 'guaranteed" value (see [ippsave] section 8.1) for the "pdl-overrides-supported" Printer Description attribute (REQUIRED in [rfc2911] section 4.4.28) to augment 'not-attempted', and 'attempted' values. Also add a REQUIRED "pdl-override-attributes-guaranteed" (1setOf type2 keyword) Printer Description attribute. The values indicate those Job Template and Document Template attributes for which the Printer guarrantees success in overriding the corresponding instruction in the PDL data. The values of this attribute returned in the Get-Printer-Attributes response MAY be colored by the "document-format" operation attribute supplied by the client in the request, if the Printer's guarrantee depends on the document format. A conforming Printer MAY return 'none' as the value. Reason: The IPPFAX needs the ability for the Printer to indicate which Job Template and Document Template attributes the Printer is able to guarantee success in overriding the PDL. Waiting for the Production Printing Set2 [ippsave] to be updated does meet the schedule for IPPFAX which is also trying to go out to last call. Also this extension is analoguous to our addition of "job-mandatory-attributes" to give a finer granularity to "ipp-attribute-fidelity" (boolean) operation attribute. Please send comments by Friday, May 2, 2003. Thanks, Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/ps/attachments/20030418/fc1bc6f2/attachment-0001.html From imcdonald at sharplabs.com Fri Apr 18 14:34:17 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:18 2009 Subject: PS> RE: IPP> 4 significant proposed increases in conformance requirem ents for the IPP Document object spec Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF8B@mailsrvnt02.enet.sharplabs.com> Hi Michael, Tom's notes are actually incomplete. A conforming implementation MUST support at least one scheme (I suggested we RECOMMEND that 'http:'), but an administrator _at_run_time_ may choose to disable this feature by reconfiguring "reference-uri-schemes-supported". I proposed making this operation (Send-URI) mandatory. But only if ALL implementations MUST support at least one reference scheme and SHOULD support 'http:' (note that PSI servers MUST support 'http:' for the AddDocumentByReference method). I contend that the burden of adding a minimal HTTP client to an existing IPP-based printer is minimal. That's the question. Cheers, - Ira McDonald -----Original Message----- From: Michael Sweet [mailto:mike@easysw.com] Sent: Friday, April 18, 2003 6:50 AM To: Hastings, Tom N Cc: sm@pwg.org; ps@pwg.org; ipp@pwg.org Subject: Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec [My initial comments; I still haven't finished going through the document object spec, so I may have more comments early next week] Hastings, Tom N wrote: > ... > 1. Change the Send-URI operation and the corresponding > "reference-uri-schemes-supported" (1setOf uriScheme) Printer > Description attribute from OPTIONAL to REQUIRED for a Printer to > support. We agreed that a conforming implementation MAY have an > empty list for the "reference-uri-schemes-supported" Printer > Description attribute. So in essense you are just changing the status code from server-error-operation-not-supported to client-error-uri-scheme-not-supported. > Reason: PSI requires this operation (and has no OPTIONAL > attributes). Optional operations are much less likely to get support > by clients. It is best practice for an OPTIONAL extension > specification (such as this spec) to have no OPTIONAL operations, so > that user clients will receive the same level of service from all > Printer implementations that support this extension. This reasoning makes no sense since you are also saying that "reference-uri-schemes-supported" can be an empty list, which means that you still have no service from an implementation that doesn't really support Send-URI. Also, I still question the usefulness of Send-URI and Print-URI since security issues (authentication and access control) make implementation for non-trivial URIs difficult, if not impossible. > 2. Change the Set-Document-Attributes operation from OPTIIOAL to > REQUIRED for a Printer to support. OK, however I think the state <-> status table (table 5) isn't right - what if you want to restart a job but print only 1 copy of the first document? > 3. Change the Set-Job-Attributes operation from OPTIONAL to > RECOMMENDED for a Printer to support. > > Reason: To go along with the change in the conformance requirements > for the Set-Document-Attributes operation. However, don't REQUIRE > Set-Job-Attributes, since most of the interesting attributes are > document attributes, not job attributes. Hmm, I'll have to review the current spec some more, but I don't remember a section on Set-Job-Attributes in the March 24th draft. Any chance you can post a message to the *IPP* list whenever you put a new draft up please? Also, it might be helpful to know when you plan on doing telecons - it can be difficult to schedule the time, but I *do* attend them occasionally... (I didn't get messages about either on the IPP list) > 4. Add an OPTIONAL 'guaranteed" value (see [ippsave] section 8.1) for > the "pdl-overrides-supported" Printer Description attribute (REQUIRED > in [rfc2911] section 4.4.28) to augment 'not-attempted', and > 'attempted' values. Also add a REQUIRED > ... OK, no problem with this. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike at easysw dot com Printing Software for UNIX http://www.easysw.com From imcdonald at sharplabs.com Fri Apr 18 14:38:46 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:18 2009 Subject: PS> RE: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF8C@mailsrvnt02.enet.sharplabs.com> Hi Harry, (1) PSI has ALREADY made all of the equivalent WSDL methods REQUIRED. I'm merely suggesting equivalent functionality for the IPP Document object implementors. And yes it _is_ like IPPv2 - the Document object is the main thing missing from IPP/1.1. But this is just and extension. We're not mandating that all IPP/1.1 implementations support the Document object and operations. (2) The FSG expects to (using PAPI/1.0 API) convert any job ticket instructions to IPP job stream instructions. The job ticket support of PDL override is useless in the Free Standards Linux environment without the correspond IPP attributes. Cheers, - Ira -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Friday, April 18, 2003 12:16 PM To: Hastings, Tom N Cc: ipp@pwg.org; ps@pwg.org; sm@pwg.org Subject: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec I'm afraid we are 1. Over complicating the Document Object - This is really beginning to look like IPPv2 2. Risking lackluster adoption based on unnecessary mandatory operations Look at the premise behind (2), below. "... users should be able to modify a document object after the job is submitted...". This might be something nice for some users but there are simpler alternatives (such as canceling the job and resubmitting it).... that don't require an architectural mandate. As for (4) guaranteeing pdl-override... I've always been opposed to the concept of pdl-override... it's premise being that we can't keep ourselves from generating Postscript with embedded production instructions and even if we could there is a mass of Postscript (still) being used for interchange. This was not true when me made the error of specifying pdl-override in IPP and it is less true today. Separating content from production instruction via the use of a job ticket has always been the goal. That goal is now within reach. I think, then, it is time to consider deprecating pdl-override...certainly not elevating the "feature" by mandating further complexity. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Hastings, Tom N" Sent by: owner-ipp@pwg.org 04/17/2003 03:00 PM To: sm@pwg.org cc: ps@pwg.org, ipp@pwg.org Subject: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec Attendees: Harry Lewis, Bob Taylor, Dave Hall, Lee Farrell, Gail Songer, Ira McDonald, Peter Zehler, Tom Hastings (did I miss anyone?) At today's PWG Semantic Model telecon we did a page by page review of the IPP Document Object Spec in preparation for Last Call: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip This mail note contains several significant changes in Printer conformance requirements that we agreed to for the indicated reasons. However, because of their significance, we agreed to post these changes to the DL for a two week comment period. Objectsion and comments on these changes are due by Friday, May 2, end of business. Silence will be interpreted as approval, so if you object, please send email. The other less significant agreements will be posted in a separate mail note as minutes. We resolved all of the issues and did the page by page review up to page 42 Table 7. We will continue the page by page at another two hour telecon next Thursday, April 24, same time: 1-3 PM EDT (10-12 PDT) with the same version of the specification. Same call-in number and HP webex. Agreed to significant conformance requirements changes: 1. Change the Send-URI operation and the corresponding "reference-uri-schemes-supported" (1setOf uriScheme) Printer Description attribute from OPTIONAL to REQUIRED for a Printer to support. We agreed that a conforming implementation MAY have an empty list for the "reference-uri-schemes-supported" Printer Description attribute. Reason: PSI requires this operation (and has no OPTIONAL attributes). Optional operations are much less likely to get support by clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. 2. Change the Set-Document-Attributes operation from OPTIIOAL to REQUIRED for a Printer to support. Reason: This is the Document object spec and users should be able to modify a Document object after the job is submitted. Optional operations are much less likely to get support by users clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. 3. Change the Set-Job-Attributes operation from OPTIONAL to RECOMMENDED for a Printer to support. Reason: To go along with the change in the conformance requirements for the Set-Document-Attributes operation. However, don't REQUIRE Set-Job-Attributes, since most of the interesting attributes are document attributes, not job attributes. 4. Add an OPTIONAL 'guaranteed" value (see [ippsave] section 8.1) for the "pdl-overrides-supported" Printer Description attribute (REQUIRED in [rfc2911] section 4.4.28) to augment 'not-attempted', and 'attempted' values. Also add a REQUIRED "pdl-override-attributes-guaranteed" (1setOf type2 keyword) Printer Description attribute. The values indicate those Job Template and Document Template attributes for which the Printer guarrantees success in overriding the corresponding instruction in the PDL data. The values of this attribute returned in the Get-Printer-Attributes response MAY be colored by the "document-format" operation attribute supplied by the client in the request, if the Printer's guarrantee depends on the document format. A conforming Printer MAY return 'none' as the value. Reason: The IPPFAX needs the ability for the Printer to indicate which Job Template and Document Template attributes the Printer is able to guarantee success in overriding the PDL. Waiting for the Production Printing Set2 [ippsave] to be updated does meet the schedule for IPPFAX which is also trying to go out to last call. Also this extension is analoguous to our addition of "job-mandatory-attributes" to give a finer granularity to "ipp-attribute-fidelity" (boolean) operation attribute. Please send comments by Friday, May 2, 2003. Thanks, Tom From dcarney at us.ibm.com Fri Apr 18 16:45:20 2003 From: dcarney at us.ibm.com (Dennis Carney) Date: Wed May 6 14:02:18 2009 Subject: PS> Re: SM> 4 significant proposed increases in conformance requirements for the IPP Document object spec Message-ID: My comments below marked by . A couple overall comments: 1) It seems like the Document object spec is becoming a grab-bag for all the ideas we come up with, whether they make sense as part of the Document object or not--the spec risks becoming a "Here's a bunch of things that we thought of that would make IPP cooler" spec. 2) I don't like the argument that we should not have OPTIONAL things in the Document object spec. Here are some reasons: - Even if we did what was proposed below, there would still be many, many OPTIONALs in the spec. If we really believe in our argument, those should all be REQUIRED, right? No? Why not? Oh, so there *is* a line between what should be OPTIONAL and what should be REQUIRED? Well, if there *is* a line, that sort of invalidates our argument that there shouldn't be any OPTIONALs. - The Document object spec has become more than just an extension. I think it is seriously rivaling RFC2911 in term of complexity (not in pages, but in complexity, with all those tables for example). This is NOT a criticism--having a Document object is a good idea and this spec is a very good one. But once a spec gets as complex as this one, it is unreasonable to consider it as just an extension that can have the "luxury" of not having any OPTIONALs. Dennis Carney IBM Printing Systems -------------------------------------------------- 1. Change the Send-URI operation and the corresponding "reference-uri-schemes-supported" (1setOf uriScheme) Printer Description attribute from OPTIONAL to REQUIRED for a Printer to support. We agreed that a conforming implementation MAY have an empty list for the "reference-uri-schemes-supported" Printer Description attribute. Reason: PSI requires this operation (and has no OPTIONAL attributes). Optional operations are much less likely to get support by clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. PSI and IPP are different. Look at the PSI "Use Cases" from the Developers Guide--there are no "Joe is at his desk and wants to print to the printer down the hall" use cases. That's not the point of PSI. PSI is very web-oriented, and as such, it makes sense to print by reference. With IPP, printing by reference is really not mainline, so it should be optional. And what does Send-URI have to do with the document object? Ok, it is a way to send a document, but the Document object spec should describe the Document object, NOT try to redefine the way IPP works, imho. 2. Change the Set-Document-Attributes operation from OPTIIOAL to REQUIRED for a Printer to support. Reason: This is the Document object spec and users should be able to modify a Document object after the job is submitted. Optional operations are much less likely to get support by users clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. It seems to have been a long-standing tradition in IPP that the ability to do "Set"s is optional. I don't see why this should change now. What is so special about Set-Document-Attributes? Why aren't we mandating the other "Set" operations as well while we're at it? 3. Change the Set-Job-Attributes operation from OPTIONAL to RECOMMENDED for a Printer to support. Reason: To go along with the change in the conformance requirements for the Set-Document-Attributes operation. However, don't REQUIRE Set-Job-Attributes, since most of the interesting attributes are document attributes, not job attributes. I have less problem here since we aren't going to REQUIRED, but my last comment is valid here as well. 4. Add an OPTIONAL 'guaranteed" value (see [ippsave] section 8.1) for the "pdl-overrides-supported" Printer Description attribute (REQUIRED in [rfc2911] section 4.4.28) to augment 'not-attempted', and 'attempted' values. Also add a REQUIRED "pdl-override-attributes-guaranteed" (1setOf type2 keyword) Printer Description attribute. The values indicate those Job Template and Document Template attributes for which the Printer guarrantees success in overriding the corresponding instruction in the PDL data. The values of this attribute returned in the Get-Printer-Attributes response MAY be colored by the "document-format" operation attribute supplied by the client in the request, if the Printer's guarrantee depends on the document format. A conforming Printer MAY return 'none' as the value. Reason: The IPPFAX needs the ability for the Printer to indicate which Job Template and Document Template attributes the Printer is able to guarantee success in overriding the PDL. Waiting for the Production Printing Set2 [ippsave] to be updated does meet the schedule for IPPFAX which is also trying to go out to last call. Also this extension is analoguous to our addition of "job-mandatory-attributes" to give a finer granularity to "ipp-attribute-fidelity" (boolean) operation attribute. The 'guaranteed' value: So you are only listing this value that already exists in another spec in the interest of trying to get the value to be "official" as quick as possible? I guess I can't argue with that, but it does seem a bit strange to me. I guess [ippsave] is going to be updated to refer to the Document object spec rather than define this new value? The "pdl-override-attributes-guaranteed" attribute: I agree that this was a shortcoming of IPP--the printer had no ability to say which attributes it could override and which it couldn't. I wonder about its applicability to the Document object, but... From hastings at cp10.es.xerox.com Fri Apr 18 19:15:18 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:02:18 2009 Subject: PS> 2 more significant proposed increases in conformance requirements for the IPP Document object spec Message-ID: In summarizing the significant conformance requirement increases that we agreed to today in the review of the IPP Document Object spec review, I forgot two more: 1. Add a REQUIRED way to the Get-Documents operation for the client to get the Documents following the limit requested in a previous request. So add the "start-after-document-number" (integer (0:MAX)) Operation attribute. 2. Add a REQUIRED way to the Get-Jobs operation for the client to get the Jobs following the limit requested in a previous request. So add the "start-after-job-id" (integer (0:MAX)) Operation attribute. Please send any comments on these additions by Friday, May 2, COB. Here are the complete proposed text for these attributes and the updated "limit" Operation attribute: 1.1 Get-Jobs ([rfc2911] section 3.2.6) This REQUIRED Job operation returns requested attributes of either completed or not completed Jobs. The following (new) "start-after-job-id" (integer(0:MAX)) Operation attribute is defined which in combination with the "limit" operation attribute ([rfc2911] section 3.2.6) permits a client to request selected ranges of jobs: 1.1.1 "limit" (integer(1:MAX)): The client OPTIONALLY supplies this Operation attribute. The Printer MUST support this Operation attribute. It is an integer value that determines the maximum number of Jobs that a client will receive from the Printer even if "which-jobs" or "my-jobs" constrain which jobs are returned. The limit is a "stateless limit" in that if the value supplied by the client is 'N', then only the first 'N' jobs are returned in the Get-Jobs Response. If the client does not supply the "limit" attribute, the Printer responds with all applicable Jobs. However, if the client also supplies the "start-after-job-id" Operation attribute (section 4.2.2) with a value 'M', the Printer returns the N Jobs starting with the Job following the one with "job-id" = 'M'. 1.1.2 "start-after-job-id" (integer(0:MAX)): The client OPTIONALLY supplies this Operation attribute. The Printer MUST support this Operation attribute. If the client supplies this attribute with a job-id value 'M', the Printer MUST return Jobs starting with the Job that is after the one with "job-id" = 'M'. If the client does not supply this attribute, the Printer assumes a '0' value which causes the Printer to return any Jobs with any "job-id" that meet the requested criteria (specified by "which-jobs" and/or "my-jobs", etc.). When the client steps through the jobs N at a time, the client MUST set the "start-after-job-id" attribute from the "job-id' of the last Job returned in a previous Get-Jobs response (rather than just adding 'N', since Printers MAY assign job-ids out or order). The client can detect when there are no more jobs when the Printer returns fewer jobs than requested by the "limit" Operation attribute ('N'). In the case when the last number of jobs returned is exactly N jobs, the client will make an extra request and receive no jobs back (still with a 'successful-ok' success code). However, this case still meets the criteria for no more Jobs since the number of Jobs returned (0) is less than "limit".. Note when the client steps through the Jobs supplying the "limit" and "start-after-job-id" Operation attributes in successive Get-Jobs requests, there are some race conditions which the client implementer needs to take into account: * For 'non-completed' Jobs (see [rfc2911] section 3.2.6.2), the Printer MUST return the Jobs in the order of the "expected time to complete" with the first expected to complete being returned first, etc. Because some Printers MAY: (1) process jobs out of order received, and/or (2) assign "job-id" in a non-monotonically increasing manner, occasionally a race condition MAY cause some jobs not be returned and some jobs MAY be returned more than once. The only way for a client to eliminate this race condition for 'not-completed' Jobs is to request all Jobs by supplying neither the "limit" nor the "start-after-job-id" Operation attribute. * For 'completed' jobs (see [rfc2911] section 3.2.6.2), the Printer MUST return the jobs in the order of "newest to oldest" to complete. Therefore, no jobs will be missed and/or doubly returned. 1.2 Get-Documents Operation This REQUIRED Job operation allows a client to retrieve the list of Document objects belonging to the target Job object. The client MAY also supply a list of Document attribute names and/or attribute group names. A group of Document object attributes will be returned for each Document object in the Job. This operation is similar to the Get-Document-Attributes operation (see section 3.5), except that this Get-Documents operation returns attributes from all Document objects contained in the Job object, instead of from a single selected Document object in the Job object. As with the Get-Document-Attributes operation the Printer MUST only return attributes that were submitted by a client when the Document object was created by the Create-Document, Send-Document, or Send-URI operations and possibly modified by the Set-Document-Attributes operation (see section 3.7). 1.2.1 Get-Documents Request The client submits the Get-Documents request to a Printer. The Get-Documents is similar to the Get-Jobs operations (see [rfc2911] section 3.2.6) except that there are no equivalents to the "which-jobs" and "my-jobs" Operation attributes. The following groups of attributes are part of the Get-Documents Request: Group 1: Operation Attributes Natural Language and Character Set: The "attributes-charset" and "attributes-natural-language" attributes as described in [rfc2911] section 3.1.4.1. Target: Either (1) the "printer-uri" (uri) plus "job-id" (integer(1:MAX)) or (2) the "job-uri" (uri) Operation attribute(s) which define the target Job object for this operation as described in [rfc2911] section 3.1.5. Requesting User Name: The "requesting-user-name" (name(MAX)) attribute SHOULD be supplied by the client as described in [rfc2911] section 8.3. 1.2.1.1 "limit" (integer(1:MAX)): The client OPTIONALLY supplies this Operation attribute. The Printer MUST support this Operation attribute. It is an integer value that determines the maximum number of Documents that a client will receive from the Printer. If the client supplies the "limit" attribute with a value 'N' and the "start-after-document-number" attribute with a value 'M', the Printer returns the N Documents starting with the Document after the one with "document-number" = 'M'. The limit is a "stateless limit" in that if the value supplied by the client is 'N', then only the first 'N' Documents are returned in the Get-Documents Response. If the client does not supply the "limit" attribute, the Printer responds with all Documents in the Job. However, if the client also supplies the "start-after-document-number" Operation attribute (section 4.3.1.2) with a value 'M', the Printer returns the N Documents starting with the Document following the one with "document-number" = 'M'. 1.2.1.2 "start-after-document-number" (integer(0:MAX)): The client OPTIONALLY supplies this Operation attribute. The Printer MUST support this Operation attribute. If the client supplies this attribute with a document-number value 'M', the Printer MUST return Documents starting with the Document that is after the one with "document-number" = 'M'. If the client does not supply this attribute, the Printer assumes a '0' value which causes the Printer to return Documents starting with "document-number" = '1' (which is the first document in the Job). Note: canceled Documents (see section 3.7) are still returned, but deleted Documents (see section 3.8) are skipped over, since they don't exist (leaving gaps in the "document-number" sequence). Please send any comments on these additions by Friday, May 2, COB. Thanks, Tom From hastings at cp10.es.xerox.com Fri Apr 18 22:10:36 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:02:18 2009 Subject: PS> RE: IPP> 4 significant proposed increases in conformance requirem ents for the IPP Document object spec Message-ID: Michael, Thanks for your comments. See my replies bracketed by ... Michael wrote: ... > 2. Change the Set-Document-Attributes operation from OPTIIOAL to > REQUIRED for a Printer to support. OK, however I think the state <-> status table (table 5) isn't right - what if you want to restart a job but print only 1 copy of the first document? (It's Table 6 in the April 7 spec, which regrettably was not announced on the IPP DL, only on the SM and PS DLs. Peter and I will make sure to announce IPP specs and telecons on the IPP DL too. The April 7 spec is at: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip ) Yes, the transition table doesn't allow the client to modify a document with Set-Document-Attributes after the Document has 'completed', 'aborted', or 'canceled'. This same transition table is in the published RFC 3380 for the Set-Job-Attributes operation as well. The reason is that a completed, canceled, or aborted job/document should have the record of what was requested, for accounting and/or the help desk trying to figure out what went wrong. If you want to modify a job and resubmit it as in your example to change the number of copies and reprint: the idea is that the client does a Restart-Job (or Reprocess-Job) with the "job-hold-until" operation attribute supplied (see [RFC 2911] section 3.3.7, Restart-Job(. Then the client can modify it with Set-Document-Attributes while the job is in the 'pending-held' state. Then the client can release the modified job for printing with Release-Job (section 3.3.6). > 3. Change the Set-Job-Attributes operation from OPTIONAL to > RECOMMENDED for a Printer to support. > > Reason: To go along with the change in the conformance requirements > for the Set-Document-Attributes operation. However, don't REQUIRE > Set-Job-Attributes, since most of the interesting attributes are > document attributes, not job attributes. Hmm, I'll have to review the current spec some more, but I don't remember a section on Set-Job-Attributes in the March 24th draft. Set-Job-Attributes wasn't in the March 24th draft or the April 7 th draft. However, in proposing to REQUIRE the Set-Document-Attributes operation it seemed reasonsable to increase the requirements for the Set-Job-Attributes operation to at lease RECOMMENDED. But that is what we are asking for feed back on. So in order to conform to the IPP Document object spec, it is RECOMMENDED that the Printer also support Set-Job-Attributes. Any chance you can post a message to the *IPP* list whenever you put a new draft up please? Also, it might be helpful to know when you plan on doing telecons - it can be difficult to schedule the time, but I *do* attend them occasionally... Peter and I will make sure to announce IPP specs and telecons on the IPP DL too. The April 7 spec is at: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip There wont' be a new spec either. We're continuing the page by page. Please send any othre comments and/or join the next telecon, Thursday, April 24, 1-3 PM EDT: > Dial in Info: > Phone Number: (877) 776-6306 > (Phone Number for Xerox Employees: 8*594-0576) > PARTICIPANT PASSCODE: 437874# We're also using webex: > ------------------------- > FIRST TIME USERS > ------------------------- > For fully interactive meetings, including the ability > to present your documents and applications, a one-time > setup takes less than 10 minutes. Click this URL to set up now: > > http://hp.webex.com > > Then click New User. > ------------------------- > > On Thursday use: > https://hp.webex.com/join/ > > Then click join unlisted meeting. > Use the info below: > ------------------------- The meeting number and password will be announced next week. ... From harryl at us.ibm.com Sat Apr 19 12:03:05 2003 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:02:18 2009 Subject: PS> RE: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec In-Reply-To: <116DB56CD7DED511BC7800508B2CA53735CF8C@mailsrvnt02.enet.sharplabs.com> Message-ID: 1. Help me out as to where PSI states this it is mandatory to support modification of a Document object after the job is submitted. 2. I support healthy alignment with FSG and I've been pushing for a job ticket interface to PSI. It's just... every time I ask for a show of hands regarding actual support for PDL-override the response is always lackluster. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "McDonald, Ira" Sent by: owner-sm@pwg.org 04/18/2003 12:38 PM To: Harry Lewis/Boulder/IBM@IBMUS, "Hastings, Tom N" cc: ipp@pwg.org, ps@pwg.org, sm@pwg.org Subject: RE: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec Hi Harry, (1) PSI has ALREADY made all of the equivalent WSDL methods REQUIRED. I'm merely suggesting equivalent functionality for the IPP Document object implementors. And yes it _is_ like IPPv2 - the Document object is the main thing missing from IPP/1.1. But this is just and extension. We're not mandating that all IPP/1.1 implementations support the Document object and operations. (2) The FSG expects to (using PAPI/1.0 API) convert any job ticket instructions to IPP job stream instructions. The job ticket support of PDL override is useless in the Free Standards Linux environment without the correspond IPP attributes. Cheers, - Ira -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Friday, April 18, 2003 12:16 PM To: Hastings, Tom N Cc: ipp@pwg.org; ps@pwg.org; sm@pwg.org Subject: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec I'm afraid we are 1. Over complicating the Document Object - This is really beginning to look like IPPv2 2. Risking lackluster adoption based on unnecessary mandatory operations Look at the premise behind (2), below. "... users should be able to modify a document object after the job is submitted...". This might be something nice for some users but there are simpler alternatives (such as canceling the job and resubmitting it).... that don't require an architectural mandate. As for (4) guaranteeing pdl-override... I've always been opposed to the concept of pdl-override... it's premise being that we can't keep ourselves from generating Postscript with embedded production instructions and even if we could there is a mass of Postscript (still) being used for interchange. This was not true when me made the error of specifying pdl-override in IPP and it is less true today. Separating content from production instruction via the use of a job ticket has always been the goal. That goal is now within reach. I think, then, it is time to consider deprecating pdl-override...certainly not elevating the "feature" by mandating further complexity. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Hastings, Tom N" Sent by: owner-ipp@pwg.org 04/17/2003 03:00 PM To: sm@pwg.org cc: ps@pwg.org, ipp@pwg.org Subject: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec Attendees: Harry Lewis, Bob Taylor, Dave Hall, Lee Farrell, Gail Songer, Ira McDonald, Peter Zehler, Tom Hastings (did I miss anyone?) At today's PWG Semantic Model telecon we did a page by page review of the IPP Document Object Spec in preparation for Last Call: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip This mail note contains several significant changes in Printer conformance requirements that we agreed to for the indicated reasons. However, because of their significance, we agreed to post these changes to the DL for a two week comment period. Objectsion and comments on these changes are due by Friday, May 2, end of business. Silence will be interpreted as approval, so if you object, please send email. The other less significant agreements will be posted in a separate mail note as minutes. We resolved all of the issues and did the page by page review up to page 42 Table 7. We will continue the page by page at another two hour telecon next Thursday, April 24, same time: 1-3 PM EDT (10-12 PDT) with the same version of the specification. Same call-in number and HP webex. Agreed to significant conformance requirements changes: 1. Change the Send-URI operation and the corresponding "reference-uri-schemes-supported" (1setOf uriScheme) Printer Description attribute from OPTIONAL to REQUIRED for a Printer to support. We agreed that a conforming implementation MAY have an empty list for the "reference-uri-schemes-supported" Printer Description attribute. Reason: PSI requires this operation (and has no OPTIONAL attributes). Optional operations are much less likely to get support by clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. 2. Change the Set-Document-Attributes operation from OPTIIOAL to REQUIRED for a Printer to support. Reason: This is the Document object spec and users should be able to modify a Document object after the job is submitted. Optional operations are much less likely to get support by users clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. 3. Change the Set-Job-Attributes operation from OPTIONAL to RECOMMENDED for a Printer to support. Reason: To go along with the change in the conformance requirements for the Set-Document-Attributes operation. However, don't REQUIRE Set-Job-Attributes, since most of the interesting attributes are document attributes, not job attributes. 4. Add an OPTIONAL 'guaranteed" value (see [ippsave] section 8.1) for the "pdl-overrides-supported" Printer Description attribute (REQUIRED in [rfc2911] section 4.4.28) to augment 'not-attempted', and 'attempted' values. Also add a REQUIRED "pdl-override-attributes-guaranteed" (1setOf type2 keyword) Printer Description attribute. The values indicate those Job Template and Document Template attributes for which the Printer guarrantees success in overriding the corresponding instruction in the PDL data. The values of this attribute returned in the Get-Printer-Attributes response MAY be colored by the "document-format" operation attribute supplied by the client in the request, if the Printer's guarrantee depends on the document format. A conforming Printer MAY return 'none' as the value. Reason: The IPPFAX needs the ability for the Printer to indicate which Job Template and Document Template attributes the Printer is able to guarantee success in overriding the PDL. Waiting for the Production Printing Set2 [ippsave] to be updated does meet the schedule for IPPFAX which is also trying to go out to last call. Also this extension is analoguous to our addition of "job-mandatory-attributes" to give a finer granularity to "ipp-attribute-fidelity" (boolean) operation attribute. Please send comments by Friday, May 2, 2003. Thanks, Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/ps/attachments/20030419/ba7a2581/attachment-0001.html From imcdonald at sharplabs.com Sat Apr 19 16:57:38 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:18 2009 Subject: PS> RE: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF8E@mailsrvnt02.enet.sharplabs.com> Hi Harry, 1) Support for modifying document object after submission is present in the FetchJobs interface that can OVERRIDE existing job or document attributes as the job flows from PSI Print Service to PSI Target Device. Whereas IPP Resubmit/Restart do NOT allow the attributes to be modified in the operation but require "job-hold-until" to be set to allow SUBSEQUENT use of the (OPTIONAL) Set-Job-Attributes. But what I meant below was: Send-Document and Send-URI are both OPTIONAL in IPP/1.1, but the AddDocumentByValue and AddDocumentByReference are REQUIRED in PSI/1.0. Since we are only just now adding Document objects to IPP, I simply propose that we offer PSI-equivalent capabilities in the protocol (for implementations of the Document object specification _only_). 2) I agree that PDL override is hard to implement (in _some_ PDLs), but what Tom and I have proposed is to disambiguate _which_ attributes (if any) can be guaranteed to successfully override the PDL. Seems to me like a good clarity enhancement to IPP. Cheers, - Ira -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Saturday, April 19, 2003 11:03 AM To: McDonald, Ira Cc: Hastings, Tom N; ipp@pwg.org; ps@pwg.org; sm@pwg.org Subject: RE: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec 1. Help me out as to where PSI states this it is mandatory to support modification of a Document object after the job is submitted. 2. I support healthy alignment with FSG and I've been pushing for a job ticket interface to PSI. It's just... every time I ask for a show of hands regarding actual support for PDL-override the response is always lackluster. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "McDonald, Ira" Sent by: owner-sm@pwg.org 04/18/2003 12:38 PM To: Harry Lewis/Boulder/IBM@IBMUS, "Hastings, Tom N" cc: ipp@pwg.org, ps@pwg.org, sm@pwg.org Subject: RE: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec Hi Harry, (1) PSI has ALREADY made all of the equivalent WSDL methods REQUIRED. I'm merely suggesting equivalent functionality for the IPP Document object implementors. And yes it _is_ like IPPv2 - the Document object is the main thing missing from IPP/1.1. But this is just and extension. We're not mandating that all IPP/1.1 implementations support the Document object and operations. (2) The FSG expects to (using PAPI/1.0 API) convert any job ticket instructions to IPP job stream instructions. The job ticket support of PDL override is useless in the Free Standards Linux environment without the correspond IPP attributes. Cheers, - Ira -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Friday, April 18, 2003 12:16 PM To: Hastings, Tom N Cc: ipp@pwg.org; ps@pwg.org; sm@pwg.org Subject: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec I'm afraid we are 1. Over complicating the Document Object - This is really beginning to look like IPPv2 2. Risking lackluster adoption based on unnecessary mandatory operations Look at the premise behind (2), below. "... users should be able to modify a document object after the job is submitted...". This might be something nice for some users but there are simpler alternatives (such as canceling the job and resubmitting it).... that don't require an architectural mandate. As for (4) guaranteeing pdl-override... I've always been opposed to the concept of pdl-override... it's premise being that we can't keep ourselves from generating Postscript with embedded production instructions and even if we could there is a mass of Postscript (still) being used for interchange. This was not true when me made the error of specifying pdl-override in IPP and it is less true today. Separating content from production instruction via the use of a job ticket has always been the goal. That goal is now within reach. I think, then, it is time to consider deprecating pdl-override...certainly not elevating the "feature" by mandating further complexity. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Hastings, Tom N" Sent by: owner-ipp@pwg.org 04/17/2003 03:00 PM To: sm@pwg.org cc: ps@pwg.org, ipp@pwg.org Subject: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec Attendees: Harry Lewis, Bob Taylor, Dave Hall, Lee Farrell, Gail Songer, Ira McDonald, Peter Zehler, Tom Hastings (did I miss anyone?) At today's PWG Semantic Model telecon we did a page by page review of the IPP Document Object Spec in preparation for Last Call: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip This mail note contains several significant changes in Printer conformance requirements that we agreed to for the indicated reasons. However, because of their significance, we agreed to post these changes to the DL for a two week comment period. Objectsion and comments on these changes are due by Friday, May 2, end of business. Silence will be interpreted as approval, so if you object, please send email. The other less significant agreements will be posted in a separate mail note as minutes. We resolved all of the issues and did the page by page review up to page 42 Table 7. We will continue the page by page at another two hour telecon next Thursday, April 24, same time: 1-3 PM EDT (10-12 PDT) with the same version of the specification. Same call-in number and HP webex. Agreed to significant conformance requirements changes: 1. Change the Send-URI operation and the corresponding "reference-uri-schemes-supported" (1setOf uriScheme) Printer Description attribute from OPTIONAL to REQUIRED for a Printer to support. We agreed that a conforming implementation MAY have an empty list for the "reference-uri-schemes-supported" Printer Description attribute. Reason: PSI requires this operation (and has no OPTIONAL attributes). Optional operations are much less likely to get support by clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. 2. Change the Set-Document-Attributes operation from OPTIIOAL to REQUIRED for a Printer to support. Reason: This is the Document object spec and users should be able to modify a Document object after the job is submitted. Optional operations are much less likely to get support by users clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. 3. Change the Set-Job-Attributes operation from OPTIONAL to RECOMMENDED for a Printer to support. Reason: To go along with the change in the conformance requirements for the Set-Document-Attributes operation. However, don't REQUIRE Set-Job-Attributes, since most of the interesting attributes are document attributes, not job attributes. 4. Add an OPTIONAL 'guaranteed" value (see [ippsave] section 8.1) for the "pdl-overrides-supported" Printer Description attribute (REQUIRED in [rfc2911] section 4.4.28) to augment 'not-attempted', and 'attempted' values. Also add a REQUIRED "pdl-override-attributes-guaranteed" (1setOf type2 keyword) Printer Description attribute. The values indicate those Job Template and Document Template attributes for which the Printer guarrantees success in overriding the corresponding instruction in the PDL data. The values of this attribute returned in the Get-Printer-Attributes response MAY be colored by the "document-format" operation attribute supplied by the client in the request, if the Printer's guarrantee depends on the document format. A conforming Printer MAY return 'none' as the value. Reason: The IPPFAX needs the ability for the Printer to indicate which Job Template and Document Template attributes the Printer is able to guarantee success in overriding the PDL. Waiting for the Production Printing Set2 [ippsave] to be updated does meet the schedule for IPPFAX which is also trying to go out to last call. Also this extension is analoguous to our addition of "job-mandatory-attributes" to give a finer granularity to "ipp-attribute-fidelity" (boolean) operation attribute. Please send comments by Friday, May 2, 2003. Thanks, Tom From imcdonald at sharplabs.com Sun Apr 20 16:54:02 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:18 2009 Subject: PS> RE: [SPAM] RE: IPP> 4 significant proposed increases in conforman ce requirem ents for the IPP Document object spec Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF92@mailsrvnt02.enet.sharplabs.com> Hi Michael, Inline comments below. Cheers, - Ira -----Original Message----- From: Mike Sweet [mailto:mike@easysw.com] Sent: Saturday, April 19, 2003 10:11 PM To: McDonald, Ira Cc: Hastings, Tom N; sm@pwg.org; ps@pwg.org; ipp@pwg.org Subject: Re: [SPAM] RE: IPP> 4 significant proposed increases in conformance requirem ents for the IPP Document object spec McDonald, Ira wrote: > ... > Tom's notes are actually incomplete. A conforming implementation > MUST support at least one scheme (I suggested we RECOMMEND that > 'http:'), but an administrator _at_run_time_ may choose to disable > this feature by reconfiguring "reference-uri-schemes-supported". Well, then you will likely find very few implementations. We've been working on Print-URI/Send-URI support for CUPS 1.2 and the authentication/security/performance issues are a real hassle for a real-world implementation. Also, you can be sure that any CUPS implementation of the spec WILL NOT enable print-by-reference by default for serious security reasons, and there will be extremely high barriers in place to limit how and where you can print from. > I proposed making this operation (Send-URI) mandatory. But only > if ALL implementations MUST support at least one reference scheme > and SHOULD support 'http:' (note that PSI servers MUST support > 'http:' for the AddDocumentByReference method). Is there any practical reason why PSI can't just require stricter requirements than the basic IPP mapping? It seems idiotic to require print-by-reference for IPP whose goals are different than PSI. _my_ goal is full-bandwidth application gateways between IPP and PSI. Everywhere that IPP doesn't have a feature at all (the out-of-band push in PSI's AddDocumentByPush) or has made a feature optional (PSI's AddDocumentByReference), the gateway will fail entirely. Note, PSI _is_ sending (over a TLS-secured channel) whatever username and password or certificate necessary to do the SMTP, IMAP, HTTPS, or whatever connection for the AddDocumentByReference, from the client embedded in the PSI Print Service or Target Device. If this is security nightmare for IPP, then the same applies to PSI - why is it so hard if the Print Service simply impersonates the end user? (I know this can't work if the end user's TLS certificate is restricted to access from a pre-configured source FQDN for the end user's system, but that problem _isn't_ soluble.) > I contend that the burden of adding a minimal HTTP client to an > existing IPP-based printer is minimal. That's the question. For a server that will only handle a single connection at a time, and for simple accesses without authentication, it can be implemented fairly easily. However, for any non-trivial implementation there are authentication, security, and performance issues that MUST be dealt with. Consider a typical web application like email which uses HTTP authentication, cookies, encryption, and probably some sort of host/ip-based session key; a print-by-reference approach is doomed to fail even if we can pass all of the required info to the IPP server, since it will somehow have to re-login and go to the right URL. Assuming it *does* work somehow, you need to securely manage this authentication information or risk compromising a remote system. I don't doubt that there is some minimal functionality that can be provided by Print-URI and friends, however the cost/benefit ratio is too high and I believe will hurt adoption of the document object spec. Well, print by reference is the main design center of PSI, so if it will hurt adoption of IPP Document objects, then it will equally hurt PSI adoption. Do you think PSI is in trouble?? -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From imcdonald at sharplabs.com Sun Apr 20 16:44:03 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:18 2009 Subject: PS> RE: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF91@mailsrvnt02.enet.sharplabs.com> Hi Michael, Actually scaling, centering, and cropping are all addressed for IPPFAX (extensions that will certainly migrate to general IPP/1.1 implementations). Cheers, - Ira -----Original Message----- From: Mike Sweet [mailto:mike@easysw.com] Sent: Saturday, April 19, 2003 10:14 PM To: McDonald, Ira Cc: 'Harry Lewis'; Hastings, Tom N; ipp@pwg.org; ps@pwg.org; sm@pwg.org Subject: Re: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec McDonald, Ira wrote: > ... > 2) I agree that PDL override is hard to implement (in _some_ PDLs), but > what Tom and I have proposed is to disambiguate _which_ attributes > (if any) can be guaranteed to successfully override the PDL. Seems > to me like a good clarity enhancement to IPP. PDL override is not even well-defined; what do you do with a PDF file that was formatted for a different media size? Scale it? Center it? Crop it? What constitutes an override??? -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From alan.berkema at hp.com Mon Apr 21 11:29:11 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:18 2009 Subject: PS> [PSI]: 4/22 Postponed - next call 04/29/03- 2 hours Message-ID: <6CD0BB10724459478066E90327DBB65120445D@xrose01.rose.hp.com> Hi All, Dave is still working hard on the changes from the last call review and will not have a new doc until early Thursday 4/24. Therefore we will not have a call on 4/22 Talk to you next week. Alan Teleconference details: NEXT: Tuesday April 29 2003 (USA) Time: 8:00AM (US PDT) Until: 10:00AM Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Last Call Comment Resolution based on the spec that Dave will post soon. Only potential controversial items will be reviewed. Most of the language changes will be accepted at the prerogative of our editor. After this meeting the speciation will be submitted for a 10 day re-circulation Last Call. Comments may be submitted via e-mail. We do not plan another page turner. Thanks, Alan ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 27995593 Meeting Password: newpsi Host: Alan Berkema 1(916)7855605 From hastings at cp10.es.xerox.com Mon Apr 21 12:08:26 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:02:18 2009 Subject: PS> 1 more significant proposed conformance change to the IPP Documen t object spec Message-ID: In going over my notes I discovered one more significant conformance changes proposed change for the IPP Document object from Thursday's April 17, telecon. This proposal will also go through the two-week comment period. 1. DEPRECATE the way a client can close a Job by supplying an empty Send-Document operation supplying the "last-document" = 'true' operation attribute for a Job created with Create-Job and any of (1) Create-Document/Send-Data, (2) Send-Document, and/or (3) Send-URI. When the Printer accepts this no-data Send-Document operation with "last-document" = 'true' the Printer MUST set the still REQUIRED "last-document" Document Description attribute. Instead, the client SHOULD use the new Close-Job operation (which also sets the "last-document" Document Description attribute). The Printer MUST continue to support this method of closing a job with an empty Send-Document request for backward compatibility with existing clients. As with the other two mail messages on significant conformance requirements changes, I will not edit this comment into the spec until we reach consensus on Friday, May 1. Please send comments. Tom From dcarney at us.ibm.com Mon Apr 21 12:11:46 2003 From: dcarney at us.ibm.com (Dennis Carney) Date: Wed May 6 14:02:18 2009 Subject: PS> Re: IPP> 2 more significant proposed increases in conformance requirements for the IPP Document object spec Message-ID: This might be an awful idea, so feel free to shoot it down with vicious force... Based on the desire to have extensions that do not include OPTIONAL items, might it make sense to break the current Document object spec into two: - The "Base Document object" spec, which defines the basics of the Document object and has no OPTIONAL items: everything is mandatory. This would make interop a breeze, and would hopefully also encourage adoption since the spec would hopefully be relatively small. - The "Extended Document object" spec, containing all the currently OPTIONAL items. This spec *could* also make all the extensions mandatory (I would think that making absolutely *everything* mandatory would discourage adoption, however). The process of going through the current spec to determine which items are "Base" and which are "Extended" might also result in determining which items aren't "Document object" items at all. Dennis Carney IBM Printing Systems Mike Sweet To: "Hastings, Tom N" Sent by: cc: sm@pwg.org, ps@pwg.org, ipp@pwg.org owner-ipp@pwg.org Subject: Re: IPP> 2 more significant proposed increases in conformance requirements for the IPP Document object spec 04/19/03 08:54 PM Hastings, Tom N wrote: > ... > 2. Add a REQUIRED way to the Get-Jobs operation for the client to get the > Jobs following the limit requested in a previous request. > > So add the "start-after-job-id" (integer (0:MAX)) Operation attribute. This is a nice addition, but has ABSOLUTELY NOTHING TO DO WITH DOCUMENT OBJECTS. It doesn't belong here. If anything, you should put together a single, small spec that adds this functionality to Get-Jobs separately. A pain, but this single attribute is useful on its own. Also, you probably need to have a way to let the client know that this attribute is supported, e.g. "start-after-job-id-supported (boolean)"... -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From dcarney at us.ibm.com Mon Apr 21 18:52:41 2003 From: dcarney at us.ibm.com (Dennis Carney) Date: Wed May 6 14:02:18 2009 Subject: PS> Re: IPP> 2 more significant proposed increases in conformance requirements for the IPP Document object spec Message-ID: I think that these ideas are good ones. However, I wonder why we didn't do anything about this before. In fact, in 2911, it is specifically called out that we purposely didn't handle this situation (2911, section 3.2.6.1: "There is no mechanism to allow for the next 'M' jobs after the first 'N' jobs."). Does anyone remember whether there was a good reason this issue was sidestepped? I've made 3 specific comments inline below, marked with . Dennis Carney IBM Printing Systems "Hastings, Tom N" cc: ps@pwg.org, ipp@pwg.org Sent by: Subject: IPP> 2 more significant proposed increases in conformance requirements for the IPP owner-ipp@pwg.org Document object spec 04/18/03 05:15 PM In summarizing the significant conformance requirement increases that we agreed to today in the review of the IPP Document Object spec review, I forgot two more: 1. Add a REQUIRED way to the Get-Documents operation for the client to get the Documents following the limit requested in a previous request. So add the "start-after-document-number" (integer (0:MAX)) Operation attribute. 2. Add a REQUIRED way to the Get-Jobs operation for the client to get the Jobs following the limit requested in a previous request. So add the "start-after-job-id" (integer (0:MAX)) Operation attribute. Please send any comments on these additions by Friday, May 2, COB. Here are the complete proposed text for these attributes and the updated "limit" Operation attribute: 1.1 Get-Jobs ([rfc2911] section 3.2.6) This REQUIRED Job operation returns requested attributes of either completed or not completed Jobs. The following (new) "start-after-job-id" (integer(0:MAX)) Operation attribute is defined which in combination with the "limit" operation attribute ([rfc2911] section 3.2.6) permits a client to request selected ranges of jobs: 1.1.1 "limit" (integer(1:MAX)): The client OPTIONALLY supplies this Operation attribute. The Printer MUST support this Operation attribute. It is an integer value that determines the maximum number of Jobs that a client will receive from the Printer even if "which-jobs" or "my-jobs" constrain which jobs are returned. The limit is a "stateless limit" in that if the value supplied by the client is 'N', then only the first 'N' jobs are returned in the Get-Jobs Response. If the client does not supply the "limit" attribute, the Printer responds with all applicable Jobs. However, if the client also supplies the "start-after-job-id" Operation attribute (section 4.2.2) with a value 'M', the Printer returns the N Jobs starting with the Job following the one with "job-id" = 'M'. We need to say what happens if job-id M is no longer in the list. I think the answer could be different for the two cases (non-completed vs. completed), making this a bit more complicated. If asking for *non-completed* jobs after job-id M, it is possible that M has completed since the client made the last call and is therefore no longer in the non-completed list. Unfortunately, this gets messy: 1) If M completed successfully, the printer should return the first N non-completed jobs (i.e. the same as if M hadn't been specified at all). 2) If M was canceled/aborted, it seems like the printer should ideally return the next job after M, *if* M hadn't been canceled/aborted. This extra attempt at correctness is, I guess, not really necessary, since the text below states that the caller can get strange results. Otherwise, if asking for *completed* jobs after job-id M, it is possible that M has been managed out of the completed list since the client made the last call. In *this* case, since completed jobs are returned in the opposite order of non-completed jobs, the printer should return an empty list. That is, since completed jobs are returned from newest to oldest, if M was managed out, jobs "after" (but actually printed before!) M are presumably also managed out, so there are actually no jobs "after" M in the completed list. This is the "correctly functioning" case of job-id M not being in the list, but there is also the "error" case where job-id M is just a bad value--it does seem strange to mandate that the printer return an empty list and success whenever the caller sends a bad "start-after-job-id" value. Maybe we want some new status-code: something like client-error-bad-start-id. Or we could possibly reuse client-error-gone or client-error-not-possible or some other existing status-code. Then there is just one answer for all the above cases: if M is not in the list, return an error and let the client decide what to do. 1.1.2 "start-after-job-id" (integer(0:MAX)): The client OPTIONALLY supplies this Operation attribute. The Printer MUST support this Operation attribute. If the client supplies this attribute with a job-id value 'M', the Printer MUST return Jobs starting with the Job that is after the one with "job-id" = 'M'. If the client does not supply this attribute, the Printer assumes a '0' value which causes the Printer to return any Jobs with any "job-id" that meet the requested criteria (specified by "which-jobs" and/or "my-jobs", etc.). When the client steps through the jobs N at a time, the client MUST set the "start-after-job-id" attribute from the "job-id' of the last Job returned in a previous Get-Jobs response (rather than just adding 'N', since Printers MAY assign job-ids out or order). The client can detect when there are no more jobs when the Printer returns fewer jobs than requested by the "limit" Operation attribute ('N'). In the case when the last number of jobs returned is exactly N jobs, the client will make an extra request and receive no jobs back (still with a 'successful-ok' success code). However, this case still meets the criteria for no more Jobs since the number of Jobs returned (0) is less than "limit".. Note when the client steps through the Jobs supplying the "limit" and "start-after-job-id" Operation attributes in successive Get-Jobs requests, there are some race conditions which the client implementer needs to take into account: * For 'non-completed' Jobs (see [rfc2911] section 3.2.6.2), the Printer MUST return the Jobs in the order of the "expected time to complete" with the first expected to complete being returned first, etc. Because some Printers MAY: (1) process jobs out of order received, and/or (2) assign "job-id" in a non-monotonically increasing manner, occasionally a race condition MAY cause some jobs not be returned and some jobs MAY be returned more than once. The only way for a client to eliminate this race condition for 'not-completed' Jobs is to request all Jobs by supplying neither the "limit" nor the "start-after-job-id" Operation attribute. * For 'completed' jobs (see [rfc2911] section 3.2.6.2), the Printer MUST return the jobs in the order of "newest to oldest" to complete. Therefore, no jobs will be missed and/or doubly returned. 1.2 Get-Documents Operation This REQUIRED Job operation allows a client to retrieve the list of Document objects belonging to the target Job object. The client MAY also supply a list of Document attribute names and/or attribute group names. A group of Document object attributes will be returned for each Document object in the Job. This operation is similar to the Get-Document-Attributes operation (see section 3.5), except that this Get-Documents operation returns attributes from all Document objects contained in the Job object, instead of from a single selected Document object in the Job object. As with the Get-Document-Attributes operation the Printer MUST only return attributes that were submitted by a client when the Document object was created by the Create-Document, Send-Document, or Send-URI operations and possibly modified by the Set-Document-Attributes operation (see section 3.7). 1.2.1 Get-Documents Request The client submits the Get-Documents request to a Printer. The Get-Documents is similar to the Get-Jobs operations (see [rfc2911] section 3.2.6) except that there are no equivalents to the "which-jobs" and "my-jobs" Operation attributes. The following groups of attributes are part of the Get-Documents Request: Group 1: Operation Attributes Natural Language and Character Set: The "attributes-charset" and "attributes-natural-language" attributes as described in [rfc2911] section 3.1.4.1. Target: Either (1) the "printer-uri" (uri) plus "job-id" (integer(1:MAX)) or (2) the "job-uri" (uri) Operation attribute(s) which define the target Job object for this operation as described in [rfc2911] section 3.1.5. Requesting User Name: The "requesting-user-name" (name(MAX)) attribute SHOULD be supplied by the client as described in [rfc2911] section 8.3. 1.2.1.1 "limit" (integer(1:MAX)): The client OPTIONALLY supplies this Operation attribute. The Printer MUST support this Operation attribute. It is an integer value that determines the maximum number of Documents that a client will receive from the Printer. If the client supplies the "limit" attribute with a value 'N' and the "start-after-document-number" attribute with a value 'M', the Printer returns the N Documents starting with the Document after the one with "document-number" = 'M'. The limit is a "stateless limit" in that if the value supplied by the client is 'N', then only the first 'N' Documents are returned in the Get-Documents Response. If the client does not supply the "limit" attribute, the Printer responds with all Documents in the Job. However, if the client also supplies the "start-after-document-number" Operation attribute (section 4.3.1.2) with a value 'M', the Printer returns the N Documents starting with the Document following the one with "document-number" = 'M'. Editorial: The above paragraph would flow better without the fourth sentence (the one starting "If the client supplies..."). 1.2.1.2 "start-after-document-number" (integer(0:MAX)): The client OPTIONALLY supplies this Operation attribute. The Printer MUST support this Operation attribute. If the client supplies this attribute with a document-number value 'M', the Printer MUST return Documents starting with the Document that is after the one with "document-number" = 'M'. If the client does not supply this attribute, the Printer assumes a '0' value which causes the Printer to return Documents starting with "document-number" = '1' (which is the first document in the Job). Note: canceled Documents (see section 3.7) are still returned, but deleted Documents (see section 3.8) are skipped over, since they don't exist (leaving gaps in the "document-number" sequence). Due to the fact that deleted Documents disappear, we have the same problem as discussed above: Document number M might no longer exist. The expected behavior for this should be similar to that decided upon for jobs, I would think; however, for Document objects, the "ideal" behavior would be to return the Documents starting with the first after Document M that hasn't been deleted. Unfortunately, this "pretend like M is still there" strategy doesn't really work as a general solution in the Get-Jobs case. Please send any comments on these additions by Friday, May 2, COB. Thanks, Tom From dcarney at us.ibm.com Mon Apr 21 19:14:18 2003 From: dcarney at us.ibm.com (Dennis Carney) Date: Wed May 6 14:02:18 2009 Subject: PS> Re: SM> 1 more significant proposed conformance change to the IPP Documen t object spec Message-ID: I'm a bit confused: I had the (apparently flawed) impression that the plan was to deprecate, for a client, using the "last-document" operation attribute entirely--that is, say the "correct" way to say a job was done was to do Close-Job. If we do that, we will by definition deprecate the special case you're discussing below, right? Am I thinking of PSI or maybe SM? Since deprecation is only a suggestion, might it make sense to deprecate "last-document" entirely? (The Printer will still have to support it, but we're encouraging clients to move to Close-Job.) Do we want to make such a stand? Dennis "Hastings, Tom N" cc: ps@pwg.org, ipp@pwg.org Sent by: Subject: SM> 1 more significant proposed conformance change to the IPP Documen t object spec owner-sm@pwg.org 04/21/03 10:08 AM In going over my notes I discovered one more significant conformance changes proposed change for the IPP Document object from Thursday's April 17, telecon. This proposal will also go through the two-week comment period. 1. DEPRECATE the way a client can close a Job by supplying an empty Send-Document operation supplying the "last-document" = 'true' operation attribute for a Job created with Create-Job and any of (1) Create-Document/Send-Data, (2) Send-Document, and/or (3) Send-URI. When the Printer accepts this no-data Send-Document operation with "last-document" = 'true' the Printer MUST set the still REQUIRED "last-document" Document Description attribute. Instead, the client SHOULD use the new Close-Job operation (which also sets the "last-document" Document Description attribute). The Printer MUST continue to support this method of closing a job with an empty Send-Document request for backward compatibility with existing clients. As with the other two mail messages on significant conformance requirements changes, I will not edit this comment into the spec until we reach consensus on Friday, May 1. Please send comments. Tom From dhall at hp.com Tue Apr 22 12:27:27 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:18 2009 Subject: PS> WSDL Namespaces Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAC8B@xvan01.vcd.hp.com> Hey All.. There are two ways we can declare our namespaces - one where the namespace actually has the path fully correct: http://www.pwg.org/schemas/ps/20030411 And another where the namespace doesn't correspond directly to the location: http://www.pwg.org/ps/20030411 Any recommendations / opinions? Dave From dhall at hp.com Wed Apr 23 11:23:06 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:18 2009 Subject: PS> IPP and Printer Pooling Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAC9C@xvan01.vcd.hp.com> Hey All... Some clarification discussion came up in the last meeting around the CreateJob method, and what should happen if the client does not specify a targetDeviceIdentifier, and the deliverToTargetDevice parameter. So far, I have only been thinking about delayed association of a Target Device, and not about the Print Service picking a Target Device based upon the requirements of the Job. Can someone describe the Use Cases around Printer Pooling? What are the requirements? Thanks! Dave From imcdonald at sharplabs.com Wed Apr 23 14:17:26 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:18 2009 Subject: PS> IPP and Printer Pooling Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF97@mailsrvnt02.enet.sharplabs.com> Hi Dave, The common case for IPP-based spoolers (like CUPS) is that the IPP Printer object supports (by some out-of-band configuration not in RFC 2911) two or more target print devices. When a user submits a job (Create-Job, Print-Job, or Print-URI), the IPP Printer object selects an available target print device and displays the NAME (not the URL, sadly) of the selected target print device in the read-only Job attribute: "output-device-assigned". I have proposed that we add an IPP Printer Description attribute: "output-device-supported(1setOf text(127))" Further, the future IPP Device object (strongly based on the Printer MIB attributes) should have a "device-name" Description attribute that MUST correspond to one of the published values of "output-device-supported". So, an IPP abstract Printer object actually ALWAYS represents a 'printer pool'. But sometimes it's a pool of one. For PSI, we need to disambiguate the mapping from PSI Print Service to IPP Printer object. I naively have always thought it was a one-to-one mapping. If so, a PSI Print Service has the same property that it always represents a 'pool', the value of an attribute of REGISTERED (and not merely KNOWN by discovery) available target devices. Comments? Cheers, - Ira McDonald High North Inc -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Wednesday, April 23, 2003 11:23 AM To: 'ps@pwg.org' Subject: PS> IPP and Printer Pooling Hey All... Some clarification discussion came up in the last meeting around the CreateJob method, and what should happen if the client does not specify a targetDeviceIdentifier, and the deliverToTargetDevice parameter. So far, I have only been thinking about delayed association of a Target Device, and not about the Print Service picking a Target Device based upon the requirements of the Job. Can someone describe the Use Cases around Printer Pooling? What are the requirements? Thanks! Dave From dhall at hp.com Tue Apr 29 11:05:17 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:18 2009 Subject: PS> RE: Next Call Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FACB4@xvan01.vcd.hp.com> I posted yesterday, but I didn't see it come through the reflector... Next week.. :) Hi All... Well, I still haven't made it through the entire PSI specification yet - So, tomorrow's meeting is canceled. Look for a update later this week about having a review next week. Thanks! Dave -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, April 29, 2003 8:02 AM To: BERKEMA,ALAN C (HP-Roseville,ex1) Cc: dhall@hp.com Subject: Next Call I don't see any sign of a call today. Is this correct? (I'm probably confused) ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/ps/attachments/20030429/e9b79ef0/attachment-0001.html From dhall at hp.com Wed Apr 30 17:49:30 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:18 2009 Subject: PS> New PSI Specification Document Available Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FACC5@xvan01.vcd.hp.com> Hey All... A new PSI Specification Document is available at: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030430.doc ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030430.pdf It incorporates all of the Last Call Review comments (Prefixed with LCRC), as well as some issues raised during the last call process. (Previxed with ISSUE). We will walk through the LCRCs and ISSUEs next Tuesday. Meeting details to follow in a subsequent message. I have returned the document to a Working Draft given the number of modifications discovered in the Last Call process. Once we have reviewed the LCRCs and the ISSUEs reviewed and resolved, I believe we should start a new, shorter Last Call process again. Dave From dhall at hp.com Fri May 2 16:50:00 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:18 2009 Subject: PS> Next Tuesday (5/6) Meeting Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FACCC@xvan01.vcd.hp.com> Hey All.. On next Tuesday, we will review the latest PSI document, each of the last call review comments, along with the issues. Dave Sprint 866-639-4756 574-935-6714 #2124228 ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Date: 5/6/2003 Time: 8:00AM, (GMT -07:00) Pacific Time, USA & Canada (DayLight Time) Meeting Number: 28476876 Meeting Password: new_psi From harryl at us.ibm.com Tue May 6 15:31:33 2003 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:02:18 2009 Subject: PS> PSI port-number (3800) assigned. Message-ID: Good news! The long awaited PSI port number has been assigned. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- ----- Forwarded by Harry Lewis/Boulder/IBM on 05/06/2003 01:31 PM ----- "IANA" 05/06/2003 01:24 PM To: Harry Lewis/Boulder/IBM@IBMUS cc: , , Subject: Re: Application for port-number (3800) Dear Harry, Thank you for returning my call and please accept our apologies for the delay. We have assigned the following user port number with you as the point of contact: pwgpsi 3800/tcp Print Services Interface pwgpsi 3800/udp Pring Services Interface # Harry Lewis May 2003 Please notify the IANA if there is a change in contact information by completing the following template: If there is anything else I can help you with, please do not hesitate to contact me. Thank you, Michelle S. Cotton IANA Administrator *************************************************************** Internet Assigned Numbers Authority (IANA) 4676 Admiralty Way, Suite 330 Marina del Rey, California 90292 Voice: (310) 823-9358 FAX: (310) 823-8649 email: iana@iana.org *************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/ps/attachments/20030506/2cff21b2/attachment-0001.html From alan.berkema at hp.com Mon May 12 17:16:04 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:18 2009 Subject: PS> [PSI]:next call 05/13/03- 2 hours Message-ID: <6CD0BB10724459478066E90327DBB6512044DB@xrose01.rose.hp.com> Teleconference details: NEXT: Tuesday May 13 2003 (USA) Time: 8:00AM (US PDT) Until: 10:00AM Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Continue Last Call Comment Resolution ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 21727912 Meeting Password: newpsi Host: Alan Berkema 1(916)7855605 From alan.berkema at hp.com Tue May 13 15:18:23 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:18 2009 Subject: PS> [PSI]:next call 05/20/03- 2 hours? Message-ID: <6CD0BB10724459478066E90327DBB6512044E6@xrose01.rose.hp.com> Teleconference details: NEXT: Tuesday May 20 2003 (USA) Time: 8:00AM (US PDT) Until: 10:00AM (Think this will just go apx 1 hour) Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Review major changes from Last Call Comment Resolution ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 21727912 Meeting Password: newpsi Host: Alan Berkema 1(916)7855605 From dhall at hp.com Fri May 16 16:09:16 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:18 2009 Subject: PS> wd-psi10-20030513.doc available Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAD05@xvan01.vcd.hp.com> ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030513.doc Hey All.. The latest wd PSI specification has been published. Acrobat couldn't convert it for some reason, so no PDF this time.. (Ira, can you give it a shot?) Dave From imcdonald at sharplabs.com Fri May 16 16:36:18 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:18 2009 Subject: PS> [PDF of] wd-psi10-20030513.doc available Message-ID: <116DB56CD7DED511BC7800508B2CA53735CFDA@mailsrvnt02.enet.sharplabs.com> Hi folks, I created a PDF (213KB versus 737KB for MS Word source) and stored at: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030513.pdf Cheers, - Ira -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Friday, May 16, 2003 4:09 PM To: 'ps@pwg.org' Subject: PS> wd-psi10-20030513.doc available ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030513.doc Hey All.. The latest wd PSI specification has been published. Acrobat couldn't convert it for some reason, so no PDF this time.. (Ira, can you give it a shot?) Dave From alan.berkema at hp.com Tue May 20 18:13:52 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:18 2009 Subject: PS> [PSI]: Interop Fest 1 Message-ID: <6CD0BB10724459478066E90327DBB651204523@xrose01.rose.hp.com> Hi All, PSI will conduct it's first interoperability event on July 15th & 16th at HP's Vancouver Wa site. Detailed logistics will follow. In order to make this event successful we need as many PSI devices as possible. Please let me know as soon as you can if you will attend and what devices you will bring to the party. We will have an interoperability test plan proposal before the June 20 F2F. This will be reviewed and finalized at the F2F. We expect this to include Basic Job Submission methods. Status, Cancel will be wants . Target Device Interface will be later. Thanks, Alan From alan.berkema at hp.com Mon May 26 11:29:13 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:18 2009 Subject: PS> [PSI] NO call 05/27/03 next 6/3 Message-ID: <6CD0BB10724459478066E90327DBB65120454D@xrose01.rose.hp.com> Dave is on a well deserved vacation this week. We will have a call on 6/3 Thanks, Alan Teleconference details: NEXT: Tuesday June 3 2003 (USA) Time: 8:00AM (US PDT) Until: 10:00AM (Think this will just go apx 1 hour) Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Review major changes from Last Call Comment Resolution ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 21727912 Meeting Password: newpsi Host: Alan Berkema 1(916)7855605 From alan.berkema at hp.com Tue May 27 13:07:08 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:18 2009 Subject: PS> RE: [PSI]: Interop Fest 1 Message-ID: <6CD0BB10724459478066E90327DBB65120454E@xrose01.rose.hp.com> For this event we will use the WSDL based on the 20030411 specification. This gives us a stable base for testing. http://www.pwg.org/schemas/ps/20030411/ Future events will use the version that results for the Last call re-circ. RSVP asap Thanks, Alan -----Original Message----- From: BERKEMA,ALAN C (HP-Roseville,ex1) [mailto:alan.berkema@hp.com] Sent: Tuesday, May 20, 2003 3:14 PM To: 'a PSI pwg.org' Subject: PS> [PSI]: Interop Fest 1 Hi All, PSI will conduct it's first interoperability event on July 15th & 16th at HP's Vancouver Wa site. Detailed logistics will follow. In order to make this event successful we need as many PSI devices as possible. Please let me know as soon as you can if you will attend and what devices you will bring to the party. We will have an interoperability test plan proposal before the June 20 F2F. This will be reviewed and finalized at the F2F. We expect this to include Basic Job Submission methods. Status, Cancel will be wants . Target Device Interface will be later. Thanks, Alan From hastings at cp10.es.xerox.com Mon Jun 2 03:00:08 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:02:18 2009 Subject: PS> Does PSI need "document-format-details-implemented"? Message-ID: We are reviewing the IPP Job Extensions spec (JOBX) next Wednesday, June 4, at the IPPFAX telecon, 1-3 PM PST. Could the PSI WG look at this ISSUE at its Tuesday, June 3 telecon? See Page 38, section 7.7 for the description of the "document-format-details-implemented" Printer attribute. 6. ISSUE: Who needs document-format-details-implemented (1setOf collection) Printer attribute? Does PSI? We assume yes. However, if PSI does support Capabilities, then we shouldn't define "document-format-details-implemented" in the [jobx] spec, since it is a poor man's Capabilities. 7. We agreed that the "document-format-implemented" member attribute of the document-format-details-implemented (1setOf collection) attribute should be changed to a single value, since it really a "key" value. So each collection value has only one "document-format". It would be good to get some feedback on the ipp@pwg.org DL about this issue before Wednesday's telecon. Thanks, Tom Here is the complete information for the Wednesday Review, if you'd care to join: -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Sunday, June 01, 2003 23:28 To: ipp@pwg.org Cc: ifx@pwg.org Subject: IFX> Updated JOBX spec for Wed, June 4, 1-3 PM PDT (4-6 PM EDT) teleco n (10 ISSUES) I've uploaded the updated version of the Job Extension spec for review Wednesday, 1-3 PM PDT (4-6 PM EDT): ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030530.pdf.zip (572KB) ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030530.doc.zip (125KB) ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030530-rev.pdf (262KB) ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030530-rev.doc.zip (142KB) Please send any comments to the ipp@pwg.org DL only! > Rick Seeler has invited you to a MeetingPlace voice conference. > > Date/Time: June 04, 2003, 01:00 PM America/Los_Angeles > Meeting ID: 123123 > Password: > Frequency: Once > > MeetingPlace Phone Numbers: > Local: 408-536-9900 Here is the webex info - Name: IFX Date: 6/4/2003 Time: 1:00PM, (GMT -07:00) Pacific Time, USA & Canada (DayLight Time) Meeting Number: 29378444 Meeting Password: pwgifx Here are the changes from the last version we reviewed at the May 28 telecon: Version 0.3, 30 May 2003: Agreements reaches at the May 28, 2003 telecon: 1. Moved the Close-Job operation to the futures specification. 2. Added the "pages-per-subset" Job Template from [pwg5100.4]. See Appendix B section 17 for the minor differences. 3. Added the terms: "Best Effort, Finished Document, Page, Page Subset, and Sheet. 4. Clarified the conformance relationships between "xxx" Operation attributes and their corresponding "xxx-default" and "xxx-supported" Printer attributes. 5. Added rationale for each missing "xxx-default" and "xxx-supported" attribute. 6. Added 'errors-detected' and 'warnings-detected' "job-state-reasons" values. 7. Added the new 'choice_iso_a4_210x297mm_na_letter_8.5x11in' "media" attribute value which is a choice of two approximately equal media. 8. Added the requirements for choice media keyword values for inclusion in a revision of the PWG IEEE-ISTO 5101.1. 9. Changed the "document-format-implemented" member attribute from 1setOf mimeMediaType to mimeMediaType since it is the key attribute value. 10. Added another "document-format-implemented" example. 11. Updated the IANA section to agree with the additions. The following 10 issues are highlighted in the document: ISSUE 01: OK that the "job-mandatory-attributes" Operation attribute has nothing to do with guaranteeing (that the attribute will supersede the PDL), but only with whether the Printer will accept the job with unsupported attributes requested - TNH ISSUE 02: From DMC: It seems like it might be possible, for certain implementations, to have a default output-device. The problem is that normally the "xxx-default" is REQUIRED [TH: not for operation attributes, so we say a Printer MAY support the "output-device-default"], whereas my idea would be more to allow a Printer to advertise a default only if it matched its actual implementation. 3.1.3.1 Why there is no "output-device-requested-default" attribute ISSUE 02 (repeat): From DMC: Should we add an "output-device-requested-default" Printer Description attribute that a Printer MAY support when it supports the "output-device-requested" Operation attribute? ISSUE 03: (Thought up while writing up the reason for no default): [rfc2911] does have the concept of attribute coloring that causes the values of Printer attributes to depend on the "document-format". Thus, we could have "document-format-version-default" whose value depends on the value of the "document-format". Do we want to have "document-format-version-default", which, if supported, the Printer MUST color the value depending on the "document-format" Operation attribute supplied in the Get-Printer-Attributes request? All part of ISSUE 04: If the client supplies more integer values for the "pages-per-subset" attribute than the Printer supports, the Printer MUST treat the remaining values as Unsupported Attribute values as follows (see [rfc2911] section 3.1.7): If the client supplies the "attribute-fidelity" Operation attribute with a 'false' value (see section 3.1.1) or omits the attribute altogether, the Printer MUST (1) otherwise accept the Job, (2) return the 'successful-ok-attributes-ignored-or-substituted' status code, and (3) return in the Unsupported Attribute Group the additional values not supported. If the client supplies either the "attribute-fidelity" Operation attribute with a 'true' value or the "job-mandatory-attributes" Operation attribute with the 'pages-per-subset' keyword value (see section 3.1.2), the Printer MUST reject the job. ISSUE 04: PWG 5100.4 was silent on whether a Printer MUST support any number of integer values for "pages-per-subset" or whether the number was implementation dependent. Is supporting only a single value considered a conforming implementation so that the above error handling is sufficient? ISSUE 05: PWG 5100.4 had the "pages-per-subset-supported" attribute specified as a boolean. MUST a Printer support any number of integer values for the "pages-per-subset" (1setOf integer(1:MAX)) Job Template attribute? If supporting a maximum number, even as low as '1', is considered conforming, should we change the attribute syntax of the "pages-per-subset-supported" to integer(1:MAX) to indicate the maximum number of values supported by the Printer? Or is it sufficient for the Printer to return in the Unsupported Attributes group the remaining values of the "pages-per-subset" (integer(1:MAX)) attribute that aren't supported? ISSUE 06: What about the maximum number of pages in a Page Subset? MUST a Printer support any number up to MAX in any Page Subset? Part of ISSUE 07: The Printer MAY scale the image to fit, but any scaling MUST be isomorphic scaling and without image content loss. ISSUE 07: Why even allow the Printer to scale? Lets simplify this choice concept to sizes that are approximately the same, such as A4 and na-letter, rather than allowing a choice, of, say, A4 or A3 which would require scaling. That makes interoperability more difficult. ISSUE 08: Who needs the "document-format-details-implemented" attribute? Does PSI? We assume yes. However, if PSI does support Capabilities, then we shouldn't define "document-format-details-implemented" in this spec, since "document-format-details-implemented" is a poor man's capability mechanism. ACTION ITEM (Tom): Ask PSI whether they intend to use "document-format-details-implemented"? If not, should "document-format-details-implemented" be moved to the IPP Futures document, or just deleted and wait for someone to request it? Document Color Separation (DCS), version 2.0. ISSUE 10: Need a reference All part of ISSUE 09: [pwg5100.4] Herriot, R., Ocke, K., "Internet Printing Protocol (IPP): Override Attributes for Documents and Pages", IEEE-ISTO 5100.4-2001, February 7, 2001, ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.4.pdf. - being obsoleted by (1) a new Page Overrides specification which removes the "document-overrides" Job Template attribute and Operation attribute in favor of using the Document Object [ippdoc] and (2) this specification [ippjobx] definition of "pages-per-subset" Job Template attribute. ISSUE 09: The IETF process never revises an RFC, but just updates or obsoletes one with another RFC. On the other hand most other standards organizations, such as ANSI, ISO, (IEEE?), and POSIX, require that standards be reviewed and if necessary be "revised". I think that we are "revising" PWG IEEE-ISTO 5100.4, not "obsoleting" it. This is just a terminology question. The second paragraph of the PWG process section 4.2 says: "Working Drafts and Candidate Standards correspond to a specific version of the Standard they are defining. Unless the working group is engaged in an effort to revise an existing PWG Standard, the Working Drafts and Candidate Standards are always defining PWG Standard Version 1.0." and section 4.4.1 says: "Although the maturity level will not appear on PWG Candidate Standards or PWG Standards, if a Candidate Standard needs to be revised, any resulting PWG Working Drafts will have a maturity level indicated on their title page." From dhall at hp.com Tue Jun 3 10:04:32 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:18 2009 Subject: PS> wd-psi10-20030601.doc available Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAD3E@xvan01.vcd.hp.com> Hey All! I'm on vacation in Wisconsin today, and will be dialing in on a slow 28.8 connection. Please download the latest document this morning: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030601.doc Ira - If I can get you to do the PDF conversion, that would be great! I'll have to try re-installing acrobat on my system.. Dave From imcdonald at sharplabs.com Tue Jun 3 10:42:14 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:18 2009 Subject: PS> [PDF of] wd-psi10-20030601.doc available Message-ID: <116DB56CD7DED511BC7800508B2CA53735D015@mailsrvnt02.enet.sharplabs.com> Hi Dave, Converted to PDF and stored at: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030601.pdf Cheers, - Ira -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Tuesday, June 03, 2003 10:05 AM To: 'ps@pwg.org' Subject: PS> wd-psi10-20030601.doc available Hey All! I'm on vacation in Wisconsin today, and will be dialing in on a slow 28.8 connection. Please download the latest document this morning: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030601.doc Ira - If I can get you to do the PDF conversion, that would be great! I'll have to try re-installing acrobat on my system.. Dave From alan.berkema at hp.com Wed Jun 4 11:42:28 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:18 2009 Subject: PS> [PSI] offcycle call 06/6/03 Message-ID: <6CD0BB10724459478066E90327DBB65120457E@xrose01.rose.hp.com> Hi all, Dave & Ira and I will get together at this time. Others are welcome. Note new webex info. NEXT: Tuesday June 6 2003 (USA) Time: 8:00AM (US PDT) Until: 10:00AM (Think this will just go apx 1 hour) Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Work on reaming actions to get spec ready to post on 6/9 ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 25369512 Meeting Password: newpsi Host: Alan Berkema 1(916)7855605 From imcdonald at sharplabs.com Thu Jun 5 21:04:12 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:18 2009 Subject: PS> Examples and Query parameters for PSI Message-ID: <116DB56CD7DED511BC7800508B2CA53735D02C@mailsrvnt02.enet.sharplabs.com> Hi Dave and Alan, Friday (6 June 2003) Below is one entire new section, new text for three existing sections, and some revised examples for existing sections, for the PSI spec. Cheers, - Ira ---------------------------------------- [Entire new section 7.1 - please delete entirely former section 7.1.1] 7.1 'PWG Standard URI Query Parameters' The following PWG standard URI query parameters are defined for use with any URL scheme in specifying Target Device Identifiers (section 7.2), Reference URI (section 7.3), or any other URI. Conformance: (1) A PSI Client MUST specify each parameter keyword in lowercase. (2) A PSI Client MUST specify well-known parameter values in lowercase. (3) A PSI Client MAY specify string parameter values in mixed case. 7.1.1 'auth' Client authentication mechanism required to access this URI, e.g., ipp://bar.com/printer?auth=digest Well-known values defined in section 4.4.2 of [RFC2911] are: 'none': no user authentication (i.e., 'anonymous'). 'requesting-user-name': user specified in protocol operation. 'basic': HTTP basic authentication [RFC2617]. 'digest': HTTP digest authentication [RFC2617]. 'certificate': user authenticated via certificate. 7.1.2 'binary' Binary transfer mode required to access this URI, e.g., ftp://joe:blues@myhost.com:21/somefile.pdf?passive=true&binary=true Well-known values are: 'true': Use binary transfer mode. 'false': Use text transfer mode (default, when absent). 7.1.3 'cert' Client certificate URI required to access this URI, e.g., ipp://bar.com/printer?auth=certificate&sec=tls&cert=ldap://f.com/abc 7.1.4 'domain' Domain name for any non-Internet URI scheme, e.g., pwg-unc://PrintServer15/*?domain=Accounting 7.1.5 'legacy' Legacy Target Device Identifier specified as a URI for PSI proxy, e.g., pwg-psitd://ps.foo.com/psi/1.0?legacy=pwg-unc://server/share 7.1.6 'location' Human-readable geographic location referenced by this URI, e.g., http://pwg-psitd:/foo.com/psi/1.0?location=First%20Floor 7.1.7 'name' Human-readable friendly name referenced by this URI, e.g., http://pwg-psitd:/foo.com/psi/1.0?name=Dave's%20Printer 7.1.8 'passive' Passive mode required to access this URI, e.g., ftp://joe:blues@myhost.com:21/somefile.txt?passive=true Well-known values are: 'true': Use passive mode. 'false': Do not use passive mode (default, when absent). 7.1.9 'pw' Password required to access this URI, e.g., pop://joe;auth=login@foo.com:110?sec=ssl3&pw=bingo&msgid=123 7.1.10 'sec' Security mechanism required to access this URI, e.g., ipp://bar.com/printer?auth=digest&sec=tls Well-known values defined in section 4.4.3 of [RFC2911] are: 'none': no security mechanism (i.e., 'anonymous'). 'ssl3': SSL3 [SSL] security for communications channel. 'tls': TLS [RFC2246] security for communications channel. ---------------------------------------- [ [ Dave - add examples in former TD Identifier sections. ] ] [ [ New text for former section 7.1.6 'ipp' ] ] A URL for an IPP print service [RFC2911]. Example: ipp://bar.com:631/printer?auth=digest&sec=tls Notes: (1) REQUIRED 'host' here is 'bar.com' (2) OPTIONAL 'port' here is '631' (default for IPP) (3) OPTIONAL 'path' here is 'printer' (4) PSI standard query 'auth' here is 'digest' [RFC2617] (5) PSI standard query 'sec' here is 'tls' [RFC2246] [ [ New text for former section 7.1.7 'ippfax' ] ] A URL for an IPPFAX print service [IPPFAX]. Example: ippfax://foo.com/faxprinter?auth=certificate Notes: (1) REQUIRED 'host' here is 'foo.com' (2) OPTIONAL 'path' here is 'faxprinter' (3) PSI standard query 'auth' here is 'certificate' [ [ New text for former section 7.1.8 'lpr' ] ] A URL for an LPR print service [RFC1179]. Example: lpr://bar.com:515/printer?location=First%20Floor Notes: (1) REQUIRED 'host' here is 'bar.com' (2) OPTIONAL 'port' here is '515' (default for LPR) (3) OPTIONAL 'path' here is 'printer' (4) PSI standard query 'location' here is 'First Floor' ---------------------------------------- [ [ Dave - fix broken examples in former Reference sections. ] ] [ [ Corrected example for former section 7.2.2 'ftp' ] ] ftp://joe:blues@myhost.com:21/somefile.pdf?passive=true&binary=true [ [ Corrected example for former section 7.2.4 'pop' ] ] pop://joe;auth=login@foo.com:110?sec=ssl3&pw=bingo&msgid=123 &attid=1.doc,2.doc,etc [ [ Corrected example for former section 7.2.5 'imap' ] ] imap://joe;auth=login@foo.com:143?sec=ssl3&pw=bingo&msgid=123 &attid=1.doc,2.doc,etc ---------------------------------------- From alan.berkema at hp.com Fri Jun 6 12:29:36 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:18 2009 Subject: PS> [PSI]: New Dates for Interop Event 1 Message-ID: <6CD0BB10724459478066E90327DBB65120458F@xrose01.rose.hp.com> All, To accommodate the companies that will attend PSI Interop 1 we have changed the dates to August 12th and 13th, 2003. Location is the same. For this event we will use the WSDL based on the 20030411 specification. This gives us a stable base for testing. http://www.pwg.org/schemas/ps/20030411/ Future events will use the version that results for the Last call re-circ. RSVP asap Thanks, Alan -----Original Message----- From: BERKEMA,ALAN C (HP-Roseville,ex1) [mailto:alan.berkema@hp.com] Sent: Tuesday, May 20, 2003 3:14 PM To: 'a PSI pwg.org' Subject: PS> [PSI]: Interop Fest 1 Hi All, PSI will conduct it's first interoperability event on July 15th & 16th at HP's Vancouver Wa site. Detailed logistics will follow. In order to make this event successful we need as many PSI devices as possible. Please let me know as soon as you can if you will attend and what devices you will bring to the party. We will have an interoperability test plan proposal before the June 20 F2F. This will be reviewed and finalized at the F2F. We expect this to include Basic Job Submission methods. Status, Cancel will be wants . Target Device Interface will be later. Thanks, Alan From dhall at hp.com Mon Jun 9 14:37:36 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:18 2009 Subject: PS> PSI 06/10 telecon. 866-639-4756 #2124228 Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAD53@xvan01.vcd.hp.com> Hi All... We will have an hour teleconference tomorrow to review the f2f meeting agenda. Dave Sprint 866-639-4756 574-935-6714 ID: 2124228 Hello David Hall, You have successfully scheduled the following meeting: Topic: psi Date: Tuesday, June 10, 2003 Time: 8:00 am, Pacific Daylight Time (GMT -07:00, San Jose) Meeting number: 745635264 Meeting password: new@psi02 http://www.webex.com We've got to start meeting like this(TM) From dhall at hp.com Tue Jun 10 11:06:36 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:18 2009 Subject: PS> wd-psi10-20030606 available. Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAD57@xvan01.vcd.hp.com> Hi All.. The psi spec is available for review at: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030606.doc ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030606.pdf We will be reviewing this at the f2f next friday.. Dave From dhall at hp.com Tue Jun 10 11:30:31 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:18 2009 Subject: PS> Tentative PSI Agenda Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAD58@xvan01.vcd.hp.com> Agenda for PSI F2F... (Done by 2 or 3??) Round table introductions Schedule review * Interop * Rest of the year PSI Overview Q&A (if needed) Test Plan Discussion * Minimal Client Testing o ByPush o ByReference o ByValue? * Status and Cancel Developers Guide Discussion Page turner to incorporate comments for last call review Please provide any additional feedback for the agenda via the reflector. Thanks! Dave From imcdonald at sharplabs.com Tue Jun 10 11:58:11 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:18 2009 Subject: PS> Tentative PSI Agenda [for Fri 20 June - F2F] Message-ID: <116DB56CD7DED511BC7800508B2CA53735D03B@mailsrvnt02.enet.sharplabs.com> Hi Dave, And also, as we just discussed, possibly a dial-in setup for the first 2 hours of the meeting (Round table, Schedule, Overview/Q&A), at least). Many FSG Open Printing members couldn't travel because of (relatively) short notice, so there might be a lot better FSG attendance for a PSI overview by teleconference. Cheers, - Ira McDonald High North Inc -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Tuesday, June 10, 2003 11:31 AM To: 'ps@pwg.org' Subject: PS> Tentative PSI Agenda Agenda for PSI F2F... (Done by 2 or 3??) Round table introductions Schedule review * Interop * Rest of the year PSI Overview Q&A (if needed) Test Plan Discussion * Minimal Client Testing o ByPush o ByReference o ByValue? * Status and Cancel Developers Guide Discussion Page turner to incorporate comments for last call review Please provide any additional feedback for the agenda via the reflector. Thanks! Dave From imcdonald at sharplabs.com Wed Jun 11 12:48:54 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:18 2009 Subject: PS> FW: Proposed new Job and Document events (IPP Notifications) Message-ID: <116DB56CD7DED511BC7800508B2CA53735D048@mailsrvnt02.enet.sharplabs.com> Oops - blew the PSI address, - Ira -----Original Message----- From: McDonald, Ira Sent: Wednesday, June 11, 2003 12:47 PM To: 'ifx@pwg.org'; 'psi@pwg.org' Subject: Proposed new Job and Document events (IPP Notifications) Hi folks, Wedesday (11 June 2003) Per an action item of mine from last week's PSI telecon (3 June) and in preparation for our IFX telecon on IPP Notifications and IPPGET this afternoon, below are all of the currently defined IPP events: 'printer-state-changed' REQUIRED (sub-events) 'printer-restarted' OPTIONAL 'printer-shutdown' OPTIONAL 'printer-stopped' REQUIRED 'printer-config-changed' REQUIRED (sub-events) 'printer-media-changed' OPTIONAL 'printer-finishings-changed' OPTIONAL 'printer-queue-order-changed' OPTIONAL 'job-state-changed' REQUIRED (sub-events) 'job-created' REQUIRED 'job-completed' REQUIRED 'job-stopped' OPTIONAL 'job-config-changed' OPTIONAL 'job-progress' OPTIONAL (page-level progress) I propose (for IPPFAX) two new job progress sub-events: 'job-progress' OPTIONAL (page-level progress) (sub-events) 'job-error' OPTIONAL (page-level error) 'job-warning' OPTIONAL (page-level warning) I propose (for IPP Document object) a new set of document events: 'document-state-changed' REQUIRED (if Document object supported) (sub-events) 'document-created' REQUIRED 'document-completed' REQUIRED Also worth considering are the (oddly, undefined) 'job-processing' and 'document-processing' events. Comments? Cheers, - Ira McDonald High North Inc From alan.berkema at hp.com Tue Jun 24 12:52:24 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:18 2009 Subject: PS> [PSI] Next Call 07/01/03 Message-ID: <0806DAA43B1555479D53B58675D3468345830E@xrose01.rose.hp.com> Note new webex number and more secure passwd :) Teleconference details: NEXT: Tuesday July 1 2003 (USA) Time: 8:00AM (US PDT) Until: 10:00AM (Think this will just go apx 1 hour) Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Review TODOs from F2F in preparation for Last Call ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting number: 742973971 Meeting password: newpsi1! Host: Alan Berkema 1(916)7855605 From alan.berkema at hp.com Mon Jun 30 18:41:32 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:18 2009 Subject: PS> [PSI] Postponded - Next Call 07/01/03 Message-ID: <0806DAA43B1555479D53B58675D3468345832F@xrose01.rose.hp.com> Hey all, I just found out that some folks are on vacation this week and Dave is not done with his edits. I will be at the 1394 TA meeting next week so the new next call date is July 15th. Have a fun 4th! Alan ---- Note new webex number and more secure passwd :) Teleconference details: NEXT: Tuesday July 15 2003 (USA) Time: 8:00AM (US PDT) Until: 10:00AM (Think this will just go apx 1 hour) Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Review TODOs from F2F in preparation for Last Call ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting number: 742973971 Meeting password: newpsi1! Host: Alan Berkema 1(916)7855605 From alan.berkema at hp.com Tue Jul 1 18:22:45 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:18 2009 Subject: PS> [PSI]: Meeting Minutes 06/20/2003 Portland F2F Message-ID: <0806DAA43B1555479D53B58675D3468345833D@xrose01.rose.hp.com> Thanks Jerry -------------- next part -------------- A non-text attachment was scrubbed... Name: PSI Minutes 062003.pdf Type: application/octet-stream Size: 43286 bytes Desc: not available Url : http://www.pwg.org/archives/ps/attachments/20030701/27591bd4/PSIMinutes062003-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: agenda_060620.pdf Type: application/octet-stream Size: 72975 bytes Desc: not available Url : http://www.pwg.org/archives/ps/attachments/20030701/27591bd4/agenda_060620-0001.obj From imcdonald at sharplabs.com Sun Jul 6 14:37:04 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:18 2009 Subject: PS> FW: SMB URL v05. Message-ID: <116DB56CD7DED511BC7800508B2CA53735D089@mailsrvnt02.enet.sharplabs.com> Hi folks, I've been corresponding with Chris Hertel (author of the 'smb:' URL scheme) recently. We could use the standard 'smb:' scheme to completely replace our need for a 'pwg-unc:' scheme in PSI/1.0. Chris says that it's already shipping in Mac OS 10 and elsewhere. Below is Chris' note to the IETF URI Review mailing list (a recent effort by IETF Area Director Ted Hardie to 'move along' URL schemes). Very good terse summary of the issues around SMB URLs in the TCP/IP environment. The spec itself is excellent reading (see URL below). Cheers, - Ira McDonald High North Inc -----Original Message----- From: Christopher R. Hertel [mailto:crh@ubiqx.mn.org] Sent: Sunday, July 06, 2003 3:23 AM To: uri-review@ietf.org Subject: SMB URL v05. Hello everyone. I've just joined this list. Please be gentle. ;) I have been working sporadically on a URI specification for SMB. SMB is the Server Message Block protocol, which is at the heart of Microsoft's filesharing system (now known as CIFS). The SMB filesharing protocol is implemented by several "third party" vendors, and in Open Source by the Samba and jCIFS projects. SMB itself is a relatively old protocol, and there are a number of quirks that must be accounted for in the URI design. In particular, there is all of RFC1001/1002 (STD 19) which specifies a mechanism for implementing the NetBIOS API on top of TCP/UDP/IPv4. Along with that comes all sorts of context information which must be supplied in order to give the NetBIOS addresses meaning in an IP environment. I have been providing draft SMB URI specifications to the IETF for about 2.5 years now. The current version number is 04, and it is due to expire in a few days. I have a minor update ready, and will send it along to keep the draft alive. The problems are: 1) I really have no idea how to push the SMB URI Internet Draft through the standards process. 2) I know a lot about SMB and NBT, and very little about URIs. To be honest, I'm not really clear on the difference between a URL and a URI (and I'm not even ashamed to admit it). :) 3) SMB is a difficult protocol, and the most important aspect of the drafts that I have submitted is the semantic mapping between the SMB URI format and SMB/NBT (NBT is a name commonly given to NetBIOS over TCP/IP as described in STD 19). In the past few years, I have gotten some very helpful feedback from Roy Fielding and Larry Masinter, and also from the SMB/CIFS development community. More recently, however, I have also received a request to "get on with it". A very reasonable request, I believe. Several vendors have already implemented support for the SMB URI in their products. It is in Thursby's Dave, Mac OS 10, and KDE Konqueror, to name a few. So, I am writing to ask for assistance in finishing this thing, either by bronzing it and putting it on a pedestal or by driving a stake through it's corrupt and evil heart. The current draft may be found here: http://www.ietf.org/internet-drafts/draft-crhertel-smb-url-04.txt I look forward to your replies (yes, I'm wearing a helmet). Sincerely, Chris Hertel -)----- -- "Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X Samba Team -- http://www.samba.org/ -)----- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)----- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)----- crh@ubiqx.mn.org OnLineBook -- http://ubiqx.org/cifs/ -)----- crh@ubiqx.org From dhall at hp.com Mon Jul 7 14:13:19 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:18 2009 Subject: PS> FW: SMB URL v05. Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FADC4@xvan01.vcd.hp.com> After reviewing the SMB specification, it seem that the smb: scheme should replace the pwg-unc: scheme that we have defined in PSI. Any dissention? I'll make a pass at getting it in the spec, and then we can review at tomorrows telecon. Dave -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Sunday, July 06, 2003 11:37 AM To: 'ps@pwg.org' Subject: PS> FW: SMB URL v05. Hi folks, I've been corresponding with Chris Hertel (author of the 'smb:' URL scheme) recently. We could use the standard 'smb:' scheme to completely replace our need for a 'pwg-unc:' scheme in PSI/1.0. Chris says that it's already shipping in Mac OS 10 and elsewhere. Below is Chris' note to the IETF URI Review mailing list (a recent effort by IETF Area Director Ted Hardie to 'move along' URL schemes). Very good terse summary of the issues around SMB URLs in the TCP/IP environment. The spec itself is excellent reading (see URL below). Cheers, - Ira McDonald High North Inc -----Original Message----- From: Christopher R. Hertel [mailto:crh@ubiqx.mn.org] Sent: Sunday, July 06, 2003 3:23 AM To: uri-review@ietf.org Subject: SMB URL v05. Hello everyone. I've just joined this list. Please be gentle. ;) I have been working sporadically on a URI specification for SMB. SMB is the Server Message Block protocol, which is at the heart of Microsoft's filesharing system (now known as CIFS). The SMB filesharing protocol is implemented by several "third party" vendors, and in Open Source by the Samba and jCIFS projects. SMB itself is a relatively old protocol, and there are a number of quirks that must be accounted for in the URI design. In particular, there is all of RFC1001/1002 (STD 19) which specifies a mechanism for implementing the NetBIOS API on top of TCP/UDP/IPv4. Along with that comes all sorts of context information which must be supplied in order to give the NetBIOS addresses meaning in an IP environment. I have been providing draft SMB URI specifications to the IETF for about 2.5 years now. The current version number is 04, and it is due to expire in a few days. I have a minor update ready, and will send it along to keep the draft alive. The problems are: 1) I really have no idea how to push the SMB URI Internet Draft through the standards process. 2) I know a lot about SMB and NBT, and very little about URIs. To be honest, I'm not really clear on the difference between a URL and a URI (and I'm not even ashamed to admit it). :) 3) SMB is a difficult protocol, and the most important aspect of the drafts that I have submitted is the semantic mapping between the SMB URI format and SMB/NBT (NBT is a name commonly given to NetBIOS over TCP/IP as described in STD 19). In the past few years, I have gotten some very helpful feedback from Roy Fielding and Larry Masinter, and also from the SMB/CIFS development community. More recently, however, I have also received a request to "get on with it". A very reasonable request, I believe. Several vendors have already implemented support for the SMB URI in their products. It is in Thursby's Dave, Mac OS 10, and KDE Konqueror, to name a few. So, I am writing to ask for assistance in finishing this thing, either by bronzing it and putting it on a pedestal or by driving a stake through it's corrupt and evil heart. The current draft may be found here: http://www.ietf.org/internet-drafts/draft-crhertel-smb-url-04.txt I look forward to your replies (yes, I'm wearing a helmet). Sincerely, Chris Hertel -)----- -- "Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X Samba Team -- http://www.samba.org/ -)----- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)----- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)----- crh@ubiqx.mn.org OnLineBook -- http://ubiqx.org/cifs/ -)----- crh@ubiqx.org From dhall at hp.com Mon Jul 7 15:54:47 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:18 2009 Subject: PS> Next Call 7/15,updated doc... Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FADC6@xvan01.vcd.hp.com> Hey All.. I've published the latest document revision: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030707.doc ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030707.pdf Looks like our next phone conference isn't untill teh 15 however. Talk to you next week! Dave -----Original Message----- From: BERKEMA,ALAN C (HP-Roseville,ex1) [mailto:alan.berkema@hp.com] Sent: Monday, June 30, 2003 3:42 PM To: 'a PSI pwg.org' Subject: PS> [PSI] Postponded - Next Call 07/01/03 Hey all, I just found out that some folks are on vacation this week and Dave is not done with his edits. I will be at the 1394 TA meeting next week so the new next call date is July 15th. Have a fun 4th! Alan ---- Note new webex number and more secure passwd :) Teleconference details: NEXT: Tuesday July 15 2003 (USA) Time: 8:00AM (US PDT) Until: 10:00AM (Think this will just go apx 1 hour) Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Review TODOs from F2F in preparation for Last Call ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting number: 742973971 Meeting password: newpsi1! Host: Alan Berkema 1(916)7855605 From imcdonald at sharplabs.com Tue Jul 8 12:10:34 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:18 2009 Subject: PS> FW: SMB URL v05. Message-ID: <116DB56CD7DED511BC7800508B2CA53735D090@mailsrvnt02.enet.sharplabs.com> Hi Dave, Thanks for the new PSI draft! About adding SMB right away to our PSI spec: Caution - the 'smb:' URL spec is quite mature (and widely deployed) - but it has just _finally_ been submitted last week to the IETF's "URI Review" mailing - the moderator (Ted Hardie) just replied that he'd be busy until after the IETF 57th Plenary in Vienna, Austria next week (13-18 July). Ted also asked "do the implementations support/use 'smb:' or 'cifs:' synonym schemes defined in this I-D"? Chris replied that they _all_ support/use "smb:" - some also accept 'cifs:' for compatibility - good news for PSI simplicity. If we move from 'pwg-unc:' to 'smb:' right now, we'll have (I believe) a Normative dependency on an unreviewed Internet-Draft. To get 'smb:' published as an approved RFC will take: a) review and revision on the mailing list; b) review and approval by an IETF Area Director; c) an IETF 4-week 'last call'; and d) movement through RFC Editor's queue. That's six to twelve months (pretty conservatively, I'm afraid). A possible finesse would be to put the "smb:" replacement for "pwg-unc:" in a new appendix "Experimental Target Device URLs (Informative)" (where we could also put my current work-in-progress on PWG URL schemes for Novell PServer, AppleTalk PAP and other legacy print protocols). I'm also plugging away at a threats model and discussion for a decent "Security Considerations" section of PSI. Which do you want first? More legacy URL schemes with ABNF and so on, or the Security Considerations? Cheers, - Ira McDonald High North Inc -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Monday, July 07, 2003 2:13 PM To: 'McDonald, Ira'; 'ps@pwg.org' Subject: RE: PS> FW: SMB URL v05. After reviewing the SMB specification, it seem that the smb: scheme should replace the pwg-unc: scheme that we have defined in PSI. Any dissention? I'll make a pass at getting it in the spec, and then we can review at tomorrows telecon. Dave -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Sunday, July 06, 2003 11:37 AM To: 'ps@pwg.org' Subject: PS> FW: SMB URL v05. Hi folks, I've been corresponding with Chris Hertel (author of the 'smb:' URL scheme) recently. We could use the standard 'smb:' scheme to completely replace our need for a 'pwg-unc:' scheme in PSI/1.0. Chris says that it's already shipping in Mac OS 10 and elsewhere. Below is Chris' note to the IETF URI Review mailing list (a recent effort by IETF Area Director Ted Hardie to 'move along' URL schemes). Very good terse summary of the issues around SMB URLs in the TCP/IP environment. The spec itself is excellent reading (see URL below). Cheers, - Ira McDonald High North Inc -----Original Message----- From: Christopher R. Hertel [mailto:crh@ubiqx.mn.org] Sent: Sunday, July 06, 2003 3:23 AM To: uri-review@ietf.org Subject: SMB URL v05. Hello everyone. I've just joined this list. Please be gentle. ;) I have been working sporadically on a URI specification for SMB. SMB is the Server Message Block protocol, which is at the heart of Microsoft's filesharing system (now known as CIFS). The SMB filesharing protocol is implemented by several "third party" vendors, and in Open Source by the Samba and jCIFS projects. SMB itself is a relatively old protocol, and there are a number of quirks that must be accounted for in the URI design. In particular, there is all of RFC1001/1002 (STD 19) which specifies a mechanism for implementing the NetBIOS API on top of TCP/UDP/IPv4. Along with that comes all sorts of context information which must be supplied in order to give the NetBIOS addresses meaning in an IP environment. I have been providing draft SMB URI specifications to the IETF for about 2.5 years now. The current version number is 04, and it is due to expire in a few days. I have a minor update ready, and will send it along to keep the draft alive. The problems are: 1) I really have no idea how to push the SMB URI Internet Draft through the standards process. 2) I know a lot about SMB and NBT, and very little about URIs. To be honest, I'm not really clear on the difference between a URL and a URI (and I'm not even ashamed to admit it). :) 3) SMB is a difficult protocol, and the most important aspect of the drafts that I have submitted is the semantic mapping between the SMB URI format and SMB/NBT (NBT is a name commonly given to NetBIOS over TCP/IP as described in STD 19). In the past few years, I have gotten some very helpful feedback from Roy Fielding and Larry Masinter, and also from the SMB/CIFS development community. More recently, however, I have also received a request to "get on with it". A very reasonable request, I believe. Several vendors have already implemented support for the SMB URI in their products. It is in Thursby's Dave, Mac OS 10, and KDE Konqueror, to name a few. So, I am writing to ask for assistance in finishing this thing, either by bronzing it and putting it on a pedestal or by driving a stake through it's corrupt and evil heart. The current draft may be found here: http://www.ietf.org/internet-drafts/draft-crhertel-smb-url-04.txt I look forward to your replies (yes, I'm wearing a helmet). Sincerely, Chris Hertel -)----- -- "Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X Samba Team -- http://www.samba.org/ -)----- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)----- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)----- crh@ubiqx.mn.org OnLineBook -- http://ubiqx.org/cifs/ -)----- crh@ubiqx.org From imcdonald at sharplabs.com Wed Jul 9 11:31:11 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:18 2009 Subject: PS> FW: [Uri-review] SMB URL v05. Message-ID: <116DB56CD7DED511BC7800508B2CA53735D094@mailsrvnt02.enet.sharplabs.com> -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Wednesday, July 09, 2003 11:22 AM To: 'Christopher R. Hertel' Cc: hardie@qualcomm.com; uri-review@ietf.org Subject: RE: [Uri-review] SMB URL v05. Hi folks, Here's a link to Chris Hertel's latest Internet-Draft of the SMB URL scheme, posted on the IEEE/ISTO Printer Working Group's anonymous FTP server: ftp://ftp.pwg.org/pub/pwg/ps/draft-crhertel-smb-url-05.txt It should also be available from the IETF I-D repositories after next week's IETF 57 in Vienna. Thanks, - Ira McDonald High North Inc PS - The IEEE/ISTO PWG folks would like to allow use of the SMB URL scheme in their new Web services printing protocol (PSI) for 'legacy' print system references. _______________________________________________ Uri-review mailing list Uri-review@ietf.org https://www1.ietf.org/mailman/listinfo/uri-review From dhall at hp.com Mon Jul 14 16:22:17 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:18 2009 Subject: PS> Meeting 7/15 - 866-639-4756 #2124228 Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FADEF@xvan01.vcd.hp.com> Hey All... Here is the info for tomorrows PSI teleconference: Topic: PSI Date: Tuesday, July 15, 2003 Time: 8:00 am, Pacific Daylight Time (GMT -07:00, San Jose) Meeting number: 742137205 866-639-4756 574-935-6714 #2124228 See you all there! Dave From imcdonald at sharplabs.com Mon Jul 14 16:30:31 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:18 2009 Subject: PS> Meeting 7/15 - 866-639-4756 #2124228 Message-ID: <116DB56CD7DED511BC7800508B2CA53735D0A4@mailsrvnt02.enet.sharplabs.com> Hi folks, Here's the URL that Dave sent out last week for the latest PSI spec: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030707.doc ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030707.pdf Cheers, - Ira McDonald High North Inc -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Monday, July 14, 2003 4:22 PM To: 'ps@pwg.org' Subject: PS> Meeting 7/15 - 866-639-4756 #2124228 Hey All... Here is the info for tomorrows PSI teleconference: Topic: PSI Date: Tuesday, July 15, 2003 Time: 8:00 am, Pacific Daylight Time (GMT -07:00, San Jose) Meeting number: 742137205 866-639-4756 574-935-6714 #2124228 See you all there! Dave From imcdonald at sharplabs.com Mon Jul 14 21:58:38 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:19 2009 Subject: PS> [PSI Reqs] Meeting 7/15 - 866-639-4756 #2124228 Message-ID: <116DB56CD7DED511BC7800508B2CA53735D0A5@mailsrvnt02.enet.sharplabs.com> Hi, As we discovered belatedly last week for WBMM and IPPFAX, the PWG Process (both old and new) REQUIRES that: * Each WG Requirements spec MUST be FORMALLY APPROVED (just like a PWG 'standards-track' spec, w/out prototyping, etc.) BEFORE the WG Protocol spec can become a Candidate Standard. At tomorrow's PSI telecon, I'd like to discuss: (a) Needed revisions for the PSI Reqs spec (v0.81, Oct 2002); and (b) Security Considerations section for PSI Protocol spec that describes the detailed network topology (firewalls, subnets, etc.) of each of the 5 Usage Scenarios in the PSI Reqs spec. The latest PSI Reqs spec is at: ftp://ftp.pwg.org/pub/pwg/ps/psi_requirements081.doc ftp://ftp.pwg.org/pub/pwg/ps/psi_requirements081.pdf Cheers, - Ira McDonald High North Inc -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Monday, July 14, 2003 4:31 PM To: 'HALL,DAVID (HP-Vancouver,ex1)'; 'ps@pwg.org' Subject: RE: PS> Meeting 7/15 - 866-639-4756 #2124228 Hi folks, Here's the URL that Dave sent out last week for the latest PSI spec: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030707.doc ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030707.pdf Cheers, - Ira McDonald High North Inc -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Monday, July 14, 2003 4:22 PM To: 'ps@pwg.org' Subject: PS> Meeting 7/15 - 866-639-4756 #2124228 Hey All... Here is the info for tomorrows PSI teleconference: Topic: PSI Date: Tuesday, July 15, 2003 Time: 8:00 am, Pacific Daylight Time (GMT -07:00, San Jose) Meeting number: 742137205 866-639-4756 574-935-6714 #2124228 See you all there! Dave From dhall at hp.com Tue Jul 15 11:03:33 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:19 2009 Subject: PS> Meeting 7/15 - 866-639-4756 #2124228 Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FADF1@xvan01.vcd.hp.com> new_psi2 is the webex password -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Monday, July 14, 2003 1:22 PM To: 'ps@pwg.org' Subject: PS> Meeting 7/15 - 866-639-4756 #2124228 Hey All... Here is the info for tomorrows PSI teleconference: Topic: PSI Date: Tuesday, July 15, 2003 Time: 8:00 am, Pacific Daylight Time (GMT -07:00, San Jose) Meeting number: 742137205 866-639-4756 574-935-6714 #2124228 See you all there! Dave From alan.berkema at hp.com Fri Jul 18 14:53:08 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:19 2009 Subject: PS> [PSI] No Call 07/22 Next Call 07/29/03 Message-ID: <0806DAA43B1555479D53B58675D34683458376@xrose01.rose.hp.com> Teleconference details: NEXT: Tuesday July 29 2003 (USA) Time: 8:00AM (US PDT) Until: 9:00AM Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Review Spec 2) Semantic Model Dependancy Update 3) Actions to move forward ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting number: 743057814 Meeting password: newpsi-1 Host: Alan Berkema 1(916)7855605 From imcdonald at sharplabs.com Mon Jul 21 13:43:35 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:19 2009 Subject: PS> FW: IPP> Re: ISSUE 17: about server-error-too-many-jobs (0x050B) Message-ID: <116DB56CD7DED511BC7800508B2CA53735D0BA@mailsrvnt02.enet.sharplabs.com> Hi, Michael Sweet's comments on 'server-error-too-many-jobs/documents'. Cheers, - Ira McDonald High North Inc -----Original Message----- From: Michael Sweet [mailto:mike@easysw.com] Sent: Monday, July 21, 2003 11:09 AM To: Hastings, Tom N Cc: ipp@pwg.org Subject: IPP> Re: ISSUE 17: about server-error-too-many-jobs (0x050B) Hastings, Tom N wrote: > Michael, > > Do you have some input on this issue in the Document object spec about what > we should say about whether or not the client should try again (later) on > the proposed new server-error-too-many-jobs (0x050B): > > 22. About ISSUE17: > 13.1 server-error-too-many-jobs (0x050B) > The client has attempted to create a Job using any of the Job Creation > operations which would exceed the capacity of the Printer and/or the policy > for this user or type of Job. The client SHOULD NOT try again later. DMC > ISSUE17: I would have said SHOULD try again later, because resources might > have been freed up. That is, I would have read "too many jobs" as a > resource issue and "too many documents" as a policy issue. If we're saying > not to try again, we should be clear that this error should only be returned > if the problem is not expected to go away. > > Good ISSUE! It would be good to get Michael Sweet's input on this, since he > requested these error codes. I think that the status codes for both too-many-jobs and too-many-documents should be worded such that a client MAY try again later, not SHOULD or SHOULD NOT. If we want to differentiate hard and soft errors, I would recommend using server-error-not-possible to specify that it is not possible to create a new job or document (i.e. not-possible means don't retry, too-many-foos means you MAY retry...) -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike at easysw dot com Printing Software for UNIX http://www.easysw.com From alan.berkema at hp.com Mon Jul 28 11:55:57 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:19 2009 Subject: PS> [PSI] Reminder Next Call 07/29/03 Message-ID: <0806DAA43B1555479D53B58675D3468345838E@xrose01.rose.hp.com> Teleconference details: NEXT: Tuesday July 29 2003 (USA) Time: 8:00AM (US PDT) Until: 9:00AM Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Recent work items form Dave & Ira 2) Semantic Model Dependancy Update 3) Actions to move forward 4) Interop Test Plan ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting number: 743057814 Meeting password: newpsi-1 Host: Alan Berkema 1(916)7855605 From hastings at cp10.es.xerox.com Mon Jul 28 16:25:24 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:02:19 2009 Subject: PS> RE: ISSUE 17: about server-error-too-many-jobs (0x050B) [comment on Document Object spec] Message-ID: Here are the current specifications for these two new error status codes from the current Document Object spec (circa June 3 with Dennis's comments added): 13.1 server-error-too-many-jobs (0x050B) The client has attempted to create a Job using any of the Job Creation operations which would exceed the capacity of the Printer and/or the policy for this user or type of Job. The client SHOULD NOT try again later. DMC ISSUE17: I would have said SHOULD try again later, because resources might have been freed up. That is, I would have read "too many jobs" as a resource issue and "too many documents" as a policy issue. If we're saying not to try again, we should be clear that this error should only be returned if the problem is not expected to go away. 13.2 server-error-too-many-documents (0x050C) The client has attempted to create a Document using any of the Document Creation operations which would exceed the capacity of the Printer for this Job and/or the policy for this user or type of Job. The client SHOULD NOT try again later. For server-error-too-many-jobs: "The client SHOULD NOT try again later" Dennis proposes: "The client SHOULD try again later." Michael proposes: Remove the policy possibility from the description and use 'client-error-not-possible' to mean a hard error and use MAY: The client has attempted to create a Job using any of the Job Creation operations which would exceed the capacity of the Printer. The client MAY try again later. Looking at the status codes descriptions in [rfc2911], I'd suggest: The client has attempted to create a Job using any of the Job Creation operations which would exceed the capacity of the Printer. The client MAY try the unmodified request again at some later point in time with an expectation that the capacity condition may have changed. For server-error-too-many-documents: "The client SHOULD NOT try again later" Dennis proposes no change. Michael proposes the same change: The client has attempted to create a Document using any of the Document Creation operations which would exceed the capacity of the Printer for this Job. The client MAY try again later. How about to align more with [rfc2911]: The client has attempted to create a Document using any of the Document Creation operations which would exceed the capacity of the Printer for this Job. The client MAY try the unmodified request again at some later point in time with an expectation that the capacity condition may have changed. Tom -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Monday, July 21, 2003 10:44 To: 'sm@pwg.org'; 'ps@pwg.org' Subject: SM> FW: IPP> Re: ISSUE 17: about server-error-too-many-jobs (0x050B) Hi, Michael Sweet's comments on 'server-error-too-many-jobs/documents'. Cheers, - Ira McDonald High North Inc -----Original Message----- From: Michael Sweet [mailto:mike@easysw.com] Sent: Monday, July 21, 2003 11:09 AM To: Hastings, Tom N Cc: ipp@pwg.org Subject: IPP> Re: ISSUE 17: about server-error-too-many-jobs (0x050B) Hastings, Tom N wrote: > Michael, > > Do you have some input on this issue in the Document object spec about what > we should say about whether or not the client should try again (later) on > the proposed new server-error-too-many-jobs (0x050B): > > 22. About ISSUE17: > 13.1 server-error-too-many-jobs (0x050B) > The client has attempted to create a Job using any of the Job Creation > operations which would exceed the capacity of the Printer and/or the policy > for this user or type of Job. The client SHOULD NOT try again later. DMC > ISSUE17: I would have said SHOULD try again later, because resources might > have been freed up. That is, I would have read "too many jobs" as a > resource issue and "too many documents" as a policy issue. If we're saying > not to try again, we should be clear that this error should only be returned > if the problem is not expected to go away. > > Good ISSUE! It would be good to get Michael Sweet's input on this, since he > requested these error codes. I think that the status codes for both too-many-jobs and too-many-documents should be worded such that a client MAY try again later, not SHOULD or SHOULD NOT. If we want to differentiate hard and soft errors, I would recommend using server-error-not-possible to specify that it is not possible to create a new job or document (i.e. not-possible means don't retry, too-many-foos means you MAY retry...) -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike at easysw dot com Printing Software for UNIX http://www.easysw.com From alan.berkema at hp.com Tue Jul 29 17:10:36 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:19 2009 Subject: PS> [PSI]: Mtg. Minutes 7/29/03 Message-ID: <0806DAA43B1555479D53B58675D346834583A7@xrose01.rose.hp.com> PSI Working Group: *Alan Berkema *Dave Hall *Ira McDonald Jerry Thrasher *Harry Lewis *Ted Tronson Peter Mierau Peter Zehler Gail Songer Paul Tykodi Bob Taylor Lee Farrell Don Wright * = attendance 07/29/03 Agenda 1) Recent work items form Dave & Ira 2) Semantic Model Dependency Update 3) Actions to move forward 4) Interop Test Plan Minutes: 1) Recent work items form Dave & Ira Dave and Ira were Unable to meet last week. Will schedule next Tuesday 8/5/2003 to work on the PSI requirements document. Major point is that the use model diagrams could be embellished to show network domains, such as Public Internet or Private Intranet etc. The domains could be used be used to identify security threats. The threats should be categorized and addressed with recommendations for default configurations and/or solutions. PSI Spec has added headers for new sections called: IEEE ISTO PWG Considerations (IANA?) International Considerations Conformance Section Suggesting apx. one page each for PS, TD & Client. Example a PS shall implement all 4 interfaces, a TD implements 3 interfaces. Includes critical details. 2) Semantic Model Dependency Update Pete will update on Thursday. 3) Actions to move forward Still do not have a succinct list of actions needed for next last call. 4) Interop Test Plan Event will now be conducted remotely. Dave will leverage tests that he has for a test plan and send to the participants. Tests will include the specific methods and the parameter values which will be tested. Parameters, such as unsupported, that will not be tested will also be identified Dave will send new logistics for conference call number and webex info. Thanks, Alan From alan.berkema at hp.com Tue Jul 29 17:34:46 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:19 2009 Subject: PS> [PSI] Next Call 08/05/03 Message-ID: <0806DAA43B1555479D53B58675D346834583A8@xrose01.rose.hp.com> NO Call on 8/12/2003 - Interop Event Teleconference details: NEXT: Tuesday August 5 2003 (USA) Time: 8:00AM (US PDT) Until: 9:00AM Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Requirements Doc 2) New Spec Considerations and Conformance Sections 3) Suuccint List of Actions needed to go to next Last Call ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting number: 743057814 Meeting password: newpsi-1 Host: Alan Berkema 1(916)7855605 From imcdonald at sharplabs.com Tue Jul 29 18:31:32 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:19 2009 Subject: PS> RE: ISSUE 17: about server-error-too-many-jobs (0x050B) [comment on Document Object spec] Message-ID: <116DB56CD7DED511BC7800508B2CA53735D0CB@mailsrvnt02.enet.sharplabs.com> Hi Tom, I agree with your suggested rewording below. Cheers, - Ira McDonald High North Inc -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Monday, July 28, 2003 4:25 PM To: McDonald, Ira; 'sm@pwg.org'; 'ps@pwg.org' Subject: RE: ISSUE 17: about server-error-too-many-jobs (0x050B) [comment on Document Object spec] Here are the current specifications for these two new error status codes from the current Document Object spec (circa June 3 with Dennis's comments added): 13.1 server-error-too-many-jobs (0x050B) The client has attempted to create a Job using any of the Job Creation operations which would exceed the capacity of the Printer and/or the policy for this user or type of Job. The client SHOULD NOT try again later. DMC ISSUE17: I would have said SHOULD try again later, because resources might have been freed up. That is, I would have read "too many jobs" as a resource issue and "too many documents" as a policy issue. If we're saying not to try again, we should be clear that this error should only be returned if the problem is not expected to go away. 13.2 server-error-too-many-documents (0x050C) The client has attempted to create a Document using any of the Document Creation operations which would exceed the capacity of the Printer for this Job and/or the policy for this user or type of Job. The client SHOULD NOT try again later. For server-error-too-many-jobs: "The client SHOULD NOT try again later" Dennis proposes: "The client SHOULD try again later." Michael proposes: Remove the policy possibility from the description and use 'client-error-not-possible' to mean a hard error and use MAY: The client has attempted to create a Job using any of the Job Creation operations which would exceed the capacity of the Printer. The client MAY try again later. Looking at the status codes descriptions in [rfc2911], I'd suggest: The client has attempted to create a Job using any of the Job Creation operations which would exceed the capacity of the Printer. The client MAY try the unmodified request again at some later point in time with an expectation that the capacity condition may have changed. For server-error-too-many-documents: "The client SHOULD NOT try again later" Dennis proposes no change. Michael proposes the same change: The client has attempted to create a Document using any of the Document Creation operations which would exceed the capacity of the Printer for this Job. The client MAY try again later. How about to align more with [rfc2911]: The client has attempted to create a Document using any of the Document Creation operations which would exceed the capacity of the Printer for this Job. The client MAY try the unmodified request again at some later point in time with an expectation that the capacity condition may have changed. Tom -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Monday, July 21, 2003 10:44 To: 'sm@pwg.org'; 'ps@pwg.org' Subject: SM> FW: IPP> Re: ISSUE 17: about server-error-too-many-jobs (0x050B) Hi, Michael Sweet's comments on 'server-error-too-many-jobs/documents'. Cheers, - Ira McDonald High North Inc -----Original Message----- From: Michael Sweet [mailto:mike@easysw.com] Sent: Monday, July 21, 2003 11:09 AM To: Hastings, Tom N Cc: ipp@pwg.org Subject: IPP> Re: ISSUE 17: about server-error-too-many-jobs (0x050B) Hastings, Tom N wrote: > Michael, > > Do you have some input on this issue in the Document object spec about what > we should say about whether or not the client should try again (later) on > the proposed new server-error-too-many-jobs (0x050B): > > 22. About ISSUE17: > 13.1 server-error-too-many-jobs (0x050B) > The client has attempted to create a Job using any of the Job Creation > operations which would exceed the capacity of the Printer and/or the policy > for this user or type of Job. The client SHOULD NOT try again later. DMC > ISSUE17: I would have said SHOULD try again later, because resources might > have been freed up. That is, I would have read "too many jobs" as a > resource issue and "too many documents" as a policy issue. If we're saying > not to try again, we should be clear that this error should only be returned > if the problem is not expected to go away. > > Good ISSUE! It would be good to get Michael Sweet's input on this, since he > requested these error codes. I think that the status codes for both too-many-jobs and too-many-documents should be worded such that a client MAY try again later, not SHOULD or SHOULD NOT. If we want to differentiate hard and soft errors, I would recommend using server-error-not-possible to specify that it is not possible to create a new job or document (i.e. not-possible means don't retry, too-many-foos means you MAY retry...) -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike at easysw dot com Printing Software for UNIX http://www.easysw.com From imcdonald at sharplabs.com Mon Aug 4 14:30:19 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:19 2009 Subject: PS> FW: IETF moves on LDAP Printer schema Message-ID: <116DB56CD7DED511BC7800508B2CA53735D0DB@mailsrvnt02.enet.sharplabs.com> Hi folks, To my complete amazement, we just got lucky. The IETF assigned a new Area Director to shepherd our LDAP Printer scheme (Ted Hardie of Qualcomm) and he intends to move it forward for IETF four week 'last call' in the near future (for publication as a future Informational RFC). Apparently, sometimes pigs do fly!!! Cheers, - Ira McDonald, co-editor of LDAP Printer schema High North Inc -----Original Message----- From: McDonald, Ira Sent: Monday, August 04, 2003 2:25 PM To: 'hardie@qualcomm.com'; McDonald, Ira; 'Pat Fleming'; 'Harry Lewis'; 'Kurt@OpenLDAP.org' Subject: RE: Help with review of draft-fleming-ldap-printer-schema-02.txt Hi Ted, Wow! Thanks for your instant reply. I just sent a note to the RFC Editor and copied you and Kurt ASAP, so soon you will be able to schedule an IETF last call. Cheers, - Ira McDonald High North Inc -----Original Message----- From: hardie@qualcomm.com [mailto:hardie@qualcomm.com] Sent: Monday, August 04, 2003 1:59 PM To: McDonald, Ira; 'Pat Fleming'; 'Harry Lewis'; 'Kurt@OpenLDAP.org' Subject: Re: Help with review of draft-fleming-ldap-printer-schema-02.txt Hi, I would also like help moving this forward. As a first step, would you be willing for us to last call the document? This is not required for an informational document, but I believe that in this case the combination of technologies (and the time it has been on the plate) would make that prudent. If you are, please let the RFC Editor know that this will be moving from "Independent via RFC Editor" to "Independent, sponsored by AD"; I'll then mark the change in the tracker and issue a four week last call. Assuming no issues come up, we should be able to get it on the ballot after the last call. thanks, Ted Hardie At 10:44 AM -0700 8/4/03, McDonald, Ira wrote: >Hi Ted and Kurt, > >Pat Fleming and I revised this LDAP Printer schema document >in response to comments from Kurt and others in June 2002. >FYI - below is the release notice Pat Fleming and I sent when >we posted draft-02 last year. > >Patrik Faltstrom has never replied to any of our subsequent >notes. > >I found out in the IETF I-D Tracker that Ted is now our shepherd >and the docment remains in 'Expert Review' (since February 2002). > >Printer industry folks active in the IETF and the IEEE/ISTO >PWG (Printer Working Group) would very much like to get this >Informational RFC published. Two IEEE/ISTO PWGs protocols >now under development recommend support of this LDAP Printer >schema for service advertising. > >Any help moving this document forward would be greatly >appreciated. > >Cheers, >- Ira McDonald, co-editor of LDAP Printer schema > High North Inc > (consultant at Sharp Labs, Easy Software, and elsewhere) > imcdonald@sharplabs.com > >-------------------------------------------------------------- > > >Copies: IPP WG > SLP Discussion List > Pat Fleming > Ken Jones > Harry Lewis > Ira McDonald > >Hi folks, Sunday (30 June 2002) > >I've just sent a final version of 'LDAP Schema for Printer Services' to >the Internet-Drafts editor and posted a copy on the PWG server in the >directory 'ftp://ftp.pwg.org/pub/pwg/ipp/new_LDAP/' in the file: > > (June 2002) > >There have been a number of minor revisions, based on IESG 'last call' >comments. The document includes a change history appendix (to be >deleted before RFC publication - see below). > >The technical content is entirely unchanged from the previous version. > >As soon as this I-D is available in the IETF repository, we will request >that it be published as an Informational RFC. > >Cheers, >- Ira McDonald (co-editor of LDAP printer schema) > High North Inc > imcdonald@sharplabs.com > >------------------------------------------------------------------------ > >Copies: Internet Drafts Editor > Pat Fleming > Ira McDonald > >I-D Editor, Sunday (30 June 2002) > >Please place this document in the Internet-Drafts repository named: > > (June 2002) > >It replaces the previous: > > (February 2002) > >There have been a number of minor revisions, based on IESG 'last call' >comments. The document includes a change history appendix (to be >deleted before RFC publication). > >The technical content is entirely unchanged from the previous version. > >Abstract > > This document defines a schema, object classes and attributes, for > printers and printer services, for use with directories that support > Lightweight Directory Access Protocol v3 (LDAP-TS). This document is > based on the printer attributes listed in Appendix E of Internet > Printing Protocol/1.1 (IPP) (RFC 2911). A few additional printer > attributes are based on definitions in the Printer MIB (RFC 1759). > >Thanks very much, >- Ira McDonald (co-editor of LDAP printer schema) > High North Inc > imcdonald@sharplabs.com > >------------------------------------------------------------------------ > >[Excerpt from Change History] > > 30 June 2002 - draft-fleming-ldap-printer-schema-02.txt > - Final edits after IESG 'last call'; > - Revised title page and section 12 'Acknowledgments' to acknowledge > Ken Jones and Harry Lewis as major contributors (rather than as > current editors), per new RFC Editor policies; > - Rewrote and simplified Abstract and section 1 Introduction, per > comments from Kurt Zeilenga; > - Added section 1.1 'Rationale for using DirectoryString syntax', per > comments from Kurt Zeilenga; > - Added section 1.2 'Rationale for using caseIgnoreMatch', per > comments from Kurt Zeilenga; > - Added section 1.3 'Rationale for using caseIgnoreSubstringsMatch', > per comments from Kurt Zeilenga; > - Renamed section 2 to 'Terminology and Conventions' and added schema > definition format reference, per comments from Kurt Zeilenga; > - Revised section 3 and section 4 to remove (erroneous) guidance on > adding new attributes to existing classes and discussion of RDN for > auxiliary classes, per comments from Kurt Zeilenga and Ryan Moats; > - Revised section 4 'Definition of Attribute Types' to remove > (erroneous) guidance on support of matching rules, per comments > from Kurt Zeilenga; > - Revised section 4 'Definition of Attribute Types' to remove > normative/lengthy descriptions from the DESC clauses and place them > _below_ each formal attribute definition, per comments from Kurt > Zeilenga; > - Revised section 4 'Definition of Attribute Types', removing all > ORDERING clauses using 'caseIgnoreOrderingMatch', per comments from > Kurt Zeilenga; > - Revised sections 4.x printer-uri, printer-xri-supported, and > printer-more-info, to provide guidance on application handling of > malformed URI and reference new sections 1.1, 1.2, and 1.3, per > comments from Kurt Zeilenga; > - Revised section 6 'Definition of Matching Rules' to remove > (erroneous) guidance on support of matching rules, per comments > from Kurt Zeilenga; > - Revised section 7 'IANA Considerations' to include completed > templates for IANA registration of new object classes and attribute > types, defined in this document; > - Revised section 9 'Security Considerations' to reference RFC 2829 > (for authentication methods) and RFC 2830 (for TLS confidentiality > and integrity), per comments from Kurt Zeilenga; > - Revised (former) section 10 'References', to separate normative and > informative references, per comments from Kurt Zeilenga; > - Corrected author contact info. From alan.berkema at hp.com Mon Aug 4 14:47:06 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:19 2009 Subject: PS> [PSI] NEW TIME!!! Next Call 08/05/03 Message-ID: <0806DAA43B1555479D53B58675D346834583D8@xrose01.rose.hp.com> Hi all, Enough regulars agreed to make this one time change. Thanks Teleconference details: NEXT: Tuesday August 5 2003 (USA) Time: 9:00AM (US PDT) Until: 10:00AM Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Requirements Doc 2) New Spec Considerations and Conformance Sections 3) Suuccint List of Actions needed to go to next Last Call ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 9:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting number: 743057814 Meeting password: newpsi-1 Host: Alan Berkema 1(916)7855605 From imcdonald at sharplabs.com Mon Aug 4 15:27:25 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:19 2009 Subject: PS> FW: Help with review of draft-fleming-ldap-printer-schema-02.txt Message-ID: <116DB56CD7DED511BC7800508B2CA53735D0DD@mailsrvnt02.enet.sharplabs.com> Hi folks, I personally think we should award SOMETHING to Ted Hardie for being the most responsive IETF Area Director I've ever heard of. See below. Cheers, - Ira McDonald, co-editor of LDAP Printer schema High North Inc -----Original Message----- From: hardie@qualcomm.com [mailto:hardie@qualcomm.com] Sent: Monday, August 04, 2003 2:46 PM To: McDonald, Ira; 'Pat Fleming'; 'Harry Lewis'; 'Kurt@OpenLDAP.org' Subject: RE: Help with review of draft-fleming-ldap-printer-schema-02.txt I got the note, and I've updated the tracker and sent a request to the Secretariat for a last call. That should be a four week call (September 1 or 2). Thanks again for your help on moving this forward, regards, Ted Hardie At 11:24 AM -0700 8/4/03, McDonald, Ira wrote: >Hi Ted, > >Wow! Thanks for your instant reply. > >I just sent a note to the RFC Editor and copied you and Kurt >ASAP, so soon you will be able to schedule an IETF last call. > >Cheers, >- Ira McDonald > High North Inc > > >-----Original Message----- >From: hardie@qualcomm.com [mailto:hardie@qualcomm.com] >Sent: Monday, August 04, 2003 1:59 PM >To: McDonald, Ira; 'Pat Fleming'; 'Harry Lewis'; 'Kurt@OpenLDAP.org' >Subject: Re: Help with review of >draft-fleming-ldap-printer-schema-02.txt > > >Hi, > I would also like help moving this forward. As a first >step, would you be willing for us to last call the document? This >is not required for an informational document, but I believe >that in this case the combination of technologies (and the time >it has been on the plate) would make that prudent. If you >are, please let the RFC Editor know that this will be moving >from "Independent via RFC Editor" to "Independent, sponsored >by AD"; I'll then mark the change in the tracker and issue a >four week last call. Assuming no issues come up, we should >be able to get it on the ballot after the last call. > thanks, > Ted Hardie > > >At 10:44 AM -0700 8/4/03, McDonald, Ira wrote: >>Hi Ted and Kurt, >> >>Pat Fleming and I revised this LDAP Printer schema document >>in response to comments from Kurt and others in June 2002. >>FYI - below is the release notice Pat Fleming and I sent when >>we posted draft-02 last year. >> >>Patrik Faltstrom has never replied to any of our subsequent >>notes. >> >>I found out in the IETF I-D Tracker that Ted is now our shepherd >>and the docment remains in 'Expert Review' (since February 2002). >> >>Printer industry folks active in the IETF and the IEEE/ISTO >>PWG (Printer Working Group) would very much like to get this >>Informational RFC published. Two IEEE/ISTO PWGs protocols >>now under development recommend support of this LDAP Printer >>schema for service advertising. >> >>Any help moving this document forward would be greatly >>appreciated. >> >>Cheers, >>- Ira McDonald, co-editor of LDAP Printer schema >> High North Inc >> (consultant at Sharp Labs, Easy Software, and elsewhere) >> imcdonald@sharplabs.com >> >>-------------------------------------------------------------- >> >> >>Copies: IPP WG >> SLP Discussion List >> Pat Fleming >> Ken Jones >> Harry Lewis >> Ira McDonald >> >>Hi folks, Sunday (30 June 2002) >> >>I've just sent a final version of 'LDAP Schema for Printer Services' to >>the Internet-Drafts editor and posted a copy on the PWG server in the >>directory 'ftp://ftp.pwg.org/pub/pwg/ipp/new_LDAP/' in the file: >> >> (June 2002) >> >>There have been a number of minor revisions, based on IESG 'last call' >>comments. The document includes a change history appendix (to be >>deleted before RFC publication - see below). >> >>The technical content is entirely unchanged from the previous version. >> >>As soon as this I-D is available in the IETF repository, we will request >>that it be published as an Informational RFC. >> >>Cheers, >>- Ira McDonald (co-editor of LDAP printer schema) >> High North Inc >> imcdonald@sharplabs.com >> >>------------------------------------------------------------------------ >> >>Copies: Internet Drafts Editor >> Pat Fleming >> Ira McDonald > > >>I-D Editor, Sunday (30 June 2002) >> >>Please place this document in the Internet-Drafts repository named: >> >> (June 2002) >> >>It replaces the previous: >> >> (February 2002) >> >>There have been a number of minor revisions, based on IESG 'last call' >>comments. The document includes a change history appendix (to be >>deleted before RFC publication). >> >>The technical content is entirely unchanged from the previous version. >> >>Abstract >> >> This document defines a schema, object classes and attributes, for >> printers and printer services, for use with directories that support >> Lightweight Directory Access Protocol v3 (LDAP-TS). This document is >> based on the printer attributes listed in Appendix E of Internet >> Printing Protocol/1.1 (IPP) (RFC 2911). A few additional printer >> attributes are based on definitions in the Printer MIB (RFC 1759). >> >>Thanks very much, >>- Ira McDonald (co-editor of LDAP printer schema) >> High North Inc >> imcdonald@sharplabs.com >> >>------------------------------------------------------------------------ >> >>[Excerpt from Change History] >> >> 30 June 2002 - draft-fleming-ldap-printer-schema-02.txt >> - Final edits after IESG 'last call'; >> - Revised title page and section 12 'Acknowledgments' to acknowledge >> Ken Jones and Harry Lewis as major contributors (rather than as >> current editors), per new RFC Editor policies; >> - Rewrote and simplified Abstract and section 1 Introduction, per >> comments from Kurt Zeilenga; >> - Added section 1.1 'Rationale for using DirectoryString syntax', per >> comments from Kurt Zeilenga; >> - Added section 1.2 'Rationale for using caseIgnoreMatch', per >> comments from Kurt Zeilenga; >> - Added section 1.3 'Rationale for using caseIgnoreSubstringsMatch', >> per comments from Kurt Zeilenga; >> - Renamed section 2 to 'Terminology and Conventions' and added schema >> definition format reference, per comments from Kurt Zeilenga; >> - Revised section 3 and section 4 to remove (erroneous) guidance on >> adding new attributes to existing classes and discussion of RDN for >> auxiliary classes, per comments from Kurt Zeilenga and Ryan Moats; >> - Revised section 4 'Definition of Attribute Types' to remove >> (erroneous) guidance on support of matching rules, per comments >> from Kurt Zeilenga; >> - Revised section 4 'Definition of Attribute Types' to remove >> normative/lengthy descriptions from the DESC clauses and place them >> _below_ each formal attribute definition, per comments from Kurt >> Zeilenga; >> - Revised section 4 'Definition of Attribute Types', removing all >> ORDERING clauses using 'caseIgnoreOrderingMatch', per comments from >> Kurt Zeilenga; >> - Revised sections 4.x printer-uri, printer-xri-supported, and >> printer-more-info, to provide guidance on application handling of >> malformed URI and reference new sections 1.1, 1.2, and 1.3, per >> comments from Kurt Zeilenga; >> - Revised section 6 'Definition of Matching Rules' to remove >> (erroneous) guidance on support of matching rules, per comments >> from Kurt Zeilenga; >> - Revised section 7 'IANA Considerations' to include completed >> templates for IANA registration of new object classes and attribute >> types, defined in this document; >> - Revised section 9 'Security Considerations' to reference RFC 2829 >> (for authentication methods) and RFC 2830 (for TLS confidentiality >> and integrity), per comments from Kurt Zeilenga; >> - Revised (former) section 10 'References', to separate normative and >> informative references, per comments from Kurt Zeilenga; >> - Corrected author contact info. From alan.berkema at hp.com Tue Aug 5 18:32:36 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:19 2009 Subject: PS> [PSI] Next Call 08/19/03 Message-ID: <0806DAA43B1555479D53B58675D346834583DD@xrose01.rose.hp.com> NO CALL 08/12/2003 Interop Date Teleconference details: NEXT: Tuesday August 19 2003 (USA) NOTE: 2 hours Time: 8:00AM (US PDT) Until: 10:00AM Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Requirements Doc 2) Spec Review 3) Suuccint List of Actions needed to go to next Last Call ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 9:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting number: 743057814 Meeting password: newpsi-1 Host: Alan Berkema 1(916)7855605 From imcdonald at sharplabs.com Wed Aug 6 14:41:18 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:19 2009 Subject: PS> Enhance version of Use Model 1 diagram Message-ID: <116DB56CD7DED511BC7800508B2CA537B00143@mailsrvnt02.enet.sharplabs.com> Hi Alan and Dave, Below is a simple ASCII-art enhancement of Use Model 1 diagram, showing the actual network technologies and connectivity, so that we can address concrete security threats. Comments? Cheers, - Ira McDonald High North Inc -------------------------- Use Model 1 ------------- ------------- | | ! | | Print |<---------------(5)----------------! Content | | Service | ! Provider | | (PS) | ! | ------------- ------------- E ^ ^ | ADSL Modem T1 Circuit | n | | | ISP ( ------ ) ISP | e | | | ( ) | t(3) (4) (6) ( INTERNET ) (0) L | | | ( ) | A | | | ( ------ ) GSM Cellular | N v v v Wireless ISP v ------------- ------------- | | ! | | Target |<---------------(1)----------------! Mobile | | Device | Bluetooth PAN ! Device | | (Printer) |<---------------(2)----------------! | ------------- ------------- (PSI Client) Data Flows: (0) Browse - Public Internet browse for content URL (1) Discovery - Bluetooth discovery (2) Reference - Bluetooth print-by-reference of content URL (3) C2S - Ethernet LAN PSI print job (4) T2S - Ethernet LAN PSI print job (5) Content - Public Internet fetch of content URL (6) Formatted Data - Ethernet LAN PSI print job From imcdonald at sharplabs.com Tue Aug 19 11:10:56 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:19 2009 Subject: PS> [Hey where's Alan and Dave? ] Next Call 08/19/03 Message-ID: <116DB56CD7DED511BC7800508B2CA537B00166@mailsrvnt02.enet.sharplabs.com> Hi, It's now ten minutes past the hour and I'm still getting "waiting music" on the PSI telecon. _are_ we meeting today? Cheers, - Ira -----Original Message----- From: BERKEMA,ALAN C (HP-Roseville,ex1) [mailto:alan.berkema@hp.com] Sent: Tuesday, August 05, 2003 6:33 PM To: 'a PSI pwg.org' Subject: PS> [PSI] Next Call 08/19/03 NO CALL 08/12/2003 Interop Date Teleconference details: NEXT: Tuesday August 19 2003 (USA) NOTE: 2 hours Time: 8:00AM (US PDT) Until: 10:00AM Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Requirements Doc 2) Spec Review 3) Suuccint List of Actions needed to go to next Last Call ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 9:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting number: 743057814 Meeting password: newpsi-1 Host: Alan Berkema 1(916)7855605 From alan.berkema at hp.com Mon Aug 25 12:48:08 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:19 2009 Subject: PS> [PSI] Next Call 08/26/03 Message-ID: <0806DAA43B1555479D53B58675D3468345841C@xrose01.rose.hp.com> Teleconference details: NEXT: Tuesday August 26 2003 (USA) NO Call 9/2/2003 (Day after Labor day) Time: 8:00AM (US PDT) Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Requirements Doc 2) Spec Review 3) Succinct List of Actions needed to go to next Last Call ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 9:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting number: 743057814 Meeting password: newpsi-1 Host: Alan Berkema 1(916)7855605 From alan.berkema at hp.com Mon Aug 25 13:14:42 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:19 2009 Subject: PS> [PSI] Diagrams for Next Call 08/26/03 Message-ID: <0806DAA43B1555479D53B58675D3468345841E@xrose01.rose.hp.com> Teleconference details: NEXT: Tuesday August 26 2003 (USA) NO Call 9/2/2003 (Day after Labor day) Time: 8:00AM (US PDT) Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Requirements Doc 2) Spec Review 3) Succinct List of Actions needed to go to next Last Call ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 9:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting number: 743057814 Meeting password: newpsi-1 Host: Alan Berkema 1(916)7855605 -------------- next part -------------- A non-text attachment was scrubbed... Name: psi reqs figs 2.pdf Type: application/octet-stream Size: 62715 bytes Desc: not available Url : http://www.pwg.org/archives/ps/attachments/20030825/4df6685c/psireqsfigs2-0001.obj From imcdonald at sharplabs.com Tue Aug 26 14:19:36 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:19 2009 Subject: PS> PSI conformance requirements draft Message-ID: <116DB56CD7DED511BC7800508B2CA537B0017E@mailsrvnt02.enet.sharplabs.com> Hi folks, Tuesday (26 August 2003) Below is a first draft of section 10 "Conformance" for the PSI Spec, per my action item at today's PSI telecon. PLEASE send comments and corrections ASAP. We need to get a completed draft of the PSI spec out by 19 September, for review at the PWG face-to-face in New York in early October. Cheers, - Ira McDonald High North Inc ----------------------------------------------- 10. Conformance This section specifies the conformance requirements (necessary for basic interoperability) and conformance recommendations (useful for improved interoperability) for all implementations of the PSI/1.0 protocol. 10.1 PSI/1.0 Common Conformance The following common conformance REQUIREMENTS apply to every PSI/1.0 implementation (Client, Print Service, or Target Device). Every PSI/1.0 implementation: (1) MUST publish the role-independent checklist of conformance claims, in product installation and product packaging literature, as defined in this section 10.1; (2) MUST publish the role-specific checklist of conformance claims, in product installation and product packaging literature, as defined in applicable sections 10.2, 10.3, and/or 10.4 below; (3) MUST support [SOAP1.1] and [WSDL1.1]; (4) MUST support the [HTTP/1.1] binding of [SOAP/1.1]; (5) MUST support the Printer Object and all mandatory elements as defined in section 7.1; (6) MUST support the Job Object and all mandatory elements as defined in section 7.2; (7) MUST support the Document Object and all mandatory elements as defined in section 7.3; (8) MUST support pwg-psips and pwg-psitd URL schemes for Target Devices, as defined in section 8.2.4; (9) MUST support the http URL scheme for References, as defined in section 8.3.1. The following common conformance RECOMMENDATIONS apply to every PSI/1.0 implementation (Client, Print Service, or Target Device). Every PSI/1.0 implementation: (1) SHOULD support [SOAP1.2] and [WSDL1.2]; (2) SHOULD support non-HTTP bindings of [SOAP1.1] or later SOAP versions; (3) SHOULD support device discovery via the PSI Service Root URL as defined in section 5.1; (4) SHOULD support device discovery for specific supported environments, for example using [SLP2.0]; (5) SHOULD support secure sessions over [TLS1.0] or later TLS versions, as defined in section 5.2; (6) SHOULD support the ipp URL scheme for Target Devices, as defined in section 8.2.5; (7) SHOULD support the ftp URL scheme for References, as defined in section 8.3.2. 10.2 PSI/1.0 Client Conformance The following conformance REQUIREMENTS apply to a PSI/1.0 Client. Every PSI/1.0 Client implementation: (1) MUST support the client role in the QueryEndPointsInterface, for access to PSI/1.0 Print Services and PSI/1.0 Target Devices, as defined in section 5.3; (2) MUST support the client role in the ServiceCapabilitesInterface, for access to PSI/1.0 Print Services and PSI/1.0 Target Devices, as defined in section 5.4; (3) MUST support the client role in the JobControlInterface, for access to PSI/1.0 Print Services and PSI/1.0 Target Devices, as defined in section 5.5. 10.3 PSI/1.0 Print Service Conformance The following conformance REQUIREMENTS apply to a PSI/1.0 Print Service. Every PSI/1.0 Print Service implementation: (1) MUST support the client role in the QueryEndPointsInterface, for access to PSI/1.0 Print Services and PSI/1.0 Target Devices, as defined in section 5.3; (2) MUST support the client role in the ServiceCapabilitesInterface, for access to PSI/1.0 Print Services and PSI/1.0 Target Devices, as defined in section 5.4; (3) MUST support the client role in the JobControlInterface, for access to PSI/1.0 Print Services and PSI/1.0 Target Devices, as defined in section 5.5; (4) MUST support the server role in the QueryEndPointsInterface, for access from PSI/1.0 Clients and PSI/1.0 Target Devices, as defined in section 5.3; (5) MUST support the server role in the ServiceCapabilitesInterface, for access from PSI/1.0 Clients and PSI/1.0 Target Devices, as defined in section 5.4; (6) MUST support the server role in the JobControlInterface, for access from PSI/1.0 Clients and PSI/1.0 Target Devices, as defined in section 5.5; (7) MUST support the server role in the TargetDeviceSupportInterface, for access from PSI/1.0 Target Devices, as defined in section 5.6. 10.4 PSI/1.0 Target Device Conformance The following conformance REQUIREMENTS apply to a PSI/1.0 Target Device. Every PSI/1.0 Target Device implementation: (1) MUST support the client role in the QueryEndPointsInterface, for access to PSI/1.0 Print Services, as defined in section 5.3; (2) MUST support the client role in the ServiceCapabilitesInterface, for access to PSI/1.0 Print Services, as defined in section 5.4; (3) MUST support the client role in the JobControlInterface, for access to PSI/1.0 Print Services, as defined in section 5.5; (4) MUST support the server role in the QueryEndPointsInterface, for access from PSI/1.0 Clients and PSI/1.0 Print Services, as defined in section 5.3; (5) MUST support the server role in the ServiceCapabilitesInterface, for access from PSI/1.0 Clients and PSI/1.0 Print Services, as defined in section 5.4; (6) MUST support the server role in the JobControlInterface, for access from PSI/1.0 Clients and PSI/1.0 Print Services, as defined in section 5.5; (7) MUST support the client role in the TargetDeviceSupportInterface, for access to PSI/1.0 Print Services, as defined in section 5.6. From alan.berkema at hp.com Tue Aug 26 16:17:39 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:19 2009 Subject: PS> [PSI] Next Call 09/09/03 Message-ID: <0806DAA43B1555479D53B58675D3468345842D@xrose01.rose.hp.com> Teleconference details: NEXT: Tuesday Septemebr 9 2003 (USA) NO Call 09/02/2003 (Day after Labor day) Time: 8:00AM (US PDT) Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Review Requirements Doc Changes ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting number: 743057814 Meeting password: newpsi-1 Host: Alan Berkema 1(916)7855605 From alan.berkema at hp.com Tue Aug 26 16:34:28 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:19 2009 Subject: PS> [PSI]: Schedule & Actions from Mtg. 8/26/03 Message-ID: <0806DAA43B1555479D53B58675D3468345842E@xrose01.rose.hp.com> PSI Working Group: *Alan Berkema *Dave Hall *Ira McDonald *Jerry Thrasher *Harry Lewis Ted Tronson Peter Mierau *Peter Zehler Gail Songer Paul Tykodi Bob Taylor Lee Farrell Don Wright * = attendance 08/26/03 Agenda 1) Review updated Use Model Diagrams 2) Schedule & Actions Minutes: 1) Review updated Use Model Diagrams Only a few minor changes to the Use Model Diagram which will appear in the next version of the PSI MRD doc. 2) Schedule & Actions 08/26/03 - Ira e-mail conformance requirements draft 09/05/03 - Alan distribute updated PSI MRD 09/09/03 - Discuss reviewer comments of updated PSI MRD 09/09/03 - Discuss reviewer comments of conformance requirements draft 09/12/03 - Dave distribute updated PSI spec. 09/16/03 - Discuss reviewer comments of updated PSI spec. 09/19/03 - Incorporate reviewer comments and Last Call candidate PSI MRD 09/19/03 - Incorporate reviewer comments and Last Call candidate PSI spec. 10/07/03 - F2F review of PSI spec and MRD 10/17/03 - Post F2F reviewed PSI spec and MRD for 10 day Last Call Thanks, Alan From imcdonald at sharplabs.com Tue Aug 26 18:18:54 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:19 2009 Subject: PS> Reminder about PSI Reqs filename Message-ID: <116DB56CD7DED511BC7800508B2CA537B00181@mailsrvnt02.enet.sharplabs.com> Hi Alan, A reminder. Please name the file containing your upcoming PSI Requirements draft as follows: wd-psireq10-200309xx.pdf/doc The adopted document will eventually be published (according to Process/2.0): req-psireq10-2003yyxx.pdf/doc Cheers, - Ira McDonald High North Inc From imcdonald at sharplabs.com Tue Aug 26 18:59:19 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:19 2009 Subject: PS> W3C drafts - Web Svcs Architecture and Glossary Message-ID: <116DB56CD7DED511BC7800508B2CA537B00182@mailsrvnt02.enet.sharplabs.com> Hi folks, Both of these documents are very well worth reading: http://www.w3.org/TR/2003/WD-ws-arch-20030808/ http://www.w3.org/TR/2003/WD-ws-gloss-20030808/ The glossary contains good definitions of a number of useful terms (Dave Hall and Alan Berkema, take note). Cheers, - Ira McDonald High North Inc From alan.berkema at hp.com Fri Sep 5 14:41:40 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:19 2009 Subject: PS> [PSI]: New MRD Message-ID: <0806DAA43B1555479D53B58675D3468345848D@xrose01.rose.hp.com> Here is my action for Tuesday, Sorry I do not have time to post. Alan <> -------------- next part -------------- A non-text attachment was scrubbed... Name: wd-psireq10-200309xx.pdf Type: application/octet-stream Size: 182224 bytes Desc: not available Url : http://www.pwg.org/archives/ps/attachments/20030905/23cce3f8/wd-psireq10-200309xx-0001.obj From imcdonald at sharplabs.com Sun Sep 7 19:37:43 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:19 2009 Subject: PS> [PSI]: [Posted] New MRD Message-ID: <116DB56CD7DED511BC7800508B2CA537B00196@mailsrvnt02.enet.sharplabs.com> Hi, New PSI Requirements spec posted at: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psireq10-200309xx.pdf Cheers, - Ira McDonald High North Inc -----Original Message----- From: BERKEMA,ALAN C (HP-Roseville,ex1) [mailto:alan.berkema@hp.com] Sent: Friday, September 05, 2003 2:42 PM To: 'a PSI pwg.org' Subject: PS> [PSI]: New MRD Here is my action for Tuesday, Sorry I do not have time to post. Alan <> From imcdonald at sharplabs.com Mon Sep 8 21:08:02 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:19 2009 Subject: PS> FW: draft-black-snmp-uri-00.txt Message-ID: <116DB56CD7DED511BC7800508B2CA537B00199@mailsrvnt02.enet.sharplabs.com> Hi folks, FYI - a new SNMP URI scheme draft - worth looking at: ftp://ftp.ietf.org/internet-drafts/draft-black-snmp-uri-00.txt Cheers, - Ira McDonald High North Inc -----Original Message----- From: Paul Hoffman / IMC [mailto:phoffman@imc.org] Sent: Monday, September 08, 2003 2:44 PM To: uri@w3.org Subject: draft-black-snmp-uri-00.txt There's a new URI document, draft-black-snmp-uri-00.txt, which discusses a URI for the SNMP protocol. The author of the draft is on this list but apparently unable to post. He's open for comments. --Paul Hoffman, Director --Internet Mail Consortium From imcdonald at sharplabs.com Tue Sep 9 11:00:28 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:19 2009 Subject: PS> FW: Latest PSI Specifiecation Message-ID: <116DB56CD7DED511BC7800508B2CA537B0019D@mailsrvnt02.enet.sharplabs.com> Hi, Posted in ZIP only (doc and pdf to follow) due to time constraints: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030729.zip Cheers, - Ira -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Tuesday, September 09, 2003 10:50 AM To: 'McDonald, Ira' Subject: FW: Latest PSI Specifiecation Don't know if this made it through the reflector.. Dave -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) Sent: Tuesday, September 09, 2003 7:37 AM To: 'ps@pwg.org' Subject: Latest PSI Specifiecation Sorry for the late update - Here is the latest (as of 07/29!! - Has it been that long already?) Dave From harryl at us.ibm.com Tue Sep 9 12:42:47 2003 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:02:19 2009 Subject: PS> Mandatory binding Message-ID: During today's conference call the topic of a mandatory binding came up. We would prefer to publish the interface and binding WSDL separately and define a discovery method. We're not sure if UDDI is too coarse a discovery method for this purpose. ---------------------------------------------- Harry Lewis Chairman - IEEE-ISTO Printer Working Group http://www.pwg.org IBM Printing Systems http://www.ibm.com/printers 303-924-5337 ---------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/ps/attachments/20030909/dc844444/attachment-0001.html From imcdonald at sharplabs.com Tue Sep 9 13:59:03 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:19 2009 Subject: PS> Posted latest PSI Specification (20030729) Message-ID: <116DB56CD7DED511BC7800508B2CA537B0019E@mailsrvnt02.enet.sharplabs.com> Hi, Now available on the FTP site at: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030729.pdf (PDF without revision marks) ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030729.doc (MS Word source but READ-ONLY copy from ZIP file) (Note that the file dates are today (20030909), but this is Dave's end-of-July most recent text). Cheers, - Ira McDonald High North Inc -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Tuesday, September 09, 2003 11:00 AM To: 'ps@pwg.org' Subject: PS> FW: Latest PSI Specifiecation Hi, Posted in ZIP only (doc and pdf to follow) due to time constraints: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030729.zip Cheers, - Ira -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Tuesday, September 09, 2003 10:50 AM To: 'McDonald, Ira' Subject: FW: Latest PSI Specifiecation Don't know if this made it through the reflector.. Dave -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) Sent: Tuesday, September 09, 2003 7:37 AM To: 'ps@pwg.org' Subject: Latest PSI Specifiecation Sorry for the late update - Here is the latest (as of 07/29!! - Has it been that long already?) Dave From imcdonald at sharplabs.com Tue Sep 9 14:11:38 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:19 2009 Subject: PS> Revised PSI conformance requirements draft (9 Sept) Message-ID: <116DB56CD7DED511BC7800508B2CA537B0019F@mailsrvnt02.enet.sharplabs.com> Hi folks, Tuesday (9 September 2003) Below is a second draft of section 10 "Conformance" for the PSI Spec, revised after our partial review at today's PSI telecon. Dave Hall now plans to get a completed draft of the PSI spec out by 26 September, for review at the PWG face-to-face in New York on 7 October. Changes to section 10.1 from first draft (26 August): (1) Added new sentence to first paragraph (about documentation); (2) Moved the first two requirements (documentation) in section 10.1 to a new paragraph for product literature recommendations; (3) Added new requirements and recommendations for XML and WSDL; (4) Added three new 'Rationale' paragraphs to section 10.1 (explaining the choices of requirement versus recommandation); (5) Rewrote several requirements and recommendations for clarity. Comments? Cheers, - Ira McDonald High North Inc ----------------------------------------------- 10. Conformance This section specifies the conformance requirements (necessary for basic interoperability) and conformance recommendations (useful for improved interoperability) for all implementations of the PSI/1.0 protocol. This section also specifies the conformance recommentations for PSI product literature (useful for informed customer purchasing decisions). 10.1 PSI/1.0 Common Conformance The following common conformance REQUIREMENTS apply to every PSI/1.0 implementation (Client, Print Service, or Target Device). Every PSI/1.0 implementation: (1) MUST support (produce and consume) valid [XML1.0] documents; (2) MUST support (publish URLs for) valid [WSDL1.1] interfaces; (3) MUST support (produce and consume) valid [SOAP1.1] messages; (4) MUST support the [HTTP/1.1] binding of [SOAP/1.1]; (5) MUST support the Printer Object and all mandatory elements, as defined in section 7.1; (6) MUST support the Job Object and all mandatory elements, as defined in section 7.2; (7) MUST support the Document Object and all mandatory elements, as defined in section 7.3; (8) MUST support pwg-psips and pwg-psitd URL schemes for Target Devices, as defined in section 8.2.4; (9) MUST support the http URL scheme for References, as defined in section 8.3.1. Rationale: Customers should be able to purchase PSI-based products with basic interoperability guaranteed for those PSI products. The following common conformance RECOMMENDATIONS apply to every PSI/1.0 implementation (Client, Print Service, or Target Device). Every PSI/1.0 implementation: (1) SHOULD support [XML1.1] or later XML versions; (2) SHOULD support [WSDL1.2] or later WSDL versions; (3) SHOULD support [SOAP1.2] or later SOAP versions; (4) SHOULD support non-HTTP bindings of [SOAP1.1] or later SOAP versions; (5) SHOULD support device discovery via the PSI Service Root URL as defined in section 5.1; (6) SHOULD support device discovery for specific supported environments, for example using [SLP2.0]; (7) SHOULD support secure sessions over [TLS1.0] or later TLS versions, as defined in section 5.2; (8) SHOULD support the ipp URL scheme for Target Devices, as defined in section 8.2.5; (9) SHOULD support the ftp URL scheme for References, as defined in section 8.3.2. Rationale: Customers should be able to purchase PSI-based products with improved interoperability probable for those PSI products. The following common conformance RECOMMENDATIONS apply to product literature. All products that claim PSI/1.0 conformance: (1) SHOULD publish the role-independent checklist of conformance claims, as defined in applicable paragraphs of this section 10.1 above, in installation, packaging, or other literature (e.g., Web pages); (2) SHOULD publish the role-specific checklist of conformance claims, as defined in applicable sections 10.2, 10.3, and/or 10.4 below, in installation, packaging, or other literature (e.g., Web pages). Rationale: Customers should be able to purchase PSI-based products with specific interoperability verified for those PSI products. 10.2 PSI/1.0 Client Conformance The following conformance REQUIREMENTS apply to a PSI/1.0 Client. Every PSI/1.0 Client implementation: (1) MUST support the client role in the QueryEndPointsInterface, for access to PSI/1.0 Print Services and PSI/1.0 Target Devices, as defined in section 5.3; (2) MUST support the client role in the ServiceCapabilitesInterface, for access to PSI/1.0 Print Services and PSI/1.0 Target Devices, as defined in section 5.4; (3) MUST support the client role in the JobControlInterface, for access to PSI/1.0 Print Services and PSI/1.0 Target Devices, as defined in section 5.5. 10.3 PSI/1.0 Print Service Conformance The following conformance REQUIREMENTS apply to a PSI/1.0 Print Service. Every PSI/1.0 Print Service implementation: (1) MUST support the client role in the QueryEndPointsInterface, for access to PSI/1.0 Print Services and PSI/1.0 Target Devices, as defined in section 5.3; (2) MUST support the client role in the ServiceCapabilitesInterface, for access to PSI/1.0 Print Services and PSI/1.0 Target Devices, as defined in section 5.4; (3) MUST support the client role in the JobControlInterface, for access to PSI/1.0 Print Services and PSI/1.0 Target Devices, as defined in section 5.5; (4) MUST support the server role in the QueryEndPointsInterface, for access from PSI/1.0 Clients and PSI/1.0 Target Devices, as defined in section 5.3; (5) MUST support the server role in the ServiceCapabilitesInterface, for access from PSI/1.0 Clients and PSI/1.0 Target Devices, as defined in section 5.4; (6) MUST support the server role in the JobControlInterface, for access from PSI/1.0 Clients and PSI/1.0 Target Devices, as defined in section 5.5; (7) MUST support the server role in the TargetDeviceSupportInterface, for access from PSI/1.0 Target Devices, as defined in section 5.6. 10.4 PSI/1.0 Target Device Conformance The following conformance REQUIREMENTS apply to a PSI/1.0 Target Device. Every PSI/1.0 Target Device implementation: (1) MUST support the client role in the QueryEndPointsInterface, for access to PSI/1.0 Print Services, as defined in section 5.3; (2) MUST support the client role in the ServiceCapabilitesInterface, for access to PSI/1.0 Print Services, as defined in section 5.4; (3) MUST support the client role in the JobControlInterface, for access to PSI/1.0 Print Services, as defined in section 5.5; (4) MUST support the server role in the QueryEndPointsInterface, for access from PSI/1.0 Clients and PSI/1.0 Print Services, as defined in section 5.3; (5) MUST support the server role in the ServiceCapabilitesInterface, for access from PSI/1.0 Clients and PSI/1.0 Print Services, as defined in section 5.4; (6) MUST support the server role in the JobControlInterface, for access from PSI/1.0 Clients and PSI/1.0 Print Services, as defined in section 5.5; (7) MUST support the client role in the TargetDeviceSupportInterface, for access to PSI/1.0 Print Services, as defined in section 5.6. From imcdonald at sharplabs.com Tue Sep 9 14:41:36 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:19 2009 Subject: PS> Mandatory binding Message-ID: <116DB56CD7DED511BC7800508B2CA537B001A2@mailsrvnt02.enet.sharplabs.com> Hi, To clarify a little... PSI conformance print services and target devices MUST publish URLs for the WSDL for each of their supported interfaces (see my revised conformance requirements message earlier today). Tools exist that convert WSDL to appropriate SOAP messages. A "SOAP binding" is a definition of SOAP message _transport_ over HTTP, SMTP, BEEP, or whatever (those three are currently standardized). For interoperability, clients and servers need to be able to consume and validate published WSDL definitions of other PSI servers. For interoperability, all PSI/1.0 clients and servers MUST support the HTTP/1.1 transport binding of SOAP/1.1. Separately, PSI/1.0 doesn't (yet) require support for UDDI based discovery. I question the desirability of adding a UDDI infrastructure dependence to all PSI/1.0 implementations. Cheers, - Ira McDonald High North Inc -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, September 09, 2003 12:43 PM To: ps@pwg.org Subject: PS> Mandatory binding During today's conference call the topic of a mandatory binding came up. We would prefer to publish the interface and binding WSDL separately and define a discovery method. We're not sure if UDDI is too coarse a discovery method for this purpose. ---------------------------------------------- Harry Lewis Chairman - IEEE-ISTO Printer Working Group http://www.pwg.org IBM Printing Systems http://www.ibm.com/printers 303-924-5337 ---------------------------------------------- From harryl at us.ibm.com Tue Sep 9 14:49:22 2003 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:02:19 2009 Subject: PS> Mandatory binding In-Reply-To: <116DB56CD7DED511BC7800508B2CA537B001A2@mailsrvnt02.enet.sharplabs.com> Message-ID: I guess we're saying it is not really necessary for interoperability that all PSI/1.0 clients and servers MUST support the HTTP/1.1 transport binding when the WSDL can call out the binding. ---------------------------------------------- Harry Lewis Chairman - IEEE-ISTO Printer Working Group http://www.pwg.org IBM Printing Systems http://www.ibm.com/printers 303-924-5337 ---------------------------------------------- "McDonald, Ira" 09/09/2003 12:41 PM To Harry Lewis/Boulder/IBM@IBMUS, ps@pwg.org cc Subject RE: PS> Mandatory binding Hi, To clarify a little... PSI conformance print services and target devices MUST publish URLs for the WSDL for each of their supported interfaces (see my revised conformance requirements message earlier today). Tools exist that convert WSDL to appropriate SOAP messages. A "SOAP binding" is a definition of SOAP message _transport_ over HTTP, SMTP, BEEP, or whatever (those three are currently standardized). For interoperability, clients and servers need to be able to consume and validate published WSDL definitions of other PSI servers. For interoperability, all PSI/1.0 clients and servers MUST support the HTTP/1.1 transport binding of SOAP/1.1. Separately, PSI/1.0 doesn't (yet) require support for UDDI based discovery. I question the desirability of adding a UDDI infrastructure dependence to all PSI/1.0 implementations. Cheers, - Ira McDonald High North Inc -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, September 09, 2003 12:43 PM To: ps@pwg.org Subject: PS> Mandatory binding During today's conference call the topic of a mandatory binding came up. We would prefer to publish the interface and binding WSDL separately and define a discovery method. We're not sure if UDDI is too coarse a discovery method for this purpose. ---------------------------------------------- Harry Lewis Chairman - IEEE-ISTO Printer Working Group http://www.pwg.org IBM Printing Systems http://www.ibm.com/printers 303-924-5337 ---------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/ps/attachments/20030909/b896deec/attachment-0001.html From imcdonald at sharplabs.com Mon Sep 15 19:55:42 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:19 2009 Subject: PS> PSI call on Tues 16 Sept?? Message-ID: <116DB56CD7DED511BC7800508B2CA537B001B0@mailsrvnt02.enet.sharplabs.com> Hi, My notes didn't capture this. Is there a PSI telecon tomorrow? I believe the answer is yes. Agenda: (a) continue to review revised PSI section 10 Conformance Requirements that I sent out last Tuesday (9 Sept); (b) review Alan's updated MRD. Right? Cheers, - Ira McDonald High North Inc From alan.berkema at hp.com Tue Sep 16 10:38:38 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:19 2009 Subject: PS> [PSI] Next Call 09/16/03 Message-ID: <0806DAA43B1555479D53B58675D346834584D5@xrose01.rose.hp.com> Teleconference details: NEXT: Tuesday Septemebr 16 2003 (USA) Time: 8:00AM (US PDT) Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Review Requirements Doc Changes ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting number: 743057814 Meeting password: newpsi-1 Host: Alan Berkema 1(916)7855605 From alan.berkema at hp.com Tue Sep 16 10:49:16 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:19 2009 Subject: PS> PSI call on Tues 16 Sept?? Message-ID: <0806DAA43B1555479D53B58675D346834584D7@xrose01.rose.hp.com> Yes, just sent out same numbers, thought I did this before? Your agenda is works for me. Alan -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Monday, September 15, 2003 4:56 PM To: 'ps@pwg.org' Subject: PS> PSI call on Tues 16 Sept?? Hi, My notes didn't capture this. Is there a PSI telecon tomorrow? I believe the answer is yes. Agenda: (a) continue to review revised PSI section 10 Conformance Requirements that I sent out last Tuesday (9 Sept); (b) review Alan's updated MRD. Right? Cheers, - Ira McDonald High North Inc From alan.berkema at hp.com Tue Sep 16 12:45:25 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:19 2009 Subject: PS> [PSI] New Day / New Time : Next Call 09/22/03 Message-ID: <0806DAA43B1555479D53B58675D346834584D9@xrose01.rose.hp.com> One Time Change: Teleconference details: NEXT: Monday Septemebr 22 2003 (USA) NO Call 9/30/03 Date before F2F Time: 9:00AM (US PDT) Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Review Conformance Specs (see Ira's e-mail) 2) Review Requirements Doc Changes especially section 5 & 6 ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting number: 743057814 Meeting password: newpsi-1 Host: Alan Berkema 1(916)7855605 From imcdonald at sharplabs.com Mon Sep 22 11:21:06 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:19 2009 Subject: PS> [PSI] Mon 22 Sept - New Day / New Time ONCE Message-ID: <116DB56CD7DED511BC7800508B2CA537B001BD@mailsrvnt02.enet.sharplabs.com> Hi, Just a reminder that this week's PSI telecon is in 40 minutes today! Cheers, - Ira -----Original Message----- From: BERKEMA,ALAN C (HP-Roseville,ex1) [mailto:alan.berkema@hp.com] Sent: Tuesday, September 16, 2003 12:45 PM To: 'a PSI pwg.org' Subject: PS> [PSI] Mon 22 Sept - New Day / New Time ONCE One Time Change: Teleconference details: NEXT: Monday Septemebr 22 2003 (USA) NO Call 9/30/03 Date before F2F Time: 9:00AM (US PDT) Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Review Conformance Specs (see Ira's e-mail) 2) Review Requirements Doc Changes especially section 5 & 6 ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting number: 743057814 Meeting password: newpsi-1 Host: Alan Berkema 1(916)7855605 From imcdonald at sharplabs.com Mon Sep 22 15:08:48 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:19 2009 Subject: PS> Section 10 Conformance - final draft (22 Sept) Message-ID: <116DB56CD7DED511BC7800508B2CA537B001BE@mailsrvnt02.enet.sharplabs.com> Hi folks, Monday (22 September 2003) Below is a third draft of section 10 "Conformance", revised per our review at today's PSI telecon, to be folded into the PSI Spec. Dave Hall now plans to get a completed draft of the PSI spec out by 26 September, for review at the PWG face-to-face in New York on Tuesday (7 October). We plan to have _all_day_ dial-in to the PSI face-to-face. Dave - the issues are labelled 'ISSUE[01/02/03]' - please fixup numbers. Dave - MOST conformance requirements/recommendations in all other spec sections (like 5.x) should probably be DELETED - so that the conformance is specified in accurate detail in sections 10.x only. Comments? Cheers, - Ira McDonald High North Inc ----------------------------------------------- Changes for third draft (22 Sept) from second draft (9 Sept): (1) Divided section 10.1 into 10.1.1, 10.1.2, 10.1.3, for clarity; (2) Added two issues to section 10.1.1 about pwg-psixx and http URLs; (3) Removed reference to WSDL/1.2 from section 10.1.2 item(2), per Jerry Thrasher comment that the next WSDL version may in fact be 2.0; (4) Moved former section 10.1.2 item (5) (PSI Service Root URL) and divided into sections 10.2, 10.3, 10.4, per PSI telecon concensus; (5) Reworded current section 10.1.2 item (5) (specific device discovery) to replace reference to SLP/2.0 with "Windows, Netware...". (6) Divided section 10.2 into 10.2.1 and 10.2.2, for clarity; (7) Moved former section 10.2 items (1) and (2) to section 10.2.2, per PSI telecon concensus; (8) Added one issue to section 10.2.2 about QueryEndpointsInterface; (9) Divided section 10.3 into 10.3.1 and 10.3.2, for clarity; (10) Moved former section 10.3 items (1), (2), (3) to section 10.3.2, per PSI telecon concensus; (11) Divided section 10.4 into 10.4.1 and 10.4.2, for clarity; (12) Moved former section 10.4 item (2) to section 10.4.2, per PSI telecon concensus. ----------------------------------------------- 10. Conformance This section specifies the conformance requirements (necessary for basic interoperability) and conformance recommendations (useful for improved interoperability) for all implementations of the PSI/1.0 protocol. This section also specifies the conformance recommentations for PSI product literature (useful for informed customer purchasing decisions). 10.1 PSI/1.0 Common Conformance 10.1.1 PSI/1.0 Common Implementation Requirements The following common conformance REQUIREMENTS apply to every PSI/1.0 implementation (Client, Print Service, or Target Device). Every PSI/1.0 implementation: (1) MUST support (produce and consume) valid [XML1.0] documents; (2) MUST support (produce and/or consume) valid [WSDL1.1] interfaces; (3) MUST support (produce and consume) valid [SOAP1.1] messages; (4) MUST support the [HTTP/1.1] binding of [SOAP/1.1]; (5) MUST support the Printer Object and all mandatory elements, as defined in section 7.1; (6) MUST support the Job Object and all mandatory elements, as defined in section 7.2; (7) MUST support the Document Object and all mandatory elements, as defined in section 7.3; (8) MUST support pwg-psips and pwg-psitd URL schemes for Target Devices, as defined in section 8.2.4; (9) MUST support the http URL scheme for References, as defined in section 8.3.1. Rationale: Customers should be able to purchase PSI-based products with basic interoperability guaranteed for those PSI products. ISSUE 01: Should item (8) above (pwg-psips/td target device URL support) be changed to SHOULD (recommendation), because the first PSI Print Services will only talk to Target Devices (printers) via existing print protocols (IPP, LPR, etc.). ISSUE 02: Should item (9) above (http reference URL support) be changed to SHOULD (recommendation), at least for PSI Clients (so that reference printing need not be implemented by clients). 10.1.2 PSI/1.0 Common Implementation Recommendations The following common conformance RECOMMENDATIONS apply to every PSI/1.0 implementation (Client, Print Service, or Target Device). Every PSI/1.0 implementation: (1) SHOULD support [XML1.1] or later XML versions; (2) SHOULD support later WSDL versions; (3) SHOULD support [SOAP1.2] or later SOAP versions; (4) SHOULD support non-HTTP bindings (SMTP, BEEP, etc.) of [SOAP1.1] or later SOAP versions; (5) SHOULD support native device discovery for the implementation's supported environments (Windows, NetWare, UNIX, Linux, etc.); (6) SHOULD support secure sessions over [TLS1.0] or later TLS versions, as defined in section 5.2; (7) SHOULD support the ipp URL scheme for Target Devices, as defined in section 8.2.5; (8) SHOULD support the ftp URL scheme for References, as defined in section 8.3.2. Rationale: Customers should be able to purchase PSI-based products with improved interoperability probable for those PSI products. 10.1.3 PSI/1.0 Common Literature Recommendations The following common conformance RECOMMENDATIONS apply to product literature. All products that claim PSI/1.0 conformance: (1) SHOULD publish the role-independent checklist of conformance claims, as defined in applicable paragraphs of this section 10.1 above, in installation, packaging, or other literature (e.g., Web pages); (2) SHOULD publish the role-specific checklist of conformance claims, as defined in applicable sections 10.2, 10.3, and/or 10.4 below, in installation, packaging, or other literature (e.g., Web pages). Rationale: Customers should be able to purchase PSI-based products with specific interoperability verified for those PSI products. 10.2 PSI/1.0 Client Conformance 10.2.1 PSI/1.0 Client Requirements The following conformance REQUIREMENTS apply to a PSI/1.0 Client. Every PSI/1.0 Client implementation: (1) MUST support the client role in the JobControlInterface, for access to PSI/1.0 Print Services and PSI/1.0 Target Devices, as defined in section 5.5. 10.2.2 PSI/1.0 Client Recommendations The following conformance RECOMMENDATIONS apply to a PSI/1.0 Client. Every PSI/1.0 Client implementation: (1) SHOULD support the client role in the QueryEndPointsInterface, for access to PSI/1.0 Print Services and PSI/1.0 Target Devices, as defined in section 5.3; (2) SHOULD support the client role in the ServiceCapabilitesInterface, for access to PSI/1.0 Print Services and PSI/1.0 Target Devices, as defined in section 5.4; (3) SHOULD support device discovery via the PSI Service Root URL as defined in section 5.1. ISSUE 03: Should item (1) above (QueryEndPointsInterface) be changed to MUST (requirement), because dynamic discovery of JobControlInterface may not be easy without this additional step 10.3 PSI/1.0 Print Service Conformance 10.3.1 PSI/1.0 Print Service Requirements The following conformance REQUIREMENTS apply to a PSI/1.0 Print Service. Every PSI/1.0 Print Service implementation: (1) MUST support the server role in the QueryEndPointsInterface, for access from PSI/1.0 Clients and PSI/1.0 Target Devices, as defined in section 5.3; (2) MUST support the server role in the ServiceCapabilitesInterface, for access from PSI/1.0 Clients and PSI/1.0 Target Devices, as defined in section 5.4; (3) MUST support the server role in the JobControlInterface, for access from PSI/1.0 Clients and PSI/1.0 Target Devices, as defined in section 5.5; (4) MUST support the server role in the TargetDeviceSupportInterface, for access from PSI/1.0 Target Devices, as defined in section 5.6; (5) MUST support device discovery via the PSI Service Root URL as defined in section 5.1. 10.3.2 PSI/1.0 Print Service Recommendations The following conformance RECOMMENDATIONS apply to a PSI/1.0 Print Service. Every PSI/1.0 Print Service implementation: (1) SHOULD support the client role in the QueryEndPointsInterface, for access to PSI/1.0 Print Services and PSI/1.0 Target Devices, as defined in section 5.3; (2) SHOULD support the client role in the ServiceCapabilitesInterface, for access to PSI/1.0 Print Services and PSI/1.0 Target Devices, as defined in section 5.4; (3) SHOULD support the client role in the JobControlInterface, for access to PSI/1.0 Print Services and PSI/1.0 Target Devices, as defined in section 5.5. 10.4 PSI/1.0 Target Device Conformance 10.4.1 PSI/1.0 Target Device Requirements The following conformance REQUIREMENTS apply to a PSI/1.0 Target Device. Every PSI/1.0 Target Device implementation: (1) MUST support the client role in the QueryEndPointsInterface, for access to PSI/1.0 Print Services, as defined in section 5.3; (2) MUST support the client role in the JobControlInterface, for access to PSI/1.0 Print Services, as defined in section 5.5; (3) MUST support the client role in the TargetDeviceSupportInterface, for access to PSI/1.0 Print Services, as defined in section 5.6; (4) MUST support the server role in the QueryEndPointsInterface, for access from PSI/1.0 Clients and PSI/1.0 Print Services, as defined in section 5.3; (5) MUST support the server role in the ServiceCapabilitesInterface, for access from PSI/1.0 Clients and PSI/1.0 Print Services, as defined in section 5.4; (6) MUST support the server role in the JobControlInterface, for access from PSI/1.0 Clients and PSI/1.0 Print Services, as defined in section 5.5; (7) MUST support device discovery via the PSI Service Root URL as defined in section 5.1. 10.4.2 PSI/1.0 Target Device Recommendations The following conformance RECOMMENDATIONS apply to a PSI/1.0 Target Device. Every PSI/1.0 Target Device implementation: (1) SHOULD support the client role in the ServiceCapabilitesInterface, for access to PSI/1.0 Print Services, as defined in section 5.4. From alan.berkema at hp.com Wed Sep 24 15:27:17 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:19 2009 Subject: PS> [PSI]: Oct 7 Mtg Agenda/Logistics Message-ID: <0806DAA43B1555479D53B58675D346830354FDD5@xrose01.rose.hp.com> NO Call 09/30/2003 This meeting will Use Webex and Teleconference, Harry is still checking to insure the room has LAN. Jerry will bring a Polycom, Harry will bring an Access Point (and Polycom ?)and I will bring a hub. The meeting will begin at 8:30AM Eastern Time, Heads up, that means 5:30AM West Coast, for those that couldn't travel. ** All Documents Posted on 9/26/2003 ** Agenda: o 8:00 AM - Coffee o 8:30 AM - Review Agenda o Introductions o Accept minutes From Last Mtg o Brief Overview of where we are, where we are going o 9:00 AM Review Requirements Document o 11:00 AM - Review PSI Spec. o 12:00 PM - Lunch - West Coast folks drive to work if needed o 1:00 PM - Continue Spec Review until Finished (~5:00 PM) Phone Bridge : TBD ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting number: 742003126 Meeting password: newpsi-1 Host: Alan Berkema 1(916)7855605 Alan Berkema Senior Engineer Scientist Connectivity Roseville, CA Hewlett-Packard Company 916 785-5605 Phone aberkema@hp.com From alan.berkema at hp.com Wed Sep 24 18:33:22 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:19 2009 Subject: PS> [PSI}: Marketing Requiremets Docs Posted Message-ID: <0806DAA43B1555479D53B58675D346830354FDD7@xrose01.rose.hp.com> ftp://ftp.pwg.org/pub/pwg/ps/wd-psireq10-200309_87.doc ftp://ftp.pwg.org/pub/pwg/ps/wd-psireq10-200309_87.pdf New content is sections 4.n.1 and section 5.1 Thanks, Alan From imcdonald at sharplabs.com Mon Sep 29 16:03:43 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:19 2009 Subject: PS> FW: Latest PSI Spec (26 Sept) Message-ID: <116DB56CD7DED511BC7800508B2CA537B001D4@mailsrvnt02.enet.sharplabs.com> Hi folks, Converted to PDF and stored on the PWG FTP server at: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030926.pdf - Adobe Acrobat version (245 KB) ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030926.doc - MS Word source (1.04 MB) ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20030926.zip - ZIP of MS Word source (227 KB) Please review/send comments on this PDF version for the upcoming PSI face-to-face on Tuesday (7 October 2003). Cheers, - Ira McDonald [for Dave Hall, Editor] High North Inc -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Monday, September 29, 2003 2:44 PM To: 'McDonald, Ira' Subject: Latest Spec Hey Ira... Can you create a PDF from the attached word doc, and upload them both? I can't seem to find the username / password combo. Thanks! Dave From alan.berkema at hp.com Thu Oct 2 11:18:57 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:19 2009 Subject: PS> [PSI]: Update: Oct 7 Mtg Agenda/Logistics Message-ID: <0806DAA43B1555479D53B58675D346830354FDFA@xrose01.rose.hp.com> Phone Bridge Info: Dial In: 1-866-365-4406 Toll #: 1-303-248-9655 Passcode: 2635888# ----------------------------------- NO Call 09/30/2003 This meeting will Use Webex and Teleconference, Harry is still checking to insure the room has LAN. Jerry will bring a Polycom, Harry will bring an Access Point (and Polycom ?)and I will bring a hub. The meeting will begin at 8:30AM Eastern Time, Heads up, that means 5:30AM West Coast, for those that couldn't travel. ** All Documents Posted on 9/26/2003 ** Agenda: o 8:00 AM - Coffee o 8:30 AM - Review Agenda o Introductions o Accept minutes From Last Mtg o Brief Overview of where we are, where we are going o 9:00 AM Review Requirements Document o 11:00 AM - Review PSI Spec. o 12:00 PM - Lunch - West Coast folks drive to work if needed o 1:00 PM - Continue Spec Review until Finished (~5:00 PM) Phone Bridge : See Top ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting number: 742003126 Meeting password: newpsi-1 Host: Alan Berkema 1(916)7855605 Alan Berkema Senior Engineer Scientist Connectivity Roseville, CA Hewlett-Packard Company 916 785-5605 Phone aberkema@hp.com From imcdonald at sharplabs.com Tue Oct 7 08:28:12 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:19 2009 Subject: PS> FW: PSI Slides for F2F (7 Oct 2003) Message-ID: <116DB56CD7DED511BC7800508B2CA537B001EC@mailsrvnt02.enet.sharplabs.com> Hi, I just posted Alan's slides for today's PWG PSI face-to-face in NYC (and telecon) to the PWG FTP site at: ftp://ftp.pwg.org/pub/pwg/ps/psi_pwg_overview_20031007.pdf (there are underscores, not spaces, in the simple filename) Cheers, - Ira -----Original Message----- From: BERKEMA,ALAN C (HP-Roseville,ex1) [mailto:alan.berkema@hp.com] Sent: Thursday, October 02, 2003 3:31 PM To: 'Ira McDonald' Subject: PSI Slides for F2F Hey Ira have a look. I am leaving for NY on 10/4 so I may not be able to change it. Hear you are on the road today. Thanks, Alan Alan Berkema Senior Engineer Scientist Connectivity Roseville, CA Hewlett-Packard Company 916 785-5605 Phone aberkema@hp.com From imcdonald at sharplabs.com Tue Oct 14 18:10:34 2003 From: imcdonald at sharplabs.com (Ira McDonald) Date: Wed May 6 14:02:19 2009 Subject: PS> PSI test message Message-ID: <3F8C3C1A.4842.55878E7@localhost> Please ignore - trying to fix my email client, - Ira From imcdonald at sharplabs.com Sun Oct 19 19:32:06 2003 From: imcdonald at sharplabs.com (Ira McDonald) Date: Wed May 6 14:02:19 2009 Subject: PS> Draft of PWG/IANA, I18N, and Security sections Message-ID: <3F92E6B6.23943.AECFA45@localhost> Hi folks, Sunday (21 October 2003) Below is draft text for inclusion in the PSI/10 protocol spec for: - Section 11 "PWG and IANA Considerations" - Section 12 "Internationalization Considerations" - Section 13 "Security Considerations" - Additions to "Normative References" - Additions to "Informative References" Dave - the following section numbers are probably wrong after our face-to-face move of some sections to the 'Conformance' section. Dave - there are a number of normative (MUST or SHOULD) requirements in this new Section 13 "Security Considerations". I suggest we simply add a pointer to these requirements to Section xx 'Conformance'. OK? Comments? Cheers, - Ira McDonald, contributing editor to PSI/1.0 High North Inc ---------------------------------------------------------------------- -- 11. PWG and IANA Considerations This document does not require any new PWG or IANA registration support. The following paragraphs describe some existing PWG, IANA, W3C, and ISO registered standard elements used in PSI/1.0: This PSI/1.0 document uses the existing standard elements of Job and Document objects defined in the PWG Semantic Model [PWG-SM]. The accompanying PSI/1.0 WSDL references schema defined in [PWG-SM]. The [XML] 'encoding' attribute contains a 'charset tag' [RFC2978]. New standard values may be registered according to [RFC2978] in the IANA Registry of Charset Tags [IANA-CHAR]. The [XML] 'lang' attribute contains a 'language tag' [RFC3066], i.e., a 'language code' [ISO639] optionally followed by a hyphen and a 'country code' [ISO3166]. New standard values (other than existing [ISO639] registrations) may be registered according to [RFC3066] in the IANA Registry of Language Tags [IANA-LANG]. The [PWG-SM] 'DocumentNaturalLanguage' element also contains a 'language tag' [RFC3066]. The [PWG-SM] 'DocumentFormat' element contains a MIME (content) media type [RFC2046]. New standard values may be registered according to [RFC2048] in the IANA Registry of Media Types [IANA-MIME]. ---------------------------------------------------------------------- -- 12. Internationalization Considerations PSI/1.0 implementations conform to all the best practice recommendations in "IETF Policy on Character Sets and Languages" [RFC2277]. PSI/1.0 implementations exchange [XML] information based on XML Schema [XSD] defined in the PWG Semantic Model [PWG-SM]. The [XML] 'encoding' attribute (which MUST be supplied by PSI/1.0 Clients) SHOULD be set to 'utf-8' [RFC2279], as recommended by [RFC2277]. The [XML] 'lang' attribute (which SHOULD be supplied by PSI/1.0 Clients) SHOULD be set to a value conforming to [RFC3066], as recommended by [RFC2277]. The [PWG-SM] 'DocumentNaturalLanguage' element (which SHOULD be suppled by PSI/1.0 Clients) SHOULD be set to a value conforming to [RFC3066], as recommended by [RFC2277]. ---------------------------------------------------------------------- -- 13. Security Considerations This section describes the security threats against PSI/1.0 clients and servers. This section specifies the security conformance requirements and recommendations for PSI/1.0 implementations. This section addresses most security issues by reference to applicable underlying protocol specifications, for example, [SOAP1.1], [HTTP1.1] and [TLS]. 13.1 Internet Threat Model This section is adapted from section 3 of "Guidelines for Writing RFC Text on Security Considerations" [RFC3552]. In the Internet threat model, we assume that the end-systems engaging in a protocol exchange have not themselves been compromised. Protecting against an attack when of the end-systems has itself been compromised is extraordinarily difficult. By contrast, we assume that the attacker has nearly complete control of the communications channel over which the end-systems communicate. This means that the attacker can read any PDU (Protocol Data Unit) on the network and undetectably remove, change, or inject forged packets onto the wire. This includes being able to generate packets that appear to be from a trusted machine. Thus, even if the end-system with which you wish to communicate is itself secure, the Internet environment provides no assurance that packets which claim to be from that system in fact are. It's important to realize that the meaning of a PDU is different at different levels. At the [IP] level, a PDU means an IP packet. At the TCP level, it means a TCP segment. At the application layer, it means some kind of application PDU. For instance, at the level of [SOAP1.1], it means a single SOAP request or response message, while at the [HTTP1.1] level, it means a single HTTP request or response message. 13.1.1 Passive Attacks In a passive attack, the attacker reads packets off the network but does not write them. The simplest way to mount such an attack is to simply be on the same LAN as the victim. On most common LAN configurations, including Ethernet, 802.3, and FDDI, any machine on the wire can read all traffic destined for any other machine on the same LAN. Note that switching hubs make this sort of sniffing substantially more difficult, since traffic destined for a machine only goes to the network segment that machine is located on. Wireless communications channels deserve special consideration, especially with the recent and growing popularity of wireless-based LANs, such as those using 802.11. Since the data is simply broadcast on well known radio frequencies, an attacker simply needs to be able to receive those transmissions. Such channels are especially vulnerable to passive attacks. Although many such channels include cryptographic protection, it is often of very poor quality. Passive attacks described in [RFC3552] and considered in PSI/1.0 are: (1) Confidentiality Violations - PSI/1.0 implementations MUST support [TLS] for protection against exposure of private business data. (2) Password Sniffing - PSI/1.0 implementations MUST support [TLS] and MUST NOT transfer cleartext passwords over unencrypted channels. (3) Offline Cryptographic Attacks - PSI/1.0 implementations MUST support [TLS] to protect against dictionary attacks against password- based challenge/response protocols [HTTPAuth]. 13.1.2 Active Attacks In an active attack, the attacker writes packets to the network and may read responses from the network. Active attacks that involve sending forged packets but not receiving any responses are called 'blind attacks'. When IP [RFC791] is used without [IPSec], there is no authentication for the sender address. Active attacks that involve forging an IP packet with a false source address are called 'spoofing attacks'. An IP packet with a forged source address may sometimes be screened out by the network infrastructure. For instance, many packet filtering firewalls screen out all packets with source addresses on the internal network that arrive on the external interface. Note that this provides no protection against an attacker who is inside the firewall. In general, protocol designers should assume that attackers can forge IP packets. Not all active attacks require forging addresses. For example, the TCP SYN denial of service attack does not require disguising the sender's address. However, it is common practice to disguise one's address in order to conceal one's identity if an attack is discovered. Active attacks described in [RFC3552] and considered in PSI/1.0 are: (1) Message Replay Attacks - PSI/1.0 implementations MUST support [TLS] and SHOULD always use at least [TLS] data integrity services for protection against [SOAP1.1] transaction replays by an attacker who has recorded a sequence of messages off the wire. (2) Message Insertion Attacks - PSI/1.0 implementations MUST support [TLS] and SHOULD always use at least [TLS] data integrity services for protection against message insertion by an attacker. PSI/1.0 implementations over [HTTP1.1] MUST take active measures to protect against denial-of-service attacks (for example, numerous incoming [TCP] connections from the same remote host or remote domain). (3) Message Deletion Attacks - PSI/1.0 implementations MUST support [TLS] and SHOULD always use at least [TLS] data integrity services for protection against message deletion by an attacker. (4) Message Modification Attacks - PSI/1.0 implementations MUST support [TLS] and SHOULD always use at least [TLS] data integrity services for protection against message modification by an attacker. (5) Man-In-The-Middle Attacks - PSI/1.0 implementations MUST support [TLS] and SHOULD always use at least [TLS] data integrity services and both Client and Server Authentication during [TLS] startup for protection against man-in-the-middle attacks. 13.2 Enterprise Threat Model In the enterprise threat model, we can no longer assume that the end-systems engaging in a protocol exchange have not themselves been compromised. Physical security of workstations and network printers in an enterprise network is often the weakest point of security defenses. And print jobs typically produce hardcopy, which an inside attacker can simply steal. Network security problems are actually worse in an enterprise network. Firewalls and border routers no longer provide any useful protection. Users and administrators who deploy PSI/1.0 products in enterprise networks SHOULD enforce the use of [TLS] and SHOULD enforce the use of strong Client and Server Authentication during [TLS] startup. 13.3 Mobile Threat Model In the mobile threat model, we can no longer defend against attackers based on network topology. Mobile clients may access home, business, or commercial PSI/1.0 products via: (1) Public Wireless - Cellular ISPs, IEEE 802.11 wireless Ethernet 'hot spots' in airports, etc. (2) Local Wireless - Bluetooth/IRDA-enabled laptops and printers, etc. Users and administrators who deploy PSI/1.0 products in mobile networks SHOULD enforce the use of [TLS] and SHOULD enforce the use of strong Client and Server Authentication during [TLS] startup. [IPSec] also offers significant security advantages in mobile networks. 13.4 HTTP Threat Model PSI/1.0 implementations are vulnerable to the following HTTP threats described in section 15 'Security Considerations' of [HTTP1.1]: (1) Attacks on personal information - [HTTP1.1] clients and servers in PSI/1.0 implementations MUST protect sensitive personal information, such as name, email address, etc. (see section 15.1 of [HTTP1.1]). (2) Attacks based on file and path names - [HTTP1.1] servers in PSI/1.0 implementations MUST NOT expose 'nearby' resources that were NOT explicitly configured for network access by administrators (see section 15.2 of [HTTP1.1]). (3) Attacks based on DNS spoofing - [HTTP1.1] clients and servers in PSI/1.0 implementations SHOULD NOT cache DNS name resolution results beyond their time-to-live value (see section 15.3 of [HTTP1.1]). (4) Attacks based on Location header spoofing - [HTTP1.1] servers in PSI/1.0 implementations MUST verify the validity of Location and Content-Location header data when supporting multiple trust domains (see section 15.4 of [HTTP1.1]). (5) Attacks based on Content-Disposition headers - [HTTP1.1] servers in PSI/1.0 implementations MUST defend against Content-Disposition header attacks (see section 15.5 of [HTTP1.1]). (6) Attacks based on retention of authentication credentials - [HTTP1.1] clients in PSI/1.0 implementations SHOULD NOT retain cached user authentication credentials beyond an administratively configured idle client time (see section 15.6 of [HTTP1.1]). (7) Attacks on HTTP Proxies - [HTTP1.1] servers in PSI/1.0 implementations SHOULD take active measures to defend against man-in-the-middle attacks and single source or distributed denial-of-service attacks (see section 15.7 of [HTTP1.1]). ---------------------------------------------------------------------- -- [for addition to Normative References section] [IANA-CHAR] IANA Registry of Charset Tags, archived at: ftp://ftp.iana.org/assignments/character-sets [IANA-LANG] IANA Registry of Language Tags, archived at: ftp://ftp.iana.org/assignments/language-tag-info [IANA-MIME] IANA Registry of Media Types, archived at: ftp://ftp.iana.org/assignments/media-types [IP] Postel, J. "Internet Protocol", RFC 791, September 1981. [IPSec] Kent, S., Atkinson, R. "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [SOAP1.2] See [SOAP1.2-0], [SOAP1.2-1], and [SOAP1.2-2]. [SOAP1.2-0] "SOAP Version 1.2 Part 0: Primer", W3C Recommendation, June 2003. [SOAP1.2-1] "SOAP Version 1.2 Part 1: Messaging Framework", W3C Recommendation, June 2003. [SOAP1.2-2] "SOAP Version 1.2 Part 2: Adjuncts", W3C Recommendation, June 2003. [TCP] Postel, J. "Transmission Control Protocol", RFC 793, September 1981. [WSDL1.2] See [WSDL1.2-1], [WSDL1.2-2], and [WSDL1.2-3] below. [WSDL1.2-1] "Web Services Description Language (WSDL) Version 1.2 -- Part 1: Core Language", W3C Working Draft, June 2003. [WSDL1.2-2] "Web Services Description Language (WSDL) Version 1.2 -- Part 2: Message Patterns", W3C Working Draft, June 2003. [WSDL1.2-3] "Web Services Description Language (WSDL) Version 1.2 -- Part 3: Bindings", W3C Working Draft, June 2003. [XML] See [XML1.0] and [XML1.1] below. [XML1.0] "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C Recommendation, October 2000. [XML1.1] "Extensible Markup Language (XML) 1.1", W3C Candidate Recommendation, October 2002. [XSD] See [XSD-1] and [XSD-2] below. [XSD-1] "XML Schema Part 1: Structures", W3C Recommendation, May 2001. [XSD-2] "XML Schema Part 2: Datatypes", W3C Recommendation, May 2001. [for addition to Informative References section] [ISO639] See [ISO639-1] and [ISO639-2] below. [ISO639-1] "Codes for the Representation of Names of Languages -- Part 1: Alpha-2 Code", ISO/IEC 639-1, 2000. [ISO639-2] "Codes for the Representation of Names of Languages -- Part 2: Alpha-3 Code", ISO/IEC 639-2, 1998. [ISO3166] See [ISO3166-1] and [ISO3166-2] below. [ISO3166-1] "Codes for the Representation of Names of Countries and their Subdivisions, Part 1: Country Codes", ISO/ISO 3166- 1, 1997. [ISO3166-2] "Codes for the Representation of Names of Countries and their Subdivisions, Part 2: Country Subdivision Codes", ISO/ISO 3166-2, 1998. [RFC2046] Freed, N., Borenstein, N. "MIME Part Two: Media Types", RFC 2046, November 1996. [RFC2048] Freed, N., Borenstein, N. "MIME Part Four: Registration Procedures", RFC 2048, November 1996. [RFC2277] Alvestrand, H. "IETF Policy on Character Sets and Languages", RFC 2277, January 1998. [RFC2279] Yergeau, F. "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. [RFC2978] Freed, N., Postel, J. "IANA Charset Registration Procedures", RFC 2978, October 2000. [RFC3066] Alvestrand, H. "Tags for the Identification of Languages", RFC 3066, January 2001. Ira McDonald (Musician / Network Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 Phone: +1-906-494-2434 Email: imcdonald@sharplabs.com From alan.berkema at hp.com Mon Oct 20 23:35:05 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:19 2009 Subject: PS> NO PSI Call 10/21 Message-ID: No Call this week stay tuned for future calls Thanks, Alan _____ Alan Berkema Senior Engineer Scientist Connectivity Roseville, CA Hewlett-Packard Company 916 785-5605 Phone aberkema@hp.com _____ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/ps/attachments/20031020/5780fb82/attachment-0001.html From imcdonald at sharplabs.com Tue Oct 21 13:53:29 2003 From: imcdonald at sharplabs.com (Ira McDonald) Date: Wed May 6 14:02:19 2009 Subject: PS> PSI Reqs revised Security/Discovery sections Message-ID: <3F953A59.31977.63F2D4@localhost> Hi folks, Tuesday (21 October 2003) Below are complete rewrite replacements for the former sections: - 5.4 Security - 6.1 Print Service Discovery Requirements Note that at our face-to-face review two weeks ago, we decided to DELETE entirely the former sections: - 5.5 Accounting Metrics - to be DELETED - 6 Other Considerations - to be DELETED Thus, the two replacement sections now are: - 5.4 Security - 5.5 Discovery Cheers, - Ira McDonald High North Inc ------------------------------------------------------------------------ 5.4 Security The PSI shall select one or more existing standard end-to-end security protocols. The selected PSI security protocol(s) shall be specified as optional to use for all PSI implementations, but mandatory to support for all PSI implementations. The selected PSI security protocol(s) shall support: (1) Client Authentication - protection from PSI service access by any unauthenticated client system or process. (2) Server Authentication - protection from PSI service offering by any unauthenticated server system or process. (3) Data Integrity - protection from PSI message insertion, message deletion, or message modification by any intermediate system. (4) Data Privacy - protection from PSI message content disclosure to any intermediate system. The PSI shall NOT specify or encourage the use of any hop-by-hop (link or network layer) security protocols, because they do not offer any end-to-end (application, session, or transport layer) security. 5.5 Discovery The PSI should select and recommend one or more existing standard discovery protocols. The selected PSI disovery protocol(s) should support: (1) Service advertising (2) Service type discovery (3) Service capabilities discovery (4) Device advertising (5) Device type discovery (6) Device capabilities discovery Ira McDonald (Musician / Network Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 Phone: +1-906-494-2434 Email: imcdonald@sharplabs.com From alan.berkema at hp.com Wed Oct 22 15:35:30 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:19 2009 Subject: PS> PSI Reqs revised Security/Discovery sections Message-ID: <7A371016E109114EA47C89370296278B290DFB@xrose01.rose.hp.com> Thanks Ira, One minor note, instead of deleting accounting it now says Accounting Attributes (instead of metrics) and it just says: The PSI shall support accounting metrics and attributes as defined in a named version of the PWG Semantic model. Alan -----Original Message----- From: owner-ps@pwg.org [mailto:owner-ps@pwg.org]On Behalf Of Ira McDonald Sent: Tuesday, October 21, 2003 10:53 AM To: ps@pwg.org Subject: PS> PSI Reqs revised Security/Discovery sections Hi folks, Tuesday (21 October 2003) Below are complete rewrite replacements for the former sections: - 5.4 Security - 6.1 Print Service Discovery Requirements Note that at our face-to-face review two weeks ago, we decided to DELETE entirely the former sections: - 5.5 Accounting Metrics - to be DELETED - 6 Other Considerations - to be DELETED Thus, the two replacement sections now are: - 5.4 Security - 5.5 Discovery Cheers, - Ira McDonald High North Inc ------------------------------------------------------------------------ 5.4 Security The PSI shall select one or more existing standard end-to-end security protocols. The selected PSI security protocol(s) shall be specified as optional to use for all PSI implementations, but mandatory to support for all PSI implementations. The selected PSI security protocol(s) shall support: (1) Client Authentication - protection from PSI service access by any unauthenticated client system or process. (2) Server Authentication - protection from PSI service offering by any unauthenticated server system or process. (3) Data Integrity - protection from PSI message insertion, message deletion, or message modification by any intermediate system. (4) Data Privacy - protection from PSI message content disclosure to any intermediate system. The PSI shall NOT specify or encourage the use of any hop-by-hop (link or network layer) security protocols, because they do not offer any end-to-end (application, session, or transport layer) security. 5.5 Discovery The PSI should select and recommend one or more existing standard discovery protocols. The selected PSI disovery protocol(s) should support: (1) Service advertising (2) Service type discovery (3) Service capabilities discovery (4) Device advertising (5) Device type discovery (6) Device capabilities discovery Ira McDonald (Musician / Network Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 Phone: +1-906-494-2434 Email: imcdonald@sharplabs.com From alan.berkema at hp.com Wed Oct 22 15:51:26 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:19 2009 Subject: PS> [PSI]: New MRD Posted Message-ID: <7A371016E109114EA47C89370296278B2FD163@xrose01.rose.hp.com> Word version has changes turned on, pdf is clean. ftp://ftp.pwg.org/pub/pwg/ps/wd-psireq10-200309_89.doc ftp://ftp.pwg.org/pub/pwg/ps/ wd-psireq10-200309_89.pdf regards, Alan _____ Alan Berkema Senior Engineer Scientist Connectivity Roseville, CA Hewlett-Packard Company 916 785-5605 Phone aberkema@hp.com _____ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/ps/attachments/20031022/c3fdf7aa/attachment-0001.html From imcdonald at sharplabs.com Wed Oct 22 18:08:31 2003 From: imcdonald at sharplabs.com (imcdonald@sharplabs.com) Date: Wed May 6 14:02:19 2009 Subject: PS> PSI Reqs revised Security/Discovery sections In-Reply-To: <7A371016E109114EA47C89370296278B290DFB@xrose01.rose.hp.com> Message-ID: <3F96C79F.27475.FBA25E@localhost> Hi Alan, Thanks - I stand corrected. Cheers, - Ira > Thanks Ira, > > One minor note, instead of deleting accounting it now > says Accounting Attributes (instead of metrics) > and it just says: > The PSI shall support accounting metrics and attributes as > defined in a named version of the PWG Semantic model. > > Alan > > > -----Original Message----- > From: owner-ps@pwg.org [mailto:owner-ps@pwg.org]On Behalf Of Ira > McDonald > Sent: Tuesday, October 21, 2003 10:53 AM > To: ps@pwg.org > Subject: PS> PSI Reqs revised Security/Discovery sections > > > Hi folks, Tuesday (21 October > 2003) > > Below are complete rewrite replacements for the former sections: > > - 5.4 Security > - 6.1 Print Service Discovery Requirements > > Note that at our face-to-face review two weeks ago, we decided to > DELETE > entirely the former sections: > > - 5.5 Accounting Metrics - to be DELETED > - 6 Other Considerations - to be DELETED > > Thus, the two replacement sections now are: > > - 5.4 Security > - 5.5 Discovery > > Cheers, > - Ira McDonald > High North Inc > > ------------------------------------------------------------------------ > > > 5.4 Security > > The PSI shall select one or more existing standard end-to-end security > protocols. The selected PSI security protocol(s) shall be specified as > optional to use for all PSI implementations, but mandatory to support for > all PSI implementations. The selected PSI security protocol(s) shall > support: > > (1) Client Authentication - protection from PSI service access by any > unauthenticated client system or process. > > (2) Server Authentication - protection from PSI service offering by any > unauthenticated server system or process. > > (3) Data Integrity - protection from PSI message insertion, message > deletion, or message modification by any intermediate system. > > (4) Data Privacy - protection from PSI message content disclosure to > any intermediate system. > > The PSI shall NOT specify or encourage the use of any hop-by-hop (link or > network layer) security protocols, because they do not offer any > end-to-end (application, session, or transport layer) security. > > > 5.5 Discovery > > The PSI should select and recommend one or more existing standard > discovery protocols. The selected PSI disovery protocol(s) should > support: > > (1) Service advertising > > (2) Service type discovery > > (3) Service capabilities discovery > > (4) Device advertising > > (5) Device type discovery > > (6) Device capabilities discovery > > Ira McDonald (Musician / Network Software Architect) > Blue Roof Music / High North Inc > PO Box 221 > Grand Marais, MI 49839 > Phone: +1-906-494-2434 > Email: imcdonald@sharplabs.com From alan.berkema at hp.com Fri Oct 24 12:38:09 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:19 2009 Subject: PS> PSI 10/7/03 F2F Mtg Mins & Slides Message-ID: <7A371016E109114EA47C89370296278B2FD167@xrose01.rose.hp.com> Skipped content of type multipart/alternative-------------- next part -------------- PSI F2F Meeting Minutes 10/07/2003 (New York,NY) I. Attendees. Lee Farrell Yiruo Yang Alan Berkema Bob Taylor Dave Hall (via phone) Ira McDonald (via phone) Harry Lewis Jerry Thrasher Alain Regnier Fumio Nagasaka Hiroshi Shiraku II. Review Agenda (see Alan's PPT) A. Introductions B. Call For Intellectual Property C. Review and Approve Minutes from June Meeting. D. Review Agenda E. PSI History/Overview F. Review Requirements Document G. Review PSI Spec. III. Review and approve minutes from June Meeting. No changes (Approved) IV. PSI History/Overview/Objectives (see Alan's presentation) V. Schedule Going Forward 10/07/03 F2F review of PSI spec. and MRD 10/17/03 10 Day Last Call 10/31/03 End date goal for initiation of formal vote to Candidate Standard Status VI. MRD Review Updated Contributor List Section 1. Overview: Section 2. Introduction: Comment: Need to update the section numbers in the first paragraph (off by one section number) Comment: Need to update the language for each section description to match what's actually in each section... Section 3. Scope of the Print Service Interoperability Spec. Section 4. Print Service Interface Use Models Comment: Remove "informative" from section title as well as throughout... Comment: Editorial (TargetDevice ==> Target Device throughout...) Comment: Clarify the meaning of the "dashed" lines in the data flows Comment: Explain the meaning of the "dotted" lines/ovals around the admin' domains. Comment: Explain the meaning of the "solid" lines in the data flows.... 4.1 Comment: In 4.1 (clarify that the step 6 transfer from the Print Service to the Target Device is a "new" print job) Comment: 4.1.1 Change 1. Printer knowledge or discovery... to Printer configuration or discover.... (comment applies to other sub-sections as well) 4.2 Comment: In Req. 3 need to mention capabilities discovery (mobile-PS-TD) comment applies throughout... Comment: Data flow 6 in picture needs to clarify that it's a "new" job. 4.3 4.4 4.5 Comment: Need the "real world" use case story that illuminates the use model. Comment: Need to make sure that the Un-formatted Data and the Application Data data flows are properly linked/explained in the data flow diagram. Comment: Need to clarify requirement 7 to clarify that the data may be either pushed to the Printer/TD or pulled by the Printer/TD.... Comment: Need to standardize on Printer or Target Device for referring to the Target Device in the text (description and requirments) Section 5. Print Service Interface Requirments Comment: Last sentence in first paragraph (issues ==> requirments) Comment: Same sentence (billing ==> accounting) 5.2 Comment: Need to mention the transfer of data from client to Print Service as well as just a reference... 5.3 Comment: Need to add "Print Service" to first sentence... Comment: Remove "may" from second sentence (is a requirement) Comment: Need to reword or remove text in this section to remove any implied solution or implementation....(see updated MRD) Need a section added that addresses discovery (move Section 6 text to Section 5) 5.4 Comment: Need to rework the security sub-section (Ira todo) 5.5 Comment: Need to reword section to remove references to any particular accounting metric requirements (refer to semantic model document) Comment: Need to remove the work "Metrics" from the sub-section title (Accounting Attributes). Comment/Action Item: Implementers guide needs to contain section describing the appropriate accounting attributes from the PWG semantic model. Section 6. Comment: Move to section 5 and reword (Ira todo). (remove section 6) *************************** End of MRD Review *************************** VII. PSI Specification Review (version 2003/09/26) Reviewed the issues and questions in the latest version of the spec. (see updated specification) Section 5 Issue 1: Toolkits/editors for WSDL aren't currently to a level to be able to correctly or consistently validate the wsdl files. Resolution: Clarify that the wsdl files are for "reference" designs only (i.e., informative). However the PSI spec. can't become a full PWG standard without normative wsdl files. Section 5.3 Issue 2: Resolve the above namespace. Resolution/Discussion: Need to move the "normative" namespace declaration discussion to the beginning of Section 5 before the discussion about the wsdl documents. (Namespace is normative, wsdl files are currently informative pending the resolution of Issue 1.) Comment: Now that there as an independent conformance section, the detailed method/parameter conformance requirements statements that are currently in each method description need to be moved to a table (or something) in the conformance section. Resolution: Dave todo, create the table..... Section 6 Issue: Client needs ability to determine the mode of the Print Service. Need semantic model attribute (autoSelectTargetDevice_supported boolean),(TargetDeviceIdentifier_supported boolean) or equivalent multivalue attribute(s)........(see updated specification) Section 10 Discussed the three conformance questions/issues (see updated spec) Action Item: (Last Call Reviewers) The conformance section should be reviewed closely to make sure it accurately summarizes the requirments of the PSI specification. Section 13 and 14 ToDo (Ira to provide standard text for these sections) Section 15 (Security Model Considerations) Ira continuing to develop the text for the Security section. *************************** End of PSI Spec. Review *************************** VII. Brief discussion of the results of the interop event. Basic operations (Createjob etc) seemed to work, however toolkit issues caused the need for extensive hand coding of the interfaces to get basic interoperability....Toolkit interoperability is still a continuing issue. VIII. There will be no PSI phone conference on October 14, 2003. Move out original "schedule going forward" dates by a week..... Next Phone conference Call on Tuesday October 21, 2003. Details will be sent to the reflector. Meeting adjourned....... -------------- next part -------------- A non-text attachment was scrubbed... Name: psi_pwg_overview.pdf Type: application/octet-stream Size: 139973 bytes Desc: not available Url : http://www.pwg.org/archives/ps/attachments/20031024/176e5791/psi_pwg_overview-0001.obj From imcdonald at sharplabs.com Mon Oct 27 12:05:51 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:19 2009 Subject: PS> PSI tomorrow (28 OCt)? Message-ID: <116DB56CD7DED511BC7800508B2CA537B001FF@mailsrvnt02.enet.sharplabs.com> Hi Alan and Dave, Are we meeting tomorrow morning (Tues 28 October)? Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com From alan.berkema at hp.com Mon Oct 27 15:07:11 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:19 2009 Subject: PS> [PSI] Next Call 10/28/03 Message-ID: <7A371016E109114EA47C89370296278B2FD174@xrose01.rose.hp.com> Teleconference details: NEXT: Tuesday Time: 8:00AM (US PDT) Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Review Requirements Doc Changes 20 Tech Spec Update for Last Call? ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting number: 743057814 Meeting password: newpsi-1 Host: Alan Berkema 1(916)7855605 From imcdonald at sharplabs.com Tue Oct 28 12:37:45 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:19 2009 Subject: PS> Next calls and PSI Spec schedules Message-ID: <116DB56CD7DED511BC7800508B2CA537B00202@mailsrvnt02.enet.sharplabs.com> Hi folks, We completed a pretty thorough pass through Alan's last-call version of PSI Requirements spec this morning. Only editorial changes (for clarity or consistency) were found. Next steps: * Fri 31 Oct - new version of PSI Protocol spec to be posted for two-week last call * Tue 4 Nov - PSI telecon - address any further last-call comments on PSI Requirements spec (Alan will lead). * Fri 7 Nov - last-call ends on PSI Requirements spec * Tue 11 Nov - PSI telecon - address any last-call comments on PSI Protocol spec (Dave will lead - Alan on vacation). * Fri 14 Nov - last-call ends on PSI Protocol spec (if Dave and I got it out by Fri 31 Oct). * ??? Nov - call for Formal Vote on PSI Requirements spec * ??? Nov - call for Formal Vote on PSI Protocol spec Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com From alan.berkema at hp.com Tue Oct 28 16:15:43 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:19 2009 Subject: PS> [PSI] Next Call 11/04/03 Message-ID: <7A371016E109114EA47C89370296278B2FD187@xrose01.rose.hp.com> I know some of you said you are out we will still try to make whatever progress we can towards Last Call, Thanks Alan Teleconference details: NEXT: Tuesday Time: 8:00AM (US PDT) Number: 866-639-4738 Participant PIN: 7855605 If Trouble with Above Try: Toll Access Number: 574-935-6700 Participant PIN: 7855605 Agenda: 1) Review Tech Spec Updates 2) Requirements Doc Status ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting number: 743057814 Meeting password: newpsi-1 Host: Alan Berkema 1(916)7855605 From imcdonald at sharplabs.com Mon Nov 10 10:56:07 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:19 2009 Subject: PS> ?? PSI call on Nov 11 ?? Message-ID: <116DB56CD7DED511BC7800508B2CA537B0022A@mailsrvnt02.enet.sharplabs.com> Hi Dave, Are you planning to host a PSI telecon tomorrow morning? Alan is on vacation this week (I believe). He said last week we'd have a call if you (Dave) wanted to host it. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com From dhall at hp.com Wed Nov 26 16:58:27 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:02:19 2009 Subject: PS> Updated Specification wd-psi10-20031126.doc Message-ID: <4EB310FE4410BB4B8E981C67B275BC4F014735BD@xvan01.vcd.hp.com> The latest revision of the PSI specification can now be found at: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20031126.doc ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20031126.pdf It includes all of the modifications from the last F2F and the new sections from Ira. (Many apologies for disappearing! Things have been really busy in my new position in HP...) (Ira, can I get you to turn the DOC into a PDF and publish it? Thanks!) Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/ps/attachments/20031126/7c020684/attachment-0001.html From imcdonald at sharplabs.com Wed Nov 26 18:16:04 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:19 2009 Subject: PS> [PDF & ZIP] Updated Specification wd-psi10-20031126.doc Message-ID: <116DB56CD7DED511BC7800508B2CA537B0027B@mailsrvnt02.enet.sharplabs.com> Hi, Converted to PDF (244 KB) and stored at: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20031126.pdf Also MS Word source (1.4 MB) packed into ZIP (261 KB): ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20031126.zip Here's a directory listing excerpt: -rw-r--r-- 1 pwg staff 1428480 Nov 26 16:50 wd-psi10-20031126.doc -rw-r--r-- 1 pwg staff 249359 Nov 26 18:07 wd-psi10-20031126.pdf -rw-r--r-- 1 pwg staff 266919 Nov 26 18:13 wd-psi10-20031126.zip Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -----Original Message----- From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Wednesday, November 26, 2003 4:58 PM To: 'ps@pwg.org' Subject: PS> Updated Specification wd-psi10-20031126.doc The latest revision of the PSI specification can now be found at: ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20031126.doc ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20031126.pdf It includes all of the modifications from the last F2F and the new sections from Ira. (Many apologies for disappearing! Things have been really busy in my new position in HP...) (Ira, can I get you to turn the DOC into a PDF and publish it? Thanks!) Dave From Ide.Kentaro at exc.epson.co.jp Tue Dec 2 14:04:40 2003 From: Ide.Kentaro at exc.epson.co.jp (Ide Kentaro) Date: Wed May 6 14:02:19 2009 Subject: FW: Re: PS> Updated Specification wd-psi10-20031126.doc Message-ID: <56DBC1B7ACBDAE45AB2858C17E2F5B2C0E01827B@hroaex2.hro.epson.co.jp> Hi folks, Because Nagasaka's mail had lost from mailing list, I resend. Kentaro Ide IJP Design Dept. Imaging & Information Products Operations Div.. SEIKO EPSON Corp Tel 81-263-5603 / Fax 81-263-5613 > -----Original Message----- >From: Nagasaka Fumio >Sent: Friday, November 28, 2003 8:11 PM >To: 'ps@pwg.org' >Subject: Re: PS> Updated Specification wd-psi10-20031126.doc > >Hi folks, > >After I reviewed the PSI specification Ver. 1.0 Working Draft, I have three comments here. > >Issue 1, >The specification does not tell what shall be defined for the documentFilterElements. > >>5.5.8 GetJobs - Specifies the elements used as a filter when creating the Job list that is returned. > >Our implementation has been confused what is doable to keep interoperability with other implementation. >Still FilterElements seems to be nebulous and there shall be an example or some descriptions. > >Issue 2, >The specification does not clear what shall a client do to detect a requested job has been completed. >The client cannot estimate how soon the service done, then the client will be required to do polling-like >method to know whether the job completed or not. > >> <<...OLE_Obj...>> > >Issue 3, >There are few method to retrieve files from the single document when a client uses AddDocumentByPush. >In this case the single document may have multiple files. >The specification says in 5.5.5. "..if a ZIP file, or a multi-part mime Document can be delivered..", >however FetchDocumentByValue can specify a file at once. There shall be an enumerating >method to let the client to know how many times to invoke FetchDocumentByValue. > >> <<...OLE_Obj...>> > >------------------------------- >Fumio Nagasaka / IJP Design Dept. >Imaging & Information Products Operations Div.. > SEIKO EPSON Corp >Tel 81-263-5603 / Fax 81-263-5613 > > >>The latest revision of the PSI specification can now be found at: >> >> >><> >> >><> >> >>It includes all of the modifications from the last F2F and the new sections >>from Ira. >> >>(Many apologies for disappearing! Things have been really busy in my new >>position in HP...) >>(Ira, can I get you to turn the DOC into a PDF and publish it? Thanks!) >> >>Dave From imcdonald at sharplabs.com Tue Dec 2 15:10:03 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:19 2009 Subject: PS> Thu 4 Dec - PSI and IPPFAX Phone Bridge number for Provo meeting Message-ID: <116DB56CD7DED511BC7800508B2CA537B0028C@mailsrvnt02.enet.sharplabs.com> Hi, Alan and Dave - please note the phone bridge and passcode below for the Thursday morning (4 Dec) PSI telecon. Gail and Rick - we should also use this phone bridge and passcode for the Thursday afternoon (4 Dec) IPPFAX telecon. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -----Original Message----- From: Zehler, Peter [mailto:PZehler@crt.xerox.com] Sent: Tuesday, December 02, 2003 11:38 AM To: PWG Announce (pwg-announce@pwg.org) Subject: PWG-ANNOUNCE> WBMM Phone Bridge number for Provo meeting All, Today's meeting has a phone bridge which is (866) 365-4406 with a passcode of 2635888#. This number will be used for today, Thursday and Friday. The PWG Semantic Model and PWG Plenary (Wednesday) will use the previously announced number and webex included below. Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 Meeting Date: 12/3/2003 Meeting Time: 9:00 AM MST (UTC -7:00) (11:00 AM EST) Instant Net Conference Details: ------------------------------- Meeting Number: 747275324 Meeting Passcode: PwgSm Meeting Host: Pete Zehler Join Instructions for Instant Net Conference: REPEAT USERS 1. Join the meeting now: http://www.mymeetings.com/nc/join.php?i=747275324&p=PwgSm&t=c 2. Enter your name 3. Agree to the Terms & Conditions and click Proceed. NEW USERS 1. Go to http://www.mymeetings.com/nc/ 2. Type in the Meeting Number 3. Type in the Meeting Passcode (if one was provided) 4. Choose "Conference" and click Proceed 5. If you are a new user, click on "New Users" to check your system and download the software and go back to Join Net Conference page 6. Enter your name 7. Agree to the Terms & Conditions and click Proceed. Dial in Info: Phone Number:(877) 707-6056 (Phone Number for Xerox Employees: 8*594-0077) PARTICIPANT PASSCODE: 437874# From alan.berkema at hp.com Tue Dec 2 16:03:52 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:19 2009 Subject: PS> Thu 4 Dec - PSI webex Info and Phone Bridge number for Provo meet ing Message-ID: <7A371016E109114EA47C89370296278B2FD259@xrose01.rose.hp.com> West Coast Folks please note the 7:30AM start time! Agenda: 1) Review PSI Spec for Last Call ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20031126.pdf Also MS Word source (1.4 MB) packed into ZIP (261 KB): ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20031126.zip PSI - Thursday morning -- 8:30am - Noon MST (7:30-11am PST) Phone bridge (866) 365-4406 with a passcode 2635888# ----------------- WebEx info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: PSI Time: 7:30AM, (GMT -08:00) Pacific Time, USA & Canada Meeting number: 748017768 Meeting password: provopsi-99 Host: Alan Berkema 1(916)7855605 From Ide.Kentaro at exc.epson.co.jp Tue Dec 2 21:59:50 2003 From: Ide.Kentaro at exc.epson.co.jp (Ide Kentaro) Date: Wed May 6 14:02:19 2009 Subject: PS> Updated Specification wd-psi10-20031126.doc Message-ID: <56DBC1B7ACBDAE45AB2858C17E2F5B2C0E018478@hroaex2.hro.epson.co.jp> Hi folks, I'm sorry for miss-attached figures. Attached two figures to this mail. | -----Original Message----- | From: owner-ps@pwg.org [mailto:owner-ps@pwg.org]On Behalf Of | Ide Kentaro | Sent: Wednesday, December 03, 2003 4:05 AM | To: ps@pwg.org | Subject: FW: Re: PS> Updated Specification wd-psi10-20031126.doc | | | Hi folks, | | Because Nagasaka's mail had lost from mailing list, I resend. | | Kentaro Ide | IJP Design Dept. | Imaging & Information Products Operations Div.. | SEIKO EPSON Corp | Tel 81-263-5603 / Fax 81-263-5613 | | > -----Original Message----- | >From: Nagasaka Fumio | >Sent: Friday, November 28, 2003 8:11 PM | >To: 'ps@pwg.org' | >Subject: Re: PS> Updated Specification wd-psi10-20031126.doc | > | >Hi folks, | > | >After I reviewed the PSI specification Ver. 1.0 Working | Draft, I have three comments here. | > | >Issue 1, | >The specification does not tell what shall be defined for | the documentFilterElements. | > | >>5.5.8 GetJobs - Specifies the elements used as a filter | when creating the Job list that is returned. | > | >Our implementation has been confused what is doable to keep | interoperability with other implementation. | >Still FilterElements seems to be nebulous and there shall | be an example or some descriptions. | > | >Issue 2, | >The specification does not clear what shall a client do to | detect a requested job has been completed. | >The client cannot estimate how soon the service done, then | the client will be required to do polling-like | >method to know whether the job completed or not. | > | >> <<...OLE_Obj...>> | > | >Issue 3, | >There are few method to retrieve files from the single | document when a client uses AddDocumentByPush. | >In this case the single document may have multiple files. | >The specification says in 5.5.5. "..if a ZIP file, or a | multi-part mime Document can be delivered..", | >however FetchDocumentByValue can specify a file at once. | There shall be an enumerating | >method to let the client to know how many times to invoke | FetchDocumentByValue. | > | >> <<...OLE_Obj...>> | > | >------------------------------- | >Fumio Nagasaka / IJP Design Dept. | >Imaging & Information Products Operations Div.. | > SEIKO EPSON Corp | >Tel 81-263-5603 / Fax 81-263-5613 | > | > | >>The latest revision of the PSI specification can now be found at: | >> | >> | >><> | >> | >><> | >> | >>It includes all of the modifications from the last F2F and | the new sections | >>from Ira. | >> | >>(Many apologies for disappearing! Things have been really | busy in my new | >>position in HP...) | >>(Ira, can I get you to turn the DOC into a PDF and publish | it? Thanks!) | >> | >>Dave | -------------- next part -------------- A non-text attachment was scrubbed... Name: psi_pointout.pdf Type: application/octet-stream Size: 11978 bytes Desc: not available Url : http://www.pwg.org/archives/ps/attachments/20031203/366ef7be/psi_pointout-0001.obj From imcdonald at sharplabs.com Thu Dec 4 14:39:45 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:20 2009 Subject: PS> RE: IFX> Today 1pm MST (12pm PST / 3pm EST) - agenda and info for Provo Message-ID: <116DB56CD7DED511BC7800508B2CA537B0029D@mailsrvnt02.enet.sharplabs.com> Hi folks, Today's meeting has a phone bridge which is (866) 365-4406 with a passcode of 2635888#. This number will be used for today (Thursday) and tomorrow (Friday) sessions at PWG Provo. Suggested Agenda: (1) Introductions (2) Agenda Review (3) IPPFAX Status Review Slides - available at ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-status-20031204.htm (4) IPPFAX Protocol Spec Review - available at ftp://ftp.pwg.org/pub/pwg/QUALDOCS/wd-ifx10-20031105.pdf (5) Next steps - action items, working group future, etc. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Tuesday, December 02, 2003 3:10 PM To: 'ps@pwg.org'; 'ifx@pwg.org' Subject: IFX> Thu 4 Dec - PSI and IPPFAX Phone Bridge number for Provo meeting Hi, Alan and Dave - please note the phone bridge and passcode below for the Thursday morning (4 Dec) PSI telecon. Gail and Rick - we should also use this phone bridge and passcode for the Thursday afternoon (4 Dec) IPPFAX telecon. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -----Original Message----- From: Zehler, Peter [mailto:PZehler@crt.xerox.com] Sent: Tuesday, December 02, 2003 11:38 AM To: PWG Announce (pwg-announce@pwg.org) Subject: PWG-ANNOUNCE> WBMM Phone Bridge number for Provo meeting All, Today's meeting has a phone bridge which is (866) 365-4406 with a passcode of 2635888#. This number will be used for today, Thursday and Friday. The PWG Semantic Model and PWG Plenary (Wednesday) will use the previously announced number and webex included below. Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 Meeting Date: 12/3/2003 Meeting Time: 9:00 AM MST (UTC -7:00) (11:00 AM EST) Instant Net Conference Details: ------------------------------- Meeting Number: 747275324 Meeting Passcode: PwgSm Meeting Host: Pete Zehler Join Instructions for Instant Net Conference: REPEAT USERS 1. Join the meeting now: http://www.mymeetings.com/nc/join.php?i=747275324&p=PwgSm&t=c 2. Enter your name 3. Agree to the Terms & Conditions and click Proceed. NEW USERS 1. Go to http://www.mymeetings.com/nc/ 2. Type in the Meeting Number 3. Type in the Meeting Passcode (if one was provided) 4. Choose "Conference" and click Proceed 5. If you are a new user, click on "New Users" to check your system and download the software and go back to Join Net Conference page 6. Enter your name 7. Agree to the Terms & Conditions and click Proceed. Dial in Info: Phone Number:(877) 707-6056 (Phone Number for Xerox Employees: 8*594-0077) PARTICIPANT PASSCODE: 437874# From imcdonald at sharplabs.com Thu Dec 4 14:41:57 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:02:20 2009 Subject: PS> RE: IFX> [Fix URL]Today 1pm MST (12pm PST / 3pm EST) - agenda and info for Provo Message-ID: <116DB56CD7DED511BC7800508B2CA537B0029E@mailsrvnt02.enet.sharplabs.com> Hi, Oops! The slides are actually at: ftp://ftp.pwg.org/pub/pwg/QUALDOCS/slides/ifx-status-20031204.htm Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -----Original Message----- From: McDonald, Ira Sent: Thursday, December 04, 2003 2:40 PM To: McDonald, Ira; 'ps@pwg.org'; 'ifx@pwg.org' Subject: RE: IFX> Today 1pm MST (12pm PST / 3pm EST) - agenda and info for Provo Hi folks, Today's meeting has a phone bridge which is (866) 365-4406 with a passcode of 2635888#. This number will be used for today (Thursday) and tomorrow (Friday) sessions at PWG Provo. Suggested Agenda: (1) Introductions (2) Agenda Review (3) IPPFAX Status Review Slides - available at ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-status-20031204.htm (4) IPPFAX Protocol Spec Review - available at ftp://ftp.pwg.org/pub/pwg/QUALDOCS/wd-ifx10-20031105.pdf (5) Next steps - action items, working group future, etc. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Tuesday, December 02, 2003 3:10 PM To: 'ps@pwg.org'; 'ifx@pwg.org' Subject: IFX> Thu 4 Dec - PSI and IPPFAX Phone Bridge number for Provo meeting Hi, Alan and Dave - please note the phone bridge and passcode below for the Thursday morning (4 Dec) PSI telecon. Gail and Rick - we should also use this phone bridge and passcode for the Thursday afternoon (4 Dec) IPPFAX telecon. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -----Original Message----- From: Zehler, Peter [mailto:PZehler@crt.xerox.com] Sent: Tuesday, December 02, 2003 11:38 AM To: PWG Announce (pwg-announce@pwg.org) Subject: PWG-ANNOUNCE> WBMM Phone Bridge number for Provo meeting All, Today's meeting has a phone bridge which is (866) 365-4406 with a passcode of 2635888#. This number will be used for today, Thursday and Friday. The PWG Semantic Model and PWG Plenary (Wednesday) will use the previously announced number and webex included below. Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 Meeting Date: 12/3/2003 Meeting Time: 9:00 AM MST (UTC -7:00) (11:00 AM EST) Instant Net Conference Details: ------------------------------- Meeting Number: 747275324 Meeting Passcode: PwgSm Meeting Host: Pete Zehler Join Instructions for Instant Net Conference: REPEAT USERS 1. Join the meeting now: http://www.mymeetings.com/nc/join.php?i=747275324&p=PwgSm&t=c 2. Enter your name 3. Agree to the Terms & Conditions and click Proceed. NEW USERS 1. Go to http://www.mymeetings.com/nc/ 2. Type in the Meeting Number 3. Type in the Meeting Passcode (if one was provided) 4. Choose "Conference" and click Proceed 5. If you are a new user, click on "New Users" to check your system and download the software and go back to Join Net Conference page 6. Enter your name 7. Agree to the Terms & Conditions and click Proceed. Dial in Info: Phone Number:(877) 707-6056 (Phone Number for Xerox Employees: 8*594-0077) PARTICIPANT PASSCODE: 437874# From alan.berkema at hp.com Mon Dec 8 13:14:16 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:02:20 2009 Subject: PS> FW: Provo PSI meeting minutes Message-ID: <7A371016E109114EA47C89370296278B2FD274@xrose01.rose.hp.com> Thanks Jerry! -------------- next part -------------- A non-text attachment was scrubbed... Name: PSI Meeting Minutes Provo.txt Type: application/octet-stream Size: 4177 bytes Desc: not available Url : http://www.pwg.org/archives/ps/attachments/20031208/2a2af3ff/PSIMeetingMinutesProvo-0001.obj