RE: [Fed-Talk] PKI SIGNED E-MAIL
RE: [Fed-Talk] PKI SIGNED E-MAIL
- Subject: RE: [Fed-Talk] PKI SIGNED E-MAIL
- From: "Coradeschi, Tom CIV USA" <email@hidden>
- Date: Tue, 08 Nov 2011 08:14:18 -0500
- Thread-topic: [Fed-Talk] PKI SIGNED E-MAIL
IIRC the whole case sensitivity issue in the local-part has roots in
history. Back In The Day(tm), I am thinking that VMS based systems,
perhaps, were quite literal about case and so forth.
That being said, anyone can propose a new or updated RFC, as I
understand it. Getting it accepted? Who knows...
http://www.rfc-editor.org/pubprocess.html
Tom Coradeschi
Chief, Systems Engineering & Technology Integration Div
PM Maneuver Ammunition Systems
NIPR: email@hidden SIPR: email@hidden
973-724-4344 (ofc) 862-251-3089 (cell)
-----Original Message-----
From: fed-talk-bounces+tom.coradeschi=email@hidden
[mailto:fed-talk-bounces+tom.coradeschi=email@hidden] On
Behalf Of Miller, Timothy J.
Sent: Tuesday, November 08, 2011 7:59 AM
To: Walls, Bryan K. (MSFC-EO50); Shawn Geddis
Cc: Fed Talk
Subject: Re: [Fed-Talk] PKI SIGNED E-MAIL
On 11/7/11 2:43 PM, "Walls, Bryan K. (MSFC-EO50)" <email@hidden>
wrote:
>I don't argue that Apple is wrong to enforce the RFP, but in this case
>the RFP is wrong. In practice no one thinks email@hidden and
>email@hidden are completely separate addresses. It could have gone
>that way, but it didn't. The RFP should be changed, but as far as I can
>tell no one considers that their job.
You'd likely get nowhere in the NWG because the semantics of the
local-part is entirely up to the endpoint. IOW, if *your* MTA wants to
bryan.walls the same as Bryan.Walls, it is free to do so. But someone
else with a compelling reason to treat them differently needs the same
freedom.
IETF doesn't function quite like other standards bodies. It's a
gentleman's agreement to do just enough to get "things" working at the
connections between networking domains; it is *not* a set of mandatory
specifications. Encoding case-sensitivity into the specification would
make a choice on the issue that doesn't need to be made (things work as
it
stands) and therefore isn't IETF responsibility.
-- T
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
.mil
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden