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/blueroofmusichttp://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
On Mon, Jul 26, 2010 at 7:52 AM, Zehler, Peter <Peter.Zehler at xerox.com> wrote:
> My comments are inline below
>>>>>> 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
>>>> From: Tom Hastings [mailto:tom.hastings at verizon.net]
> Sent: Monday, July 26, 2010 1:11 AM
> To: Zehler, Peter; ipp at pwg.org; mfd at pwg.org; cloud at pwg.org> 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>
>>>> 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 L:
>> 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 .
> 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?
>> <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: ipp-bounces at pwg.org [mailto:ipp-bounces at pwg.org] On Behalf Of Zehler,
> Peter
> Sent: Thursday, July 22, 2010 11:48
> To: ipp at pwg.org; mfd at pwg.org> Subject: [IPP] Attributes needed for Cloud Printing and definition
> inconsistencies
>>>> 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*(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
>>>> 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> 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) (Corrected)
>> Size = 18 (0x12) (encoded centimeter) (corrected)
> HorizontalPrecision = 34 (0x22) (encoded centimeter) (corrected)
> VerticalPrecision = 34 (0x22) (encoded centimeter) (corrected)
>> 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.
> _______________________________________________
> mfd mailing list
>mfd at pwg.org>https://www.pwg.org/mailman/listinfo/mfd>>
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.