Last Modified: 2005-02-09
The APPAREA meeting on March 7 2005 was called to order at 9:02 am local time, after John Leslie agreed to act as Scribe, and was chaired by Scott Hollenbeck. Scott presented the agenda for bashing, and no changes were suggested.
Scott announced the closing of two working groups which had completed their work -- FAX and TRADE -- and the formation of two new groups -- SIEVE and LTRU. The charter has been updated for OPES.
Scott gave an update of the status of ATOMPUB. Two basic documents have been written: one for format and the other for protocol. Please check for overlap with other groups' work before last-call. The format document is pretty much finished, though there are still some details about what is to be core functions vs. extensions. The protocol document is somewhat behind schedule.
Two BOFs are planned: CALCIFY and SLRRP.
Bob Morgan introduced the CALCIFY BOF. The work intends to focus on a revision of the calendaring RFC. There is an active mailing list. The BOF will meet Thursday. Bob will not be able to act as Working Group Chair; so they're still seeking the right person...
Scott Barvick introduced the SLRRP BOF with a "context-setting" example. RFID tagging is being mandated by retailers and by DoD. The supply chain crosses every imaginable boundary, including enterprise boundaries and national boundaries. Tags will be read in large quantities; SLRRP tackles how to network the data. Existing prototypes are working today but may not continue to work when large numbers of RF readers start creating interference for each other.
Pete Resnick asked where IP protocol enters this picture. Scott Barvick referred to a slide with many circles for different readers. The back end of each device is IP. Each reader must power the tags, and produces 40 times the RF power of a typical Access Point. The BOF will include presentation of both the RF and IP considerations. There is an active mailing list with 110 members.
Randy Gellens asked what part the IETF plays in this. Scott Barvick explained there are many existing air protocols: the IETF will design a simple data protocol to work with all air protocols, and control the RF readers.
Rich Shockey asked why the proposed work differs from work already done for EPC Global. Scott Barvick explained the EPC air protocol will go to ISO; folks are now working on software interfaces for inter-company data access. SLRRP is intended to be multi-level, and a more centralized architecture. It sets out to solve different problems, and different folks are working on it.
Scott Hollenbeck next describe out-of-APParea BOFs of potential interest, including BTNS and NTP (which is now a newly-formed WG), and a couple of individual RFC submissions he's shepherding. Dave Crocker commented on the individual submissions: that their subjects deal with people more than protocols.
Scott Hollenbeck described changes in the process of handoff, comments, and revisions when I-Ds go to the IESG for publication as RFCs. This will involve more work for Working Group Chairs, with the WGCs being responsible for shepherding much of the process. Dave Crocker asked how this would affect individual submissions; the answer is, it doesn't.
Patrik Faltstrom talked about the IDN problem (where internationalized domain names contain characters "indistinguishable" from plain ASCII, and thus are inevitably confused with exiting ASCII domain names). Patrik opined that this is much the same as the Oh-versus-zero problems we've been dealing with for decades.
Yoshiro Yoneya presented suggestions for application guidelines, including extra mapping, extra prohibitions, and visual highlighting of international characters. Pete Resnick asked whether this was strictly highlighting or involved changing the protocol. Answer: no protocol change. Pete commented that it would be unfortunate to suggest that "Green means bad".
Dave Crocker suggested there are meta-questions we should consider before drowning ourselves in details. Patrik Faltstrom said that registration authorities would like to help solve the problem, but they need guidelines. John Klensin said he's spent the last two years worrying about this problem: we designed a good coding standard for IDN but shuffled off all the usage issues as "somebody else's problem". The result is a situation which is badly broken. Application developers are pushing back: forming their own tables and enforcing their own restrictions. A simple one-lable/one-script rule would have helped (by, e.g., preventing the mixing of latin and cyrillic scripts). There's a worse problem facing us with characters that look like colon and slash. We should perhaps have just redefined "letters" and "numbers" instead of trying to get every Unicode into internationalized domain names.
Patrik Faltstrom asked if John intended to revise tables. Answer: we need to do that anyway to transition to Unicode 4.1. Pete Resnick asked to what extent we want to recommend certain characters as appropriate vs. changing the tables. Answer: we need both; a recommendation without any changes to the standard won't work.
Dave Crocker commented that the problem is vastly more serious than we think; and that we won't succeed in fixing a deep semantic problem with surface syntactic changes. We need an empirical basis in cognitive science; and probably lack that expertise. In the meantime, a restrictive approach is appealing.
Sam Hartman agreed it's perceived as serious. He quoted Paul Hoffman as saying it's not clear how much worse this will be in practice, and warned against redesigning the whole (internationalization) system.
John Klensin attempted to define "serious". We're losing interoperability. Different application designers are coming up with different implementations which are incompatible. This is "serious" because the IETF standard is in essence dead. He believes, however, that the fix need only involve changes to the tables: the algorithms are sound. Patrik Faltstrom asked John if he meant changing tables for registries or for applications. John's reply was somewhat confusing: he talked of different rules for putting things in (DNS) than for looking them up; and it was clear that something about this way of thinking worried him.
Leslie Daigle suggested we need to keep focused on interoperability. She agreed with Sam Hartman that we're seeing a reaction which may be a matter of perception. She announced that the IAB has formed an Ad Hoc committee to study this issue.
Dave Crocker said there are at least two issues: confusion of names and the possibility of syntactic attacks like (non-ASCII) colon-slash. Harald Alvestrand reminded us there are usages of IDN which are clearly not a problem, while other usages present a clear danger, or merely a grey area in between. We mustn't lose track of the first group. Jeff Halleen(sp?) commented that the Unicode mailing-list keeps finding new requirements. Sam Hartman asked if there was sufficient value in reducing Harald's third category without fixing the second. John Klensin suggested we could whittle away at the grey, and greatly reduce Harald's second area.
Leslie Daigle said we need to be careful _which_ slippery slope we slide down. We're confusing the activity of representing real world names in the DNS and the activity of expanding the repertoire available for representing host names. The former requires that we become experts in Unicode, scripts and language requirements (which we are not). The latter is a question of expanding one of our protocols. Dave Crocker agreed. We have no (formal) list of requirements, no list of threats. We should understand the threats before arguing about intent. Harald Alvestrand disagreed: we always design for intents. Brian Carpenter said we've been ducking this issue since 1995; and if we're to have any hope of fixing it, we need to quickly write down some alternatives. Dave Crocker disagreed with Harald: we design for flexibility; we didn't know, for example, how email would be used while we were designing it.
Patrik Faltstrom announced that the IAB Ad Hoc committee is looking to publish a document on this issue by the end of March.
Under the Open Mike agenda item, Barry Leiba asked if there was any hope of getting RFCs 2821 and 2822 (defining email) to the appropriate standard level, so we can stop referring to RFC 821 and 822 as normative. John Klensin replied 2821 would need at least two weeks of serious work before he could circulate anything (and that he had many other demands on his time). It would be very helpful if there was a tool to translate the XML of Microsoft Word into XML2RFC. Pete Resnick has already done the translation to XML2RFC, but there's a major pending issue of revision of the BNF: major changes have been proposed which he finds harder to read. John Klensin with Pete that wholesale replacement of BNF is inappropriate: some proposed changes are good, some are bad, and some are ugly. Chris Newman volunteered to help _during_ the IETF week.
Scott Hollenbeck mentioned some issue with Dave Crocker's work on RFC224. Dave Crocker didn't seem to understand what Scott was concerned about, but agreed to check on the situation.
The meeting was adjourned at 10:43 local time.
-- John Leslie <email@example.com>