Subject: [Uri-review] Request to review the 'pops' URI scheme registration.

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sun, 13 Feb 2011 08:03:09 +0200

Hello,

In accordance with RFC 4395, Section 5.2, I am writing to request the 
review of the 'pops' URI scheme registration.  This scheme is used to 
designate the access to POP3 mailboxes over TLS connection.

You may find the appropriate draft here: 
http://tools.ietf.org/html/draft-yevstifeyev-pops-uri-scheme-00

Thank you fore your time,
Mykyta Yevstifeyev

---

From: Graham Klyne <[email-masked]>
Date: Mon, 14 Feb 2011 10:46:35 +0000

I note that pops: defaults to port 110, the same as regular pop.  I therefore 
assume that the use of a secure channel is determined by a protocol interaction 
within the POP connection.

This leaves me wondering why a separate URI scheme is needed.  It may be that 
I'm missing something, but I'd think that at least the document needs to say a 
little more than it does about the relationship to pop: and the normal POP protocol.

I'd also point out that this is more than just "In accordance with RFC 4395" - 
it is a proposal for a standards-track protocol update - it's going to need more 
than review on this URI-review list to get published.

#g
--

Mykyta Yevstifeyev wrote:
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Uri-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uri-review

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Mon, 14 Feb 2011 20:07:09 +0200

14.02.2011 12:46, Graham Klyne wrote:
> I note that pops: defaults to port 110, the same as regular pop.  I 
> therefore assume that the use of a secure channel is determined by a 
> protocol interaction within the POP connection.
That may be found in RFC 2595.
>
> This leaves me wondering why a separate URI scheme is needed.  It may 
> be that I'm missing something, but I'd think that at least the 
> document needs to say a little more than it does about the 
> relationship to pop: and the normal POP protocol.
Thia is described in the aforementioned doc., that is referenced 
normatively here.
>
> I'd also point out that this is more than just "In accordance with RFC 
> 4395" - it is a proposal for a standards-track protocol update - it's 
> going to need more than review on this URI-review list to get published.
I'll also ask for review possibly on MORG list.

Mykyta Yevstifeyev

---

From: Eric Johnson <[email-masked]>
Date: Mon, 14 Feb 2011 10:45:13 -0800

Hmmm. Don't know why this caught my attention, but I see some points to 
raise:

I concur with Graham - I don't see the need for a separate scheme. This 
seems to have been anticipated by section 7 of 2595, which you reference.

Section 7 of 2595 in fact raises the very reasons why a separate scheme 
might be undesirable: About ports:

"Separate ports lead to a separate URL scheme which intrudes into the 
user interface in inappropriate ways.  For example, many web pages use 
language like "click here if your browser supports SSL." This is a 
decision the browser is often more capable of making than the user."

... since the point is that introducing a new scheme is problematic, 
what's the implementation experience that works as a counterpoint to 
this very argument?

There seems to be a normative SHOULD here that the user agent collect 
password information before engaging the protocol. This isn't motivated 
at all.

Section 2 of your draft (presumably) restates syntax from 2384, but that 
is either unnecessary, or confusing, because implementers will then need 
to check for differences. If 2384 is ever updated, these could 
potentially be inconsistent.

Most importantly, this draft discusses no implementation experience that 
suggests that there's a problem that would be solved by the introduction 
of this new scheme.

-Eric.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 15 Feb 2011 10:31:57 +0000

Hi Mykyta,

First of all, thanks for doing this draft (For the record: I've asked 
Mykyta to work on it.)

> That may be found in RFC 2595.

I think I agree with Graham here. Use of STLS with POP3 (on port 110) 
doesn't need a new URI scheme, because a POP3 client can always 
negotiate STLS, if it is advertised by the corresponding POP3 server. If 
use of STLS is mandatory, then it would be better to extend the existing 
pop:// URIs to require STLS (e.g. by extending <auth> ABNF production or 
one of its sub-productions).

What I think actually needs a new URI scheme is use of POP3 over TLS on 
a separate port 995. In such case the STLS command is not used and TLS 
negotiation starts immediately after connecting to the port 995. So this 
is similar to how "https" works.
For this variant of POP RFC 2595 is a wrong reference.

>> I'd also point out that this is more than just "In accordance with 
>> RFC 4395" - it is a proposal for a standards-track protocol update - 
>> it's going to need more than review on this URI-review list to get 
>> published.
>

IMHO, it is a wrong place for POP3 related discussions. There used to be 
a POP3 mailing list on imc.org, but I don't know how used it is now. 
apps-discuss is probably a better place for this discussion.

>>> In accordance with RFC 4395, Section 5.2, I am writing to request 
>>> the review of the 'pops' URI scheme registration.  This scheme is 
>>> used to designate the access to POP3 mailboxes over TLS connection.
>>>