[MFD] Attributes needed for Cloud Printing and definition inconsistencies

[MFD] Attributes needed for Cloud Printing and definition inconsistencies

[MFD] Attributes needed for Cloud Printing and definition inconsistencies

Zehler, Peter Peter.Zehler at xerox.com
Thu Jul 22 18:48:27 UTC 2010


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: Peter.Zehler at Xerox.com <mailto: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.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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/mfd/attachments/20100722/e7fc6afc/attachment-0001.html>


More information about the mfd mailing list