idnits 2.17.1 draft-ietf-acap-dict-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([ACAP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 1998) is 9533 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'REF' is mentioned on line 55, but not defined Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Daboo 3 Internet Draft: ACAP Personal Dictionary Cyrusoft International, Inc. 4 Document: draft-ietf-acap-dict-00.txt March 1998 5 Expires: September, 1998 7 ACAP personal dictionary dataset class 9 Status of this memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other documents 18 at any time. It is inappropriate to use Internet- Drafts as 19 reference material or to cite them other than as "work in progress." 21 To view the entire list of current Internet-Drafts, please check the 22 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 24 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 25 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 27 Discussion and suggestions for improvement are requested. This 28 document will expire six months after publication. Distribution of 29 this draft is unlimited. 31 Abstract 33 The Application Configuration Access Protocol [ACAP] is designed to 34 support remote storage and access of common application option, 35 configuration and preference information. Its main benefits are in 36 providing a way for users to gain access to personal information 37 from any computer at a location supporting an internet connection, 38 by keeping this information stored centrally on a server. 39 Additionally, it allows 'kiosk' style use of computers so that users 40 do not need to store data locally on a shared or public workstation 41 or network computer. This specification defines a standard dataset 42 class for personal dictionaries that would allow users to keep one 43 or more 'user dictionaries' stored on an ACAP server for access by 44 any ACAP-aware application that requires such information, for 45 example any application that uses a spell checker. 47 0. Outstanding 49 ABNF for entries. 50 Examples. 52 1. Introduction 54 Various types of dataset have been designed to operate with 55 ACAP [ACAP]. Among these are options [REF] and addressbooks [REF], 56 allowing storage of personal options or preferences, and personal 57 addressbooks. This specification defines the 'dictionary' dataset 58 class to be used for storing personal dictionary information, for 59 use, for example, with spelling checkers. 61 Currently many different desktop applications support different 62 spellchecker modules, most requiring their own main and user-defined 63 dictionaries. The dictionary dataset in ACAP is designed to address 64 the problem of having to maintain separate user dictionaries for a 65 variety of applications on a single computer, as well as on 66 different computers. The aim of the dictionary dataset in ACAP is to 67 ensure that a user's personal dictionary is always synchronized 68 across applications and computers. ACAP-aware spellcheckers can make 69 use of this capability by storing and accessing their user-defined 70 dictionaries through ACAP. 72 This dataset is not meant to be used for the main dictionary (which 73 is usually large) that is normally provided with a spell checker, 74 but merely for the few hundred or thousand words a user may add as 75 they use the spell checker. 77 Additionally, this draft does not describe the spellchecking process 78 itself. That will always be left to the local client implementation. 80 One aim of this draft is to go further than conventional 81 spellcheckers by allowing additional information about words to be 82 stored. This will take the form of a classic 'paper-based' 83 dictionary which includes definitions of words, for example. This 84 additional information is optional, but may be useful for grammar 85 checkers or other programs that require more details about a word. 87 2. Conventions Used in this Document 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in "Key words for use in 92 RFCs to Indicate Requirement Levels" [KEYWORDS]. 94 3. ACAP Personal Dictionaries 96 3.1. ACAP Personal Dictionary Dataset Prefix 98 Datasets whose names begin with "/dictionary" are assumed to contain 99 dictionary entries as defined in this specification. 101 3.2. ACAP Dictionary Hierarchy 103 Hierarchical dictionaries SHOULD be represented using ACAP 104 hierarchy. Any entry in a dictionary can also be a hierarchy node 105 by setting the "subdataset" attribute. 107 4. Recommended ACAP Attributes 109 The following attributes MAY be used in an ACAP dictionary entry. A 110 dictionary entry MUST have an "entry" attribute and a "lang" 111 attribute. 113 Beyond this rule, clients MAY choose any subset of the basic 114 attributes described below, as well as using registered private 115 attributes. Clients are encouraged to provide a way to view all 116 textual attributes in an entry regardless of whether the client 117 knows the special semantics associated with them. 119 The ABNF defines the content of the attribute values prior to their 120 encoding as an ACAP string. Clients MUST conform to the syntax when 121 generating these attributes, but MUST NOT assume that the attribute 122 values will conform to this syntax on access. Servers MUST NOT 123 enforce the syntax. Unless otherwise stated, all attributes in this 124 specification are single-valued and textual. 126 4.1. Basic Attributes 128 These attributes are defined in ACAP [ACAP] and have meaning in all 129 dataset classes. This section describes how they are used in an 130 dictionary dataset. 132 entry 133 The word, or title of a subdictionary. This attribute MUST be 134 present in the dataset entry. 136 lang 137 IANA registered language tag. The language tag is used to 138 identify which language this word is used in. It is used to 139 allow multi-lingual dictionaries. This attribute MUST be 140 present in the dataset entry. 142 definition 143 Definition of word (may be multivalued). This provides an 144 entry for the classic 'paper-based' dictionary definition of 145 the word. 147 grammar 148 Grammatical context (noun, verb, adjective etc - may be 149 multivalued). This attribute should be kept synchronized 150 with the 'definition' attribute so that there is exactly one 151 value for each corresponding value in the 'definition' 152 attribute. 154 pronunciation.human 155 Human pronunciation using some defined phonetic description. 156 This must be related to the language tag in use. 158 pronunciation.machine 159 Machine pronunciation using some defined phonetic 160 description. This must be related to the language tag in 161 use. This attribute provides a way for computer based 162 "text-to-speech" processing engines to determine the correct 163 pronunciation of a word. 165 synonyms 166 ACAP urls to other words that are synonyms of this word (may 167 be multivalued), or words that are synonyms of this word and 168 don't have an entry in this dataset (e.g. they are in the 169 main dictionary and reside on the client machine). 171 homonyms 172 ACAP urls to other words that are homonyms of this word (may 173 be multivalued), or words that are synonyms of this word and 174 don't have an entry in this dataset (e.g. they are in the 175 main dictionary and reside on the client machine). 177 capitalize 178 value: true/false - indicates whether the word should always 179 appear with the first letter capitalized. 181 real name 182 value: true/false - indicates that the word represents a real 183 name. 185 subdataset 186 Indicates a sub-dictionary exists. If set, the 'entry' 187 attribute corresponds to the name of the sub-dictionary. 189 plural 190 The plural form of the word. 192 expand 193 Expansion of the entry if it is an abbreviation or acronym. 195 5. References 197 [ACAP] Newman, C., Myers, J. G., "Application Configuration Access 198 Protocol", RFC2244. 200 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 201 Requirement Levels", BCP 14, RFC 2119, March 1997. 203 6. Author's Addresses 205 Cyrus Daboo 206 Cyrusoft International, Inc. 207 Suite 780 208 The Design Center 209 5001 Baum Blvd. 210 Pittsburgh, PA 15213 211 USA. 213 215 Expires: September, 1998.