home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / acap / acap-minutes-97aug.txt < prev   
Text File  |  1997-10-10  |  32KB  |  1,090 lines
  1. ACAP Working Group Minutes, Munich IETF August 1997:
  2.  
  3.  
  4. Recorded By: Randall Gellens
  5.  
  6. Chris presented agenda; called for comments.
  7. No comments on agenda.
  8.  
  9. Comment: post "why ACAP" doc to LDAP [?] list
  10.  
  11. Security issues:
  12.     Adopt SASL anonymous mechanism?
  13.     Cosensus: Yes (a few people liked it, no one objected).
  14.  
  15.     Issue: not permitted to have plaintext login.
  16.  
  17.     Not possible to use ACAP without (a) upgrading one's security
  18. infrastructure or (b) violating IESG rules.
  19.  
  20.     Options:
  21.  
  22.     1)  Require CRAM-MD5
  23.     [Discussion of pros and cons.]
  24.  
  25.     2)  Write RFC for & Require CRAM-SHA1
  26.     [Discussion of pros and cons.]
  27.  
  28.     3)  Adopt & Require SCRAM (salted verifier + encrypted hash of pw)
  29.     [Discussion of pros and cons.]
  30.  
  31.     4)  Wait for SSH or TLS and require its use (with plaintext
  32. passwords encrypted underneath)
  33.     [Discussion of pros and cons.]
  34.  
  35.     Comments: AARG list had other mechanism suggestions.
  36.     Answer: We want to stick with simple mechanisms to avoid delay.
  37.  
  38.     Call for consensus on (4):
  39.     no one liked it.
  40.  
  41.     Comment: difficulty of getting implementors to adopt mechanism.
  42.  
  43.     Comment: we are discussing mandatory mechanisms, SASL allows more
  44. secure mechanisms as well.
  45.  
  46.     Comment: go with MUST for CRAM-xxx, SHOULD do something stronger.
  47.  
  48.     Comment: go with CRAM-MD5 because it is easiest to get through
  49. standards process.
  50.  
  51.     Comment: unable to get CRAM-xxx except CRAM-MD5 through security area
  52.  
  53.     Comment: SCRAM not had review...eliminate?
  54.  
  55.     [discussion of Authentication exchange & verifier both on wire; risks]
  56.  
  57.     [discussion of risks of stealing host's password file]
  58.  
  59.     Comment: CRAM-MD5 & -SHA1 both riskier than /etc/pw since stealing
  60. verifier gives access to all accounts
  61.  
  62.     Comment: took 6 months to get CRAM-MD5 through standard process;
  63. new protocols take time, especially security protocols
  64.  
  65.     Comment: other problems with CRAM.  No authentication id.  Mutual
  66. authentication problem.
  67.  
  68.     Comment: go with CRAM-MD5 as baseline.
  69.  
  70.     Comment: SCRAM-SHA1 needs review by crypto people.  Then move
  71. forward or drop.
  72.  
  73.     Call for consensus: use CRAM-MD5 as baseline; also pursue SCRAM-SHA1.
  74.  
  75.     Comment: Also pursue other AARG proposals.  If CRAM-MD5 is
  76. baseline, other mechanisms are optional and can be pursued in their own time
  77.  
  78.     Comment: CRAM is like APOP: why not just use APOP?
  79.  
  80.     Answer: APOP worse than CRAM.  More security risks.  Must store
  81. password in clear on server.
  82.  
  83.     Answer: CRAM-MD5 is in all ways better than APOP.
  84.  
  85.     Back to consensus.
  86.     No objections.  CRAM-MD5 to be used as baseline; also pursue
  87. SCRAM-SHA1.
  88.  
  89.     Comment: CRAM-MD5 is the only option which is already an RFC.
  90.  
  91.     Harald: This is the right choice for the ACAP group.  It is not for
  92. the ACAP group to do crypto protocols.
  93.  
  94.     Chris Newman: ACAP has dependencies on SASL-PLAIN for transition
  95. mechanism.  Since plain may not be approved, we need to remove dependencies.
  96.  
  97.     Should we remove the transition error codes?  That means all users
  98. must change their password to use ACAP.  Should we try and get SASL-PLAIN
  99. on the standards-track?  That would delay ACAP.
  100.  
  101.     John Myers proposed that we leave the transition error codes in but
  102. remove the dependencies on SASL-PLAIN.  That way there is a means to do
  103. transition but the mechanism is not specified.
  104.     Call for consensus on John's proposal.
  105.     No objections: ACAP to leave transition error codes in, but delete
  106. dependencies on SASL-PLAIN.
  107.  
  108.     Comment: How would a user get the transition error codes?  No login
  109. mechanism specified in ACAP which uses them.
  110.  
  111.     Answer: Through an unspecified mechanism.  Maybe CRAM-MD5.  The
  112. error codes mean "The server does not have auth [something] for you".
  113.  
  114.     Comment: Don't we need a consistent error msg which tells users to
  115. go to their admin?
  116.  
  117.     Answer: This is a UI issue.
  118.  
  119.     Comment: Leave transition out of spec, do it in its own spec which
  120. updates ACAP?
  121.  
  122.     Comment: Controversial proposal to transition away from plaintext?
  123.  
  124.     Answer: It's not controversial.
  125.  
  126.     Comment: The mechanism is conttroversial.
  127.  
  128.     Answer: We are only leaving in the error codes, not the mechanism.
  129.  
  130.     Harald: I think an informational RFC which specifies a plaintext
  131. mechanism and how to use it in a transition strategy, and how to use it
  132. with IMAP login would not be any more offensive to the IESG than a document
  133. on how to do 8-bit to 7-bit downgrades in email.
  134.  
  135.     Chris Newman: I intend to do that.
  136.  
  137.  
  138. Authid/groupid datasets:
  139.  
  140.     Authid:
  141.  
  142.     Authid draft posted.  Now in I-D directories.  How many have read it?
  143.     (Three people raised their hands).
  144.  
  145.     Steve Hole: [summarized draft]
  146.         authentication-id, authorization-id, user-id,
  147.         authent-id -> user-id    group={user-id, group-id}
  148.  
  149.     Comment: Any way to associate an authentication mechanism with a
  150. specific auth. id?
  151.  
  152.     Answer: Yes.  Multi-value attribute which holds list of auth-ids
  153. per user-id; e.g., different Kerberos principals.
  154.  
  155.     Steve Hole: Not only would ACAP use this dataset, but other servers
  156. (e.g., IMAP) could use it.
  157.  
  158.     Steve Hole: Organizations like to keep their auth-ids secret.
  159. "Hackers handbook".  Also auth-ids are often meaningless (e.g., numeric).
  160.  
  161.     Comment: Nothing in draft that says at any level that ID is unique.
  162.  
  163.     Answer: Was supposed to be.
  164.  
  165.     Answer: Must be because it is stored in the "entry" attribute,
  166. which must be unique.
  167.  
  168.     Answer: Can't have auth-id bind to more to more than one user-id?
  169. Maybe we want to allow it.
  170.  
  171.     Steve Hole: It is possible for an ACAP server to provide this
  172. dataset but not obey its semantics.
  173.  
  174.     Comment: Why are there different attributess for user-ids &
  175. group-ids in group lists?  Is it to allow users & groups with the same name?
  176.  
  177.     Answer: It's not intended to allow that.  Need to clarify.
  178.  
  179.     Comment: Is there a group member-of?  A way to find what groups a
  180. group is in?
  181.     Answer:  Not sure how useful it is, but it should be there for
  182. completeness.
  183.  
  184.     Comment: If a group is removed, it's needed to know which groups to
  185. clean up.
  186.  
  187.     Comment: User name field has no semantics or constraints on it.
  188. This is a problem with interaction with other directory services.  Should
  189. require minimum amount of structure?  Consider one database with ACAP and
  190. LDAP access protocols.  If name is freely structured, it is very hard to
  191. impose structure later or use it from more than one place.
  192.  
  193.     Chris Newman: Purpose of field is not to be a directory service;
  194. it's only to make a user-friendly UI.  Make the field the LDAP common name
  195. if there is a directory service back-end.
  196.  
  197.     Comment: Say that [in the spec].
  198.  
  199.     Comment: Might have multiple access protocols for same data; there
  200. is a move to single storage.
  201.  
  202.     Steve Hole: It's left to the discretion of the site admin to put
  203. whatever they want in there.
  204.  
  205.     Comment: Sites are now trying to take old pw files and put into
  206. directory.  Problem is name fields were overloaded, must be moved manually.
  207.  
  208.     Steve Hole: There is a potential for other attributes.  For
  209. example, expired, disabled, etc.  There are potentially a lot.  Didn't
  210. bother to specify them, but there may be a sub-set which is useful to
  211. standardize.  Discuss on list?
  212.  
  213.  
  214.     Options dataset draft:
  215.  
  216.     [Steve gave summary]
  217.     This was complex, but became very simple because of multi-valued
  218. attributes.  The idea is it's a scribble-space for options.  Certain kinds
  219. of configuration info should be shared between applications/users.  Those
  220. become datasets.  The draft defines rules for how such datasets are to be
  221. specified.
  222.  
  223.     Also option to conventionalize single options which are useful to
  224. multiple applications, e.g., SMTP host name for mailers.  Should be
  225. standardized in common, but doesn't need heavy-weight registration
  226. procedure.  Need light-weight registry procedure.
  227.  
  228.     Comment: What form are datasets defined in?  Are datasets spec in
  229. ASN.1?
  230.  
  231.     Answer: ABNF in standards-track RFC.
  232.  
  233.     Comment: LDAP et al has a procedure.
  234.  
  235.     Answer: That's for different problems.
  236.  
  237.     Comment: Need type specified.
  238.  
  239.     Answer: Other drafts are addressing that.  It's not really part of
  240. ACAP.  In ACAP you know what you are going after.  Possible use for
  241. RegEdit-type apps (generic dataset editor) but not generally very useful.
  242.  
  243.     Comment: It's not as different as you imagine from other efforts.
  244. Consider Service Location, very similar considerations.  Calsched, other
  245. groups are doing similar schema work.  Need to pay attention to other
  246. groups.
  247.  
  248.     Comment: Service Location could be font-end for LDAP directory.
  249.  
  250.     Comment: ACAP could be same thing.
  251.  
  252.     Comment: Draft for how to transfer schema stuff from Server
  253. Location to others.
  254.  
  255.  
  256.     Personal Addressbook Specification:
  257.  
  258.     [Summary of draft]
  259.     The draft is numbered -00 but is really later.  The I-D people
  260. never published the earlier version.
  261.  
  262.     Users own the information in an ACAP addressbook.  It can contain
  263. the user's comments on how people are jerks or whatever.  Unlike a
  264. directory, this is not generally for public consumption.  The information
  265. is similar to white pages.  This is based on white pages, but adds
  266. attributes appropriate for personal address books (e.g., comments).
  267.  
  268.     (1)  Issue with vCard.  vCard is going to be a big deal. There is a
  269. problem mapping vCard to LDAP.  It will be worse with ACAP since there is
  270. no property description.
  271.  
  272.     E.g., phone/address.  Personal, cellular, etc.  vCard says "this is
  273. phone number for purpose x" instead of having different named attributes.
  274. How to map?
  275.  
  276.     One idea: add parallel attribute for each phone number to list what
  277. it is used for.
  278.  
  279.     Two attributes with relation between names.
  280.  
  281.     Or metadata for uses of attribute.
  282.  
  283.  
  284.     (2) vCard allows subsitution of URL for value.  We could have an
  285. attribute name convention for doing this.
  286.  
  287.     Comment: Define attribute which is URL, one type of URL is data URL.
  288.  
  289.     Comment: Data URL is meaningless without typing.
  290.  
  291.     Comment: Meaning goes with attribute.  Photo attribute has data
  292. URL; you know what it is.
  293.  
  294.     (3)  Lots of porly-specified attributes like 'role' and 'title'.
  295. Doesn't want to add to dataset class if specification will change.
  296.  
  297.     Comment: Fits with ACAP.
  298.  
  299.  
  300.     Media types dataset:
  301.  
  302.     This is a perfect fit for ACAP.  User-customizable site defaults.
  303.  
  304.     Comment:  There was a comment in another session that lots of mail
  305. applications are broken becaue they don't allow selection of helper
  306. applicationss per MIME type.
  307.  
  308.     Chris Newman:  How many people had read media types dataset draft?
  309.     (a few)
  310.  
  311.     Chris Newman: Media types carry security warning.
  312.  
  313.     Comment: Risk is in interpretive contents.
  314.  
  315.     Comment: It's a disservice to not have it, but having it might
  316. cause problem getting it through security area.
  317.  
  318.     Comment: It won't introduce new security risks.
  319.  
  320.     Comment: It could carry risks to new systems.  Batch files, for
  321. example.
  322.  
  323.     Comment: Applications start with hard-coded list; users can add to
  324. but not delete from it.
  325.  
  326.     Comment: By default in Internet Explorer everything is considered
  327. dangerous.  Users can say to stop warning for all types except core list.
  328.  
  329.     Comment: Could have admin supply core list to prevent users from
  330. not being warned about type "foo".
  331.  
  332.     Comment: Security risks are highly application specific; plain-text
  333. is a potential risk [on some displays] but don't want to see warning for
  334. every access of plain-text content.
  335.  
  336.     Chris Newman: Should we    flush this attribute?  Or discuss on list?
  337.  
  338.     Call for consensus:
  339.     A few want to discuss, no one wants to punt.
  340.  
  341.  
  342.     Language specific comparitors.
  343.  
  344.  
  345.     [John Myers summarized issues]
  346.     -language
  347.     -unicode decomposition
  348.     -strength (how exact is search)
  349.         + in general 4 cases: alphanumeric / diacriticals / case /
  350. specials
  351.  
  352.     Comment: Is 'special' comma or Cryllic without diacritical?
  353.  
  354.         + ISO 1461/1462 specifies up to 7 levels of distinction
  355.  
  356.         + Java has 4 fixed levels: primary/secondary/tertiary/identical
  357.  
  358.     -version/vendor
  359.         functions won't be same between implementation.
  360.  
  361.     -other qualities
  362.         +dictionary/phonebook/etc.
  363.  
  364.  
  365.     Strawman:
  366.  
  367.         language -tag; properties
  368.  
  369.     e.g.,
  370.  
  371.         fr; secondarystrength
  372.         en; phonetic; primarystrength
  373.  
  374.     ACAP base comparators:
  375.         i; octet
  376.         i; numeric
  377.         i; ascii-casefold
  378.     ("i" stands for "international", cross-language)
  379.  
  380.     Comment: What is "i; numeric"?
  381.  
  382.     Comment: Same as ASCII numeric?
  383.  
  384.     Comment: Fractions.
  385.  
  386.     Comment: UTF-8 numeric.
  387.  
  388.     John Myers:: Specified in ISO 10646.
  389.  
  390.     Chris Newman: Base spec requires support for UTF-8 but not complex
  391. mapping.
  392.  
  393.     Comment: Since we're talking about atoi what about UTF-8?
  394.  
  395.     Comment: Kanjii numerals.
  396.  
  397.     Comment: How are these collated?
  398.  
  399.     Answer: code-point order.
  400.  
  401.     Comment: Entire procol is UTF-8 but these are octets.
  402.  
  403.     [lots of comments on ordering vs octets which are outside the set]
  404.  
  405.     Someone (Chris?): We changed the name of the "i; numeric"
  406. comparitor to "i; ascii-numeric".
  407.  
  408.     Comment: New comparitors added as extension docs?
  409.  
  410.     Answer: Registry thing, like MIME.
  411.  
  412.     Comment: Problem with semicolon in syntax?
  413.  
  414.     Comment: Could use colon or slash.
  415.  
  416.     Comment: Proposal in specific order?
  417.  
  418.     John Myers: Specific order is best.  Truncated case.
  419.  
  420.     Chris Newman: Don't want same comparitor with two names.  Sort
  421. proposal by names.
  422.  
  423.     Comment: How to sort?
  424.  
  425.     Chris Newman: Use US ASCII sorting.
  426.  
  427.     Comment: Unhappy with having server tell client which comparitors
  428. are valid in LANG response.  Can't have client which detects all
  429. comparitors available.
  430.  
  431.     Chris Newman: There could be 500 comparitors.  Don't want to
  432. announce them all in greeting.
  433.  
  434.     Comment: use a dataset?
  435.  
  436.     Chris Newman: The problem with that is it's a solution specific to
  437. ACAP; need same services in IMAP, etc.
  438.  
  439.  
  440.     Comment: Why do you need all comparitors?
  441.  
  442.     Comment: Bilingual user, doesn't want to move into one language only.
  443.  
  444.     Chris Newman: LANG has list of languages in order of preference;
  445. response has all comparitors valid in all languages.
  446.  
  447.     Comment: is there a way to switch back to the default?
  448.  
  449.     [discusion of difference between default languge = English and
  450. switching to English]
  451.  
  452.     Comment: Some kind of tag to specify technical English or "default".
  453.  
  454.     Comment: This seems very complicated.  Why need more than store and
  455. search?
  456.  
  457.     Chris Newman: Error texts and comparitor discovery.
  458.  
  459.     John Myers: English vs "Internationalized English"
  460.  
  461.     Comment: Why so complicated?
  462.  
  463.     Comment: The two Englishes MAY be different.
  464.  
  465.     John Myers: Can't get compators without selecting language.
  466.  
  467.     Chris Newman: Default language is 'en'?  En=any English dialect.
  468.  
  469.     Comment: Don't need to discover comparitor for English?
  470.  
  471.     Comment: Yes, select En.
  472.  
  473.  
  474.  
  475. WG Milestones & Disposition
  476.  
  477.     Close down Working Group after Draft or put out dataset specs,
  478. extensions, etc.?
  479.  
  480.     Comment: Keep group going until ACAP is at Draft or Proposed?
  481.  
  482.     Comment: Mailing list stays around after WG closes.
  483.  
  484.     Comment: Do dataset classes in charter.
  485.  
  486.     Comment: Add additional dataset classes to charter.
  487.  
  488.     Call for consensus on having group do all discussed dataset classes.
  489.     No objections.
  490.  
  491.     Do media types extension?
  492.  
  493.     Comment: Ask on list; lots of discussion.
  494.  
  495.     Do type labelling extension?
  496.  
  497.     Comment: Do Rob's only.
  498.  
  499.     Naming convention and registry for language-sensitive comparitor?
  500.  
  501.     Comment: Only useful if other groups need it?
  502.  
  503.     John Myers: Who has the knowledge to do it?
  504.  
  505.     Comment: Spin off a new group to do it.  Get more experts, raise
  506. profile.
  507.  
  508.     Comment: Dood idea.  Get people from LDAP etc.
  509.  
  510.     Comment: BOF in December on that?
  511.     John Myers will chair.
  512.  
  513.     Chris Newman:  Meet in December to discuss work on dataset classes etc?
  514.  
  515.     Comment: Yes.
  516.  
  517.     Comment: Proposal to just do dataset classes for which drafts are
  518. available.
  519.     No objections.
  520.  
  521.     Want options dataset to go though at same time as spec.
  522.  
  523.     Chris Newman to send in charter update.  New ACAP spec with short
  524. last-call on list.
  525.  
  526.     Meeting adjourned.
  527.  
  528.  
  529.  
  530.  
  531.  
  532.  
  533.  
  534.  
  535.  
  536. From - Wed Sep 10 16:04:45 1997
  537. Received: from ietf.org by ietf.org id aa10429; 9 Sep 97 12:02 EDT
  538. Received: from THOR.INNOSOFT.COM by ietf.org id aa10425; 9 Sep 97 12:02 EDT
  539. Received: from eleanor.innosoft.com ("port 45763"@ELEANOR.INNOSOFT.COM)
  540.  by INNOSOFT.COM (PMDF V5.1-10 #8694)
  541.  with SMTP id <01INFLTO2XF294FJPP@INNOSOFT.COM> for minutes@ietf.org; Tue,
  542.  9 Sep 1997 09:01:17 PDT
  543. Date: Tue, 09 Sep 1997 09:03:15 -0700 (PDT)
  544. Sender:minutes-request@ietf.org
  545. From: Chris Newman <Chris.Newman@innosoft.com>
  546. Subject: ACAP WG Minutes (Munich IETF) (fwd)
  547. To: IETF ACAP Mailing List <ietf-acap@andrew.cmu.edu>, minutes@ietf.org
  548. Message-id: <Pine.SOL.3.95.970909085831.15232A-100000@eleanor.innosoft.com>
  549. MIME-version: 1.0
  550. Content-type: TEXT/PLAIN; charset=US-ASCII
  551. Originator-Info: login-id=chris; server=thor.innosoft.com
  552. Status:   
  553. X-Mozilla-Status: 8001
  554.  
  555. ACAP Working Group Minutes, Munich IETF August 1997:
  556.  
  557.  
  558. Recorded By: Randall Gellens
  559.  
  560. Chris presented agenda; called for comments.
  561. No comments on agenda.
  562.  
  563. Comment: post "why ACAP" doc to LDAP [?] list
  564.  
  565. Security issues:
  566.     Adopt SASL anonymous mechanism?
  567.     Cosensus: Yes (a few people liked it, no one objected).
  568.  
  569.     Issue: not permitted to have plaintext login.
  570.  
  571.     Not possible to use ACAP without (a) upgrading one's security
  572. infrastructure or (b) violating IESG rules.
  573.  
  574.     Options:
  575.  
  576.     1)  Require CRAM-MD5
  577.     [Discussion of pros and cons.]
  578.  
  579.     2)  Write RFC for & Require CRAM-SHA1
  580.     [Discussion of pros and cons.]
  581.  
  582.     3)  Adopt & Require SCRAM (salted verifier + encrypted hash of pw)
  583.     [Discussion of pros and cons.]
  584.  
  585.     4)  Wait for SSH or TLS and require its use (with plaintext
  586. passwords encrypted underneath)
  587.     [Discussion of pros and cons.]
  588.  
  589.     Comments: AARG list had other mechanism suggestions.
  590.     Answer: We want to stick with simple mechanisms to avoid delay.
  591.  
  592.     Call for consensus on (4):
  593.     no one liked it.
  594.  
  595.     Comment: difficulty of getting implementors to adopt mechanism.
  596.  
  597.     Comment: we are discussing mandatory mechanisms, SASL allows more
  598. secure mechanisms as well.
  599.  
  600.     Comment: go with MUST for CRAM-xxx, SHOULD do something stronger.
  601.  
  602.     Comment: go with CRAM-MD5 because it is easiest to get through
  603. standards process.
  604.  
  605.     Comment: unable to get CRAM-xxx except CRAM-MD5 through security area
  606.  
  607.     Comment: SCRAM not had review...eliminate?
  608.  
  609.     [discussion of Authentication exchange & verifier both on wire; risks]
  610.  
  611.     [discussion of risks of stealing host's password file]
  612.  
  613.     Comment: CRAM-MD5 & -SHA1 both riskier than /etc/pw since stealing
  614. verifier gives access to all accounts
  615.  
  616.     Comment: took 6 months to get CRAM-MD5 through standard process;
  617. new protocols take time, especially security protocols
  618.  
  619.     Comment: other problems with CRAM.  No authentication id.  Mutual
  620. authentication problem.
  621.  
  622.     Comment: go with CRAM-MD5 as baseline.
  623.  
  624.     Comment: SCRAM-SHA1 needs review by crypto people.  Then move
  625. forward or drop.
  626.  
  627.     Call for consensus: use CRAM-MD5 as baseline; also pursue SCRAM-SHA1.
  628.  
  629.     Comment: Also pursue other AARG proposals.  If CRAM-MD5 is
  630. baseline, other mechanisms are optional and can be pursued in their own time
  631.  
  632.     Comment: CRAM is like APOP: why not just use APOP?
  633.  
  634.     Answer: APOP worse than CRAM.  More security risks.  Must store
  635. password in clear on server.
  636.  
  637.     Answer: CRAM-MD5 is in all ways better than APOP.
  638.  
  639.     Back to consensus.
  640.     No objections.  CRAM-MD5 to be used as baseline; also pursue
  641. SCRAM-SHA1.
  642.  
  643.     Comment: CRAM-MD5 is the only option which is already an RFC.
  644.  
  645.     Harald: This is the right choice for the ACAP group.  It is not for
  646. the ACAP group to do crypto protocols.
  647.  
  648.     Chris Newman: ACAP has dependencies on SASL-PLAIN for transition
  649. mechanism.  Since plain may not be approved, we need to remove dependencies.
  650.  
  651.     Should we remove the transition error codes?  That means all users
  652. must change their password to use ACAP.  Should we try and get SASL-PLAIN
  653. on the standards-track?  That would delay ACAP.
  654.  
  655.     John Myers proposed that we leave the transition error codes in but
  656. remove the dependencies on SASL-PLAIN.  That way there is a means to do
  657. transition but the mechanism is not specified.
  658.     Call for consensus on John's proposal.
  659.     No objections: ACAP to leave transition error codes in, but delete
  660. dependencies on SASL-PLAIN.
  661.  
  662.     Comment: How would a user get the transition error codes?  No login
  663. mechanism specified in ACAP which uses them.
  664.  
  665.     Answer: Through an unspecified mechanism.  Maybe CRAM-MD5.  The
  666. error codes mean "The server does not have auth [something] for you".
  667.  
  668.     Comment: Don't we need a consistent error msg which tells users to
  669. go to their admin?
  670.  
  671.     Answer: This is a UI issue.
  672.  
  673.     Comment: Leave transition out of spec, do it in its own spec which
  674. updates ACAP?
  675.  
  676.     Comment: Controversial proposal to transition away from plaintext?
  677.  
  678.     Answer: It's not controversial.
  679.  
  680.     Comment: The mechanism is conttroversial.
  681.  
  682.     Answer: We are only leaving in the error codes, not the mechanism.
  683.  
  684.     Harald: I think an informational RFC which specifies a plaintext
  685. mechanism and how to use it in a transition strategy, and how to use it
  686. with IMAP login would not be any more offensive to the IESG than a document
  687. on how to do 8-bit to 7-bit downgrades in email.
  688.  
  689.     Chris Newman: I intend to do that.
  690.  
  691.  
  692. Authid/groupid datasets:
  693.  
  694.     Authid:
  695.  
  696.     Authid draft posted.  Now in I-D directories.  How many have read it?
  697.     (Three people raised their hands).
  698.  
  699.     Steve Hole: [summarized draft]
  700.         authentication-id, authorization-id, user-id,
  701.         authent-id -> user-id    group={user-id, group-id}
  702.  
  703.     Comment: Any way to associate an authentication mechanism with a
  704. specific auth. id?
  705.  
  706.     Answer: Yes.  Multi-value attribute which holds list of auth-ids
  707. per user-id; e.g., different Kerberos principals.
  708.  
  709.     Steve Hole: Not only would ACAP use this dataset, but other servers
  710. (e.g., IMAP) could use it.
  711.  
  712.     Steve Hole: Organizations like to keep their auth-ids secret.
  713. "Hackers handbook".  Also auth-ids are often meaningless (e.g., numeric).
  714.  
  715.     Comment: Nothing in draft that says at any level that ID is unique.
  716.  
  717.     Answer: Was supposed to be.
  718.  
  719.     Answer: Must be because it is stored in the "entry" attribute,
  720. which must be unique.
  721.  
  722.     Answer: Can't have auth-id bind to more to more than one user-id?
  723. Maybe we want to allow it.
  724.  
  725.     Steve Hole: It is possible for an ACAP server to provide this
  726. dataset but not obey its semantics.
  727.  
  728.     Comment: Why are there different attributess for user-ids &
  729. group-ids in group lists?  Is it to allow users & groups with the same name?
  730.  
  731.     Answer: It's not intended to allow that.  Need to clarify.
  732.  
  733.     Comment: Is there a group member-of?  A way to find what groups a
  734. group is in?
  735.     Answer:  Not sure how useful it is, but it should be there for
  736. completeness.
  737.  
  738.     Comment: If a group is removed, it's needed to know which groups to
  739. clean up.
  740.  
  741.     Comment: User name field has no semantics or constraints on it.
  742. This is a problem with interaction with other directory services.  Should
  743. require minimum amount of structure?  Consider one database with ACAP and
  744. LDAP access protocols.  If name is freely structured, it is very hard to
  745. impose structure later or use it from more than one place.
  746.  
  747.     Chris Newman: Purpose of field is not to be a directory service;
  748. it's only to make a user-friendly UI.  Make the field the LDAP common name
  749. if there is a directory service back-end.
  750.  
  751.     Comment: Say that [in the spec].
  752.  
  753.     Comment: Might have multiple access protocols for same data; there
  754. is a move to single storage.
  755.  
  756.     Steve Hole: It's left to the discretion of the site admin to put
  757. whatever they want in there.
  758.  
  759.     Comment: Sites are now trying to take old pw files and put into
  760. directory.  Problem is name fields were overloaded, must be moved manually.
  761.  
  762.     Steve Hole: There is a potential for other attributes.  For
  763. example, expired, disabled, etc.  There are potentially a lot.  Didn't
  764. bother to specify them, but there may be a sub-set which is useful to
  765. standardize.  Discuss on list?
  766.  
  767.  
  768.     Options dataset draft:
  769.  
  770.     [Steve gave summary]
  771.     This was complex, but became very simple because of multi-valued
  772. attributes.  The idea is it's a scribble-space for options.  Certain kinds
  773. of configuration info should be shared between applications/users.  Those
  774. become datasets.  The draft defines rules for how such datasets are to be
  775. specified.
  776.  
  777.     Also option to conventionalize single options which are useful to
  778. multiple applications, e.g., SMTP host name for mailers.  Should be
  779. standardized in common, but doesn't need heavy-weight registration
  780. procedure.  Need light-weight registry procedure.
  781.  
  782.     Comment: What form are datasets defined in?  Are datasets spec in
  783. ASN.1?
  784.  
  785.     Answer: ABNF in standards-track RFC.
  786.  
  787.     Comment: LDAP et al has a procedure.
  788.  
  789.     Answer: That's for different problems.
  790.  
  791.     Comment: Need type specified.
  792.  
  793.     Answer: Other drafts are addressing that.  It's not really part of
  794. ACAP.  In ACAP you know what you are going after.  Possible use for
  795. RegEdit-type apps (generic dataset editor) but not generally very useful.
  796.  
  797.     Comment: It's not as different as you imagine from other efforts.
  798. Consider Service Location, very similar considerations.  Calsched, other
  799. groups are doing similar schema work.  Need to pay attention to other
  800. groups.
  801.  
  802.     Comment: Service Location could be font-end for LDAP directory.
  803.  
  804.     Comment: ACAP could be same thing.
  805.  
  806.     Comment: Draft for how to transfer schema stuff from Server
  807. Location to others.
  808.  
  809.  
  810.     Personal Addressbook Specification:
  811.  
  812.     [Summary of draft]
  813.     The draft is numbered -00 but is really later.  The I-D people
  814. never published the earlier version.
  815.  
  816.     Users own the information in an ACAP addressbook.  It can contain
  817. the user's comments on how people are jerks or whatever.  Unlike a
  818. directory, this is not generally for public consumption.  The information
  819. is similar to white pages.  This is based on white pages, but adds
  820. attributes appropriate for personal address books (e.g., comments).
  821.  
  822.     (1)  Issue with vCard.  vCard is going to be a big deal. There is a
  823. problem mapping vCard to LDAP.  It will be worse with ACAP since there is
  824. no property description.
  825.  
  826.     E.g., phone/address.  Personal, cellular, etc.  vCard says "this is
  827. phone number for purpose x" instead of having different named attributes.
  828. How to map?
  829.  
  830.     One idea: add parallel attribute for each phone number to list what
  831. it is used for.
  832.  
  833.     Two attributes with relation between names.
  834.  
  835.     Or metadata for uses of attribute.
  836.  
  837.  
  838.     (2) vCard allows subsitution of URL for value.  We could have an
  839. attribute name convention for doing this.
  840.  
  841.     Comment: Define attribute which is URL, one type of URL is data URL.
  842.  
  843.     Comment: Data URL is meaningless without typing.
  844.  
  845.     Comment: Meaning goes with attribute.  Photo attribute has data
  846. URL; you know what it is.
  847.  
  848.     (3)  Lots of porly-specified attributes like 'role' and 'title'.
  849. Doesn't want to add to dataset class if specification will change.
  850.  
  851.     Comment: Fits with ACAP.
  852.  
  853.  
  854.     Media types dataset:
  855.  
  856.     This is a perfect fit for ACAP.  User-customizable site defaults.
  857.  
  858.     Comment:  There was a comment in another session that lots of mail
  859. applications are broken becaue they don't allow selection of helper
  860. applicationss per MIME type.
  861.  
  862.     Chris Newman:  How many people had read media types dataset draft?
  863.     (a few)
  864.  
  865.     Chris Newman: Media types carry security warning.
  866.  
  867.     Comment: Risk is in interpretive contents.
  868.  
  869.     Comment: It's a disservice to not have it, but having it might
  870. cause problem getting it through security area.
  871.  
  872.     Comment: It won't introduce new security risks.
  873.  
  874.     Comment: It could carry risks to new systems.  Batch files, for
  875. example.
  876.  
  877.     Comment: Applications start with hard-coded list; users can add to
  878. but not delete from it.
  879.  
  880.     Comment: By default in Internet Explorer everything is considered
  881. dangerous.  Users can say to stop warning for all types except core list.
  882.  
  883.     Comment: Could have admin supply core list to prevent users from
  884. not being warned about type "foo".
  885.  
  886.     Comment: Security risks are highly application specific; plain-text
  887. is a potential risk [on some displays] but don't want to see warning for
  888. every access of plain-text content.
  889.  
  890.     Chris Newman: Should we    flush this attribute?  Or discuss on list?
  891.  
  892.     Call for consensus:
  893.     A few want to discuss, no one wants to punt.
  894.  
  895.  
  896.     Language specific comparitors.
  897.  
  898.  
  899.     [John Myers summarized issues]
  900.     -language
  901.     -unicode decomposition
  902.     -strength (how exact is search)
  903.         + in general 4 cases: alphanumeric / diacriticals / case /
  904. specials
  905.  
  906.     Comment: Is 'special' comma or Cryllic without diacritical?
  907.  
  908.         + ISO 1461/1462 specifies up to 7 levels of distinction
  909.  
  910.         + Java has 4 fixed levels: primary/secondary/tertiary/identical
  911.  
  912.     -version/vendor
  913.         functions won't be same between implementation.
  914.  
  915.     -other qualities
  916.         +dictionary/phonebook/etc.
  917.  
  918.  
  919.     Strawman:
  920.  
  921.         language -tag; properties
  922.  
  923.     e.g.,
  924.  
  925.         fr; secondarystrength
  926.         en; phonetic; primarystrength
  927.  
  928.     ACAP base comparators:
  929.         i; octet
  930.         i; numeric
  931.         i; ascii-casefold
  932.     ("i" stands for "international", cross-language)
  933.  
  934.     Comment: What is "i; numeric"?
  935.  
  936.     Comment: Same as ASCII numeric?
  937.  
  938.     Comment: Fractions.
  939.  
  940.     Comment: UTF-8 numeric.
  941.  
  942.     John Myers:: Specified in ISO 10646.
  943.  
  944.     Chris Newman: Base spec requires support for UTF-8 but not complex
  945. mapping.
  946.  
  947.     Comment: Since we're talking about atoi what about UTF-8?
  948.  
  949.     Comment: Kanjii numerals.
  950.  
  951.     Comment: How are these collated?
  952.  
  953.     Answer: code-point order.
  954.  
  955.     Comment: Entire procol is UTF-8 but these are octets.
  956.  
  957.     [lots of comments on ordering vs octets which are outside the set]
  958.  
  959.     Someone (Chris?): We changed the name of the "i; numeric"
  960. comparitor to "i; ascii-numeric".
  961.  
  962.     Comment: New comparitors added as extension docs?
  963.  
  964.     Answer: Registry thing, like MIME.
  965.  
  966.     Comment: Problem with semicolon in syntax?
  967.  
  968.     Comment: Could use colon or slash.
  969.  
  970.     Comment: Proposal in specific order?
  971.  
  972.     John Myers: Specific order is best.  Truncated case.
  973.  
  974.     Chris Newman: Don't want same comparitor with two names.  Sort
  975. proposal by names.
  976.  
  977.     Comment: How to sort?
  978.  
  979.     Chris Newman: Use US ASCII sorting.
  980.  
  981.     Comment: Unhappy with having server tell client which comparitors
  982. are valid in LANG response.  Can't have client which detects all
  983. comparitors available.
  984.  
  985.     Chris Newman: There could be 500 comparitors.  Don't want to
  986. announce them all in greeting.
  987.  
  988.     Comment: use a dataset?
  989.  
  990.     Chris Newman: The problem with that is it's a solution specific to
  991. ACAP; need same services in IMAP, etc.
  992.  
  993.  
  994.     Comment: Why do you need all comparitors?
  995.  
  996.     Comment: Bilingual user, doesn't want to move into one language only.
  997.  
  998.     Chris Newman: LANG has list of languages in order of preference;
  999. response has all comparitors valid in all languages.
  1000.  
  1001.     Comment: is there a way to switch back to the default?
  1002.  
  1003.     [discusion of difference between default languge = English and
  1004. switching to English]
  1005.  
  1006.     Comment: Some kind of tag to specify technical English or "default".
  1007.  
  1008.     Comment: This seems very complicated.  Why need more than store and
  1009. search?
  1010.  
  1011.     Chris Newman: Error texts and comparitor discovery.
  1012.  
  1013.     John Myers: English vs "Internationalized English"
  1014.  
  1015.     Comment: Why so complicated?
  1016.  
  1017.     Comment: The two Englishes MAY be different.
  1018.  
  1019.     John Myers: Can't get compators without selecting language.
  1020.  
  1021.     Chris Newman: Default language is 'en'?  En=any English dialect.
  1022.  
  1023.     Comment: Don't need to discover comparitor for English?
  1024.  
  1025.     Comment: Yes, select En.
  1026.  
  1027.  
  1028.  
  1029. WG Milestones & Disposition
  1030.  
  1031.     Close down Working Group after Draft or put out dataset specs,
  1032. extensions, etc.?
  1033.  
  1034.     Comment: Keep group going until ACAP is at Draft or Proposed?
  1035.  
  1036.     Comment: Mailing list stays around after WG closes.
  1037.  
  1038.     Comment: Do dataset classes in charter.
  1039.  
  1040.     Comment: Add additional dataset classes to charter.
  1041.  
  1042.     Call for consensus on having group do all discussed dataset classes.
  1043.     No objections.
  1044.  
  1045.     Do media types extension?
  1046.  
  1047.     Comment: Ask on list; lots of discussion.
  1048.  
  1049.     Do type labelling extension?
  1050.  
  1051.     Comment: Do Rob's only.
  1052.  
  1053.     Naming convention and registry for language-sensitive comparitor?
  1054.  
  1055.     Comment: Only useful if other groups need it?
  1056.  
  1057.     John Myers: Who has the knowledge to do it?
  1058.  
  1059.     Comment: Spin off a new group to do it.  Get more experts, raise
  1060. profile.
  1061.  
  1062.     Comment: Dood idea.  Get people from LDAP etc.
  1063.  
  1064.     Comment: BOF in December on that?
  1065.     John Myers will chair.
  1066.  
  1067.     Chris Newman:  Meet in December to discuss work on dataset classes etc?
  1068.  
  1069.     Comment: Yes.
  1070.  
  1071.     Comment: Proposal to just do dataset classes for which drafts are
  1072. available.
  1073.     No objections.
  1074.  
  1075.     Want options dataset to go though at same time as spec.
  1076.  
  1077.     Chris Newman to send in charter update.  New ACAP spec with short
  1078. last-call on list.
  1079.  
  1080.     Meeting adjourned.
  1081.  
  1082.  
  1083.  
  1084.  
  1085.  
  1086.  
  1087.  
  1088.  
  1089.  
  1090.