Skip to content

Commit a382534

Browse files
jstedfastjstedfast
committedSep 19, 2018
Added rfc8437: IMAP UNAUTHENTICATE Extension for Connection Reuse
·
4.11.02.0.7
1 parent 051be2c commit a382534

File tree

1 file changed

+619
-0
lines changed

1 file changed

+619
-0
lines changed
 

‎rfc/rfc8437.txt

+619
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,619 @@
1+
2+
3+
4+
5+
6+
7+
Internet Engineering Task Force (IETF) C. Newman
8+
Request for Comments: 8437 Oracle
9+
Updates: 3501 August 2018
10+
Category: Standards Track
11+
ISSN: 2070-1721
12+
13+
14+
IMAP UNAUTHENTICATE Extension for Connection Reuse
15+
16+
Abstract
17+
18+
This specification extends the Internet Message Access Protocol
19+
(IMAP) to allow an administrative client to reuse the same IMAP
20+
connection on behalf of multiple IMAP user identities.
21+
22+
Status of This Memo
23+
24+
This is an Internet Standards Track document.
25+
26+
This document is a product of the Internet Engineering Task Force
27+
(IETF). It represents the consensus of the IETF community. It has
28+
received public review and has been approved for publication by the
29+
Internet Engineering Steering Group (IESG). Further information on
30+
Internet Standards is available in Section 2 of RFC 7841.
31+
32+
Information about the current status of this document, any errata,
33+
and how to provide feedback on it may be obtained at
34+
https://www.rfc-editor.org/info/rfc8437.
35+
36+
Copyright Notice
37+
38+
Copyright (c) 2018 IETF Trust and the persons identified as the
39+
document authors. All rights reserved.
40+
41+
This document is subject to BCP 78 and the IETF Trust's Legal
42+
Provisions Relating to IETF Documents
43+
(https://trustee.ietf.org/license-info) in effect on the date of
44+
publication of this document. Please review these documents
45+
carefully, as they describe your rights and restrictions with respect
46+
to this document. Code Components extracted from this document must
47+
include Simplified BSD License text as described in Section 4.e of
48+
the Trust Legal Provisions and are provided without warranty as
49+
described in the Simplified BSD License.
50+
51+
52+
53+
54+
55+
56+
57+
58+
Newman Standards Track [Page 1]
59+
60+
RFC 8437 IMAP UNAUTHENTICATE for Connection Reuse August 2018
61+
62+
63+
Table of Contents
64+
65+
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
66+
2. Conventions Used in This Document . . . . . . . . . . . . . . 2
67+
3. UNAUTHENTICATE Command . . . . . . . . . . . . . . . . . . . 3
68+
4. Interactions . . . . . . . . . . . . . . . . . . . . . . . . 4
69+
4.1. Stateful Extensions . . . . . . . . . . . . . . . . . . . 4
70+
4.2. Client Certificates, SASL EXTERNAL, and imaps . . . . . . 5
71+
5. Revised State Machine . . . . . . . . . . . . . . . . . . . . 6
72+
6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 7
73+
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
74+
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
75+
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8
76+
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
77+
10.1. Normative References . . . . . . . . . . . . . . . . . . 8
78+
10.2. Informative References . . . . . . . . . . . . . . . . . 9
79+
Appendix A. Design Considerations . . . . . . . . . . . . . . . 11
80+
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
81+
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
82+
83+
1. Introduction
84+
85+
Modern IMAP [RFC3501] server deployments often have peer systems with
86+
administrative privilege that perform actions on behalf of IMAP end
87+
users. For example, a voicemail gateway can use IMAP to store a
88+
user's voicemail and mark that voicemail as \Seen when the user
89+
listens to it via the phone interface. These systems can issue the
90+
IMAP AUTHENTICATE command with administrative credentials to act on
91+
behalf of other users. However, with the IMAP base specification,
92+
these specialized IMAP clients must close the connection and create a
93+
new connection for each user. For efficiency reasons, it is
94+
desirable for these clients to reuse the same connection,
95+
particularly if SSL has been negotiated. This specification proposes
96+
the UNAUTHENTICATE command to achieve this goal.
97+
98+
The IMAP state machine described in Section 3 of RFC 3501 does not
99+
have a transition from authenticated or selected state to not
100+
authenticated state. The UNAUTHENTICATE command adds this
101+
transition.
102+
103+
2. Conventions Used in This Document
104+
105+
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
106+
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
107+
"OPTIONAL" in this document are to be interpreted as described in
108+
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
109+
capitals, as shown here.
110+
111+
112+
113+
114+
Newman Standards Track [Page 2]
115+
116+
RFC 8437 IMAP UNAUTHENTICATE for Connection Reuse August 2018
117+
118+
119+
3. UNAUTHENTICATE Command
120+
121+
Arguments: None
122+
123+
Responses: No specific response for this command
124+
125+
Result: OK - Completed, now in not authenticated state
126+
BAD - Command unknown or arguments invalid
127+
128+
This command directs the server to reset all connection state except
129+
for the state of the TLS [RFC8446] layer. Upon completion, the
130+
server connection is placed in not authenticated state. This
131+
represents Transition 7 in the State Machine Diagram (Section 5).
132+
133+
If a mailbox was selected, the mailbox ceases to be selected, but no
134+
expunge event is generated. If a Simple Authentication and Security
135+
Layer (SASL) [RFC4422] was active, the server terminates its outgoing
136+
security layer immediately after sending the CRLF following the OK
137+
response. The client's outgoing security layer terminates
138+
immediately after the CRLF following the UNAUTHENTICATE command.
139+
Note that a BAD response only occurs if UNAUTHENTICATE is issued in
140+
an invalid state, is not advertised by the server, or does not follow
141+
the command syntax in the specification. A NO response is not
142+
permitted. As a result, specification-compliant implementations will
143+
interoperate across security layer termination.
144+
145+
After sending this command, the client is free to issue a new
146+
AUTHENTICATE or LOGIN command as permitted based on the server's
147+
capabilities. If no SASL security layer was active, the client is
148+
permitted to pipeline the UNAUTHENTICATE command with a subsequent
149+
AUTHENTICATE command. If the IMAP server also advertises SASL-IR
150+
[RFC4959], this permits an administrative client to re-authenticate
151+
in one round trip. Because of this pipelining optimization, a server
152+
advertising UNAUTHENTICATE is not permitted to respond to the
153+
UNAUTHENTICATE command with a NO response if it is unable to reset
154+
the state associated with the connection. Servers MAY close the
155+
connection with an untagged BYE response if this preferably rare
156+
situation occurs.
157+
158+
Servers MAY choose to advertise the UNAUTHENTICATE capability only
159+
after authentication has completed. As a result, clients may need to
160+
issue an IMAP CAPABILITY command after authentication in order to
161+
determine the availability of UNAUTHENTICATE.
162+
163+
164+
165+
166+
167+
168+
169+
170+
Newman Standards Track [Page 3]
171+
172+
RFC 8437 IMAP UNAUTHENTICATE for Connection Reuse August 2018
173+
174+
175+
The IMAP ID [RFC2971] command provides properties about the client
176+
primarily for use in server log or audit files. Because IMAP ID is
177+
not related to application authentication or user identity in any
178+
way, and caching it for the duration of the client connection can be
179+
useful, the interaction between IMAP ID and the UNAUTHENTICATE
180+
command is defined by the implementation.
181+
182+
4. Interactions
183+
184+
This section describes interactions between this extension and other
185+
IMAP extensions or usage models.
186+
187+
4.1. Stateful Extensions
188+
189+
The connection state for the following list of IMAP extensions MUST
190+
be reset if both a) the specified extension is advertised and b) the
191+
UNAUTHENTICATE command is advertised and used. This list may not be
192+
complete; the requirement to reset the connection state applies to
193+
all current and future extensions except STARTTLS and ID. Additional
194+
requirements apply to specific stateful extensions as follows:
195+
196+
o Cached identity information, such as group memberships, that are
197+
used to evaluate access control lists [RFC4314] MUST be reset.
198+
199+
o After an UNAUTHENTICATE command is issued, CONDSTORE servers
200+
[RFC7162] MUST behave as if no CONDSTORE-enabling command was
201+
issued.
202+
203+
o If IMAP COMPRESS [RFC4978] is active, the server terminates its
204+
outgoing compression layer after it sends the CRLF following the
205+
OK response. The client terminates its outgoing compression layer
206+
after the CRLF following the UNAUTHENTICATE command. When it
207+
matters, the compression layer terminates before a SASL layer
208+
terminates.
209+
210+
o Any extensions enabled by the IMAP ENABLE [RFC5161] command cease
211+
to be enabled when the UNAUTHENTICATE command is issued. This
212+
includes, but is not limited to, CONDSTORE [RFC7162], QRESYNC
213+
[RFC7162], METADATA [RFC5464], METADATA-SERVER [RFC5464], and
214+
UTF8=ACCEPT [RFC6855].
215+
216+
o A server advertising SEARCHRES [RFC5182] discards any saved search
217+
results so that '$' subsequently represents the empty set.
218+
219+
o A server advertising LANGUAGE [RFC5255] will revert to the
220+
"i-default" language.
221+
222+
223+
224+
225+
226+
Newman Standards Track [Page 4]
227+
228+
RFC 8437 IMAP UNAUTHENTICATE for Connection Reuse August 2018
229+
230+
231+
o When a server advertises CONTEXT=SEARCH or CONTEXT=SORT [RFC5267],
232+
the UNAUTHENTICATE command includes an implicit CANCELUPDATE for
233+
all server contexts.
234+
235+
o When a server advertises NOTIFY [RFC5465], the UNAUTHENTICATE
236+
command cancels the server state related to the NOTIFY command and
237+
reverts to default IMAP base-specification behavior for
238+
notifications.
239+
240+
4.2. Client Certificates, SASL EXTERNAL, and imaps
241+
242+
When a TLS [RFC8446] security layer is negotiated using either the
243+
STARTTLS command or the imaps port [RFC8314], IMAP servers may be
244+
configured to request a client certificate, and IMAP clients may
245+
provide one. Client credentials at the TLS layer do not normally
246+
impact the application layer; however, they do have an impact when
247+
the SASL EXTERNAL mechanism [RFC4422] in an IMAP AUTHENTICATE command
248+
is used to direct the server to use the provided client certificate
249+
to authenticate as the specified IMAP user. The UNAUTHENTICATE
250+
command breaks any application-level binding of the TLS client
251+
credentials but does not discard the client credentials. As a
252+
result, an administrative client may use a client certificate with
253+
administrative privilege to act on behalf of multiple IMAP users in
254+
the same connection via the EXTERNAL mechanism and the UNAUTHENTICATE
255+
command.
256+
257+
Some server implementations using the imaps port will request and use
258+
a TLS client certificate to authenticate immediately as the default
259+
IMAP identity associated with that certificate. These
260+
implementations indicate this behavior by using the PREAUTH greeting,
261+
as indicated by Transition 2 in the State Machine Diagram
262+
(Section 5). As a result, TLS client certificates cannot be used for
263+
administrative proxy authentication with the imaps port unless the
264+
UNAUTHENTICATE command is also advertised. In that case, an
265+
administrative client can respond to the PREAUTH greeting with an
266+
UNAUTHENTICATE command and then issue an AUTHENTICATE EXTERNAL
267+
command.
268+
269+
270+
271+
272+
273+
274+
275+
276+
277+
278+
279+
280+
281+
282+
Newman Standards Track [Page 5]
283+
284+
RFC 8437 IMAP UNAUTHENTICATE for Connection Reuse August 2018
285+
286+
287+
5. Revised State Machine
288+
289+
+----------------------+
290+
|connection established|
291+
+----------------------+
292+
||
293+
\/
294+
+--------------------------------------+
295+
| server greeting |
296+
+--------------------------------------+
297+
|| (1) || (2) || (3)
298+
\/ || ||
299+
+-----------------+ || ||
300+
|Not Authenticated|<===||=========++ ||
301+
+-----------------+ || (7) || ||
302+
|| (8) || (4) || || ||
303+
|| \/ \/ || ||
304+
|| +----------------+ || ||
305+
|| | |========++ ||
306+
|| | Authenticated |<=++ || ||
307+
|| +----------------+ || || ||
308+
|| || (8) || (5) ||(6) || ||
309+
|| || \/ || || ||
310+
|| || +--------+ || || ||
311+
|| || |Selected|==++ || ||
312+
|| || | |========++ ||
313+
|| || +--------+ ||
314+
|| || || (8) ||
315+
\/ \/ \/ \/
316+
+--------------------------------------+
317+
| Logout |
318+
+--------------------------------------+
319+
||
320+
\/
321+
+-------------------------------+
322+
|both sides close the connection|
323+
+-------------------------------+
324+
325+
Revised IMAP state machine transitions:
326+
327+
1. Connection without pre-authentication (OK greeting)
328+
329+
2. Pre-authenticated connection (PREAUTH greeting)
330+
331+
3. Rejected connection (BYE greeting)
332+
333+
4. Successful LOGIN or AUTHENTICATE command
334+
335+
336+
337+
338+
Newman Standards Track [Page 6]
339+
340+
RFC 8437 IMAP UNAUTHENTICATE for Connection Reuse August 2018
341+
342+
343+
5. Successful SELECT or EXAMINE command
344+
345+
6. CLOSE, UNSELECT [RFC3691], or failed SELECT or EXAMINE command
346+
347+
7. UNAUTHENTICATE command
348+
349+
8. LOGOUT command, server shutdown, or connection closed
350+
351+
6. Formal Syntax
352+
353+
The following syntax specification uses the Augmented Backus-Naur
354+
Form (ABNF), as described in [RFC5234]. Amended terms are defined in
355+
[RFC3501].
356+
357+
capability =/ "UNAUTHENTICATE"
358+
359+
command-auth =/ "UNAUTHENTICATE"
360+
361+
command-select =/ "UNAUTHENTICATE"
362+
363+
7. IANA Considerations
364+
365+
IANA has added the UNAUTHENTICATE capability to the "IMAP
366+
Capabilities" registry.
367+
368+
8. Security Considerations
369+
370+
The original IMAP state machine was designed to allow a server-
371+
implementation approach in which each IMAP authentication identity
372+
matches an operating system identity and the server revokes all
373+
administrative privilege once authentication completes. This
374+
extension is not compatible with that implementation approach.
375+
However, that approach has significant performance costs on Unix
376+
systems, and this extension is designed for environments where
377+
efficiency is a relatively high-priority deployment goal. This
378+
extension is therefore appropriate for some deployments but may not
379+
be appropriate for the most security-sensitive environments.
380+
381+
IMAP server implementations are complicated and can retain a lot of
382+
state related to an authenticated user. Server implementers need to
383+
take care to reset all server state such that authentication as a
384+
subsequent user does not inherit any data or privileges from the
385+
previous user. State data associated with a user can include cached
386+
identity information such as group membership used to evaluate access
387+
control lists [RFC4314], active notifications [RFC5465], access to
388+
per-user data such as flags, etc.
389+
390+
391+
392+
393+
394+
Newman Standards Track [Page 7]
395+
396+
RFC 8437 IMAP UNAUTHENTICATE for Connection Reuse August 2018
397+
398+
399+
IMAP server systems are often deployed in a two-tier model where a
400+
server-side IMAP proxy routes to an IMAP backend that handles all
401+
connections for a subset of possible users. Some IMAP proxies enter
402+
a pass-through mode after authentication. If enabled, the
403+
UNAUTHENTICATE command would allow a client, on a subsequent
404+
authentication, to bypass any security restrictions present in the
405+
proxy layer but not in the backend server layer. As a result, IMAP
406+
server implementations of this extension MUST provide a way to
407+
disable it when it is not needed. Use of an IMAP proxy that
408+
processes the UNAUTHENTICATE command at the proxy layer eliminates
409+
this concern. Another option to mitigate this concern is for servers
410+
to only enable the UNAUTHENTICATE extension if the supplied
411+
authentication credentials are associated with an administrative
412+
identity.
413+
414+
9. Privacy Considerations
415+
416+
For the most part, this extension will have no impact on the privacy
417+
considerations already present in an IMAP implementation. However,
418+
if this extension were used between data centers, it could improve
419+
end-user privacy by increasing the difficultly of traffic analysis
420+
due to connection reuse.
421+
422+
10. References
423+
424+
10.1. Normative References
425+
426+
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
427+
Requirement Levels", BCP 14, RFC 2119,
428+
DOI 10.17487/RFC2119, March 1997,
429+
<https://www.rfc-editor.org/info/rfc2119>.
430+
431+
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
432+
4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
433+
<https://www.rfc-editor.org/info/rfc3501>.
434+
435+
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
436+
Specifications: ABNF", STD 68, RFC 5234,
437+
DOI 10.17487/RFC5234, January 2008,
438+
<https://www.rfc-editor.org/info/rfc5234>.
439+
440+
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
441+
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
442+
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
443+
444+
445+
446+
447+
448+
449+
450+
Newman Standards Track [Page 8]
451+
452+
RFC 8437 IMAP UNAUTHENTICATE for Connection Reuse August 2018
453+
454+
455+
10.2. Informative References
456+
457+
[RFC2971] Showalter, T., "IMAP4 ID extension", RFC 2971,
458+
DOI 10.17487/RFC2971, October 2000,
459+
<https://www.rfc-editor.org/info/rfc2971>.
460+
461+
[RFC3691] Melnikov, A., "Internet Message Access Protocol (IMAP)
462+
UNSELECT command", RFC 3691, DOI 10.17487/RFC3691,
463+
February 2004, <https://www.rfc-editor.org/info/rfc3691>.
464+
465+
[RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
466+
RFC 4314, DOI 10.17487/RFC4314, December 2005,
467+
<https://www.rfc-editor.org/info/rfc4314>.
468+
469+
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
470+
Authentication and Security Layer (SASL)", RFC 4422,
471+
DOI 10.17487/RFC4422, June 2006,
472+
<https://www.rfc-editor.org/info/rfc4422>.
473+
474+
[RFC4959] Siemborski, R. and A. Gulbrandsen, "IMAP Extension for
475+
Simple Authentication and Security Layer (SASL) Initial
476+
Client Response", RFC 4959, DOI 10.17487/RFC4959,
477+
September 2007, <https://www.rfc-editor.org/info/rfc4959>.
478+
479+
[RFC4978] Gulbrandsen, A., "The IMAP COMPRESS Extension", RFC 4978,
480+
DOI 10.17487/RFC4978, August 2007,
481+
<https://www.rfc-editor.org/info/rfc4978>.
482+
483+
[RFC5161] Gulbrandsen, A., Ed. and A. Melnikov, Ed., "The IMAP
484+
ENABLE Extension", RFC 5161, DOI 10.17487/RFC5161, March
485+
2008, <https://www.rfc-editor.org/info/rfc5161>.
486+
487+
[RFC5182] Melnikov, A., "IMAP Extension for Referencing the Last
488+
SEARCH Result", RFC 5182, DOI 10.17487/RFC5182, March
489+
2008, <https://www.rfc-editor.org/info/rfc5182>.
490+
491+
[RFC5255] Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet
492+
Message Access Protocol Internationalization", RFC 5255,
493+
DOI 10.17487/RFC5255, June 2008,
494+
<https://www.rfc-editor.org/info/rfc5255>.
495+
496+
[RFC5267] Cridland, D. and C. King, "Contexts for IMAP4", RFC 5267,
497+
DOI 10.17487/RFC5267, July 2008,
498+
<https://www.rfc-editor.org/info/rfc5267>.
499+
500+
501+
502+
503+
504+
505+
506+
Newman Standards Track [Page 9]
507+
508+
RFC 8437 IMAP UNAUTHENTICATE for Connection Reuse August 2018
509+
510+
511+
[RFC5464] Daboo, C., "The IMAP METADATA Extension", RFC 5464,
512+
DOI 10.17487/RFC5464, February 2009,
513+
<https://www.rfc-editor.org/info/rfc5464>.
514+
515+
[RFC5465] Gulbrandsen, A., King, C., and A. Melnikov, "The IMAP
516+
NOTIFY Extension", RFC 5465, DOI 10.17487/RFC5465,
517+
February 2009, <https://www.rfc-editor.org/info/rfc5465>.
518+
519+
[RFC6855] Resnick, P., Ed., Newman, C., Ed., and S. Shen, Ed., "IMAP
520+
Support for UTF-8", RFC 6855, DOI 10.17487/RFC6855, March
521+
2013, <https://www.rfc-editor.org/info/rfc6855>.
522+
523+
[RFC7162] Melnikov, A. and D. Cridland, "IMAP Extensions: Quick Flag
524+
Changes Resynchronization (CONDSTORE) and Quick Mailbox
525+
Resynchronization (QRESYNC)", RFC 7162,
526+
DOI 10.17487/RFC7162, May 2014,
527+
<https://www.rfc-editor.org/info/rfc7162>.
528+
529+
[RFC8314] Moore, K. and C. Newman, "Cleartext Considered Obsolete:
530+
Use of Transport Layer Security (TLS) for Email Submission
531+
and Access", RFC 8314, DOI 10.17487/RFC8314, January 2018,
532+
<https://www.rfc-editor.org/info/rfc8314>.
533+
534+
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
535+
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
536+
<https://www.rfc-editor.org/info/rfc8446>.
537+
538+
539+
540+
541+
542+
543+
544+
545+
546+
547+
548+
549+
550+
551+
552+
553+
554+
555+
556+
557+
558+
559+
560+
561+
562+
Newman Standards Track [Page 10]
563+
564+
RFC 8437 IMAP UNAUTHENTICATE for Connection Reuse August 2018
565+
566+
567+
Appendix A. Design Considerations
568+
569+
The author deliberately chose to add a separate UNAUTHENTICATE
570+
command instead of allowing the LOGIN or AUTHENTICATE commands to be
571+
issued when the connection is in a state other than unauthenticated.
572+
The primary reason for this choice is that the code that transitions
573+
from not authenticated state to authenticated state in a server is
574+
often the most security-sensitive code, because it needs to assume
575+
and handle unconditionally hostile attackers. That sensitive code is
576+
simpler if it only handles a single server state (unauthenticated)
577+
and the state transition is as simple as possible. Smaller and
578+
simpler code is easier to audit and write in a secure way.
579+
580+
A secondary reason to have a separate command is that it is simpler
581+
to enable or disable the feature with that design. See the
582+
discussion in the Security Considerations section recommending that
583+
implementations provide a way to disable this extension.
584+
585+
Acknowledgements
586+
587+
Thanks to Fred Batty for implementing UNAUTHENTICATE and to Cyrus
588+
Daboo for constructive suggestions to improve this document.
589+
590+
Author's Address
591+
592+
Chris Newman
593+
Oracle
594+
440 E. Huntington Dr., Suite 400
595+
Arcadia, CA 91006
596+
United States of America
597+
598+
Email: chris.newman@oracle.com
599+
600+
601+
602+
603+
604+
605+
606+
607+
608+
609+
610+
611+
612+
613+
614+
615+
616+
617+
618+
Newman Standards Track [Page 11]
619+

0 commit comments

Comments
 (0)
Please sign in to comment.