IETF65, day 2 (Tuesday)

From a discussion this morning that relates well to things around here in Dallas: "The difference between Britain and the US is that in the US, 100 years is a long time, while in Britain, 100 miles is a long way." Indeed; nothing is close to anything in this part of the country, at least.

Digital Identity Exchange

As expected, this was contentious, and the meeting never got past the problem definition. In particular, we never got to the first draft proposal.

The motivation here is in the desire to solve the problem of presentation of identity to multiple web sites. "Identity", here, may include, but is not limited to, authentication credentials. DIX is looking to solve a broader problem of distributed identity issues that, in the process, solves this one. From the presentation slides, DIX is:

The transmission of digital representation of a set of Claims made by one Party about itself or another Digital Subject, to one or more other Parties.

...and the problem statement is:

The Internet is host to many online information sources and services. There is a growing demand for users to identify, and provide information about themselves. Users bear the burden of managing their own authentication materials and repeatedly providing their identity information. Signing in to web pages and completing user registration forms is an example.

The discussion of the problem and the suitability of various solution methods was extensive and animated, and I'll leave the details for the meeting minutes, which should eventually appear here, and the jabber log, which is here. The BOF did conclude with the decision that this is a useful thing to pursue in the IETF.

Intellectual Property Rights

The purpose of this working group is to clarify and update the IETF's IPR policy. There are many disagreements on the details of this, even down to the wording and scope of copyright notices in the draft documents. As with DIX, I'm not going to attempt to summarize the extensive discussion here. The jabber log is here, but doesn't really cover the breadth of the discussion in the room.

Sieve email filtering language

Lots of progress here. We reviewed the status of the working group documents that have moved on (Vacation, Variables, Relational update), and those that are ready to move on (Spamtest update, IMAP Flags, EditHeader, Body). Then we covered status and issues on the documents that still need some work. Not much to discuss on Spamtest-bis, Date, Subaddress-bis, Regex, MIME loops. Significant items on the rest follow.

Refuse:

• Should we add a ":mime" tag for cases where Refuse generates a DSN/MDN? Decision: no, leave it for a future extension if anyone ends up wanting it.
• If the message has changed (as with EditHeader) and Refuse generates a DSN/MDN, should the message bounced be the modified message or the original? Decision: original; change the text, and add a warning that the implications of refusing based on changes, but bouncing the original, must be understood.
• What should happen if the reason string contains non-ASCII characters and Refuse will generate a protocol-level rejection (which can't contain non-ASCII characters? No decision, so the issue remains open.

Notifications:

• Need to consider whether to provide a way to get the message body, or parts of it, to include in the notification text. Ned warns of some security (access controls) and robustness (message loops and the like) issues with doing that, so if we do, we must be careful. Issue remains open.
• Should there be text in the base notifications doc about error recovery, notification loops, suppression of idential notificatons, etc, or should those be pushed down to the method descriptions? Decision: have a section in the notifications doc about "method considerations", and outline the needs there. That way, all method documents will follow those guidelines and be consistent.
• Should "priority" be "importance"? What does it mean? How many values should it have? Should it align with XMPP? Decision: "Importance", refers to the importance of delivery of the notification, align with XMPP, take values from there.
• Should there be a "mandatory to implement" notification method? Will the IESG require it? Decision: IESG won't require it, do not have one. Default notification method is therefore implementation-dependent, which is OK.
• Several minor issues, to be dealt with by the editors.

Sieve base spec (3028bis):

• Should the base spec recommend that "fileinto" map UTF-8 mailbox names to modified UTF-7 in the IMAP environment? Decision: Make it a general recommendation to map names for environments where that's necessary, and point out the IMAP case specifically.
• There are significant problems with the IANA template, and, consequently, with the current IANA registry. Decision: editor will re-do the IANA template and request a replacement of the registry.
• Lots of dependencies on this spec, so it must move ahead quickly. But also, this spec depends upon draft-newman-i18n-comparator, so that must also move quickly. More reviewers are needed for that spec.

ManageSieve:
Decision to make this a working group deliverable.

Other issues:

• Should there be a test for the presence of extensions, so extensions can be used conditionally? Decision: Yes, and add this to the upcoming "environment" draft (which I'm on the hook to write...).
• Should we have exception handling in Sieve? Decision: No, leave it to the implementation to handle errors. Add text recommending notifying the owner of the script if there are errors in the execution of it.
• The working group will recharter to update its milestones and to add the ManageSieve work.