Subject: [apps-discuss] draft-yevstifeyev-pop-wrong-state

From: Pete Resnick <[email-masked]>
Date: Sun, 21 Aug 2011 12:26:51 -0500

Greetings all,

[Non-WG item]

The ISE received  draft-yevstifeyev-pop-wrong-state to publish as an 
Experimental document in the Independent RFC submission stream and has 
asked me to check on its suitability. Two questions for the list:

1. Is there significant interest in implementing this POP response code 
extension? I ask because, if there is, it might be more appropriate to 
bring this into some Applications working group.

2. If there isn't widespread interest, does anyone see any harm in this 
being published as Experimental in the Independent stream? It seems to 
me a very simple extension with little significant impact.

Thoughts welcome.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: Barry Leiba <[email-masked]>
Date: Tue, 23 Aug 2011 13:00:29 -0400

> extension? I ask because, if there is, it might be more appropriate to bring
> this into some Applications working group.

I can't imagine that there'll be a lot of interest.  POP clients and
servers have been interoperating well for a good many years without
this response code, and I don't see folks lining up to rev their code
for something that basically amounts to servers helping new clients
debug their bad implementations.

> being published as Experimental in the Independent stream? It seems to me a
> very simple extension with little significant impact.

It appears to me to be fairly useless, but totally harmless.  I think
it's a waste of time, but I otherwise have no objection to it.

Barry

---

From: Chris Newman <[email-masked]>
Date: Tue, 23 Aug 2011 23:25:01 -0700

> debug their bad implementations.

POP clients do not interoperate well when using TLS client certificate 
authentication on port 995. This might have been useful if the discussion 
around draft-melnikov-pop3-over-tls-01.txt had a different outcome, but I 
do not view it as particularly useful presently.

> it's a waste of time, but I otherwise have no objection to it.

I'd call it "mostly harmless" :-). If a server implementation tries to be 
helpful prior to authentication, that might increase the code attack 
surface albeit by very little. But the draft does not require that 
behavior. Non-standards track RFCs do end up in RFPs sometimes and this one 
might fall in the category of "easier to implement than to try to correct a 
bad RFP". So it could end up wasting implementer time, albeit not very much.

I have no objections to going ahead with this. If someone is motivated to 
do specification work I do not like to discourage them with a hard 
rejection and it's helpful for them to learn the hard way that publishing 
an RFC does not result in useful deployment ;-).

		- Chris