Cover Pages: XML Daily Newslink: Thursday, 01 July 2010

A Cover Pages Publication http://xml.coverpages.org/
Provided by OASIS and Sponsor Members
Edited by Robin Cover

This issue of XML Daily Newslink is sponsored by:
Oracle Corporation http://www.oracle.com

Headlines

IETF Outcomes: Successes and Failures
W3C Web Applications Working Group Issues Call for Implementations
W3C Publishes Update for the Contacts API Working Draft
Civic Location Format Extension for Utility and Lamp Post Numbers
NIST Recommendation for Password-Based Key Derivation: Storage Apps
Experimental IETF Internet Draft for a Metadata Query Protocol
Emergency Text Messaging Using the SIP MESSAGE Method
Encouraging Steps on Privacy from Facebook

IETF Outcomes: Successes and Failures
Dave Crocker, IETF Journal

An interview with Dave Crocker IETF 77 in Anaheim took the opportunity to explore Crocker's observations on the IETF decision to deploy a Wiki supporting IETF Successes and Failures. "In February 2010, IETF chair Russ Housley announced the launch of a new wiki dealing with 'IETF Outcomes', and the wiki may be found on the IETF tools site. The Wiki features technologies and services that were developed within the IETF and that represent notable successes and failures. It is the result of a collaborative effort by IETF participants-who are invited to use it to provide feedback about the utility of IETF work — and it is a mechanism for facilitating public understanding of IETF work and its impact.

The IETF has operated in its current form since 1989. Some of its standards have succeeded on a very large and visible scale. Others are successful, but visible only to a more limited community. Others have fared poorly. The contents of the wiki are revised according to the views of individual contributors, and have not been subject to the usual IETF Rough Consensus assessment..."

Dave Crocker: "For many of us, the usual measure of success is the publication of an RFC, but we're in the communications business, and in the real world this involves closing the loop with feedback... One of the columns of the wiki table is called Usage, which might seem an odd term, but ultimately, the reason we make stuff is so it gets used. What does it mean to get used? I don't think that having software implement a spec qualifies it as a success. I think having somebody use that software makes it a success. The difference is very important. The IETF is driven largely by an industry that produces things, not by an industry that uses those things. The rating system is only a five-point scale, from complete failure to massive success...

It's not only usage that matters; it's also the extent to which a piece of work prompted derivative works. It turns out you can have something that's a complete failure but that triggers derivative work of importance. An example of that is PEM (Privacy Enhanced Mail), which generated a lot of useful outcomes, even though the protocol itself was a complete failure... Frequently, people are brutally honest about their own work. The IETF environment encourages that level of honesty. People don't beat themselves up in public very often, but within the community there is respect for learning what didn't wor k and then using that information... I myself have had concerns about the wiki format, that it could create competition between IETF areas. But what's bad about that?"

W3C Web Applications Working Group Issues Call for Implementations
Staff, W3C Announcement

The W3C Web Applications Working Group now invites implementation of two Candidate Recommendation (CR) specifications: Digital Signatures for Widgets and The 'view-mode' Media Feature. W3C publishes a Candidate Recommendation to indicate that the document is believed to be stable and to encourage implementation by the developer community

The CR specification Digital Signatures for Widgets defines a profile of the XML Signature Syntax and Processing 1.1 specification to allow a widget package to be digitally signed. Widget authors and distributors can digitally sign widgets as a mechanism to ensure continuity of authorship and distributorship. Prior to instantiation, a user agent can use the digital signature to verify the integrity of the widget package and to confirm the signing key(s). This document specifies conformance requirements on both widget packages and user agents. The Web Applications (WebApps) Working Group expects to request advancement this document to Proposed Recommendation once the Working Group has developed a comprehensive Widgets Digital Signature Test Suite, and demonstrated at least two interoperable implementations. The WebApps Working Group expects to show these implementations by September 2010.

A companion Implementation Report: Digital Signatures for Widgets report presents the results from running the test cases of the Test Suite against various user agents that claim to support the 'Digital Signatures For Widgets Specification'. The implementation report serves two purposes: (1) To allow the working group to retrospectively analyze how implementers have interpreted the assertions of the specification, which is part of the W3C's Candidate Recommendation phase. Analyzing how the specification has been interpreted by implementers allows the Working Group to clear up ambiguities or change the specification retrospectively to match the behavior of implementations (i.e., match reality). (2) To allow the working group to demonstrate interoperability across various implementations, thus allowing meeting the W3C requirements to progress this specification along the W3C's recommendation track.

The 'view-mode' Media Feature defines a media feature to match the different visual presentation modes that can be applied to web applications and thereby apply different styling based on these different modes using CSS Media Queries. Web applications, be they widgets or in-browser, can on most platforms be run in multiple visual modes. At times they may occupy the entire screen, at others they may be minimised to a specific docking area; at times they may have chrome that matches the operating system's style while at others they may be providing their own controls in order to provide for a more immersive experience. The user is generally in control of at least several aspects of these modalities, and it is therefore important for authors to be able to react to these in order to provide different styling to their applications. In order to achieve this, this specification defines a media feature that allows different CSS style rules to be applied depending on whether a given media query matches... The Web Applications Working Group hopes to request advancememt of this document to Proposed Recommendation once the Working Group has demonstrated at least two interoperable implementations (interoperable meaning at least two implementations that pass each mandatory test in the test suite) as documented in an Implementation Report..."

W3C Publishes Update for the Contacts API Working Draft
Richard Tibbett (ed), W3C Technical Report

Members of the W3C Device APIs and Policy Working Group have released a revised version of the Contacts API specification, updating the draft of 2010-01-21. This W3C Contacts API document defines the high-level interfaces required to provide access to a user's unified address book. Document Section 4 presents the API Description (interfaces for ServiceContacts, Contacts, Contact, ContactProperties, ContactName, ContactField, ContactAddress, ContactOrganization, ContactAccount, ContactFindOptions, ContactFindSuccessCB, ContactSuccessCB, ContactErrorCB, and ContactError). Document Section 3 outlines Security and Privacy Considerations: Privacy considerations for implementors of the Contacts API, and Privacy considerations for recipients of contact information. Section 5 discusses Contact Search Processing. Appendices present 'User Interaction Guidelines' and 'Search Weights'.

From the document Introduction: Every operating system and a large number of web-based service providers have different ways of representing address book information. Most users are required to maintain a plurality of contact lists which leads to multiple copies of address book data. The multiplicity of address books that a user is required to maintain often leads to disjointed and inconsistent information being stored across a user's address book providers.

Providing address book information to these service providers means handing over all of your data and trusting these providers with the security and privacy of storing and sharing of your information. When sharing this data with third parties users are, more often than not, required to hand over access to their whole address book. Users are implicitly required to trust 3rd parties with all of their data when, in reality, the user may only wish, or need, to share a subset of their address book information so that an application can fulfill its purpose.

This specification defines the concept of a user's unified address book—where address book data may be sourced from a plurality of sources—both online and locally. This specification then defines the interfaces on which third party applications can access a user's unified address book; with explicit user permission and filtering. The focus of this data sharing is on making the user aware of the data that they will share and putting them at the centre of the data sharing process; free to select both the extent to which they share their address book information and the ability to restrict which pieces of information related to which contact gets shared. The API itself is agnostic of any underlying address book sources and storage. A conforming implementation is required to implement all fields defined in this specification..."

Civic Location Format Extension for Utility and Lamp Post Numbers
Robins George, Henning Schulzrinne, Brian Rosen (eds), IETF Internet Draft

IETF has published an initial level -00 Internet Draft for the Standards Track specification Civic Location Format Extension for Utility and Lamp Post Numbers. From the Abstract: "This document describes an extension to civic location format and adds two new CAtypes [civic address types]: PN (pole number) and MP (milepost). Pole Numbers are used on poles such as lamp posts or utility poles, and can be used in some circumstances as location information. Mileposts are numeric values measured from an end of a trail, road, railway line or other feature. Specifically, the document defines an extension of the civic address format defined in RFC 4119 ('A Presence-based GEOPRIV Location Object Format') and updated by RFC 5139 (Revised Civic Location Format for Presence Information Data Format Location Object - PIDF-LO) to carry such pole number and milepost information.

In some areas, utility and lamp posts carry a unique identifier, which we call a pole number in this document. In some countries, the label on the lamp post also carries the local emergency service number, such as '110', encouraging callers to use the pole number to identify their location... On some roads, and many trails, railroad rights of way and other linear features, a post with a mile or kilometer distance from one end of the feature may be found (a 'milepost'). There are other cases of poles or markers with numeric indications that are not the same as a 'house number' or street address number.

A pole number can consist of any combination of letters and digits. Punctuation characters and embedded spaces are ignored; lower and upper case letters are treated as equivalent. Mileposts are traditionally mile or kilometer distances from one end of the feature, but the field may contain any combination of letters, digits and punctuation characters. There could be country specific considerations for PN or MP use, but none are described in this document."

Document section 4 provides two examples in XML representation using the 'civicAddress' element with PN (pole number) and MP (milepost), following the RFC 5139 XML notation for the representation of civic location. "This format is designed for use with Presence Information Data Format Location Object (PIDF-LO) documents. The format is based on the civic address definition in PIDF-LO, but adds several new elements based on the civic types defined for Dynamic Host Configuration Protocol (DHCP), and adds a hierarchy to address complex road identity schemes. The format also includes support for the 'xml:lang' language tag and restricts the types of elements where appropriate..."

NIST Recommendation for Password-Based Key Derivation: Storage Apps
Meltem S. Turan, Elaine Barker, William Burr, Lily Chen (eds), NIST Special Publication

Members of the U.S. National Institute of Standards and Technology (NIST) Computer Security Division Information Technology Laboratory have published a Draft NIST Special Publication 800-132. Recommendation for Password-Based Key Derivation Part 1: Storage Applications. This Recommendation specifies techniques for the derivation of master keys from passwords to protect electronic data in a storage environment. The editors invite public comment on the draft through July 28, 2010.

"The randomness of cryptographic keys is essential for the security of cryptographic applications. However, in some applications, such as the protection of electronically stored data, passwords are the only input required from the users who are eligible to access the data. Due to the low entropy and possibly poor randomness of those passwords, they are not suitable to be directly used as cryptographic keys. This Recommendation specifies a family of Password-Based Key Derivation Functions (PBKDFs) for deriving cryptographic keys from passwords for the protection of electronically-stored data...

This Recommendation specifies a family of functions to derive cryptographic keying material from a password. The derived keying material is called a Master Key (MK), denoted as mk. MK is used either to form one or more Data Protection Keys (DPKs) to protect data through segmentation or derivation using an approved key derivation function (KDF), or to protect DPKs. If the MK is used to protect DPKs, the protection shall use an approved authenticated encryption mode or an approved key protection method.

A password is a string of characters that is usually chosen by users. In most applications, passwords are used to authenticate a user in order to gain access to a resource. Since most user-chosen passwords have low entropy and weak randomness properties (discussed in Appendix A.1), these passwords shall not be used directly as cryptographic keys. However, in certain applications, such as protecting data in storage devices, the password is the only secret information that is available to the cryptographic algorithm that protects the data..."

Experimental IETF Internet Draft for a Metadata Query Protocol
Chad LaJoie (ed), IETF Internet Draft

IETF has published an initial level -00 Experimental Internet Draft for Metadata Query Protocol. This document defines a simple protocol for retrieving metadata about entities. The goal of the protocol is to profile various aspects of HTTP to allow requesters to rely on certain, rigorously defined, behaviour. The metadata retrieval protocol seeks to fully employ the features of HTTP, and makes mandatory some optional HTTP features.

"Many clients of web-based services are capable of consuming descriptive metadata about a service in order to customize or information the client's connection parameters. While the form of the metadata (e.g., JSON, XML) and content varies between services this document attempts to specifies a set of semantics for HTTP that allow clients to rely on certain behavior. The defined behavior is meant to make it easy for clients to perform queries, to be efficient for both requesters and responders, and allow the responder to scale in various ways.

The metadata query protocol retrieves metadata based on one or more 'tag' or 'keyword' identifiers. A request may return information for none, one, or a collection of entities. The query protocol uses identifiers to 'tag' metadata for single- and multi-entity metadata collections... The assignment of such identifiers to a particular metadata document is the responsibility of the query responder. If a metadata collection already contains a well known identifier it is recommended that such a natural identifier is used when possible. Any given metadata collection MAY have more than one identifier associated with it.

A Metadata Query request is performed by issuing an HTTP GET request. The request MUST contain at least one identifier but MAY contain more than one. Each identifier must be properly URL encoded. If more than one identifier is used the returned metadata MUST have been labelled with each identifier... The response to a Metadata Query request MUST be a document that provides metadata for the given request identifiers in the format described by the request's Content-Type header... If the responder can not create a valid document it MUST respond with a 500 status code. An example of such an error would be the case where the result of the query is metadata for multiple entities but the request content type does not support returning multiple results in a single document..."

Emergency Text Messaging Using the SIP MESSAGE Method
Jong Yul Kim, Wonsang Song, H. Henning Schulzrinne (et al, eds) IETF Internet Draft

A first public IETF Internet Draft has been published for Emergency Text Messaging Using the SIP MESSAGE Method. The specification is intended as an IETF BCP (Best Current Practices) on how to use the SIP MESSAGE method for emergency text messaging from citizen and visitors to authorities. The document assumes that the Emergency Services network (ESInet) and PSAPs are SIP-based infrastructures. However, the caller-facing access network may or may not be IP based. Emergency messages may be sent end-to-end using the SIP MESSAGE method, or it may be in a different format and protocol in the caller side and have to be converted to SIP MESSAGE somewhere along the path towards the call taker. Therefore, it also provides recommendations on how a SIP MESSAGE is formed from non-SIP text protocols.

The recommendations reference Framework for Emergency Calling Using Internet Multimedia, produced by the IETF Emergency Context Resolution with Internet Technologies (ECRIT) Working Group. The document describes how the SIP MESSAGE method is used to support emergency text messaging within the framework described in the Framework for Emergency Calling specification. The existing framework does not consider methods that do not create a session or are not a part of it. The main difference between the existing framework and the MESSAGE approach is in the way the proxies handle SIP MESSAGE methods

Emergency text communication may utilize SIP MESSAGE end-to-end from the caller's end device or application to the call taker, or may start as another form of text messaging scheme such as SMS but ultimately be converted to a SIP MESSAGE. Text handling after the conversion is the same. In any case, the MESSAGE request is constructed as described in RFC 3428. The body of the request contains the message to be delivered. If the location information is appended to the body of the request, the caller's message and the location information must be inserted into the body of the request as multiple MIME attachments... When the call taker sends a reply to the caller, the application constructs a SIP MESSAGE request without location or other special header fields used in emergency and sends it towards the caller. The reply follows the normal SIP routing path. If the caller's original message was not SIP, then the replies from call taker must also be converted from SIP MESSAGE request to the original message format and tranport protocol...

Proxies that determine the next hop of an emergency request based on location or local policy need to keep track of MESSAGE requests it handles. On the other hand, proxies that foward MESSAGE requests based on the To header field or the Route header field do not need to keep track since the MESSAGE requests will be delivered consistently... The original message may not be SIP. It may be an SMS message or an IM message in a proprietary format and protocol. In these cases, the original format and protocol must be converted to a SIP MESSAGE..."

See also: ECRIT references

Encouraging Steps on Privacy from Facebook
Erica Newland, CDT Policy Beta Blog

"Facebook has announced positive steps to ensure that platform applications will begin adhering to a new standard of transparency: before users connect to an application, they will interact with a dialog box that details exactly what pieces of personal information the user will have to share in order to use the app.

In the past, Facebook users who wanted to connect with an application were presented with a dialog box that indicated the application may "pull your profile information, photos, your friends' info, and other content that it requires to work." Users did not have the tools to differentiate those applications that pulled only the information they needed to work from those that more liberally requested user data. But once Facebook fully implements the announced changes, users who install new applications will be told exactly what information these applications are requesting, whether it is their political interests and work history, friends' photo albums and current city, or all of the above. By giving users granular and easy-to-understand notice of an application's data collection practices, Facebook will be empowering them to make more informed decisions around sharing their data.

The new permissions model also creates real incentives for application developers to minimize their data collection: now that they have to be transparent about what types of data they are collecting, application developers may think twice before asking for access to information in excess of what they need to deliver their advertised product.."

The Center for Democracy and Technology is "a non-profit public interest organization working to keep the Internet open, innovative, and free. As a civil liberties group with expertise in law, technology, and policy, CDT works to enhance free expression and privacy in communications technologies by finding practical and innovative solutions to public policy challenges while protecting civil liberties. CDT is dedicated to building consensus among all parties interested in the future of the Internet and other new communications media."


SEARCH \| ABOUT \| INDEX \| NEWS \| CORE STANDARDS \| TECHNOLOGY REPORTS \| EVENTS \| LIBRARY

Headlines

Sponsors