On 23/09/2020 07:16, Fernando Pereñíguez García wrote:
Hi Tero,
Thank you very much for your clarification. We will update reference RFC
822 accordingly in our draft.
Tom, you proposed us to replace RFC 822 with 2822, but it is also obsoleted
by 5322. So, if you agree, we will reference RFC 5322 instead.
That is fine by me; my comment was that RFC822 is obsoleted by RCC2822
so you should consider a more up-to-date version not that RFC2822 was
the correct update!
You said previously that you did not understand my comment on RFC6020 in
IANA Considerations. It is fine. What I was trying to say is that in
most places, RFC7950 is the better reference so RFC6020 should not be
used but for IANA Considerations, RFC6020 is the better reference so
when updating elsewhere in the I-D, leave IANA Considerations alone.
Tom Petch
Best regards,
Fernando.
El mar., 22 sept. 2020 a las 19:50, Tero Kivinen (<kivinen@xxxxxx>)
escribió:
Fernando Pereñíguez García writes:
I note that RFC822 and RFC3280 are Obsoleted which makes their use
problematic.
[Authors] Following your recommendation, we have replaced RFC 3280 with
RFC
5280. Regarding RFC 822, we reference it because the IKEv2 protocol
specification (RFC 7296) explicitly defines RFC 822 emails address (see
page
90) as a valid identification type. If we replace RFC 822 with RFC 2821,
we
don't know its impact on IKEv2.
IKEv2 talks about RFC 822 email addresses, the reference points
Internationalized Email Headers RFC 6532, with comment of:
Because of [EAI], implementations would be wise to treat this
field as UTF-8 encoded text, not as pure ASCII.
So it uses RFC822 as name not as reference. There should not be any
problems to replace that with newer versions. Most of the
implementations simply consider that as a string and some cases they
actually do not even follow the string email address format, as they
add some routing information for AAAA in the end or something.
--
kivinen@xxxxxx
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
