ACAP Working Group Minutes, Munich IETF August 1997: Recorded By: Randall Gellens Chris presented agenda; called for comments. No comments on agenda. Comment: post "why ACAP" doc to LDAP [?] list Security issues: Adopt SASL anonymous mechanism? Cosensus: Yes (a few people liked it, no one objected). Issue: not permitted to have plaintext login. Not possible to use ACAP without (a) upgrading one's security infrastructure or (b) violating IESG rules. Options: 1) Require CRAM-MD5 [Discussion of pros and cons.] 2) Write RFC for & Require CRAM-SHA1 [Discussion of pros and cons.] 3) Adopt & Require SCRAM (salted verifier + encrypted hash of pw) [Discussion of pros and cons.] 4) Wait for SSH or TLS and require its use (with plaintext passwords encrypted underneath) [Discussion of pros and cons.] Comments: AARG list had other mechanism suggestions. Answer: We want to stick with simple mechanisms to avoid delay. Call for consensus on (4): no one liked it. Comment: difficulty of getting implementors to adopt mechanism. Comment: we are discussing mandatory mechanisms, SASL allows more secure mechanisms as well. Comment: go with MUST for CRAM-xxx, SHOULD do something stronger. Comment: go with CRAM-MD5 because it is easiest to get through standards process. Comment: unable to get CRAM-xxx except CRAM-MD5 through security area Comment: SCRAM not had review...eliminate? [discussion of Authentication exchange & verifier both on wire; risks] [discussion of risks of stealing host's password file] Comment: CRAM-MD5 & -SHA1 both riskier than /etc/pw since stealing verifier gives access to all accounts Comment: took 6 months to get CRAM-MD5 through standard process; new protocols take time, especially security protocols Comment: other problems with CRAM. No authentication id. Mutual authentication problem. Comment: go with CRAM-MD5 as baseline. Comment: SCRAM-SHA1 needs review by crypto people. Then move forward or drop. Call for consensus: use CRAM-MD5 as baseline; also pursue SCRAM-SHA1. Comment: Also pursue other AARG proposals. If CRAM-MD5 is baseline, other mechanisms are optional and can be pursued in their own time Comment: CRAM is like APOP: why not just use APOP? Answer: APOP worse than CRAM. More security risks. Must store password in clear on server. Answer: CRAM-MD5 is in all ways better than APOP. Back to consensus. No objections. CRAM-MD5 to be used as baseline; also pursue SCRAM-SHA1. Comment: CRAM-MD5 is the only option which is already an RFC. Harald: This is the right choice for the ACAP group. It is not for the ACAP group to do crypto protocols. Chris Newman: ACAP has dependencies on SASL-PLAIN for transition mechanism. Since plain may not be approved, we need to remove dependencies. Should we remove the transition error codes? That means all users must change their password to use ACAP. Should we try and get SASL-PLAIN on the standards-track? That would delay ACAP. John Myers proposed that we leave the transition error codes in but remove the dependencies on SASL-PLAIN. That way there is a means to do transition but the mechanism is not specified. Call for consensus on John's proposal. No objections: ACAP to leave transition error codes in, but delete dependencies on SASL-PLAIN. Comment: How would a user get the transition error codes? No login mechanism specified in ACAP which uses them. Answer: Through an unspecified mechanism. Maybe CRAM-MD5. The error codes mean "The server does not have auth [something] for you". Comment: Don't we need a consistent error msg which tells users to go to their admin? Answer: This is a UI issue. Comment: Leave transition out of spec, do it in its own spec which updates ACAP? Comment: Controversial proposal to transition away from plaintext? Answer: It's not controversial. Comment: The mechanism is conttroversial. Answer: We are only leaving in the error codes, not the mechanism. Harald: I think an informational RFC which specifies a plaintext mechanism and how to use it in a transition strategy, and how to use it with IMAP login would not be any more offensive to the IESG than a document on how to do 8-bit to 7-bit downgrades in email. Chris Newman: I intend to do that. Authid/groupid datasets: Authid: Authid draft posted. Now in I-D directories. How many have read it? (Three people raised their hands). Steve Hole: [summarized draft] authentication-id, authorization-id, user-id, authent-id -> user-id group={user-id, group-id} Comment: Any way to associate an authentication mechanism with a specific auth. id? Answer: Yes. Multi-value attribute which holds list of auth-ids per user-id; e.g., different Kerberos principals. Steve Hole: Not only would ACAP use this dataset, but other servers (e.g., IMAP) could use it. Steve Hole: Organizations like to keep their auth-ids secret. "Hackers handbook". Also auth-ids are often meaningless (e.g., numeric). Comment: Nothing in draft that says at any level that ID is unique. Answer: Was supposed to be. Answer: Must be because it is stored in the "entry" attribute, which must be unique. Answer: Can't have auth-id bind to more to more than one user-id? Maybe we want to allow it. Steve Hole: It is possible for an ACAP server to provide this dataset but not obey its semantics. Comment: Why are there different attributess for user-ids & group-ids in group lists? Is it to allow users & groups with the same name? Answer: It's not intended to allow that. Need to clarify. Comment: Is there a group member-of? A way to find what groups a group is in? Answer: Not sure how useful it is, but it should be there for completeness. Comment: If a group is removed, it's needed to know which groups to clean up. Comment: User name field has no semantics or constraints on it. This is a problem with interaction with other directory services. Should require minimum amount of structure? Consider one database with ACAP and LDAP access protocols. If name is freely structured, it is very hard to impose structure later or use it from more than one place. Chris Newman: Purpose of field is not to be a directory service; it's only to make a user-friendly UI. Make the field the LDAP common name if there is a directory service back-end. Comment: Say that [in the spec]. Comment: Might have multiple access protocols for same data; there is a move to single storage. Steve Hole: It's left to the discretion of the site admin to put whatever they want in there. Comment: Sites are now trying to take old pw files and put into directory. Problem is name fields were overloaded, must be moved manually. Steve Hole: There is a potential for other attributes. For example, expired, disabled, etc. There are potentially a lot. Didn't bother to specify them, but there may be a sub-set which is useful to standardize. Discuss on list? Options dataset draft: [Steve gave summary] This was complex, but became very simple because of multi-valued attributes. The idea is it's a scribble-space for options. Certain kinds of configuration info should be shared between applications/users. Those become datasets. The draft defines rules for how such datasets are to be specified. Also option to conventionalize single options which are useful to multiple applications, e.g., SMTP host name for mailers. Should be standardized in common, but doesn't need heavy-weight registration procedure. Need light-weight registry procedure. Comment: What form are datasets defined in? Are datasets spec in ASN.1? Answer: ABNF in standards-track RFC. Comment: LDAP et al has a procedure. Answer: That's for different problems. Comment: Need type specified. Answer: Other drafts are addressing that. It's not really part of ACAP. In ACAP you know what you are going after. Possible use for RegEdit-type apps (generic dataset editor) but not generally very useful. Comment: It's not as different as you imagine from other efforts. Consider Service Location, very similar considerations. Calsched, other groups are doing similar schema work. Need to pay attention to other groups. Comment: Service Location could be font-end for LDAP directory. Comment: ACAP could be same thing. Comment: Draft for how to transfer schema stuff from Server Location to others. Personal Addressbook Specification: [Summary of draft] The draft is numbered -00 but is really later. The I-D people never published the earlier version. Users own the information in an ACAP addressbook. It can contain the user's comments on how people are jerks or whatever. Unlike a directory, this is not generally for public consumption. The information is similar to white pages. This is based on white pages, but adds attributes appropriate for personal address books (e.g., comments). (1) Issue with vCard. vCard is going to be a big deal. There is a problem mapping vCard to LDAP. It will be worse with ACAP since there is no property description. E.g., phone/address. Personal, cellular, etc. vCard says "this is phone number for purpose x" instead of having different named attributes. How to map? One idea: add parallel attribute for each phone number to list what it is used for. Two attributes with relation between names. Or metadata for uses of attribute. (2) vCard allows subsitution of URL for value. We could have an attribute name convention for doing this. Comment: Define attribute which is URL, one type of URL is data URL. Comment: Data URL is meaningless without typing. Comment: Meaning goes with attribute. Photo attribute has data URL; you know what it is. (3) Lots of porly-specified attributes like 'role' and 'title'. Doesn't want to add to dataset class if specification will change. Comment: Fits with ACAP. Media types dataset: This is a perfect fit for ACAP. User-customizable site defaults. Comment: There was a comment in another session that lots of mail applications are broken becaue they don't allow selection of helper applicationss per MIME type. Chris Newman: How many people had read media types dataset draft? (a few) Chris Newman: Media types carry security warning. Comment: Risk is in interpretive contents. Comment: It's a disservice to not have it, but having it might cause problem getting it through security area. Comment: It won't introduce new security risks. Comment: It could carry risks to new systems. Batch files, for example. Comment: Applications start with hard-coded list; users can add to but not delete from it. Comment: By default in Internet Explorer everything is considered dangerous. Users can say to stop warning for all types except core list. Comment: Could have admin supply core list to prevent users from not being warned about type "foo". Comment: Security risks are highly application specific; plain-text is a potential risk [on some displays] but don't want to see warning for every access of plain-text content. Chris Newman: Should we flush this attribute? Or discuss on list? Call for consensus: A few want to discuss, no one wants to punt. Language specific comparitors. [John Myers summarized issues] -language -unicode decomposition -strength (how exact is search) + in general 4 cases: alphanumeric / diacriticals / case / specials Comment: Is 'special' comma or Cryllic without diacritical? + ISO 1461/1462 specifies up to 7 levels of distinction + Java has 4 fixed levels: primary/secondary/tertiary/identical -version/vendor functions won't be same between implementation. -other qualities +dictionary/phonebook/etc. Strawman: language -tag; properties e.g., fr; secondarystrength en; phonetic; primarystrength ACAP base comparators: i; octet i; numeric i; ascii-casefold ("i" stands for "international", cross-language) Comment: What is "i; numeric"? Comment: Same as ASCII numeric? Comment: Fractions. Comment: UTF-8 numeric. John Myers:: Specified in ISO 10646. Chris Newman: Base spec requires support for UTF-8 but not complex mapping. Comment: Since we're talking about atoi what about UTF-8? Comment: Kanjii numerals. Comment: How are these collated? Answer: code-point order. Comment: Entire procol is UTF-8 but these are octets. [lots of comments on ordering vs octets which are outside the set] Someone (Chris?): We changed the name of the "i; numeric" comparitor to "i; ascii-numeric". Comment: New comparitors added as extension docs? Answer: Registry thing, like MIME. Comment: Problem with semicolon in syntax? Comment: Could use colon or slash. Comment: Proposal in specific order? John Myers: Specific order is best. Truncated case. Chris Newman: Don't want same comparitor with two names. Sort proposal by names. Comment: How to sort? Chris Newman: Use US ASCII sorting. Comment: Unhappy with having server tell client which comparitors are valid in LANG response. Can't have client which detects all comparitors available. Chris Newman: There could be 500 comparitors. Don't want to announce them all in greeting. Comment: use a dataset? Chris Newman: The problem with that is it's a solution specific to ACAP; need same services in IMAP, etc. Comment: Why do you need all comparitors? Comment: Bilingual user, doesn't want to move into one language only. Chris Newman: LANG has list of languages in order of preference; response has all comparitors valid in all languages. Comment: is there a way to switch back to the default? [discusion of difference between default languge = English and switching to English] Comment: Some kind of tag to specify technical English or "default". Comment: This seems very complicated. Why need more than store and search? Chris Newman: Error texts and comparitor discovery. John Myers: English vs "Internationalized English" Comment: Why so complicated? Comment: The two Englishes MAY be different. John Myers: Can't get compators without selecting language. Chris Newman: Default language is 'en'? En=any English dialect. Comment: Don't need to discover comparitor for English? Comment: Yes, select En. WG Milestones & Disposition Close down Working Group after Draft or put out dataset specs, extensions, etc.? Comment: Keep group going until ACAP is at Draft or Proposed? Comment: Mailing list stays around after WG closes. Comment: Do dataset classes in charter. Comment: Add additional dataset classes to charter. Call for consensus on having group do all discussed dataset classes. No objections. Do media types extension? Comment: Ask on list; lots of discussion. Do type labelling extension? Comment: Do Rob's only. Naming convention and registry for language-sensitive comparitor? Comment: Only useful if other groups need it? John Myers: Who has the knowledge to do it? Comment: Spin off a new group to do it. Get more experts, raise profile. Comment: Dood idea. Get people from LDAP etc. Comment: BOF in December on that? John Myers will chair. Chris Newman: Meet in December to discuss work on dataset classes etc? Comment: Yes. Comment: Proposal to just do dataset classes for which drafts are available. No objections. Want options dataset to go though at same time as spec. Chris Newman to send in charter update. New ACAP spec with short last-call on list. Meeting adjourned. From - Wed Sep 10 16:04:45 1997 Received: from ietf.org by ietf.org id aa10429; 9 Sep 97 12:02 EDT Received: from THOR.INNOSOFT.COM by ietf.org id aa10425; 9 Sep 97 12:02 EDT Received: from eleanor.innosoft.com ("port 45763"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01INFLTO2XF294FJPP@INNOSOFT.COM> for minutes@ietf.org; Tue, 9 Sep 1997 09:01:17 PDT Date: Tue, 09 Sep 1997 09:03:15 -0700 (PDT) Sender:minutes-request@ietf.org From: Chris Newman Subject: ACAP WG Minutes (Munich IETF) (fwd) To: IETF ACAP Mailing List , minutes@ietf.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=thor.innosoft.com Status: X-Mozilla-Status: 8001 ACAP Working Group Minutes, Munich IETF August 1997: Recorded By: Randall Gellens Chris presented agenda; called for comments. No comments on agenda. Comment: post "why ACAP" doc to LDAP [?] list Security issues: Adopt SASL anonymous mechanism? Cosensus: Yes (a few people liked it, no one objected). Issue: not permitted to have plaintext login. Not possible to use ACAP without (a) upgrading one's security infrastructure or (b) violating IESG rules. Options: 1) Require CRAM-MD5 [Discussion of pros and cons.] 2) Write RFC for & Require CRAM-SHA1 [Discussion of pros and cons.] 3) Adopt & Require SCRAM (salted verifier + encrypted hash of pw) [Discussion of pros and cons.] 4) Wait for SSH or TLS and require its use (with plaintext passwords encrypted underneath) [Discussion of pros and cons.] Comments: AARG list had other mechanism suggestions. Answer: We want to stick with simple mechanisms to avoid delay. Call for consensus on (4): no one liked it. Comment: difficulty of getting implementors to adopt mechanism. Comment: we are discussing mandatory mechanisms, SASL allows more secure mechanisms as well. Comment: go with MUST for CRAM-xxx, SHOULD do something stronger. Comment: go with CRAM-MD5 because it is easiest to get through standards process. Comment: unable to get CRAM-xxx except CRAM-MD5 through security area Comment: SCRAM not had review...eliminate? [discussion of Authentication exchange & verifier both on wire; risks] [discussion of risks of stealing host's password file] Comment: CRAM-MD5 & -SHA1 both riskier than /etc/pw since stealing verifier gives access to all accounts Comment: took 6 months to get CRAM-MD5 through standard process; new protocols take time, especially security protocols Comment: other problems with CRAM. No authentication id. Mutual authentication problem. Comment: go with CRAM-MD5 as baseline. Comment: SCRAM-SHA1 needs review by crypto people. Then move forward or drop. Call for consensus: use CRAM-MD5 as baseline; also pursue SCRAM-SHA1. Comment: Also pursue other AARG proposals. If CRAM-MD5 is baseline, other mechanisms are optional and can be pursued in their own time Comment: CRAM is like APOP: why not just use APOP? Answer: APOP worse than CRAM. More security risks. Must store password in clear on server. Answer: CRAM-MD5 is in all ways better than APOP. Back to consensus. No objections. CRAM-MD5 to be used as baseline; also pursue SCRAM-SHA1. Comment: CRAM-MD5 is the only option which is already an RFC. Harald: This is the right choice for the ACAP group. It is not for the ACAP group to do crypto protocols. Chris Newman: ACAP has dependencies on SASL-PLAIN for transition mechanism. Since plain may not be approved, we need to remove dependencies. Should we remove the transition error codes? That means all users must change their password to use ACAP. Should we try and get SASL-PLAIN on the standards-track? That would delay ACAP. John Myers proposed that we leave the transition error codes in but remove the dependencies on SASL-PLAIN. That way there is a means to do transition but the mechanism is not specified. Call for consensus on John's proposal. No objections: ACAP to leave transition error codes in, but delete dependencies on SASL-PLAIN. Comment: How would a user get the transition error codes? No login mechanism specified in ACAP which uses them. Answer: Through an unspecified mechanism. Maybe CRAM-MD5. The error codes mean "The server does not have auth [something] for you". Comment: Don't we need a consistent error msg which tells users to go to their admin? Answer: This is a UI issue. Comment: Leave transition out of spec, do it in its own spec which updates ACAP? Comment: Controversial proposal to transition away from plaintext? Answer: It's not controversial. Comment: The mechanism is conttroversial. Answer: We are only leaving in the error codes, not the mechanism. Harald: I think an informational RFC which specifies a plaintext mechanism and how to use it in a transition strategy, and how to use it with IMAP login would not be any more offensive to the IESG than a document on how to do 8-bit to 7-bit downgrades in email. Chris Newman: I intend to do that. Authid/groupid datasets: Authid: Authid draft posted. Now in I-D directories. How many have read it? (Three people raised their hands). Steve Hole: [summarized draft] authentication-id, authorization-id, user-id, authent-id -> user-id group={user-id, group-id} Comment: Any way to associate an authentication mechanism with a specific auth. id? Answer: Yes. Multi-value attribute which holds list of auth-ids per user-id; e.g., different Kerberos principals. Steve Hole: Not only would ACAP use this dataset, but other servers (e.g., IMAP) could use it. Steve Hole: Organizations like to keep their auth-ids secret. "Hackers handbook". Also auth-ids are often meaningless (e.g., numeric). Comment: Nothing in draft that says at any level that ID is unique. Answer: Was supposed to be. Answer: Must be because it is stored in the "entry" attribute, which must be unique. Answer: Can't have auth-id bind to more to more than one user-id? Maybe we want to allow it. Steve Hole: It is possible for an ACAP server to provide this dataset but not obey its semantics. Comment: Why are there different attributess for user-ids & group-ids in group lists? Is it to allow users & groups with the same name? Answer: It's not intended to allow that. Need to clarify. Comment: Is there a group member-of? A way to find what groups a group is in? Answer: Not sure how useful it is, but it should be there for completeness. Comment: If a group is removed, it's needed to know which groups to clean up. Comment: User name field has no semantics or constraints on it. This is a problem with interaction with other directory services. Should require minimum amount of structure? Consider one database with ACAP and LDAP access protocols. If name is freely structured, it is very hard to impose structure later or use it from more than one place. Chris Newman: Purpose of field is not to be a directory service; it's only to make a user-friendly UI. Make the field the LDAP common name if there is a directory service back-end. Comment: Say that [in the spec]. Comment: Might have multiple access protocols for same data; there is a move to single storage. Steve Hole: It's left to the discretion of the site admin to put whatever they want in there. Comment: Sites are now trying to take old pw files and put into directory. Problem is name fields were overloaded, must be moved manually. Steve Hole: There is a potential for other attributes. For example, expired, disabled, etc. There are potentially a lot. Didn't bother to specify them, but there may be a sub-set which is useful to standardize. Discuss on list? Options dataset draft: [Steve gave summary] This was complex, but became very simple because of multi-valued attributes. The idea is it's a scribble-space for options. Certain kinds of configuration info should be shared between applications/users. Those become datasets. The draft defines rules for how such datasets are to be specified. Also option to conventionalize single options which are useful to multiple applications, e.g., SMTP host name for mailers. Should be standardized in common, but doesn't need heavy-weight registration procedure. Need light-weight registry procedure. Comment: What form are datasets defined in? Are datasets spec in ASN.1? Answer: ABNF in standards-track RFC. Comment: LDAP et al has a procedure. Answer: That's for different problems. Comment: Need type specified. Answer: Other drafts are addressing that. It's not really part of ACAP. In ACAP you know what you are going after. Possible use for RegEdit-type apps (generic dataset editor) but not generally very useful. Comment: It's not as different as you imagine from other efforts. Consider Service Location, very similar considerations. Calsched, other groups are doing similar schema work. Need to pay attention to other groups. Comment: Service Location could be font-end for LDAP directory. Comment: ACAP could be same thing. Comment: Draft for how to transfer schema stuff from Server Location to others. Personal Addressbook Specification: [Summary of draft] The draft is numbered -00 but is really later. The I-D people never published the earlier version. Users own the information in an ACAP addressbook. It can contain the user's comments on how people are jerks or whatever. Unlike a directory, this is not generally for public consumption. The information is similar to white pages. This is based on white pages, but adds attributes appropriate for personal address books (e.g., comments). (1) Issue with vCard. vCard is going to be a big deal. There is a problem mapping vCard to LDAP. It will be worse with ACAP since there is no property description. E.g., phone/address. Personal, cellular, etc. vCard says "this is phone number for purpose x" instead of having different named attributes. How to map? One idea: add parallel attribute for each phone number to list what it is used for. Two attributes with relation between names. Or metadata for uses of attribute. (2) vCard allows subsitution of URL for value. We could have an attribute name convention for doing this. Comment: Define attribute which is URL, one type of URL is data URL. Comment: Data URL is meaningless without typing. Comment: Meaning goes with attribute. Photo attribute has data URL; you know what it is. (3) Lots of porly-specified attributes like 'role' and 'title'. Doesn't want to add to dataset class if specification will change. Comment: Fits with ACAP. Media types dataset: This is a perfect fit for ACAP. User-customizable site defaults. Comment: There was a comment in another session that lots of mail applications are broken becaue they don't allow selection of helper applicationss per MIME type. Chris Newman: How many people had read media types dataset draft? (a few) Chris Newman: Media types carry security warning. Comment: Risk is in interpretive contents. Comment: It's a disservice to not have it, but having it might cause problem getting it through security area. Comment: It won't introduce new security risks. Comment: It could carry risks to new systems. Batch files, for example. Comment: Applications start with hard-coded list; users can add to but not delete from it. Comment: By default in Internet Explorer everything is considered dangerous. Users can say to stop warning for all types except core list. Comment: Could have admin supply core list to prevent users from not being warned about type "foo". Comment: Security risks are highly application specific; plain-text is a potential risk [on some displays] but don't want to see warning for every access of plain-text content. Chris Newman: Should we flush this attribute? Or discuss on list? Call for consensus: A few want to discuss, no one wants to punt. Language specific comparitors. [John Myers summarized issues] -language -unicode decomposition -strength (how exact is search) + in general 4 cases: alphanumeric / diacriticals / case / specials Comment: Is 'special' comma or Cryllic without diacritical? + ISO 1461/1462 specifies up to 7 levels of distinction + Java has 4 fixed levels: primary/secondary/tertiary/identical -version/vendor functions won't be same between implementation. -other qualities +dictionary/phonebook/etc. Strawman: language -tag; properties e.g., fr; secondarystrength en; phonetic; primarystrength ACAP base comparators: i; octet i; numeric i; ascii-casefold ("i" stands for "international", cross-language) Comment: What is "i; numeric"? Comment: Same as ASCII numeric? Comment: Fractions. Comment: UTF-8 numeric. John Myers:: Specified in ISO 10646. Chris Newman: Base spec requires support for UTF-8 but not complex mapping. Comment: Since we're talking about atoi what about UTF-8? Comment: Kanjii numerals. Comment: How are these collated? Answer: code-point order. Comment: Entire procol is UTF-8 but these are octets. [lots of comments on ordering vs octets which are outside the set] Someone (Chris?): We changed the name of the "i; numeric" comparitor to "i; ascii-numeric". Comment: New comparitors added as extension docs? Answer: Registry thing, like MIME. Comment: Problem with semicolon in syntax? Comment: Could use colon or slash. Comment: Proposal in specific order? John Myers: Specific order is best. Truncated case. Chris Newman: Don't want same comparitor with two names. Sort proposal by names. Comment: How to sort? Chris Newman: Use US ASCII sorting. Comment: Unhappy with having server tell client which comparitors are valid in LANG response. Can't have client which detects all comparitors available. Chris Newman: There could be 500 comparitors. Don't want to announce them all in greeting. Comment: use a dataset? Chris Newman: The problem with that is it's a solution specific to ACAP; need same services in IMAP, etc. Comment: Why do you need all comparitors? Comment: Bilingual user, doesn't want to move into one language only. Chris Newman: LANG has list of languages in order of preference; response has all comparitors valid in all languages. Comment: is there a way to switch back to the default? [discusion of difference between default languge = English and switching to English] Comment: Some kind of tag to specify technical English or "default". Comment: This seems very complicated. Why need more than store and search? Chris Newman: Error texts and comparitor discovery. John Myers: English vs "Internationalized English" Comment: Why so complicated? Comment: The two Englishes MAY be different. John Myers: Can't get compators without selecting language. Chris Newman: Default language is 'en'? En=any English dialect. Comment: Don't need to discover comparitor for English? Comment: Yes, select En. WG Milestones & Disposition Close down Working Group after Draft or put out dataset specs, extensions, etc.? Comment: Keep group going until ACAP is at Draft or Proposed? Comment: Mailing list stays around after WG closes. Comment: Do dataset classes in charter. Comment: Add additional dataset classes to charter. Call for consensus on having group do all discussed dataset classes. No objections. Do media types extension? Comment: Ask on list; lots of discussion. Do type labelling extension? Comment: Do Rob's only. Naming convention and registry for language-sensitive comparitor? Comment: Only useful if other groups need it? John Myers: Who has the knowledge to do it? Comment: Spin off a new group to do it. Get more experts, raise profile. Comment: Dood idea. Get people from LDAP etc. Comment: BOF in December on that? John Myers will chair. Chris Newman: Meet in December to discuss work on dataset classes etc? Comment: Yes. Comment: Proposal to just do dataset classes for which drafts are available. No objections. Want options dataset to go though at same time as spec. Chris Newman to send in charter update. New ACAP spec with short last-call on list. Meeting adjourned.