As mailers learn more about the USPS Intelligent Mail program that begins in May, they see two things repeated over and over in relation to the electronic documentation (eDoc) requirements for the Full-Service option: Mail.dat and Mail.XML. However, very few understand what the differences are between the two. Both specifications are developed by the International Digital Enterprise Alliance (IDEAlliance) — an industry association specializing in technology, supply chain, and best practices for the mailing, printing and publishing industries — and freely available as a service to the mailing industry. The specifications are used to share information among organizations in the mailing supply chain and the Postal Service and their structure and purpose are significantly different.
In the last issue, we discussed the Mail.dat specification and answered some basic questions about what it is, some of its benefits, etc. In this issue we are going to take a similar look at the latest specification from IDEAlliance: Mail.XML. The information presented here will again be in a Q&A format and will provide a basic understanding of the Mail.XML specification and its purpose. A more detailed article, focusing on business communication strategy and services architecture, will be printed in the next edition.
What is XML? XML stands for Extensible Markup Language, and is often defined as "a human-readable way of describing data or structured data." It also means that you can extend a specification with fields — without necessarily impacting your communication software. XML is the current standard of communication between two or more computers over the internet and is the Business-to-Business communication and automation standard. Today, almost all eCommerce occurs through XML.
What is Mail.XML? Mail.XML, which really began several years ago as the Transaction Messaging specification, is an XML-based communication specification developed by the IDEAlliance in collaboration with the USPS to automate business processes and communication wherever possible. Mail.XML is a messaging protocol that enables two-way communication between parties in the mailing supply chain and is designed to increase efficiency and lower costs by removing many manual data entry processes and enabling quick, near real-time communication between business partners. The core focus of Mail.XML is light-weight, business-function-specific communication where computers are "talking" with each other.
What information is Mail.XML communicating? Mail.XML uses the comprehensive Mail.dat database to communicate mailing related information and specific transactions between members of the mailing supply chain, i.e., buying of services for printing, manufacturing, and transportation processes. In addition, the information communicated to and from the USPS supports mail verification, acceptance, and induction processes.
What types of messages does Mail.XML support? Mail.XML currently supports container-based scheduling, pick up and drop off business processes, as well as identifying different business entities responsible for performing different services such as quality of mailing, address correction, and delivery confirmation on a mailing. Mail.XML also supports the communication of eDoc with the PostalOne! system.
Does the USPS currently support Mail.XML? Yes. The original Transaction Messaging specification has been supported by the USPS since 2004. The initial focus was FAST appointment scheduling and automation processes. The new version of Mail.XML (version 6.0) supports eDoc requirements for the Intelligent Mail Full-Service option, as well as the Full-Service data feedback requirements from the USPS to the industry.
The USPS is taking a phased approach to the Mail.XML version 6.0 implementation: In May 2009, the USPS will support all transportation and appointments needs for the Full-Service option. It will also provide the capability for mailers to receive ACS Change Of Address (COA) and Nixie data, as well as Start-the-Clock and Container Scan data. In November 2009, the USPS plans to support all Full-Service eDoc functionality through Mail.XML version 6.0.
What types of messages will be supported with version 6.0? The following types of messages will be supported in Mail.XML version 6.0:
--Transportation and Scheduling
Truck Availability for certain facilities and pick-up requests
Scheduling requests and responses for the USPS FAST system
Joint-Scheduling (multi-party) communication between the industry and from the industry to the USPS
Ability to download Customer Supplier Agreements for Origin-entered mailings
--Full-Service eDoc
Qualification reports
Container and Bundle reports
All Postage Statements currently supported through Mail.dat
Ability to request Mailer IDs and CRIDs from the USPS
Third-party data distribution for ACS COA, ACS Nixie, Confirm and Start-the-Clock data
--Full-Service Data Feedback
ACS - Change of address and Nixies
Start-the-Clock
Container Scans
What are some of the benefits of Mail.XML? Mail.XML is designed for two-way conversational communications that occur in near real-time. This increase in speed of communicating allows for more efficient business processes and can help you lower your cost of doing business. Also, Mail.XML can let you automate certain business functions because when you know all the "conflict situations" and you store the answers or triggers for each situation in your software, then the software is resolving most of the conflicts, thereby minimizing human interaction wherever possible and increasing the speed of business decision-making and improving the quality of services to everyone within the industry.
Will Mail.XML replace Mail.dat? NO. Mail.dat and Mail.XML are different specifications, and Mail.XML will not replace Mail.dat. These specifications currently exist side-by-side and will continue to do so for many years to come. (Remember - Mail.dat provides a storage/database model for mailing information while Mail.XML enables two-way business-function specific communication between members of the supply chain.) As mentioned earlier, the next issue of this publication will have a more detailed article devoted to Mail.XML and the benefits of Services Oriented Architecture (SOA). In the meantime, for more information about both Mail.dat and Mail.XML, you can visit the IDEAlliance website at www.idealliance.org.
Wallace Vingelis is Director of Product Management and Postal Affairs for Anchor Software, LLC, and currently serves as Co-Chair for the Mail.dat Specification for IDEAlliance. He can be reached at wvingelis@anchorcomputersoftware.com.
Shariq Mirza is the President and CEO of Assurety Consulting Inc. and currently serves as the IDEAlliance Technical Director for the Mail.dat and Mail.XML specifications. Mr. Mirza has over 11 years of USPS compliance experience. He can be reached at Smirza@AssuretyConsulting.com.
In the last issue, we discussed the Mail.dat specification and answered some basic questions about what it is, some of its benefits, etc. In this issue we are going to take a similar look at the latest specification from IDEAlliance: Mail.XML. The information presented here will again be in a Q&A format and will provide a basic understanding of the Mail.XML specification and its purpose. A more detailed article, focusing on business communication strategy and services architecture, will be printed in the next edition.
What is XML? XML stands for Extensible Markup Language, and is often defined as "a human-readable way of describing data or structured data." It also means that you can extend a specification with fields — without necessarily impacting your communication software. XML is the current standard of communication between two or more computers over the internet and is the Business-to-Business communication and automation standard. Today, almost all eCommerce occurs through XML.
What is Mail.XML? Mail.XML, which really began several years ago as the Transaction Messaging specification, is an XML-based communication specification developed by the IDEAlliance in collaboration with the USPS to automate business processes and communication wherever possible. Mail.XML is a messaging protocol that enables two-way communication between parties in the mailing supply chain and is designed to increase efficiency and lower costs by removing many manual data entry processes and enabling quick, near real-time communication between business partners. The core focus of Mail.XML is light-weight, business-function-specific communication where computers are "talking" with each other.
What information is Mail.XML communicating? Mail.XML uses the comprehensive Mail.dat database to communicate mailing related information and specific transactions between members of the mailing supply chain, i.e., buying of services for printing, manufacturing, and transportation processes. In addition, the information communicated to and from the USPS supports mail verification, acceptance, and induction processes.
What types of messages does Mail.XML support? Mail.XML currently supports container-based scheduling, pick up and drop off business processes, as well as identifying different business entities responsible for performing different services such as quality of mailing, address correction, and delivery confirmation on a mailing. Mail.XML also supports the communication of eDoc with the PostalOne! system.
Does the USPS currently support Mail.XML? Yes. The original Transaction Messaging specification has been supported by the USPS since 2004. The initial focus was FAST appointment scheduling and automation processes. The new version of Mail.XML (version 6.0) supports eDoc requirements for the Intelligent Mail Full-Service option, as well as the Full-Service data feedback requirements from the USPS to the industry.
The USPS is taking a phased approach to the Mail.XML version 6.0 implementation: In May 2009, the USPS will support all transportation and appointments needs for the Full-Service option. It will also provide the capability for mailers to receive ACS Change Of Address (COA) and Nixie data, as well as Start-the-Clock and Container Scan data. In November 2009, the USPS plans to support all Full-Service eDoc functionality through Mail.XML version 6.0.
What types of messages will be supported with version 6.0? The following types of messages will be supported in Mail.XML version 6.0:
--Transportation and Scheduling
Truck Availability for certain facilities and pick-up requests
Scheduling requests and responses for the USPS FAST system
Joint-Scheduling (multi-party) communication between the industry and from the industry to the USPS
Ability to download Customer Supplier Agreements for Origin-entered mailings
--Full-Service eDoc
Qualification reports
Container and Bundle reports
All Postage Statements currently supported through Mail.dat
Ability to request Mailer IDs and CRIDs from the USPS
Third-party data distribution for ACS COA, ACS Nixie, Confirm and Start-the-Clock data
--Full-Service Data Feedback
ACS - Change of address and Nixies
Start-the-Clock
Container Scans
What are some of the benefits of Mail.XML? Mail.XML is designed for two-way conversational communications that occur in near real-time. This increase in speed of communicating allows for more efficient business processes and can help you lower your cost of doing business. Also, Mail.XML can let you automate certain business functions because when you know all the "conflict situations" and you store the answers or triggers for each situation in your software, then the software is resolving most of the conflicts, thereby minimizing human interaction wherever possible and increasing the speed of business decision-making and improving the quality of services to everyone within the industry.
Will Mail.XML replace Mail.dat? NO. Mail.dat and Mail.XML are different specifications, and Mail.XML will not replace Mail.dat. These specifications currently exist side-by-side and will continue to do so for many years to come. (Remember - Mail.dat provides a storage/database model for mailing information while Mail.XML enables two-way business-function specific communication between members of the supply chain.) As mentioned earlier, the next issue of this publication will have a more detailed article devoted to Mail.XML and the benefits of Services Oriented Architecture (SOA). In the meantime, for more information about both Mail.dat and Mail.XML, you can visit the IDEAlliance website at www.idealliance.org.
Wallace Vingelis is Director of Product Management and Postal Affairs for Anchor Software, LLC, and currently serves as Co-Chair for the Mail.dat Specification for IDEAlliance. He can be reached at wvingelis@anchorcomputersoftware.com.
Shariq Mirza is the President and CEO of Assurety Consulting Inc. and currently serves as the IDEAlliance Technical Director for the Mail.dat and Mail.XML specifications. Mr. Mirza has over 11 years of USPS compliance experience. He can be reached at Smirza@AssuretyConsulting.com.
