I’m a computer software researcher, working as Internet Standards Manager for Futurewei Technologies.
I spend most of my time on e-mail and antispam technology, Internet of Things technology, and Internet security, and on standards development in those areas. I also try to keep a finger or two in context services technology, aiming to better connect users to important (non-spam) messages while avoiding inundation by unimportant or annoying ones. For more detail, see the sections below.
I serve as Applications and Real-Time Area Director in the Internet Engineering Task Force (IETF).
I am a Senior Technical Advisor for the Messaging Malware Mobile Anti-Abuse Working Group (M3AAWG), and am the IETF liaison to M3AAWG.
I am a member of the Security and Stability Advisory Committee (SSAC) in the Internet Corporation for Assigned Names and Numbers (ICANN).
I am on the editorial board for IEEE Internet Computing magazine, and I am currently an Associate Editor in Chief.
I was a program chair for the 2010 Collaboration, Electronic messaging, Anti-Abuse and Spam Conference (CEAS), and have been a program chair and on the program committee during the other years of the conference.
I retired from IBM in 2009 as a Senior Technical Staff Member at IBM’s Thomas J. Watson Research center.
I am working with the Internet Engineering Task Force (IETF) on several applications- and security-related standards. I served as Applications Area Director, on the Internet Engineering Steering Group (IESG), from 2012 to 2016, and on the Internet Architecture Board (IAB) from 2007 to 2009; I participate in the Security Directorate and the Applications Area Directorate. I’m active in a number of IETF working groups and have chaired quite a number over the years, including DKIM and OAUTH. I’m currently chairing the following:
Domain-based Message Authentication, Reporting & Conformance (dmarc)
DMARC uses existing mail authentication technologies (SPF and DKIM) to extend validation to the RFC5322.From field. DMARC uses DNS records to add policy-related requests for receivers and defines a feedback mechanism from receivers back to domain owners. This allows a domain owner to advertise that mail can safely receive differential handling, such as rejection, when the use of the domain name in the From field is not authenticated.
Open Specification for Pretty Good Privacy (openpgp)
OpenPGP is an Internet standard that covers object encryption, object signing, and identity certification. These were defined by the first incarnation of the OpenPGP working group. This incarnation of the working group is chartered to primarily produce a revision of RFC4880 to address issues that have since been identified by the community.
Uniform Resource Names, Revised (urnbis)
The RFCs defining URNs were published in 1997-2001. They rely on old (or even provisional) basic documents on the concepts of URI and URL. At that time there was almost no URN implementation experience. The core URN RFCs -- RFC 2141 (URN Syntax), RFC 3406 (Namespace Definition Mechanisms) -- are based on outdated framework documents and understanding of digital archiving. The urnbos working group is updating those key RFCs describing the URN system.
During my last few years in IBM Research, we developed more effective antispam techniques, some of which have made their way into IBM’s Lotus software products, and some into the product line from IBM Internet Security Systems. US patents 7,475,118 and 8,549,081 cover some of this work.
In Context Services, closely connected to pervasive/ubiquitous computing work, we emphasized three areas:
For the messages themselves, we tied together e-mail, instant messaging, alerts, calendar alarms, and other similar things that can broadly be grouped into the category of “messaging”. It’s obvious that if you’ve defined e-mail from your boss to be “important”, you want to be informed quickly about new e-mail from your boss. But also, if you’ve set your calendar to give you an alarm ten minutes before an important meeting, it does little good if that alarm pops up on your desktop computer when you’re not in your office. That alarm is a “message” too, and we’ll handle it as one.
For connecting you, we handle your desktop and laptop computers, of course, but we also handle a variety of wireless/handheld devices, including cell phones (through SMS), BlackBerry(tm) handhelds, personal digital assistants (PDAs) connected through wireless modems, and other similar devices.
For winnowing important messages from the chaff of all the unimportant ones, we used advanced filtering technology that takes into account general user preferences, specific targeted filters, and user context.
User context refers to information obtained dynamically about where the user is, what she’s doing, and how she’s relating to the people around her. Is the user at home, at work, in a public place? On vacation? In a meeting? Seeing a Broadway show? Has she specified that she’s not to be disturbed? Will she be available for interruption in 30 minutes, or not for 3 hours? Is she out of town? Returning tomorrow, or not for two weeks?
All this information can be used both in the filtering, to change the definition of what “important” means (perhaps mail from my boss is important, but not if I’m on vacation unless it’s marked “urgent”), and in the delivery, deciding how to deliver a message at a particular time (if I’m at home, don’t sent alerts to my desktop computer in the office; if I’m at a show, don’t ring my cell phone).
Much of our work was focused on the context information — obtaining it, using it effectively, securing it to protect the user’s privacy. US patent 7,496,585 covers some of this work.