Hi John,
At 13:24 13-10-2009, John C Klensin wrote:
Before trying to embark on an in-depth review of this long and
complex document, could the IESG explain to the community why it
is being processed as a Proposed Standard? After reading
quickly through its first few pages, and despite containing a
standard IPR clause rather than a "no derivative rights other
than to publish" one, it appears to be a translation and
adaptation of an existing national standard and set of
regulations, with no provisions for transferring change control
to the IETF, etc.
From what I understand, this "document describes PEC's technical
aspects and features" (see Section 1.1). This is more about
documenting an existing "Italian Standard" than the usual "Standard
Track" approach where changes can be suggested and change control
transferred to the IETF. I don't believe that this document belongs
on the Standard Track; not in its current shape anyway.
Quoting the publication request:
"The PEC concept was pitched to the SMIME WG at IETF 71. Numerous
questions were asked and answered to the satisfaction of the WG."
It may seem like the document is about S/MIME. However, most of the
specification, in my opinion, relates to RFC 5321 and RFC 5322. The
document re-purposes some email concepts.
From Section 2.1:
"Both "From:" and "Sender:" fields MUST contain the same value."
Quoting Section 3.6.2 of RFC 5322:
"The "Sender:" field specifies the mailbox of the agent responsible
for the actual transmission of the message."
That's not to be confused with the author of a message.
In Section 3.1.1:
"sender's address, specified in the SMTP reverse path, coincides
with the one in the message's "From:" field;"
The address in the reverse path doesn't always coincide with the
address from the "From:" header field.
These are quick comments and should not be considered as a review of
the draft. Publishing this document as a Proposed Standard will be
considered as an encouragement for other governments to adopt a
similar model. There isn't even an Internationalization
Considerations section in this draft. The Security Considerations is
sparse. It will seem, to the reader, like PEC avoids the complexity
of end-to-end systems while offering a lower, yet acceptable level of
security to guarantee sender identity, message integrity,
confidentiality, and non-repudiation of origin. I pointed out to the
authors of this draft in June 2009 that as a closed system, PEC may work fine.
This draft could certainly do with wider review. How can there be no
IANA considerations when several (X-) headers are defined? Speaking
of which, from Section 3.3.3:
"The header will contain the following fields:
X-Ricevuta: errore-consegna
Date: [date of notification emission]
Subject: AVVISO DI MANCATA CONSEGNA: [original subject]
From: certified-mail@[mail_domain]
To: [original sender]
X-Riferimento-Message-ID: [Message-ID of original message]
The notification body is composed of readable text according to a
model that relates the following data:
Non-delivery PEC notification
On [date] at [time] ([time zone]), in the message "[subject]"
originating from "[original sender]" and addressed to
"[recipient]"
an error was detected.
The message was refused by the system.
Message identification: [Message-ID]"
That looks odd given the header fields are in Italian. Does the
Italian Posta Elettronica Certificata specifications actually
recommend the English text in the notification body?
Regards,
-sm
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf