search

ietf-wg-emailcore / emailcore

3 stars 0 forks source link

Recommendation about timezones to use in Date and Received header fields #66

Closed aamelnikov closed 10 months ago

aamelnikov commented 2 years ago

Discussion on the mailing list about use of -00:00 timezone resulted in the following suggestion:

Recommendations about what time zones should be chosen for a given message, either in the "Date:" header field or in the various other fields, notably trace fields, in which time-stamps are applied and/or what receiving systems should do about them.

ksmurchison commented 2 years ago

@aamelnikov I just read the thread and didn't see consensus on what the recommendations should be. Can you provide a link? Or are we talking about the use of -0000? I didn't see consensus on resurrecting UT

aamelnikov commented 1 year ago

Now that I reread the ticket I am not sure. I agree about no consensus to resurrect "UT" so far.

Please post a message to the mailing list, asking what we want to say (if anything) about "-0000".

ksmurchison commented 1 year ago

@aamelnikov After reading the current thread for this issue, it looks like Levine/Klensin would like for text to be added/clarified in 5322bis and leave the A/S alone. Do you agree? If not, I'm not sure I have been able to distill out any suggested text for the A/S.

toddherr commented 10 months ago

Get consensus on list to close ticket. Topic discussed in 5322bis section 3.3.

toddherr commented 10 months ago

Working group was notified on list on 30 November 2023 of intent to close this issue unless a lack of consensus for closing was demonstrated on list. That post drew no replies by the stated deadline of 8 December 2023, so therefore this issue is closed.

klensin commented 10 months ago

Just for the historical record should anyone come back and look at this ticket/thread... while the "Received" field is defined in RFC 821 --- 5321, the definition of that time-stamp in 5321/5321bis explicitly points to 5322/5322bis for its definition. So closing this as described above does not create or leave any loose ends.