[MFD] RE: [IPP] Attributes needed for Cloud Printing and definition inconsistencies [4 questions about the representation of the values]

[MFD] RE: [IPP] Attributes needed for Cloud Printing and definition inconsistencies [4 questions about the representation of the values]

[MFD] RE: [IPP] Attributes needed for Cloud Printing and definition inconsistencies [4 questions about the representation of the values]

Ira McDonald blueroofmusic at gmail.com
Mon Jul 26 16:54:37 UTC 2010


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: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.




More information about the mfd mailing list