Subject: [IPP] Attributes needed for Cloud Printing and definition inconsistencies

From: "Zehler, Peter" <[email-masked]>
Date: Thu, 22 Jul 2010 11:48:27 -0700

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 Research Center Webster
Email: [email-masked] <mailto:[email-masked]> 
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.2
20973,-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.

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: "Tom Hastings" <[email-masked]>
Date: Sun, 25 Jul 2010 15:00:34 -0700

Pete,

I assume that there is a typo in the definition of "longitude".  The
sentence:

Values above that are east and below are south

should be:

Values above that are east and below are west

Here are the two descriptions of the two new attributes for "latitude" and
"longitude":

*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

Tom

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Zehler,
Peter
Sent: Thursday, July 22, 2010 11:48
To: [email-masked]; [email-masked]
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

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.

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:

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.

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*

*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*

*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 Research Center Webster
Email:  <mailto:[email-masked]> [email-masked]
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 

             exponent.

             "worldwide" size.

 

 

 

Google Map URL:

http://maps.google.com/maps?f=q
<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&h
q=&hnear=800+Phillips+Rd,+Webster,+Monroe,+New+York+14580&ll=43.220973,-77.4
17162&spn=0.001781,0.003264&t=h&z=19>
&source=s_q&hl=en&geocode=&q=800+phillips+rd+webster+ny+14580&sll=37.0625,-9
5.677068&sspn=62.226996,106.962891&ie=UTF8&hq=&hnear=800+Phillips+Rd,+Webste
r,+Monroe,+New+York+14580&ll=43.220973,-77.417162&spn=0.001781,0.003264&t=h&
z=19 

Decimal Degrees (WGS84)

Latitude Longitude 
43.220973 -77.417162 

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:

Size of Printer:

91 centimeter (3 feet)

Margin of error

183 centimeter (6 feet)

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  <http://www.mailscanner.info/> MailScanner, and is 
believed to be clean.

---

From: "Tom Hastings" <[email-masked]>
Date: Sun, 25 Jul 2010 22:10:47 -0700

Pete,

I have 4 questions about your proposed IPP attributes for Geo Location for
Cloud Printing:

1. The representation of the values of your proposed IPP "size",
"horizontal-precision", and "vertical-precision" attributes are completely
different from the representation of the same attributes in RFC1876.

If this difference is intentional, it would be good to explain the
difference and why and to indicate this intended difference in the spec?

As I read RFC 1876, the representation of the SIZE, HORIZ PRE, and VERT PRE
attributes are all using this funny SIZE representation as a pair of
four-bit unsigned integers, where the most significant 4-bit unsigned
integer represents the base and the second 4-bit integer represents the
power of 10 by which to multiple the base, sort of a compressed floating
point representation, but using power of 10, not power of 2.  The reason
give in RFC 1876 is so that the value is more easily human readable.  HORIZ
PRE and VERT PRE attributes defined in RFC 1876, say:

expressed using the same representation as SIZE

i.e., using this same 8-bit "floating point" representation.

BTW, the VERT PRE attribute has an ironic Freudian slip typo in RFC 1876,
since I don't find this representation very sane :-(:
expressed using the sane representation as for SIZE

2. The definitions on the <http://pwg-wiki.wikispaces.com/Geolocation>
appear to be part of the PWG Semantic Model:

This page proposes an IPP collection representing the DNS LOC data defined
in RFC 1876 <http://www.rfc-editor.org/rfc/rfc1876.txt>  .
printer-geo-location (collection)
The "printer-geo-location" attribute provides the physical location of the
printer. The collection has the following member attributes.
size (integer (0:MAX))

Diameter of enclosing sphere for printer in centimeters. 0 represents any
size less than one centimeter.
horizontal-precision (integer (0:MAX))

The circle of error of the latitude and longitude measurement in
centimeters. 0 represents an error of less than one centimeter.
vertical-precision (integer(0:MAX))

The circle of error of the altitude measurement in centimeters. 0 represents
an error of less than one centimeter.
latitude (integer(-324000000:324000000))

The latitude in thousandths of arc seconds from the equator. 0 represents
the equator, positive values represent locations North of the equator, and
negative values represent locations South of the equator.
longitude (integer(-648000000:648000000))

The longitude in thousandths of arc seconds from the prime meridian. 0
represents the prime meridian, positive values represent locations East of
the meridian, and negative values represent locations West of the meridian.
altitude (integer(-100000:MAX))

The distance in centimeters from the WGS-84 ellipsoid to the center of the
enclosing sphere defined by the "side" member attribute. 0 represents the
WGS-84 ellipsoid height, positive values represent locations above the
ellipsoid, and negative values represent locations below the ellipsoid. 

The PWG SM definitions appear to use signed 32-bit integer notation and
description which have the same bit representation as the unsigned 32-bit
integer notation and description in RFC 1876, right?  Why change to use the
unsigned integer notation and descriptions, when the rest of the SM and IPP
use signed integer notations and descriptions?

3. What is the relationship between Cloud Printing (which these definitions
are proposed for) and IPP Everywhere?

4. I like the idea used in IPP and the SM to have the data type indicate the
range of values in the definition of the attribute name and attribute
syntax, i.e., latitude (integer(-324000000:324000000)).  Why isn't this
technique of specifying the data type and the data type range used in your
proposal for attributes needed for Cloud Printing?

Tom

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Zehler,
Peter
Sent: Thursday, July 22, 2010 11:48
To: [email-masked]; [email-masked]
Subject: [IPP] Attributes needed for Cloud Printing and definition
inconsistencies

Job Identifiers:

*existing*

*new*

Printer Identifiers:

*new*

 

Printer Location:

*existing*

*new*

*new*

*new*

*new*

*new*

*new*

*new*

 

Peter Zehler

 

             exponent.

             "worldwide" size.

 

 

 

Google Map URL:

Decimal Degrees (WGS84)

Latitude Longitude 
43.220973 -77.417162 

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:

Size of Printer:

91 centimeter (3 feet)

Margin of error

183 centimeter (6 feet)

---

From: "Zehler, Peter" <[email-masked]>
Date: Mon, 26 Jul 2010 04:52:46 -0700

My comments are  inline below

Peter Zehler

Xerox Research Center Webster
Email: [email-masked]
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: Tom Hastings [mailto:[email-masked]] 
Sent: Monday, July 26, 2010 1:11 AM
To: Zehler, Peter; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [IPP] Attributes needed for Cloud Printing and definition
inconsistencies [4 questions about the representation of the values]

Pete,

I have 4 questions about your proposed IPP attributes for Geo Location
for Cloud Printing:

1. The representation of the values of your proposed IPP "size",
"horizontal-precision", and "vertical-precision" attributes are
completely different from the representation of the same attributes in
RFC1876.

<PZ>I made a mistake in my values.  I used 8 bit unsigned integers
instead of 4 bit.  The values should be; Size= 18 (0x12),
HorizontalPrecision=34 (0x22), VerticalPrecision=34 (0x22).  (This is
why I really don't like this representation.  That and the fact that for
the dimensions associated with MFDs it is not as precise a expressing it
in simple centimeters)</PZ>

As I read RFC 1876, the representation of the SIZE, HORIZ PRE, and VERT
PRE attributes are all using this funny SIZE representation as a pair of
four-bit unsigned integers, where the most significant 4-bit unsigned
integer represents the base and the second 4-bit integer represents the
power of 10 by which to multiple the base, sort of a compressed floating
point representation, but using power of 10, not power of 2.  The reason
give in RFC 1876 is so that the value is more easily human readable.
HORIZ PRE and VERT PRE attributes defined in RFC 1876, say:

BTW, the VERT PRE attribute has an ironic Freudian slip typo in RFC
1876, since I don't find this representation very sane L:
expressed using the sane representation as for SIZE

This page proposes an IPP collection representing the DNS LOC data
defined in RFC 1876 <http://www.rfc-editor.org/rfc/rfc1876.txt>  .
printer-geo-location (collection)
The "printer-geo-location" attribute provides the physical location of
the printer. The collection has the following member attributes.
size (integer (0:MAX))

Diameter of enclosing sphere for printer in centimeters. 0 represents
any size less than one centimeter.
horizontal-precision (integer (0:MAX))

The circle of error of the altitude measurement in centimeters. 0
represents an error of less than one centimeter.
latitude (integer(-324000000:324000000))

The latitude in thousandths of arc seconds from the equator. 0
represents the equator, positive values represent locations North of the
equator, and negative values represent locations South of the equator.
longitude (integer(-648000000:648000000))

The longitude in thousandths of arc seconds from the prime meridian. 0
represents the prime meridian, positive values represent locations East
of the meridian, and negative values represent locations West of the
meridian.
altitude (integer(-100000:MAX))

The distance in centimeters from the WGS-84 ellipsoid to the center of
the enclosing sphere defined by the "side" member attribute. 0
represents the WGS-84 ellipsoid height, positive values represent
locations above the ellipsoid, and negative values represent locations
below the ellipsoid. 

The PWG SM definitions appear to use signed 32-bit integer notation and
description which have the same bit representation as the unsigned
32-bit integer notation and description in RFC 1876, right?  Why change
to use the unsigned integer notation and descriptions, when the rest of
the SM and IPP use signed integer notations and descriptions?

<PZ>To the best of my knowledge printer-geo-location  is not part of the
PWG semantic model yet.  I put out this mail note to test my
understanding of the proposal on the wiki site.  I want to be sure the
semantics and syntax are well defined and the mapping to rfc1876 is
clear.</PZ>

3. What is the relationship between Cloud Printing (which these
definitions are proposed for) and IPP Everywhere?

<PZ>Cloud Printing can be implemented without IPP Everywhere.  The
initial implementations will not be using IPP or IPP Everywhere.  It
will be cobbled together with existing technologies used in Web
Services, messaging protocols, standard document formats and print
driver related technologies.  IPP could play a role in this environment
but I believe it is most critical to obtain semantic alignment between
IPP and the emerging Cloud Printing technologies.  IPP Everywhere
addresses a number of IPP shortcomings such as printer discovery, common
document formats, and interoperable security.  IPP Everywhere could
apply to Cloud Printing but would require some extensions to accommodate
intervening firewalls.</PZ>

4. I like the idea used in IPP and the SM to have the data type indicate
the range of values in the definition of the attribute name and
attribute syntax, i.e., latitude (integer(-324000000:324000000)).  Why
isn't this technique of specifying the data type and the data type range
used in your proposal for attributes needed for Cloud Printing?

<PZ>Added to definitions below.</PZ>

Tom

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Zehler, Peter
Sent: Thursday, July 22, 2010 11:48
To: [email-masked]; [email-masked]
Subject: [IPP] Attributes needed for Cloud Printing and definition
inconsistencies

Job Identifiers:

*existing*

*new*

Printer Identifiers:

*new*

 

Printer Location:

*existing*

*new*

*new*(modified)

size (SM:Size) (0x00 to 0x99):  Diameter of the bounding sphere
containing the device expressed in centimeters.    Datatype: abstract:
int32, IPP:integer, SM:xs:int  (Note: representation is 2 encoded 4 bit
integers(0-9).  Most significant represents the base and the least
significant represents the power of 10.)  

*new*(modified)

horizontal-precision (SM: HorizontalPrecision) (0x00 to 0x99):  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(Note: representation is 2
encoded 4 bit integers(0-9).  Most significant represents the base and
the least significant represents the power of 10.)  

*new*(modified)

vertical-precision (SM: VerticalPrecision) (0x00 to 0x99):  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(Note: representation is 2
encoded 4 bit integers(0-9).  Most significant represents the base and
the least significant represents the power of 10.)  

*new* (modified)

latitude (SM:Latitude(1823483648 to 4618967296): ):  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* (corrected) (modified)

longitude (SM:Latitude) (1499483648  to 4942967296) 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 west.  The
value is rounded away from the prime meridian   Datatype: abstract:
int32, IPP:integer, SM:xs:int

*new* (modified)

altitude (SM:Altitude) (0 to MAX):  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

 

Peter Zehler

 

             exponent.

             "worldwide" size.

 

 

 

Google Map URL:

Decimal Degrees (WGS84)

Latitude Longitude 
43.220973 -77.417162 

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:

Size of Printer:

91 centimeter (3 feet)

Margin of error

183 centimeter (6 feet)

PrinterGeoLocation (RFC1876) (Corrected)

Size = 18 (0x12) (encoded centimeter) (corrected)
HorizontalPrecision = 34 (0x22)  (encoded centimeter) (corrected)
VerticalPrecision = 34 (0x22)  (encoded centimeter) (corrected)

 

-- 
This message has been scanned for viruses and 
dangerous content by MailScanner <http://www.mailscanner.info/> , and is

believed to be clean.

---

From: Ira McDonald <[email-masked]>
Date: Mon, 26 Jul 2010 12:54:37 -0400

Hi,

The "printer-geo-location" attributes on that Wiki were
written by Mike Sweet and intended *specifically* for
the IPP Everywhere project.

They can certainly be added to PWG SM XML Schema
and used for Cloud Printing, but *in IPP specs* they'll be
documented in the single IPP Everywhere Protocol spec
(*after* we complete the IPP Everywhere Requirements
spec mandated by our project charter).

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:[email-masked]
winter:
  579 Park Place  Saline, MI  48176
  734-944-0094
summer:
  PO Box 221  Grand Marais, MI 49839
  906-494-2434

On Mon, Jul 26, 2010 at 7:52 AM, Zehler, Peter <[email-masked]> wrote:
> 1. The representation of the values of your proposed IPP “size”,
> “horizontal-precision”, and “vertical-precision” attributes are completely
> <PZ>I made a mistake in my values.  I used 8 bit unsigned integers instead
> of 4 bit.  The values should be; Size= 18 (0x12), HorizontalPrecision=34
> (0x22), VerticalPrecision=34 (0x22).  (This is why I really don’t like this
> representation.  That and the fact that for the dimensions associated with
> MFDs it is not as precise a expressing it in simple centimeters)</PZ>
>
>
>
> i.e., using this same 8-bit “floating point” representation.
>
>
>
> since I don’t find this representation very sane L:
>
> in RFC 1876 .
> <PZ>To the best of my knowledge printer-geo-location  is not part of the PWG
> semantic model yet.  I put out this mail note to test my understanding of
> the proposal on the wiki site.  I want to be sure the semantics and syntax
> are well defined and the mapping to rfc1876 is clear.</PZ>
>
>
>
>
>
> <PZ>Cloud Printing can be implemented without IPP Everywhere.  The initial
> implementations will not be using IPP or IPP Everywhere.  It will be cobbled
> together with existing technologies used in Web Services, messaging
> protocols, standard document formats and print driver related technologies.
> IPP could play a role in this environment but I believe it is most critical
> to obtain semantic alignment between IPP and the emerging Cloud Printing
> technologies.  IPP Everywhere addresses a number of IPP shortcomings such as
> printer discovery, common document formats, and interoperable security.  IPP
> Everywhere could apply to Cloud Printing but would require some extensions
> to accommodate intervening firewalls.</PZ>
>
>
>
>
>
> syntax, i.e., latitude (integer(-324000000:324000000)).  Why isn’t this
> 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
> Note:  I do not believe the IPP attribute “job-uri” is applicable as a
> 1)      RFC2911 states “Since every URL is a specialized form of a URI, even
> well.”.   All uses of the uri syntax is really a URL syntax.
>
> 4)      Regarding the “job-uri” RFC2911  further states that “This URI is
> then used by clients as the target for subsequent Job operations.”.  The
> 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
> Note:  I do not believe the IPP attribute “printer-uri” is applicable as a
> 1)      RFC2911 states “Since every URL is a specialized form of a URI, even
> well.”.   All uses of the uri syntax is really a URL syntax.
>
> 4)      The printer may have multiple “printer-uri” values as enumerated in
> the “printer-uris-supported” attribute.  There should be only a single
> 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
> device that this Printer represents.  (Example: Pete’s Office)  This is
> size (SM:Size) (0x00 to 0x99):  Diameter of the bounding sphere containing
> the device expressed in centimeters.    Datatype: abstract: int32,
> IPP:integer, SM:xs:int  (Note: representation is 2 encoded 4 bit
> horizontal precision expressed as the diameter of the “circle of error”
> abstract: int32, IPP:integer, SM:xs:int(Note: representation is 2 encoded 4
> bit integers(0-9).  Most significant represents the base and the least
> 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(Note: representation is 2 encoded 4 bit
> thousandths of a second of arc.  The value 2147483648  (231) represents the
> equator.  Values above that are north and below are south.   Datatype:
> thousandths of a second of arc.  The value 2147483648  (231) represents the
> prime meridian.  Values above that are east and below are west.  The value
> is rounded away from the prime meridian   Datatype: abstract: int32,
> IPP:integer, SM:xs:int
>
>
>
> *new* (modified)
>
> altitude (SM:Altitude) (0 to MAX):  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
> 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
>
> mfd mailing list
> [email-masked]
> https://www.pwg.org/mailman/listinfo/mfd
>
>

---

From: "Zehler, Peter" <[email-masked]>
Date: Mon, 26 Jul 2010 10:06:27 -0700

Before the wiki write-up by Mike is simply accepted as the IPP Everywhere definition, I want to be sure we have complete agreement on the exact semantics and syntax for the PWG as a whole.  I assume a single definition of semantics and abstract syntax is preferred.  Once we have consensus I will add that to the PWG Semantic model.  Individual protocol binding specifications can handle the encoding of the attributes.  If the PWG definition differs from RFC1876, I want to be sure that differences and mapping is clearly explained. After reading Mike's definition and RFC1876 it seems to me that they are not the same.

Peter Zehler

-----Original Message-----
From: Ira McDonald [mailto:[email-masked]] 
Sent: Monday, July 26, 2010 12:55 PM
To: Zehler, Peter; Ira McDonald
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [MFD] RE: [IPP] Attributes needed for Cloud Printing and definition inconsistencies [4 questions about the representation of the values]

Hi,

Cheers,
- Ira

On Mon, Jul 26, 2010 at 7:52 AM, Zehler, Peter <[email-masked]> wrote:
> (0x22), VerticalPrecision=34 (0x22).  (This is why I really don't like this
> since I don't find this representation very sane L:
>
> precision expressed as the diameter of the "circle of error" (i.e. twice the

---

From: Michael Sweet <[email-masked]>
Date: Mon, 26 Jul 2010 10:45:15 -0700

And FWIW, my quick write-up was meant to provide the same RFC 1876 information via IPP attributes, just without the strange encoding.

Pete: I'll compare our two definitions against RFC 1876 and provide feedback later today. I'm in 100% agreement that we want to make sure the definition we use in IPP Everywhere and the PWG Semantic model need to be consistent with each other and RFC 1876...

>   579 Park Place  Saline, MI  48176

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair