Here is attached a list of obsoleted RFCs referred in the *.rst, *.txt, *.py, *.c and *.h files. I think it would be worthwhile to update the source code and documentation for more modern RFCs. For example for updating RFC3548 to RFC4648 there is an issue #16995.
2013/6/8 Serhiy Storchaka <storchaka@gmail.com>:
Here is attached a list of obsoleted RFCs referred in the *.rst, *.txt, *.py, *.c and *.h files. I think it would be worthwhile to update the source code and documentation for more modern RFCs.
Just because you change the reference, doesn't mean the code is automatically compliant with the updated RFC. :)
For example for updating RFC3548 to RFC4648 there is an issue #16995.
-- Regards, Benjamin
08.06.13 11:23, Benjamin Peterson написав(ла):
2013/6/8 Serhiy Storchaka <storchaka@gmail.com>:
Here is attached a list of obsoleted RFCs referred in the *.rst, *.txt, *.py, *.c and *.h files. I think it would be worthwhile to update the source code and documentation for more modern RFCs.
Just because you change the reference, doesn't mean the code is automatically compliant with the updated RFC. :)
Of course. Maintainers should review his modules and conclude what should be made for supporting more modern RFCs. I'm surprised that even new ipaddress module uses obsoleted RFC.
On 2013-06-08 10:59, Serhiy Storchaka wrote:
08.06.13 11:23, Benjamin Peterson ... :
2013/6/8 Serhiy Storchaka ... :
Here is attached a list of obsoleted RFCs referred in the *.rst, *.txt, *.py, *.c and *.h files. I think it would be worthwhile to update the source code and documentation for more modern RFCs.
Just because you change the reference, doesn't mean the code is automatically compliant with the updated RFC. :)
Of course. Maintainers should review his modules and conclude what should be made for supporting more modern RFCs.
I'm surprised that even new ipaddress module uses obsoleted RFC.
I for one am not :-) Let's pick that one ... as it seems to depend on the perspective chosen (web docs vs. python code comments) (cf. Details) Summary: Besides the magic, that lies in the process that transforms the documentation inside the python source into the web presented form, it should be easy and semantically correct, to simply replace the two occurences of "RFC 3513 2.5.6" with "RFC 4291 2.5.7". Details: The current web doc (3.4.0a0) at http://docs.python.org/dev/library/ipaddress#ipaddress.IPv6Address only shows this (no RFC3513 in sight): """ The following constitutes a valid IPv6 address: 1. A string consisting of ... See RFC 4291 for details. ... """ the current source at Lib/ipaddress.py you checked has: # --- 8< ----- ------ ------- ------ ---- ------- ----- ------ ---- class IPv6Network(_BaseV6, _BaseNetwork): # ... snipped methods, reformatted, shortened ... @property def is_site_local(self): """Test if the address is reserved for site-local. Note that the site-local address space has been deprecated by RFC 3879. Use is_private to test if this address is in the space of unique local addresses as defined by RFC 4193. Returns: A boolean, True if the ad... is res... per RFC 3513 2.5.6. """ sitelocal_network = IPv6Network('fec0::/10') return self in sitelocal_network # --- 8< ----- ------ ------- ------ ---- ------- ----- ------ ---- and later: # --- 8< ----- ------ ------- ------ ---- ------- ----- ------ ---- class IPv6Network(_BaseV6, _BaseNetwork): # ... again snipped methods, reformatted, shortened ... @property def is_site_local(self): """Test if the address is reserved for site-local. Note that the site-local address space has been deprecated by RFC 3879. Use is_private to test if this address is in the space of unique local addresses as defined by RFC 4193. Returns: A boolean, True if the ad... is res... per RFC 3513 2.5.6. """ return (self.network_address.is_site_local and self.broadcast_address.is_site_local) # --- 8< ----- ------ ------- ------ ---- ------- ----- ------ ---- The RFC 3513 (April 2003) has been obsoleted by RFC 4291 (February 2006) and the latter has been updated by RFC 5952 (August 2010) and RFC 6052 (October 2010). The given motivation for referencing inside the python source file is in both cases the detailed specification of what a reserved address actaully is. Looking at RFC 3513 has at section 2.5.6 (the referenced one): # --- 8< ----- ------ ------- ------ ---- ------- ----- ------ ---- 2.5.6 Local-Use IPv6 Unicast Addresses There are two types of local-use unicast addresses defined. These are Link-Local and Site-Local. The Link-Local is for use on a single link and the Site-Local is for use in a single site. Link-Local addresses have the following format: | 10 | | bits | 54 bits | 64 bits | +----------+-------------------------+----------------------------+ |1111111010| 0 | interface ID | +----------+-------------------------+----------------------------+ Link-Local addresses are designed to be used for addressing on a single link for purposes such as automatic address configuration, neighbor discovery, or when no routers are present. Routers must not forward any packets with link-local source or destination addresses to other links. Site-Local addresses have the following format: | 10 | | bits | 54 bits | 64 bits | +----------+-------------------------+----------------------------+ |1111111011| subnet ID | interface ID | +----------+-------------------------+----------------------------+ Site-local addresses are designed to be used for addressing inside of a site without the need for a global prefix. Although a subnet ID may be up to 54-bits long, it is expected that globally-connected sites will use the same subnet IDs for site-local and global prefixes. Routers must not forward any packets with site-local source or destination addresses outside of the site. # --- 8< ----- ------ ------- ------ ---- ------- ----- ------ ---- The obsoleting RFC 4291 has separated the description of Link-Local and Site-Local IPv6 Unicast adresses, thus if the section 2.5.6 reference for the is_site_local method was correct from the start - which seems to be a quite reasonable assumption - then the new section level reference should be "RFC 4291 2.5.7": # --- 8< ----- ------ ------- ------ ---- ------- ----- ------ ---- 2.5.7. Site-Local IPv6 Unicast Addresses Site-Local addresses were originally designed to be used for addressing inside of a site without the need for a global prefix. Site-local addresses are now deprecated as defined in [SLDEP]. Site-Local addresses have the following format: | 10 | | bits | 54 bits | 64 bits | +----------+-------------------------+----------------------------+ |1111111011| subnet ID | interface ID | +----------+-------------------------+----------------------------+ The special behavior of this prefix defined in [RFC3513] must no longer be supported in new implementations (i.e., new implementations must treat this prefix as Global Unicast). Existing implementations and deployments may continue to use this prefix. # --- 8< ----- ------ ------- ------ ---- ------- ----- ------ ---- But there seems to be a problem when actually using Site-Local addresses, as the new RFC (deviating from the obsoleted one) states (c.f. above): """ Site-local addresses are now deprecated as defined in [SLDEP]. """ Otherwise as a format reference all is well. The updateing RFCs seem to not interfere with the detail pointed to (by trusting the relation between title and content :-): [RFC5952] "A Recommendation for IPv6 Address Text Representation" [RFC6052] "IPv6 Addressing of IPv4/IPv6 Translators" All the best, Stefan.
Serhiy Storchaka writes:
08.06.13 11:23, Benjamin Peterson написав(ла):
2013/6/8 Serhiy Storchaka <storchaka@gmail.com>:
Here is attached a list of obsoleted RFCs referred in the *.rst, *.txt, *.py, *.c and *.h files. I think it would be worthwhile to update the source code and documentation for more modern RFCs.
Just because you change the reference, doesn't mean the code is automatically compliant with the updated RFC. :)
Of course. Maintainers should review his modules and conclude what should be made for supporting more modern RFCs.
I suspect in many cases the answer is going to be "nothing". Grepping out the references and checking for obsoleted RFCs is useful information, of course. Good GSoC fodder, for one thing. But I'd be cautious about even creating an issue without consideration of each case individually. This can be a *lot* of work, for very little gain. In the case of mail, consider that STD 11 still points to RFC 822![1] Also, even the most modern RFC 5322 REQUIREs parsers to accept the "obsolete" syntax of section 4, which I believe is that of RFC 822. In any case, it's pretty close. So you wouldn't want to change the parser anyway. Whether it would be worth auditing the generative functions for 5322 conformance, and creating tests, is a more difficult question, but it still sounds like much work for little gain. The analysis is surely different for other RFCs, but for this particular series I see little harm in letting each component of the email module continue to explicitly target whichever of the RFCs happened to be current when its author started coding. Footnotes: [1] http://tools.ietf.org/html/std11
On 08.06.2013 09:45, Serhiy Storchaka wrote:
Here is attached a list of obsoleted RFCs referred in the *.rst, *.txt, *.py, *.c and *.h files. I think it would be worthwhile to update the source code and documentation for more modern RFCs.
Thanks for creating such a list. BTW: What is rfcuse.txt that's mentioned several times in the list ?
For example for updating RFC3548 to RFC4648 there is an issue #16995.
Given that more recent RFCs tend to introduce new functionality and sometimes backwards incompatible changes, I think each RFC update would need to be handled in a separate ticket. Some updates could probably be done in one go, e.g. RFC 821 -> 2821 -> 5321 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 08 2013)
Python Projects, Consulting and Support ... http://www.egenix.com/ mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
2013-07-01: EuroPython 2013, Florence, Italy ... 23 days to go 2013-07-16: Python Meeting Duesseldorf ... 38 days to go ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
08.06.13 11:42, M.-A. Lemburg написав(ла):
On 08.06.2013 09:45, Serhiy Storchaka wrote:
Here is attached a list of obsoleted RFCs referred in the *.rst, *.txt, *.py, *.c and *.h files. I think it would be worthwhile to update the source code and documentation for more modern RFCs.
Thanks for creating such a list.
BTW: What is rfcuse.txt that's mentioned several times in the list ?
Oh, sorry. It is here by mistake. Just ignore it.
For example for updating RFC3548 to RFC4648 there is an issue #16995.
Given that more recent RFCs tend to introduce new functionality and sometimes backwards incompatible changes, I think each RFC update would need to be handled in a separate ticket.
Some updates could probably be done in one go, e.g. RFC 821 -> 2821 -> 5321
Of course. This list is only a start point.
On Sat, 08 Jun 2013 12:51:23 +0300, Serhiy Storchaka <storchaka@gmail.com> wrote:
08.06.13 11:42, M.-A. Lemburg написав(ла):
On 08.06.2013 09:45, Serhiy Storchaka wrote:
Here is attached a list of obsoleted RFCs referred in the *.rst, *.txt, *.py, *.c and *.h files. I think it would be worthwhile to update the source code and documentation for more modern RFCs.
Given that more recent RFCs tend to introduce new functionality and sometimes backwards incompatible changes, I think each RFC update would need to be handled in a separate ticket.
Some updates could probably be done in one go, e.g. RFC 821 -> 2821 -> 5321
Of course. This list is only a start point.
We've already done some (most?) of the work for the smtplib update. A thorough review is needed to make sure there aren't any leftovers and to update any comments and docs that haven't been fixed yet. For the email package, the support for RFC 5322 is mostly done, in the new policies. The legacy policies will continue to only support the older RFCs formally, though in many cases the code is also conformant with the newer RFCs because the relevant details have not changed. --David
By mistake some local files were added to the list. Here's an updated list. It now also contains low-case references. Attached also a script used to generate this list.
participants (6)
-
Benjamin Peterson -
M.-A. Lemburg -
R. David Murray -
Serhiy Storchaka -
Stefan Drees -
Stephen J. Turnbull