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.
RSS Feed