William Wagner | 1 Aug 17:08 2010
Picon
Picon

[Pwg-Announce] First Session - MFD

Greetings:

The first session of the MFD Face-to-face meeting on 3 August is concerned with the Requirements Document Last Call Comments Review and Overall Specification Review. I have posted what we believe to be the final Requirements Document LCRC at:

ftp://ftp.pwg.org/pub/pwg/mfd/wd/lcrc-mfdreq10-20100722.pdf

ftp://ftp.pwg.org/pub/pwg/mfd/wd/lcrc-mfdreq10-20100722.doc

ftp://ftp.pwg.org/pub/pwg/mfd/wd/lcrc-mfdreq10-20100722-rev.pdf

ftp://ftp.pwg.org/pub/pwg/mfd/wd/lcrc-mfdreq10-20100722-rev.doc

 

and the Last Call Resolution Comments at:

ftp://ftp.pwg.org/pub/pwg/mfd/wd/mfdreq10-last-call-comment-resolution-20100722.txt

 

I have posted an update to the “Overall” document at

ftp://ftp.pwg.org/pub/pwg/mfd/wd/wd-mfdoverallmod10-20100730.pdf

ftp://ftp.pwg.org/pub/pwg/mfd/wd/wd-mfdoverallmod10-20100730.doc

ftp://ftp.pwg.org/pub/pwg/mfd/wd/wd-mfdoverallmod10-20100730-rev.pdf

ftp://ftp.pwg.org/pub/pwg/mfd/wd/wd-mfdoverallmod10-20100730-rev.doc

 

This document does not yet reflect the recent changes to the Schema, but does include some major changes. Also, I would like the WG sense on how to proceed with some other issues with that document.

Thanks,

Bill Wagner

 

From: pwg-announce-bounces <at> pwg.org [mailto:pwg-announce-bounces <at> pwg.org] On Behalf Of Zehler, Peter
Sent: Saturday, July 31, 2010 9:59 AM
To: pwg-announce <at> pwg.org
Subject: [Pwg-Announce] Updated Plenary slides for MFD & v 1.104 of SM schema available

 

All,

I have updated the MFD plenary slides with corrected links for the MFD Requirements and FaxIn specifications.  The MFD page has all the correct document links.  Also note that I have published the latest WSDL and schema (v1.104). 

 

The updated slides are available at:

<ftp://ftp.pwg.org/pub/pwg/mfd/minutes/MFD_WG_Plenary_Aug_10.pdf>

 

The MFD page is located at:

<http://www.pwg.org/mfd/index.html>

 

 

 

Peter Zehler

Xerox Research Center Webster
Email: Peter.Zehler <at> Xerox.com
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701

 


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
pwg-announce mailing list
pwg-announce <at> pwg.org
https://www.pwg.org/mailman/listinfo/pwg-announce
Ira McDonald | 5 Aug 00:47 2010
Picon

[Pwg-Announce] Minutes for today's PWG Plenary (4 August 2010)

Hi,

Minutes for today's PWG Plenary are posted at:

  ftp://ftp.pwg.org/pub/pwg/general/minutes/pwg-plenary-minutes-20100804.htm

Please send any corrections or additions to me.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:blueroofmusic <at> gmail.com
winter:
  579 Park Place  Saline, MI  48176
  734-944-0094
summer:
  PO Box 221  Grand Marais, MI 49839
  906-494-2434

--

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
pwg-announce mailing list
pwg-announce <at> pwg.org
https://www.pwg.org/mailman/listinfo/pwg-announce

Christoph Lindemann | 9 Aug 11:37 2010

RE: Attributes needed for Cloud Printing and definitioninconsistencies

Hi,

 

Would it also be possible to add some sort of parent job UUID list/hierarchy? So it will be possible to track source/parent jobs after splitting a job into several jobs.

 

For example (maybe not the best, but..):

Imagine I have a company internal print cloud, to which I submit the jobs. This cloud could forward jobs to other external clouds, based on location (one provider for US, another for EU,…), cost or other parameters.

 

So if I need to print a marketing document in both US and EU, I could submit the job to a special queue in the company cloud, which again would submit 1 copy to my local DeskJet printer, submit a new job with 10000 copies to the external EU print/cloud partner and another 10000 to the US partner.

In this example, the jobs at the two external clouds, better not have the same UUID if I need to track them. But I would still need the “root job” UUID for doing accounting.

 

Hope this makes sense,

Christoph Lindemann

 

 

From: ipp-bounces <at> pwg.org [mailto:ipp-bounces <at> pwg.org] On Behalf Of Zehler, Peter
Sent: Thursday, July 22, 2010 8:48 PM
To: ipp <at> pwg.org; mfd <at> pwg.org
Subject: [IPP] Attributes needed for Cloud Printing and definitioninconsistencies

 

Job Identifiers:

*existing*

job-id (SM: JobId): The identifier for a job with a local scope.  That is the ID is unique within the service.  The ID may be reused in other instance of a Printer (i.e. Print Service)  or for jobs in other types of services (e.g. Copy Service).  Datatype: abstract:int32, IPP:integer, SM:xs:int

 

*new*

job-uuid (SM:JobUuid):  The identifier for a job with a global scope.  The identifier is unique for a Job across all service instances of any service type.    The UUID URN namespace is specified in rfc4122.  The format used for “job-uuid” is the string representation of a UUID as a URN.  An example is “urn:uuid:a6b90f34-d0b1-1956 -7dec-009c4386fe3”.  The version (aka subtype) used is implementation specific.  Version 1 (i.e. time based) is recommended.   Datatype: abstract:char[64], IPP:uri MaxLength=64, SM:xs:anyURI maxLen=64

 

Note:  I do not believe the IPP attribute “job-uri” is applicable as a globally unique identifier.

1)   RFC2911 states “Since every URL is a specialized form of a URI, even though the more generic term URI is used throughout the rest of this document, its usage is intended to cover the more specific notion of URL as well.”.   All uses of the uri syntax is really a URL syntax.

2)   URL implies not only a specific protocol binding but also a location.

3)   Locations can be specified using an IP address that need not be locally unique (e.g. 192.168.1.1, localhost)

4)   Regarding the “job-uri” RFC2911  further states that “This URI is then used by clients as the target for subsequent Job operations.”.  The globally unique identifier for a job should not specify a transport endpoint for a specific protocol.  

5)   The globally unique identifier for a Job, Printer or Service should be a URN.  It should be protocol independent so that a product that supports multiple protocols should have the same identifiers regardless of the protocol mapping.

6)   The  globally unique identifier for a Job, Printer or Service should require no central authority to administrate them.  Generation of a unique identifier should be simple from an administrative point of view and preferably automated.

 

Note: Both the local and global identifiers should be mandated.  For legacy protocol mappings (e.g. IPP 1.1, WS-Print, LPR) the local identifier MUST still be maintained.  It is possible to use the time_low portion of the Timestamp in the version 1 UUID as the local identifier.  The implementation may then keep only the 128 bit local representation of the UUID and use it to create the appropriate protocol values.

 

Printer Identifiers:

*existing (Service Monitoring MIB)*

applIndex (SM: <service>Id i.e. PrinterId): The service identifier with a local scope.  That is the ID is unique across the service instances collocated on a host.  Datatype: abstract:int32, MIB:integer, SM:xs:int

 

*new*

printer-uuid (SM:ServiceUuid):  The identifier for a Printer with a global scope.  The identifier is unique across all service instances of any service type.    The UUID URN namespace is specified in rfc4122.  The format used for “job-uuid” is the string representation of a UUID as a URN.  An example is “urn:uuid:a6b90f34-d0b1-1956 -7dec-009c4386fe3”.  The version (aka subtype) used is implementation specific.  Version 1 (i.e. time based) is recommended.   Datatype: abstract:char[64], IPP:uri, SM:xs:anyURI maxLen=64

 

Note:  I do not believe the IPP attribute “printer-uri” is applicable as a globally unique identifier. 

1)   RFC2911 states “Since every URL is a specialized form of a URI, even though the more generic term URI is used throughout the rest of this document, its usage is intended to cover the more specific notion of URL as well.”.   All uses of the uri syntax is really a URL syntax.

2)   URL implies not only a specific protocol binding but also a location.

3)   Locations can be specified using an IP address that need not be locally unique (e.g. 192.168.1.1, localhost)

4)   The printer may have multiple “printer-uri” values as enumerated in the “printer-uris-supported” attribute.  There should be only a single  identifier for a printer.

5)   The globally unique identifier for a Job, Printer or Service should be a URN.  It should be protocol independent so that a product that supports multiple protocols should have the same identifiers regardless of the protocol mapping.

6)   The  globally unique identifier for a Job, Printer or Service should require no central authority to administrate them.  Generation of a unique identifier should be simple from an administrative point of view and preferably automated.

 

 

Note: The local instance id in the MIB and SM are artifacts of the model’s data binding and are insufficient for use as an identifier.  IPP’s printer-uri, the URL for Web Service bindings (e.g. WS-Print) and the IP address for legacy protocols such as LPR and Port 9100 are also insufficient.  They need not be globally unique.  Nonroutable IP addresses may be used. 

 

Printer Location:

*existing*

printer-location (SM: ServiceLocation): Identifies the location of the device that this Printer represents.  (Example: Pete’s Office)  This is helpful for a human but is pretty much useless for geolocation since the content is implementation specific.   Datatype: abstract:char[127], IPP:string MaxLength=127, SM:xs:int

 

*new*

printer-geo-location (SM:ServiceGeoLocation):  This identifies the location of the associated device using the World Geodetic System 1984(WGS84).  The means for expressing the location information is the same as used in DNS (rfc1876)  Datatype: abstract:class, IPP:collection, SM:sequence

 

*new*

size (SM:Size):  Diameter of the bounding sphere containing the device expressed in centimeters.    Datatype: abstract: int32, IPP:integer, SM:xs:int

 

*new*

horizontal-precision (SM: HorizontalPrecision):  The horizontal precision expressed as the diameter of the “circle of error” (i.e. twice the +- error value)  The units are centimeters.    Datatype: abstract: int32, IPP:integer, SM:xs:int

 

*new*

vertical-precision (SM: VerticalPrecision):  The vertical precision expressed as the diameter of the “circle of error” (i.e. twice the +- error value)  The units are centimeters.    Datatype: abstract:integer, IPP: int32, SM:xs:int

 

*new*

latitude (SM:Latitude):  The latitude of the center of the sphere described by the size attribute.  Expressed in thousandths of a second of arc.  The value 2147483648  (231) represents the equator.  Values above that are north and below are south.   Datatype: abstract: int32, IPP:integer, SM:xs:int

 

*new*

longitude (SM:Latitude):  The longitude of the center of the sphere described by the size attribute.  Expressed in thousandths of a second of arc.  The value 2147483648  (231) represents the prime meridian.  Values above that are east and below are south.  The value is rounded away from the prime meridian   Datatype: abstract: int32, IPP:integer, SM:xs:int

 

*new*

altitude (SM:Altitude):  The altitude of the center of the sphere described by the size attribute.  Expressed in centimeters from a base of 100,000m below the reference spheroid used by GPS [WGS 84].  Altitude above (or below) sea level may be used as an approximation of altitude relative to the [WGS 84] spheroid, though due to the Earth's surface not being a perfect spheroid, there will be differences.    Datatype: abstract: int32, IPP:integer, SM:xs:int

 

Note:  There is disagreement on the semantics for all the attributes between what is posted on <http://pwg-wiki.wikispaces.com/Geolocation>  and what I have in the definition above.  I took the definition directly from rfc1876 (I think).  See included text from rfc1876 and the location example below. 

 

 

 

Peter Zehler

Xerox ResearchCenter Webster
Email: Peter.Zehler <at> Xerox.com
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701

 

 

From rfc1876 section 2 <http://www.rfc-editor.org/rfc/rfc1876.txt>

 

SIZE         The diameter of a sphere enclosing the described entity, in

             centimeters, expressed as a pair of four-bit unsigned

             integers, each ranging from zero to nine, with the most

             significant four bits representing the base and the second

             number representing the power of ten by which to multiply

             the base.  This allows sizes from 0e0 (<1cm) to 9e9

             (90,000km) to be expressed.  This representation was chosen

             such that the hexadecimal representation can be read by

             eye; 0x15 = 1e5.  Four-bit values greater than 9 are

             undefined, as are values with a base of zero and a non-zero

             exponent.

 

             Since 20000000m (represented by the value 0x29) is greater

             than the equatorial diameter of the WGS 84 ellipsoid

             (12756274m), it is therefore suitable for use as a

             "worldwide" size.

 

HORIZ PRE    The horizontal precision of the data, in centimeters,

             expressed using the same representation as SIZE.  This is

             the diameter of the horizontal "circle of error", rather

             than a "plus or minus" value.  (This was chosen to match

             the interpretation of SIZE; to get a "plus or minus" value,

             divide by 2.)

 

VERT PRE     The vertical precision of the data, in centimeters,

             expressed using the sane representation as for SIZE.  This

             is the total potential vertical error, rather than a "plus

             or minus" value.  (This was chosen to match the

             interpretation of SIZE; to get a "plus or minus" value,

             divide by 2.)  Note that if altitude above or below sea

             level is used as an approximation for altitude relative to

             the [WGS 84] ellipsoid, the precision value should be

             adjusted.

 

LATITUDE     The latitude of the center of the sphere described by the

             SIZE field, expressed as a 32-bit integer, most significant

             octet first (network standard byte order), in thousandths

             of a second of arc.  2^31 represents the equator; numbers

             above that are north latitude.

 

LONGITUDE    The longitude of the center of the sphere described by the

             SIZE field, expressed as a 32-bit integer, most significant

             octet first (network standard byte order), in thousandths

             of a second of arc, rounded away from the prime meridian.

             2^31 represents the prime meridian; numbers above that are

             east longitude.

 

ALTITUDE     The altitude of the center of the sphere described by the

             SIZE field, expressed as a 32-bit integer, most significant

             octet first (network standard byte order), in centimeters,

             from a base of 100,000m below the [WGS 84] reference

             spheroid used by GPS (semimajor axis a=6378137.0,

             reciprocal flattening rf=298.257223563).  Altitude above

             (or below) sea level may be used as an approximation of

             altitude relative to the the [WGS 84] spheroid, though due

             to the Earth's surface not being a perfect spheroid, there

             will be differences.  (For example, the geoid (which sea

             level approximates) for the continental US ranges from 10

             meters to 50 meters below the [WGS 84] spheroid.

             Adjustments to ALTITUDE and/or VERT PRE will be necessary

             in most cases.  The Defense Mapping Agency publishes geoid

             height values relative to the [WGS 84] ellipsoid.

 

 

 

 

 

 

 

2-Dimmensional Location of my office printer

Google Map URL:

http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=800+phillips+rd+webster+ny+14580&sll=37.0625,-95.677068&sspn=62.226996,106.962891&ie=UTF8&hq=&hnear=800+Phillips+Rd,+Webster,+Monroe,+New+York+14580&ll=43.220973,-77.417162&spn=0.001781,0.003264&t=h&z=19

Location representations:

Decimal Degrees (WGS84)

Latitude Longitude
43.220973 -77.417162

Degrees, Minutes & Seconds

Latitude Longitude
N43 13 15 W77 25 01

GPS

Latitude Longitude
N 43 13.258 W 77 25.030

UTM

 X Y

18N 303685 4788191

 

My office elevation:

12800 centimeters (419 feet) above sea level

Size of Printer:

91 centimeter (3 feet)

Margin of error

183 centimeter (6 feet)

 

PrinterGeoLocation (RFC1876)

Size = 258 (0x0102) (encoded centimeter)
HorizontalPrecision = 514 (0x0202)  (encoded centimeter)
VerticalPrecision = 514 (0x0202)  (encoded centimeter)

Latitude = 2303079151 (thousandths of a second of arc, 231 represent equater)  ( (DecimalDegreeLatitude*60*60*1000)+2147483648 )

Longitude = 1868781865 (thousandths of a second of arc, 231 represent prime meridian) ( 2147483648-(DecimalDegreeLongitude*60*60*1000) )
Altitude = 10012800 (centimeter)  (OfficeElevation+10000000)

 

 


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
ipp mailing list
ipp <at> pwg.org
https://www.pwg.org/mailman/listinfo/ipp
Michael Sweet | 9 Aug 22:59 2010
Picon

[Pwg-Announce] PWG MFD Requirements Formal Vote (9-31 August 2010)

Greetings:

This email initiates the Formal Approval vote by the PWG membership on the PWG MFD Requirements, which is
located at:

    ftp://ftp.pwg.org/pub/pwg/mfd/wd/wd-mfdreq10-20100722.pdf

The complete list of PWG Last Call issues and resolutions is located at:

    ftp://ftp.pwg.org/pub/pwg/mfd/wd/mfdreq10-last-call-comment-resolution-20100722.txt

The voting period will open today on Monday 9 August 2010 and will close at 10pm (US Pacific Time) on Tuesday
31 August 2010.

Valid votes are: Yes, No, No (with Strong Objection), Abstain.

Representatives from PWG member companies are strongly encouraged to exercise their right to vote.

PWG Privacy Policy:  Your vote is confidential and will not be disclosed by PWG officers or document editors.

To vote, send an email with *exactly* the following subject line format:

    MFD Requirements Formal Vote-<company name>-<voter's last name>-<Yes/No/Abstain>

Example: MFD Requirements Formal Vote-Acme-McGee-Yes

Any "No" vote MUST state the reason for the "No" vote and MUST contain a description of the *technical*
changes required to turn the "No" vote into a "Yes" vote - otherwise such a "No" vote will NOT be counted.  Any
"No" vote MUST NOT contain *editorial* comments, per the PWG Process/3.0.

Any "Yes" vote MAY contain "editorial" comments but MUST NOT contain any *technical* comments, per the PWG Process/3.0.

Please send your vote to all of the following email addresses (replacing "dot" with '.' and "at" with ' <at> '):

    msweet"at"apple"dot"com (PWG Chair)

    ptykodi"at"tykodi"dot"com (PWG Secretary) 

    Peter"dot"Zehler"at"xerox"dot"com (MFD WG Chair)

    wamwagner"at"comcast"dot"net (MFD Requirements Editor)

Please do NOT simply reply to this note on PWG-Announce (to preserve the confidentiality of your vote).

Note:
(1) This Formal Vote is being conducted under the rules of the PWG Process/3.0 and the current PWG Policy on
Intellectual Property and Confidentiality agreement. The 2010 PWG Membership Agreement calls out both
of these documents and the links are provided below.

(2) To be eligible to vote the member MUST have submitted a signed copy of the 2010 PWG Membership Agreement
and paid their dues.

The PWG Definition of the Standards Development Process Version 3.0 is located at:

    http://www.pwg.org/chair/membership_docs/pwg-process30.pdf

The PWG Policy on Intellectual Property and Confidentiality is located at:

    http://www.pwg.org/chair/membership_docs/pwg-ip-policy.pdf

Regards,
Michael Sweet (PWG Chair)
--

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
pwg-announce mailing list
pwg-announce <at> pwg.org
https://www.pwg.org/mailman/listinfo/pwg-announce

Michael Sweet | 13 Aug 20:51 2010
Picon

IPP Face-to-face Minutes Posted for August F2F

All,

I've posted the minutes for the IPP face-to-face meeting at:


Apologies for the delay; for some reason I thought I had posted them already...

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair





--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
ipp mailing list
ipp <at> pwg.org
https://www.pwg.org/mailman/listinfo/ipp
Ira McDonald | 20 Aug 22:53 2010
Picon

[Pwg-Announce] Fwd: [Isms] RFC 5953 - TLS Transport Model for SNMP

Hi,

The long-awaited enterprise network-friendly way to deploy SNMP
authentication and security using TLS and DTLS.

Recommended reading.

Cheers,
- Ira

---------- Forwarded message ----------
From:  <rfc-editor <at> rfc-editor.org>
Date: Fri, Aug 20, 2010 at 2:14 PM
Subject: [Isms] RFC 5953 on Transport Layer Security (TLS) Transport
Model for the Simple Network Management Protocol (SNMP)
To: ietf-announce <at> ietf.org, rfc-dist <at> rfc-editor.org
Cc: isms <at> ietf.org, rfc-editor <at> rfc-editor.org

A new Request for Comments is now available in online RFC libraries.

       RFC 5953

       Title:      Transport Layer Security (TLS) Transport
                   Model for the Simple Network Management
                   Protocol (SNMP)
       Author:     W. Hardaker
       Status:     Standards Track
       Stream:     IETF
       Date:       August 2010
       Mailbox:    ietf <at> hardakers.net
       Pages:      65
       Characters: 147393
       Updates/Obsoletes/SeeAlso:   None

       I-D Tag:    draft-ietf-isms-dtls-tm-14.txt

       URL:        http://www.rfc-editor.org/rfc/rfc5953.txt

This document describes a Transport Model for the Simple Network
Management Protocol (SNMP), that uses either the Transport Layer
Security protocol or the Datagram Transport Layer Security (DTLS)
protocol.  The TLS and DTLS protocols provide authentication and
privacy services for SNMP applications.  This document describes how
the TLS Transport Model (TLSTM) implements the needed features of a
SNMP Transport Subsystem to make this protection possible in an
interoperable way.

This Transport Model is designed to meet the security and operational
needs of network administrators.  It supports the sending of SNMP
messages over TLS/TCP and DTLS/UDP.  The TLS mode can make use of
TCP's improved support for larger packet sizes and the DTLS mode
provides potentially superior operation in environments where a
connectionless (e.g., UDP) transport is preferred.  Both TLS and DTLS
integrate well into existing public keying infrastructures.

This document also defines a portion of the Management Information
Base (MIB) for use with network management protocols.  In particular,
it defines objects for managing the TLS Transport Model for SNMP.
[STANDARDS TRACK]

This document is a product of the Integrated Security Model for SNMP
Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
 http://www.ietf.org/mailman/listinfo/ietf-announce
 http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor <at> rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
Association Management Solutions, LLC

_______________________________________________
Isms mailing list
Isms <at> ietf.org
https://www.ietf.org/mailman/listinfo/isms

--

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
pwg-announce mailing list
pwg-announce <at> pwg.org
https://www.pwg.org/mailman/listinfo/pwg-announce

Ira McDonald | 21 Aug 19:43 2010
Picon

Proposal for mapping Printer MIB into IPP

Hi,                                            Saturday (21 August 2010)

Per my action item from our August 2010 PWG Meeting, here is my proposal
for a new IPP spec called "IPP Printer Device Extensions".

Since the complete ABNF and mapping rules for all 170+ objects defined
in the Printer MIB will be fairly long, I suggest that this should be in
a separate IPP spec and not simply included in "IPP Everywhere" spec.

Comments?

Cheers,
- Ira

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

Approach:

- Avoid use of new Object (e.g., Device) or Collection to reduce cost
  for lightweight mobile implementations of IPP Clients

- Follow style of IPP PSX mapping of prtAlertTable, i.e., array of text
  parameters in "printer-alert" representing most columns and separate
  attributes like "printer-alert-description" for string MIB objects

- Convert all enumerated values from Printer MIB into IANA registered
  string names, e.g., "prtChannelType" of "38" maps to "chBidirPortTCP"

- Map bit masks, e.g., "prtChannelStatus (PrtSubUnitStatusTC), directly
  as integers (because string encoding in IPP is too verbose)

Pros:

- Simple human-readable text encoding

- Lightweight (no new attribute groups, objects, etc.)

- High fidelity mapping from Printer MIB objects to IPP attributes

Cons:

- Like "printer-alert", maps a *single* physical output device onto an
  IPP Printer object

- Note that this precedent was already established with "printer-alert"
  which has shipped in CUPS and various printers for several years

Examples:

printer-channel[1] =
    "index=1;type=chBidirPortTCP;jclIndex=0;pdlIndex=1;
    state=printDataAccepted;ifIndex=3;status=0;"

printer-channel-version[1] =
    "Bi-Directional Raw TCP/IP Printing"

printer-channel-info[1] =
    "Port=9100"

printer-marker[1] =
    "index=1;markTech=inkjetAqueous;counterUnit=impressions;
    lifeCount=23412;powerOnCount=479;processColorants=4;
    spotColorants=0;addressUnit=tenThousandthsOfInches;
    addressFeedDir=600;addressXFeedDir=600;
    northMargin=1066;southMargin=1066;eastMargin=1066;westMargin=1066;
    status=0;"

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

--

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
ipp <at> pwg.org
https://www.pwg.org/mailman/listinfo/ipp

Ira McDonald | 21 Aug 19:59 2010
Picon

Re: PWG Last Call of IPP JPS2 (26 July to 27 August 2010)

Hi,

Reminder that this PWG Last Call for IPP JPS2
will end this coming Friday (27 August 2010).

Please take the time to review this document and
send your acknowledgment as described below,
so that we can achieve the quorum required by the
PWG Process/3.0 in order to exit from PWG Last
Call.

Thanks,
- Ira McDonald (IPP editor)

On Mon, Jul 26, 2010 at 11:19 PM, Michael Sweet <msweet <at> apple.com> wrote:
> Greetings:
>
> [This PWG Last Call will start today on Monday 26 July 2010.
> This PWG Last Call will end at Friday 27 August 2010 at 10pm US PDT.]
>
> This is the formal announcement of the PWG Last Call for the IPP Job and
> Printer Operations Set-2 (JPS2) specification, which is located at:
>
>  ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v31-20100725-clean.pdf
>
> All required operations and attributes defined in this document have been
> prototyped by Apple and/or Xerox.  The IPP WG has completed a working
> group last call and subsequent revisions of this document.
>
> The PWG Process/3.0 requires that a quorum (30%) of PWG voting members
> must acknowledge a PWG Last Call (with or without comments), before any
> document can progress to PWG Formal Vote.
>
> Please send your review acknowledgment *exactly* as follows:
>
> To:  ipp <at> pwg.org
> Subject:  <Company Name> has reviewed IPP JPS2 and has [no] comments
>
>
> Please do NOT simply reply to this note on the PWG-Announce list.
>
>
> Note:  The PWG Definition of the Standards Development Process Version 3.0
> is located at:
>
>  http://www.pwg.org/chair/membership_docs/pwg-process30.pdf
>
> Regards,
> - Michael Sweet (PWG Chair)
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> _______________________________________________
> pwg-announce mailing list
> pwg-announce <at> pwg.org
> https://www.pwg.org/mailman/listinfo/pwg-announce
>
>

--

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
ipp <at> pwg.org
https://www.pwg.org/mailman/listinfo/ipp

Ira McDonald | 21 Aug 23:05 2010
Picon

Stable Draft of IPP/2.0 Second Edition (21 August 2010)

[Based on IPP WG complete review on 5 August - for review at IPP
WG meeting on 21 August and IPP WG Last Call]

I've just posted a Stable draft of IPP/2.0 Second Edition at:

 ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipp20-20100821.pdf / doc
 - clean copy with line numbers

 ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipp20-20100821-rev.pdf / doc
 - redlines from 18 July draft

Prototype reports for IPP/2.2 new content already exist.

So this spec is ready for final review, IPP WG last call, and PWG
Last Call.

Comments?

Cheers,
- Ira

------------------------------------------------------------------------------
Changes made to create 21 August 2010 version (Stable Draft)

Editorial – Changed status to Stable Draft – all changes below per
IPP WG review at August F2F

Editorial – Revised Table 1 in section 4, to move 3 TLS versions
together at end, add note that empty cells mean OPTIONAL, and
extend non-OPTIONAL levels to the right

Editorial – Revised Tables 4 and 5 in section 5 to remove gray
background on IPP/1.1 rows

Editorial – Revised all Tables to make heading rows repeat (across
pages)

Editorial – Revised Table 6 in section 6.1 to add operation-id,
request-id, status-code, and version-number as REQUIRED
parameters in all operation requests and/or responses

Editorial – Revised Table 6 in section 6.1 to make
requested-attributes and requesting-user-name apply to All objects

Editorial – Revised Table 7 in section 6.2 to change
“CONDITIONAL” to “REQUIRED for color”

Editorial – Global – Changed “STRONGLY RECOMMENDED”
to “RECOMMENDED”

Editorial – Revised Acknowledgments table, adding and
correcting several rows

--

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
ipp <at> pwg.org
https://www.pwg.org/mailman/listinfo/ipp

Ira McDonald | 21 Aug 23:10 2010
Picon

IPP Agenda - 4pm EDT Monday 21 August 2010

Hi,

[as planned at our August F2F]

Reminder of our next IPP WG call:

 Monday 21 August - 1-2pm PDT / 4-5pm EDT

 Call-in toll-free number (US/Canada): 1-866-469-3239
 Call-in toll number (US/Canada): 1-650-429-3300 (Primary)
 Call-in toll number (US/Canada): 1-408-856-9570 (Backup)

 Attendee Access Code: *******#
 Attendee ID Code: # (empty)

If you need the Attendee Access code, please email me a request.

*** Main Objective - move IPP/2.0 SE into IPP WG Last Call ***

Agenda:

(1) PWG IP Policy and Minute Taker
  - Mike?

(2) Approve IPP minutes from last meeting (August F2F)
  - ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-f2f-minutes-20100805.pdf

(3) Status of IPP Version 2.0 Second Edition (Ira)
  - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipp20-20100821-rev.pdf
    (new Stable draft for IPP WG last call - no open issues)

(4) Status of PWG Last Call on IPP JPS2 (Tom)
  - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v31-20100725-clean.pdf
    (ends Friday 27 August)

(5) Review of IPP Printer Device Extensions proposal (Ira)
  - email proposal sent on 21 August

(6) Status of IPP Everywhere Project (Mike/Ira)
  - ftp://ftp.pwg.org/pub/pwg/ipp/slides/ipp-wg-agenda-august-10.pdf
    (other pending action items?)

(7) Next Steps
 - IPP WG - Monday 13 September (Monday 6th is Labor Day)
 - IPP/2.0 SE into IPP WG Last Call?
 - IPP JPS2 into PWG Formal Vote?

Cheers,
- Ira (IPP co-editor)

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:blueroofmusic <at> gmail.com
winter:
  579 Park Place  Saline, MI  48176
  734-944-0094
summer:
  PO Box 221  Grand Marais, MI 49839
  906-494-2434

--

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
ipp <at> pwg.org
https://www.pwg.org/mailman/listinfo/ipp


Gmane