Minutes from EAI WG meeting, IETF 71, 2008-03-13 A. Administrivia -Call to order -Agenda bashing (no changes). B. Status of "core" drafts These are in Last Call. If you have read the documents, please send your remarks to the IETF general list. C. Downgrade draft The authors think this is ready for WG Last Call. They posted an -07 draft was, which fixed some typos and minor issues. Please review and comment on list. * Request for comments. - None heard * Who has read the draft? - A fair number * Does anyone know of a fatal objection? -None heard * Other issues? MIC: Randall Gellens raised a concern related to -downgrade-, -mailinglist-, and perhaps others. He is not comfortble with any of these until there is a decision about -mailto-; then we can see whether that decision affects the other drafts. *Resolved to put this issue on the list for -mailto- discussion. The Chair also resolved that, in the absence of further objections, he would send a two-week WG Last Call, and then send for IESG processing. D. -pop- and -imap- 1. Pete Resnick discussed -imap-. He had been waiting for -enable-; it is available now, so he will pdate. Otherwise, he's received neither nits nor sunstantive remarks recently. He has some issues fixed in an unissued, working version. 2. Randall Gellens discussed -pop-. There are some changes from the -02 draft. The most significant is that there is "one big switch" to throw: no longer two commands for each operation, but one single UTF-8 command that happens prior to authentication. There is no more reference to -imap-, and "US-ASCII" has been changed to "ASCII" in the document. The previous draft had two commands for everything. Now, there are only two kinds of maildrops. If it's ASCII-only, then nothing changes. If it's a UTF-8 mailstore, then if the UTF-8 command is issued, the user gets UTF-8; otherwise, downgrading happens. Upconversion is eliminated. He has a question for the WG: should -pop- have a required downgrade mechanism, or just require that the result conform to RFC 2822? The current text says that a server "normally" downgrades. Randy now thinks this is bad: POP servers need not do anything in a special way. Only clients who have any use for downgrade headers are ones that should as well have the UTF-8 command. The counter argument is that there might be a client that could upgrade, and that then has downgrade interpretation capablities. He asks the WG for input. MIC: Tony Hansen agrees with the latter (upgrading client) view. + Randall replies that these cases are never going to be truly upgradable. MIC: Pete Resnick asks about the case of some middle piece like fetchmail. What is the reason not to refer to -downgrade-? + Randall replies that it's an extra requirement, and also that AD (Chris Newman) has requested that the reference not be normative. MIC: Chris Newman, no-hat, notes that downgrade has some wiggle room in it. Therefore, pretending there's one way to downgrade is not a good idea. + Barry Leiba asks, "Why have a downgrade mechanism at all, if it's not consistently applied?" + Chris replies that it's a very good starting point + Chair notes that it is also a mandatory way when in the middle of the net with no knowledge of the target. + Pete asks whether this becomes a SHOULD + John Klensin suggests a difference between a normative downgrade at the edges of a network (past SMTP final delivery) and in the middle of the network. + Chris also argues that, if there is to be specification of what goes on the wire, it should be an RFC2822 message and naught else. Therefore, this is not a necessary requirement. + Randall notes that, even though -downgrade- has variability, it is less than "anything at all". It's the best hope for a future client. + Chris says he merely wants the reference to be informational *Propose three options: MUST -downgrade-, SHOULD -downgrade-, "might" -downgrade-. In this case, "might" is just a note that "many people like to do that", and has no normative force. -SUPPORT FOR MUST: 1 -SUPPORT FOR SHOULD: 5 -SUPPORT FOR MIGHT: 4 *Chair calls no consensus; the debate will go to the list. MIC: Cyrus Daboo asks about the interaction between the TLS and UTF-8 commands, and would like a sentence about what happens if you issue UTF-8 twice. + Randall notes that he isn't clear this is needed, but expresses no objection + Chair outlines an implausible attack, and says he thinks it better to define it one way or the other. He asks for a document update, and then will plan to proceed to EG Last Call. E. -mailto- *Who has read the document? -Few hands rise MIC: Ted Hardie expresses unhappiness. The document will affect systems outside of mail. This needs review. MIC: John Klensin notes that in light of discussion in another meeting about percent signs, the document looks worse. Exhorts review. *Notes that one of the reasons the current draft is unpopular is because it allows approximately the full syntax of mail addresses (like angle brackets) and uses % encoding to hide some elements. He notes that it will not cause problems for current URI encoding as long as it's not for mail. MIC: Randall Gellens expresses concern about % encoding making the mailto: URL look random to humans (who have become used to checking the URL for reasonableness). The context-specificity is also troublesome, because it's impossible to detect the context in every case. He suggests that what's important is to solve the problem long-term: no option is pretty in the short term. MIC: Ted Hardie prefers a completely different URI scheme, because the current effort to maintain a relationship with the older scheme is making a hard problem harder. MIC: Pete Resnick notes that mailto: is in mailing list headers, and there's already more than one of those, so there's a precedent to having more than one scheme. MIC: Barry Leiba offers the observation that the current Firefox handles the examples in -mailto- witout trouble (he tried), but the mail client can't handle the result. + Chris Newman (no hat) observed that 90% of the time the point of a mailto: URI is to launch an application with an opaque string. So if it will remain useful to launch different applications depening on 7- or 8-bits, then there's a good reason for a different URI scheme. + Barry replies that the answer is yes only in the short term. + Randall notes that it might not be bad to have a new scheme with the intent to deprecate the old one, given other acknowledged problems with the existing scheme. *Current target status is EXPERIMENTAL. Does the WG want to keep as close to the eventual syntax as possible? He rules this a discussion for the list. F. -mailinglist- The current darft is -03. Randall Gellens outlines the differences from -02, and points to the -mailto- issue. *Does the document use IRIs or URIs? + Randall notes that the document is hand-wavy because of the -mailto- issue. MIC: Ted Hardie: Given the way IRI is set up, of there's no definition, one cannot act on a general principle. So you must make a URI form before you send anything on the wire. He suggests the current text be pulled. MIC: John Klensin warns that the current document seems to be relying on XML syntax that may be about to be changed by the W3C. Warn them. MIC: Pete Resnick notes that the discussion has convinced him of the need for a new scheme in -mailto-, and that it should be referred to in this document. Randall finished by asking people to read and comment. G. -scenarios- * This has received no comment since it's been revised. Throw it away? MIC: John Klensin suggests taking the useful bits out and folding them into a -framework-bis- document. * Kill? -no support * Publish now? -no support * Fold to -framework-bis-? -12 people * No opinion? -6 people * Rough consensus to fold to -framework-bis-. H. New drafts. -email-clients and -downgraded-display- for consideration. Ernie Darrow offered some background. * Add to next charter? -4 people * Don't put it in the charter? -No support * Put it in the next charter. I. Future work * Propose to set aside some time in Dublin to perform an interoperation demo. * Is the Chair out of his mind to propose standards track completion by end of 2008? MIC: Barry Leiba notes that it depends on how the testing goes, but thinks mid 2009 is more likely. MIC: John Klensin is unusually optimisic, and also notes that a short deadline is a way to keep the pressure on. * Spring, finish up the current documents. * Fall, start standards track document. * Question for AD: is this too optimistic? MIC: AD (Chris Newman): It sounds a little aggressive, but he won't say no. J. Summary of actions 1. Send WGLC: -downgrade- ! depends on decision about URIs/IRIs first. 2. -pop- and -imap- will have one more round of revisions, then WGLC. 3. -mailinglist- ! depends on URI/IRI decision 4. -scenarios- to be folded into -framework-bis- 5. Client-side items will become a part of the charter, but the discussion will go to the list about the timetable. Meeting adjourned.