| rev |
line source |
|
yuuji@0
|
1
|
|
yuuji@0
|
2
|
|
yuuji@0
|
3
|
|
yuuji@0
|
4
|
|
yuuji@0
|
5
|
|
yuuji@0
|
6
|
|
yuuji@0
|
7 Network Working Group R. Siemborski
|
|
yuuji@0
|
8 Request for Comments: 4959 Google, Inc.
|
|
yuuji@0
|
9 Category: Standards Track A. Gulbrandsen
|
|
yuuji@0
|
10 Oryx Mail Systems GmbH
|
|
yuuji@0
|
11 September 2007
|
|
yuuji@0
|
12
|
|
yuuji@0
|
13
|
|
yuuji@0
|
14 IMAP Extension for Simple Authentication and Security Layer (SASL)
|
|
yuuji@0
|
15 Initial Client Response
|
|
yuuji@0
|
16
|
|
yuuji@0
|
17 Status of This Memo
|
|
yuuji@0
|
18
|
|
yuuji@0
|
19 This document specifies an Internet standards track protocol for the
|
|
yuuji@0
|
20 Internet community, and requests discussion and suggestions for
|
|
yuuji@0
|
21 improvements. Please refer to the current edition of the "Internet
|
|
yuuji@0
|
22 Official Protocol Standards" (STD 1) for the standardization state
|
|
yuuji@0
|
23 and status of this protocol. Distribution of this memo is unlimited.
|
|
yuuji@0
|
24
|
|
yuuji@0
|
25 Abstract
|
|
yuuji@0
|
26
|
|
yuuji@0
|
27 To date, the Internet Message Access Protocol (IMAP) has used a
|
|
yuuji@0
|
28 Simple Authentication and Security Layer (SASL) profile which always
|
|
yuuji@0
|
29 required at least one complete round trip for an authentication, as
|
|
yuuji@0
|
30 it did not support an initial client response argument. This
|
|
yuuji@0
|
31 additional round trip at the beginning of the session is undesirable,
|
|
yuuji@0
|
32 especially when round-trip costs are high.
|
|
yuuji@0
|
33
|
|
yuuji@0
|
34 This document defines an extension to IMAP which allows clients and
|
|
yuuji@0
|
35 servers to avoid this round trip by allowing an initial client
|
|
yuuji@0
|
36 response argument to the IMAP AUTHENTICATE command.
|
|
yuuji@0
|
37
|
|
yuuji@0
|
38
|
|
yuuji@0
|
39
|
|
yuuji@0
|
40
|
|
yuuji@0
|
41
|
|
yuuji@0
|
42
|
|
yuuji@0
|
43
|
|
yuuji@0
|
44
|
|
yuuji@0
|
45
|
|
yuuji@0
|
46
|
|
yuuji@0
|
47
|
|
yuuji@0
|
48
|
|
yuuji@0
|
49
|
|
yuuji@0
|
50
|
|
yuuji@0
|
51
|
|
yuuji@0
|
52
|
|
yuuji@0
|
53
|
|
yuuji@0
|
54
|
|
yuuji@0
|
55
|
|
yuuji@0
|
56
|
|
yuuji@0
|
57
|
|
yuuji@0
|
58 Siemborski & Gulbrandsen Standards Track [Page 1]
|
|
yuuji@0
|
59
|
|
yuuji@0
|
60 RFC 4959 IMAP Ext for SASL Initial Client Response September 2007
|
|
yuuji@0
|
61
|
|
yuuji@0
|
62
|
|
yuuji@0
|
63 1. Introduction
|
|
yuuji@0
|
64
|
|
yuuji@0
|
65 The SASL initial client response extension is present in any IMAP
|
|
yuuji@0
|
66 [RFC3501] server implementation which returns "SASL-IR" as one of the
|
|
yuuji@0
|
67 supported capabilities in its CAPABILITY response.
|
|
yuuji@0
|
68
|
|
yuuji@0
|
69 Servers which support this extension will accept an optional initial
|
|
yuuji@0
|
70 client response with the AUTHENTICATE command for any SASL [RFC4422]
|
|
yuuji@0
|
71 mechanisms which support it.
|
|
yuuji@0
|
72
|
|
yuuji@0
|
73 2. Conventions Used in This Document
|
|
yuuji@0
|
74
|
|
yuuji@0
|
75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|
yuuji@0
|
76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
|
yuuji@0
|
77 document are to be interpreted as described in [RFC2119].
|
|
yuuji@0
|
78
|
|
yuuji@0
|
79 In examples, "C:" and "S:" indicate lines sent by the client and
|
|
yuuji@0
|
80 server, respectively.
|
|
yuuji@0
|
81
|
|
yuuji@0
|
82 Formal syntax is defined by [RFC4234] as extended by [RFC3501].
|
|
yuuji@0
|
83
|
|
yuuji@0
|
84 3. IMAP Changes to the IMAP AUTHENTICATE Command
|
|
yuuji@0
|
85
|
|
yuuji@0
|
86 This extension adds an optional second argument to the AUTHENTICATE
|
|
yuuji@0
|
87 command that is defined in Section 6.2.2 of [RFC3501]. If this
|
|
yuuji@0
|
88 second argument is present, it represents the contents of the
|
|
yuuji@0
|
89 "initial client response" defined in Section 5.1 of [RFC4422].
|
|
yuuji@0
|
90
|
|
yuuji@0
|
91 As with any other client response, this initial client response MUST
|
|
yuuji@0
|
92 be encoded as defined in Section 4 of [RFC4648]. It also MUST be
|
|
yuuji@0
|
93 transmitted outside of a quoted string or literal. To send a zero-
|
|
yuuji@0
|
94 length initial response, the client MUST send a single pad character
|
|
yuuji@0
|
95 ("="). This indicates that the response is present, but is a zero-
|
|
yuuji@0
|
96 length string.
|
|
yuuji@0
|
97
|
|
yuuji@0
|
98 When decoding the BASE64 [RFC4648] data in the initial client
|
|
yuuji@0
|
99 response, decoding errors MUST be treated as IMAP [RFC3501] would
|
|
yuuji@0
|
100 handle them in any normal SASL client response. In particular, the
|
|
yuuji@0
|
101 server should check for any characters not explicitly allowed by the
|
|
yuuji@0
|
102 BASE64 alphabet, as well as any sequence of BASE64 characters that
|
|
yuuji@0
|
103 contains the pad character ('=') anywhere other than the end of the
|
|
yuuji@0
|
104 string (e.g., "=AAA" and "AAA=BBB" are not allowed).
|
|
yuuji@0
|
105
|
|
yuuji@0
|
106 If the client uses an initial response with a SASL mechanism that
|
|
yuuji@0
|
107 does not support an initial response, the server MUST reject the
|
|
yuuji@0
|
108 command with a tagged BAD response.
|
|
yuuji@0
|
109
|
|
yuuji@0
|
110
|
|
yuuji@0
|
111
|
|
yuuji@0
|
112
|
|
yuuji@0
|
113
|
|
yuuji@0
|
114 Siemborski & Gulbrandsen Standards Track [Page 2]
|
|
yuuji@0
|
115
|
|
yuuji@0
|
116 RFC 4959 IMAP Ext for SASL Initial Client Response September 2007
|
|
yuuji@0
|
117
|
|
yuuji@0
|
118
|
|
yuuji@0
|
119 Note: support and use of the initial client response is optional for
|
|
yuuji@0
|
120 both clients and servers. Servers that implement this extension MUST
|
|
yuuji@0
|
121 support clients that omit the initial client response, and clients
|
|
yuuji@0
|
122 that implement this extension MUST NOT send an initial client
|
|
yuuji@0
|
123 response to servers that do not advertise the SASL-IR capability. In
|
|
yuuji@0
|
124 such a situation, clients MUST fall back to an IMAP [RFC3501]
|
|
yuuji@0
|
125 compatible mode.
|
|
yuuji@0
|
126
|
|
yuuji@0
|
127 If either the client or the server do not support the SASL-IR
|
|
yuuji@0
|
128 capability, a mechanism which uses an initial client response is
|
|
yuuji@0
|
129 negotiated using the challenge/response exchange described in
|
|
yuuji@0
|
130 [RFC3501], with an initial zero-length server challenge.
|
|
yuuji@0
|
131
|
|
yuuji@0
|
132 4. Examples
|
|
yuuji@0
|
133
|
|
yuuji@0
|
134 The following is an example authentication using the PLAIN (see
|
|
yuuji@0
|
135 [RFC4616]) SASL mechanism (under a TLS protection layer, see
|
|
yuuji@0
|
136 [RFC4346]) and an initial client response:
|
|
yuuji@0
|
137
|
|
yuuji@0
|
138 ... client connects to server and negotiates a TLS
|
|
yuuji@0
|
139 protection layer ...
|
|
yuuji@0
|
140 C: C01 CAPABILITY
|
|
yuuji@0
|
141 S: * CAPABILITY IMAP4rev1 SASL-IR AUTH=PLAIN
|
|
yuuji@0
|
142 S: C01 OK Completed
|
|
yuuji@0
|
143 C: A01 AUTHENTICATE PLAIN dGVzdAB0ZXN0AHRlc3Q=
|
|
yuuji@0
|
144 S: A01 OK Success (tls protection)
|
|
yuuji@0
|
145
|
|
yuuji@0
|
146 Note that even when a server supports this extension, the following
|
|
yuuji@0
|
147 negotiation (which does not use the initial response) is still valid
|
|
yuuji@0
|
148 and MUST be supported by the server:
|
|
yuuji@0
|
149
|
|
yuuji@0
|
150 ... client connects to server and negotiates a TLS
|
|
yuuji@0
|
151 protection layer ...
|
|
yuuji@0
|
152 C: C01 CAPABILITY
|
|
yuuji@0
|
153 S: * CAPABILITY IMAP4rev1 SASL-IR AUTH=PLAIN
|
|
yuuji@0
|
154 S: C01 OK Completed
|
|
yuuji@0
|
155 C: A01 AUTHENTICATE PLAIN
|
|
yuuji@0
|
156 (note that there is a space following the "+" in the
|
|
yuuji@0
|
157 following line)
|
|
yuuji@0
|
158 S: +
|
|
yuuji@0
|
159 C: dGVzdAB0ZXN0AHRlc3Q=
|
|
yuuji@0
|
160 S: A01 OK Success (tls protection)
|
|
yuuji@0
|
161
|
|
yuuji@0
|
162 The following is an example authentication using the SASL EXTERNAL
|
|
yuuji@0
|
163 mechanism (defined in [RFC4422]) under a TLS protection layer (see
|
|
yuuji@0
|
164 [RFC4346]) and an empty initial client response:
|
|
yuuji@0
|
165
|
|
yuuji@0
|
166
|
|
yuuji@0
|
167
|
|
yuuji@0
|
168
|
|
yuuji@0
|
169
|
|
yuuji@0
|
170 Siemborski & Gulbrandsen Standards Track [Page 3]
|
|
yuuji@0
|
171
|
|
yuuji@0
|
172 RFC 4959 IMAP Ext for SASL Initial Client Response September 2007
|
|
yuuji@0
|
173
|
|
yuuji@0
|
174
|
|
yuuji@0
|
175 ... client connects to server and negotiates a TLS
|
|
yuuji@0
|
176 protection layer ...
|
|
yuuji@0
|
177 C: C01 CAPABILITY
|
|
yuuji@0
|
178 S: * CAPABILITY IMAP4rev1 SASL-IR AUTH=PLAIN AUTH=EXTERNAL
|
|
yuuji@0
|
179 S: C01 OK Completed
|
|
yuuji@0
|
180 C: A01 AUTHENTICATE EXTERNAL =
|
|
yuuji@0
|
181 S: A01 OK Success (tls protection)
|
|
yuuji@0
|
182
|
|
yuuji@0
|
183 This is in contrast with the handling of such a situation when an
|
|
yuuji@0
|
184 initial response is omitted:
|
|
yuuji@0
|
185
|
|
yuuji@0
|
186 ... client connects to server and negotiates a TLS protection
|
|
yuuji@0
|
187 layer ...
|
|
yuuji@0
|
188 C: C01 CAPABILITY
|
|
yuuji@0
|
189 S: * CAPABILITY IMAP4rev1 SASL-IR AUTH=PLAIN AUTH=EXTERNAL
|
|
yuuji@0
|
190 S: C01 OK Completed
|
|
yuuji@0
|
191 C: A01 AUTHENTICATE EXTERNAL
|
|
yuuji@0
|
192 (note that there is a space following the "+" in the
|
|
yuuji@0
|
193 following line)
|
|
yuuji@0
|
194 S: +
|
|
yuuji@0
|
195 C:
|
|
yuuji@0
|
196 S: A01 OK Success (tls protection)
|
|
yuuji@0
|
197
|
|
yuuji@0
|
198 5. IANA Considerations
|
|
yuuji@0
|
199
|
|
yuuji@0
|
200 The IANA has added SASL-IR to the IMAP4 Capabilities Registry.
|
|
yuuji@0
|
201
|
|
yuuji@0
|
202 6. Security Considerations
|
|
yuuji@0
|
203
|
|
yuuji@0
|
204 The extension defined in this document is subject to many of the
|
|
yuuji@0
|
205 Security Considerations defined in [RFC3501] and [RFC4422].
|
|
yuuji@0
|
206
|
|
yuuji@0
|
207 Server implementations MUST treat the omission of an initial client
|
|
yuuji@0
|
208 response from the AUTHENTICATE command as defined by [RFC3501] (as if
|
|
yuuji@0
|
209 this extension did not exist).
|
|
yuuji@0
|
210
|
|
yuuji@0
|
211 Although [RFC3501] has no express line length limitations, some
|
|
yuuji@0
|
212 implementations choose to enforce them anyway. Such implementations
|
|
yuuji@0
|
213 MUST be aware that the addition of the initial response parameter to
|
|
yuuji@0
|
214 AUTHENTICATE may increase the maximum line length that IMAP parsers
|
|
yuuji@0
|
215 may expect to support. Server implementations MUST be able to
|
|
yuuji@0
|
216 receive the largest possible initial client response that their
|
|
yuuji@0
|
217 supported mechanisms might receive.
|
|
yuuji@0
|
218
|
|
yuuji@0
|
219
|
|
yuuji@0
|
220
|
|
yuuji@0
|
221
|
|
yuuji@0
|
222
|
|
yuuji@0
|
223
|
|
yuuji@0
|
224
|
|
yuuji@0
|
225
|
|
yuuji@0
|
226 Siemborski & Gulbrandsen Standards Track [Page 4]
|
|
yuuji@0
|
227
|
|
yuuji@0
|
228 RFC 4959 IMAP Ext for SASL Initial Client Response September 2007
|
|
yuuji@0
|
229
|
|
yuuji@0
|
230
|
|
yuuji@0
|
231 7. Formal Syntax
|
|
yuuji@0
|
232
|
|
yuuji@0
|
233 The following syntax specification uses the Augmented Backus-Naur
|
|
yuuji@0
|
234 Form [RFC4234] notation. [RFC3501] defines the non-terminals
|
|
yuuji@0
|
235 capability, auth-type, and base64.
|
|
yuuji@0
|
236
|
|
yuuji@0
|
237 capability =/ "SASL-IR"
|
|
yuuji@0
|
238
|
|
yuuji@0
|
239 authenticate = "AUTHENTICATE" SP auth-type [SP (base64 / "=")]
|
|
yuuji@0
|
240 *(CRLF base64)
|
|
yuuji@0
|
241 ;;redefine AUTHENTICATE from [RFC3501]
|
|
yuuji@0
|
242
|
|
yuuji@0
|
243 8. Acknowledgments
|
|
yuuji@0
|
244
|
|
yuuji@0
|
245 The authors would like to acknowledge the contributions of Ken
|
|
yuuji@0
|
246 Murchison and Mark Crispin, along with the rest of the IMAPEXT
|
|
yuuji@0
|
247 Working Group for their assistance in reviewing this document.
|
|
yuuji@0
|
248
|
|
yuuji@0
|
249 Alexey Melnikov and Cyrus Daboo also had some early discussions about
|
|
yuuji@0
|
250 this extension.
|
|
yuuji@0
|
251
|
|
yuuji@0
|
252 9. References
|
|
yuuji@0
|
253
|
|
yuuji@0
|
254 9.1. Normative References
|
|
yuuji@0
|
255
|
|
yuuji@0
|
256 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
|
yuuji@0
|
257 Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|
yuuji@0
|
258
|
|
yuuji@0
|
259 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
|
|
yuuji@0
|
260 4rev1", RFC 3501, March 2003.
|
|
yuuji@0
|
261
|
|
yuuji@0
|
262 [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
|
|
yuuji@0
|
263 Specifications: ABNF", RFC 4234, October 2005.
|
|
yuuji@0
|
264
|
|
yuuji@0
|
265 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
|
|
yuuji@0
|
266 Security Layer (SASL)", RFC 4422, June 2006.
|
|
yuuji@0
|
267
|
|
yuuji@0
|
268 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
|
|
yuuji@0
|
269 Encodings", RFC 4648, October 2006.
|
|
yuuji@0
|
270
|
|
yuuji@0
|
271 9.2. Informative References
|
|
yuuji@0
|
272
|
|
yuuji@0
|
273 [RFC4616] Zeilenga, K., "The PLAIN Simple Authentication and
|
|
yuuji@0
|
274 Security Layer (SASL) Mechanism", RFC 4616, August 2006.
|
|
yuuji@0
|
275
|
|
yuuji@0
|
276 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
|
|
yuuji@0
|
277 (TLS) Protocol Version 1.1", RFC 4346, April 2006.
|
|
yuuji@0
|
278
|
|
yuuji@0
|
279
|
|
yuuji@0
|
280
|
|
yuuji@0
|
281
|
|
yuuji@0
|
282 Siemborski & Gulbrandsen Standards Track [Page 5]
|
|
yuuji@0
|
283
|
|
yuuji@0
|
284 RFC 4959 IMAP Ext for SASL Initial Client Response September 2007
|
|
yuuji@0
|
285
|
|
yuuji@0
|
286
|
|
yuuji@0
|
287 Authors' Addresses
|
|
yuuji@0
|
288
|
|
yuuji@0
|
289 Robert Siemborski
|
|
yuuji@0
|
290 Google, Inc.
|
|
yuuji@0
|
291 1600 Ampitheatre Parkway
|
|
yuuji@0
|
292 Mountain View, CA 94043
|
|
yuuji@0
|
293
|
|
yuuji@0
|
294 Phone: +1 650 623 6925
|
|
yuuji@0
|
295 EMail: robsiemb@google.com
|
|
yuuji@0
|
296
|
|
yuuji@0
|
297
|
|
yuuji@0
|
298 Arnt Gulbrandsen
|
|
yuuji@0
|
299 Oryx Mail Systems GmbH
|
|
yuuji@0
|
300 Schweppermannstr. 8
|
|
yuuji@0
|
301 D-81671 Muenchen
|
|
yuuji@0
|
302 Germany
|
|
yuuji@0
|
303
|
|
yuuji@0
|
304 EMail: arnt@oryx.com
|
|
yuuji@0
|
305
|
|
yuuji@0
|
306
|
|
yuuji@0
|
307
|
|
yuuji@0
|
308
|
|
yuuji@0
|
309
|
|
yuuji@0
|
310
|
|
yuuji@0
|
311
|
|
yuuji@0
|
312
|
|
yuuji@0
|
313
|
|
yuuji@0
|
314
|
|
yuuji@0
|
315
|
|
yuuji@0
|
316
|
|
yuuji@0
|
317
|
|
yuuji@0
|
318
|
|
yuuji@0
|
319
|
|
yuuji@0
|
320
|
|
yuuji@0
|
321
|
|
yuuji@0
|
322
|
|
yuuji@0
|
323
|
|
yuuji@0
|
324
|
|
yuuji@0
|
325
|
|
yuuji@0
|
326
|
|
yuuji@0
|
327
|
|
yuuji@0
|
328
|
|
yuuji@0
|
329
|
|
yuuji@0
|
330
|
|
yuuji@0
|
331
|
|
yuuji@0
|
332
|
|
yuuji@0
|
333
|
|
yuuji@0
|
334
|
|
yuuji@0
|
335
|
|
yuuji@0
|
336
|
|
yuuji@0
|
337
|
|
yuuji@0
|
338 Siemborski & Gulbrandsen Standards Track [Page 6]
|
|
yuuji@0
|
339
|
|
yuuji@0
|
340 RFC 4959 IMAP Ext for SASL Initial Client Response September 2007
|
|
yuuji@0
|
341
|
|
yuuji@0
|
342
|
|
yuuji@0
|
343 Full Copyright Statement
|
|
yuuji@0
|
344
|
|
yuuji@0
|
345 Copyright (C) The IETF Trust (2007).
|
|
yuuji@0
|
346
|
|
yuuji@0
|
347 This document is subject to the rights, licenses and restrictions
|
|
yuuji@0
|
348 contained in BCP 78, and except as set forth therein, the authors
|
|
yuuji@0
|
349 retain all their rights.
|
|
yuuji@0
|
350
|
|
yuuji@0
|
351 This document and the information contained herein are provided on an
|
|
yuuji@0
|
352 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
|
yuuji@0
|
353 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
|
|
yuuji@0
|
354 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
|
|
yuuji@0
|
355 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
|
|
yuuji@0
|
356 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
|
yuuji@0
|
357 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|
yuuji@0
|
358
|
|
yuuji@0
|
359 Intellectual Property
|
|
yuuji@0
|
360
|
|
yuuji@0
|
361 The IETF takes no position regarding the validity or scope of any
|
|
yuuji@0
|
362 Intellectual Property Rights or other rights that might be claimed to
|
|
yuuji@0
|
363 pertain to the implementation or use of the technology described in
|
|
yuuji@0
|
364 this document or the extent to which any license under such rights
|
|
yuuji@0
|
365 might or might not be available; nor does it represent that it has
|
|
yuuji@0
|
366 made any independent effort to identify any such rights. Information
|
|
yuuji@0
|
367 on the procedures with respect to rights in RFC documents can be
|
|
yuuji@0
|
368 found in BCP 78 and BCP 79.
|
|
yuuji@0
|
369
|
|
yuuji@0
|
370 Copies of IPR disclosures made to the IETF Secretariat and any
|
|
yuuji@0
|
371 assurances of licenses to be made available, or the result of an
|
|
yuuji@0
|
372 attempt made to obtain a general license or permission for the use of
|
|
yuuji@0
|
373 such proprietary rights by implementers or users of this
|
|
yuuji@0
|
374 specification can be obtained from the IETF on-line IPR repository at
|
|
yuuji@0
|
375 http://www.ietf.org/ipr.
|
|
yuuji@0
|
376
|
|
yuuji@0
|
377 The IETF invites any interested party to bring to its attention any
|
|
yuuji@0
|
378 copyrights, patents or patent applications, or other proprietary
|
|
yuuji@0
|
379 rights that may cover technology that may be required to implement
|
|
yuuji@0
|
380 this standard. Please address the information to the IETF at
|
|
yuuji@0
|
381 ietf-ipr@ietf.org.
|
|
yuuji@0
|
382
|
|
yuuji@0
|
383
|
|
yuuji@0
|
384
|
|
yuuji@0
|
385
|
|
yuuji@0
|
386
|
|
yuuji@0
|
387
|
|
yuuji@0
|
388
|
|
yuuji@0
|
389
|
|
yuuji@0
|
390
|
|
yuuji@0
|
391
|
|
yuuji@0
|
392
|
|
yuuji@0
|
393
|
|
yuuji@0
|
394 Siemborski & Gulbrandsen Standards Track [Page 7]
|
|
yuuji@0
|
395
|
