This issue of XML Daily Newslink is sponsored by:
Sun Microsystems, Inc. http://sun.com
- Open Document Format for Office Applications (OpenDocument) Version 1.2
- W3C First Public Working Draft for Uniform Messaging Policy, Level One
- Apache Software Foundation Announces Apache SpamAssassin Version 3.3.0
- IETF Forms New Messaging Abuse Reporting Format (MARF) Working Group
- Google to Bring NOAA Data to New Heights
Open Document Format for Office Applications (OpenDocument) Version 1.2
Patrick Durusau and Michael Brauer (eds), OASIS Public Review Draft
Members of the OASIS Open Document Format for Office Applications (OpenDocument) Technical Committee have released an approved 'Committee Draft 04' version of Open Document Format for Office Applications (OpenDocument) Version 1.2, Part 1: Introduction and OpenDocument Schema for public review through March 26, 2010. The OpenDocument format defines an XML file format for office applications.
OpenDocument Version 1.2 has three parts: Part 1 defines an XML schema for office applications and its semantics. The schema is suitable for office documents, including text documents, spreadsheets, charts and graphical documents like drawings or presentations, but is not restricted to these kinds of documents. Part 2 defines a formula language to be used in OpenDocument documents. Part 3 defines a package format to be used for OpenDocument documents... This Part 1 document has seven appendices: OpenDocument Relax NG Schema; OpenDocument Metadata Manifest Ontology; MIME Types and File Name Extensions; Bidirectional (BiDi) Scripts,Numeric Digits Presentation and Calendars; Recommend Usage of SMIL; Changes From Previous Specification Versions; Acknowledgments.
The specification defines two methods of document representation: as a single XML document and as a collection of files within a package, each of which stores a part of a complete document. When an OpenDocument document is represented as a package, there are four root elements, 'office:document-content', 'office:document-styles', 'office:document-meta', and, 'office:document-settings', each stored as a separate file. A package may also contain image files, embedded objects and implementation specific files.
OpenDocument supports five types of metadata: (1) RDF metadata describing documents or the content of identifiable ODF elements; (2) Text content being used as RDF metadata; (3) Pre-defined metadata ('meta.xml'); (4) User-defined metadata—using the 'meta:user-defined' element; (5) Custom metadata—custom XML elements within 'meta.xml'.
W3C First Public Working Draft for Uniform Messaging Policy, Level One
Tyler Close and Mark Miller (eds), W3C Technical Report
Members of the W3C Web Applications Working Group have published a First Public Working Draft for Uniform Messaging Policy, Level One. The Uniform Messaging Policy (UMP) enables cross-site messaging that avoids Cross-Site-Request-Forgery and similar attacks that abuse HTTP cookies and other credentials. For example, content from customer.example.org can safely specify requests to resources determined by service.example.com. Rather than restricting information retrieval to a single origin, as the Same Origin Policy almost does, the Uniform Messaging Policy supports origin independent messaging.
Details: "The main goals of this specification are to (a) provide a means for a resource owner to consent to cross-origin information retrieval and (b) support origin independent messaging that avoids Cross-Site-Request-Forgery (CSRF) and similar attacks. We introduce an HTTP response header that enables opting-out of Same Origin Policy protection for a given HTTP response in order to meet the first of these goals. To understand the second goal, consider an attack case, in which service is the attacker and wants a request delivered to a resource that customer has permission to use but service does not. When informing customer of the intended request target, service provides the URL for a resource hosted by customer... When the user agent sends the request, customer receives a request with the user's cookies, sent by content hosted by customer. The request is indistinguishable from a legitimate request to the resource, so it is processed...
In the attack cases, user credentials (such as cookies) are automatically included in requests whose content is partly determined by another site. These cases are similar to the familiar CSRF attack, in which another site uses an HTML <form> element to determine the target and body of a request that includes the user's credentials. To avoid this class of attacks, and so meet the second goal, we introduce a messaging policy for uniform requests that don't automatically include any credentials. By withholding credentials, requests can be safely produced in collaboration with other sites, even when the request target is within the same origin.
Many of the most popular user-agents have recently deployed messaging mechanisms that support opting-out of Same Origin Policy protection. Level One of the Uniform Messaging Policy is within the intersection of HTTP messaging functionality supported across all these user-agents. Unfortunately, this subset does not include many parts of HTTP messaging, such as custom request headers and methods such as PUT and DELETE. It is expected that a Level Two specification will eventually provide this functionality..."
Apache Software Foundation Announces Apache SpamAssassin Version 3.3.0
Staff, ASF Announcement
The Apache Software Foundation (ASF) has announced the release of Apache SpamAssassin 3.3.0, the first major code release from the Apache SpamAssassin Project since May 2007. Apache SpamAssassin v3.3.0 marks the Project's 4th major (and 24th overall release) since the SpamAssassin Project joined the ASF in December 2003. Apache SpamAssassin is an award winning, mature, wide-spectrum, extensible email filtering package deployed by hundreds of thousands of organizations world-wide.
Apache SpamAssassin 3.3.0 represents a major shift in how SpamAssassin rules (the actual patterns that help to identify spam) are updated. Starting with version 3.3.0, rules are now separate from the core product and are instead downloaded using "sa-update", SpamAssassin's automatic update software. This method was optional with the 3.2.x series of releases and has proven to be very popular.
SpamAssassin provides a comprehensive set of features and support for methods and standards such as text based patterns, bayesian scoring, DNS based black and white lists, DKIM and SPF sender authentication, and email signature clearing houses. The software utilizes a principle of identifying multiple reasons for classifying an email as spam to improve accuracy and decrease the chance of legitimate emails being incorrectly identified as spam.
Established in 1999, the all-volunteer Foundation oversees more than seventy leading Open Source projects, including Apache HTTP Server -- the world's most popular Web server software. Through The ASF's meritocratic process known as "The Apache Way," nearly 300 individual Members and 2,000 Committers successfully collaborate to develop freely available enterprise-grade software, benefiting millions of users worldwide: thousands of software solutions are distributed under the Apache License; and the community actively participates in ASF mailing lists, mentoring initiatives, and ApacheCon, the Foundation's official user conference, trainings, and expo. The ASF is funded by individual donations and corporate sponsors including Facebook, Google, HP, Microsoft, Progress Software, SpringSource/VMware, and Yahoo!
See also: the Apache SpamAssassin Project
IETF Forms New Messaging Abuse Reporting Format (MARF) Working Group
Staff, IESG Secretary Announcement
The Internet Engineering Steering Group announced the formation of a new working group in the IETF Applications Area: Messaging Abuse Reporting Format (MARF).
"Messaging anti-abuse operations between independent services often requires sending reports on observed fraud, spam, virus or other abuse activity. A standardized report format enables automated processing. The Abuse Reporting Format (ARF) specification has gained sufficient popularity to warrant formal codification, to ensure and encourage future interoperability with new implementations. The primary function of this working group will be to solicit review and refinement of the existing specification.
A report format is amenable to processing by humans or software, with the latter requiring the format to be standardized, to permit interoperability between automated services, particularly without prior arrangement. ARF was developed as a community effort within the context of a messaging trade organization independent of the IETF, and uses a format similar to a Delivery Status Notification (DSN, RFC3464) to report fraud, spam, viruses or other abusive activity in the email system. ARF as initially defined is already in widespread use at large ISPs, so interoperability can be demonstrated. Some tools already exist for processing ARF messages, a few of which are open source. In order to preserve the installed base, the working group will make the minimum changes necessary to the existing specification and will seek to have backward compatibility...
The MARF Working Group will first produce a Proposed Standard track specification of ARF. The group will also produce an informational document detailing guidelines for deploying and using ARF, including descriptions of current practices and their rationales. The group will specify the integration of ARF into DKIM-aware environments, with IETF I-D 'draft-kucherawy-dkim-reporting-06' as its input. It contains extensions to DKIM that are related to ARF as a means of reporting DKIM-related failures which include phishing ("fraud") and as such are relevant to the ARF effort. Finally, the WG will consider a means for publishing the address to which ARF reports should be sent..."
See also: the IETF Applications Area
Google to Bring NOAA Data to New Heights
William Jackson, Government Computer News
"The U.S. National Oceanic and Atmospheric Administration (NOAA) is one of the federal agencies most responsible for getting scientific information (e.g., weather patterns, ocean temperatures, rainfall averages) out to the public. NOAA has chosen Google as a partner to collaborate on several research and development projects to make the data more accessible online. The cooperative R&D agreement will enable the two organizations to collaborate for their mutual benefit and for the benefit of the public without an exchange of money. Google gets access to vast amounts of data and Earth sciences expertise, and NOAA gets access to software and visualization acumen.
One of the opportunities is visualizing data. NOAA is no stranger to visualization. Its Science on a Sphere technology, which it licenses to museums, science centers, research facilities and schools around the world, uses a computer-driven multi-projector system to realistically display scientific data about the Earth on a spherical surface. Richard Spinrad, NOAA assistant administrator for research, would like to expand that capability to new datasets.
This would be done by rendering files in the Keyhole Markup Language used by Google Earth for display in the Science on a Sphere system. This would require translating files from two-coordinate dimensions to four coordinates (the three spatial dimensions plus time). Doing this would give Google a new way to display its data and would give NOAA new datasets to use with Science on a Sphere...."
KML (formerly 'Keyhole Markup Language') is a file format used to display geographic data in an Earth browser, such as Google Earth, Google Maps, and Google Maps for mobile. You can create KML files to pinpoint locations, add image overlays, and expose rich data in new ways. KML is an international standard maintained by the Open Geospatial Consortium (OGC).
See also: KML references
XML Daily Newslink and Cover Pages sponsored by:
|Sun Microsystems, Inc.||http://sun.com|
XML Daily Newslink: http://xml.coverpages.org/newsletter.html
Newsletter Archive: http://xml.coverpages.org/newsletterArchive.html
Newsletter subscribe: firstname.lastname@example.org
Newsletter unsubscribe: email@example.com
Newsletter help: firstname.lastname@example.org
Cover Pages: http://xml.coverpages.org/