Re: Last Call: draft-gennai-smime-cnipa-pec (Certified Electronic Mail) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]