[Django] #36131: URLValidator not correctly validating URLs

[Django]

#36131: URLValidator not correctly validating URLs
-------------------------------+----------------------------------------
Reporter: Ludwig Kraatz | Type: Bug
Status: new | Component: Core (Other)
Version: 5.1 | Severity: Normal
Keywords: URL Validator | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------+----------------------------------------
== Abstract

An URL is a way of describing a Resource.

https://resource -> is a valid URL.

== Why do i raise this as issue

An URL resource-descriptor is constructed like that [RFC 3986#section-3]:

{{{
foo://example.com:8042/over/there?name=ferret#nose
\_/ \______________/\_________/ \_________/ \__/
| | | | |
scheme authority path query fragment
}}}

so: scheme, authority, rest...

The issue in djangos URLValidation I want to address, is a over-
specification and 'selective circumvention of wrongful parsing' when it
comes to the -host- compnent of the authority part.

What djangos URLValidator currently does:
host_re = "( FQDN-REGEX | localhost )"

Basically, django parses IP-OR-FQDN-OR-LOCALHOST-URLs.

This is basically the 'selective circumvention of wrongful parsing' i
mentioned earlier. By ”| localhost" the URL field "feels" more okay,
because all the obvious URLs on localhost that exist, now pass. But there
is so much more than "localhost" besides FQDN as used for "(global) DNS
URLs".

The RFC also acknowledges this. It is recommending using a syntax for
hosts that conforms to the DNS syntax.

[https://datatracker.ietf.org/doc/html/rfc3986#section-3.2.2]
{{{
A host identified by a registered name is a sequence of characters
usually intended for lookup within a locally defined host or service
name registry, though the URI's scheme-specific semantics may require
that a specific registry (or fixed name table) be used instead. The
most common name registry mechanism is the Domain Name System (DNS).
A registered name intended for lookup in the DNS uses the syntax

defined in Section 3.5 of [RFC1034] and Section 2.1 of [RFC1123].
Such a name consists of a sequence of domain labels separated by ".",
each domain label starting and ending with an alphanumeric character
and possibly also containing "-" characters. The rightmost domain
label of a fully qualified domain name in DNS may be followed by a
single "." and should be if it is necessary to distinguish between
the complete domain name and some local domain.

reg-name = *( unreserved / pct-encoded / sub-delims )

If the URI scheme defines a default for host, then that default
applies when the host subcomponent is undefined or when the
registered name is empty (zero length). For example, the "file" URI
scheme is defined so that no authority, an empty host, and
"localhost" all mean the end-user's machine, whereas the "http"
scheme considers a missing authority or empty host invalid.

This specification does not mandate a particular registered name
lookup technology and therefore does not restrict the syntax of reg-
name beyond what is necessary for interoperability. Instead, it
delegates the issue of registered name syntax conformance to the
operating system of each application performing URI resolution, and
that operating system decides what it will allow for the purpose of
host identification. A URI resolution implementation might use DNS,
host tables, yellow pages, NetInfo, WINS, or any other system for
lookup of registered names. However, a globally scoped naming
system, such as DNS fully qualified domain names, is necessary for
URIs intended to have global scope. URI producers should use names
that conform to the DNS syntax, even when use of DNS is not
immediately apparent, and should limit these names to no more than
255 characters in length.
}}}
What is said in many ways:
- local host resolution is completely okay.
- no "." is required // as, a sequence (which is not further specified to
length restrictions) can consist of 1, which would lack a "." seperator
- host names that are -compatible-, are valid.


[RFC 6762 Multicast DNS # Section 3]
{{{
It is unimportant whether a name ending with ".local." occurred
because the user explicitly typed in a fully qualified domain name
ending in ".local.", or because the user entered an unqualified
domain name and the host software appended the suffix ".local."
because that suffix appears in the user's search list.
}}}
It is stated clearly, that a user can describe a resource with the
implication, that if its not a fully qualified domain name, the TLD .local
is to be assumed. As such - the URL, which is what the user would be
referencing, was to be able to deal with more non-FQDN than just
"localhost". This is in the context of Multicast DNS, which seems more
than close enough to be considered relevant, when talking about URLs - as
the URL RFC was so closely described around DNS.

[RFC 3986 URI/URL # 1.1]
{{{
URIs that
identify in relation to the end-user's local context should only be
used when the context itself is a defining aspect of the resource,
such as when an on-line help manual refers to a file on the end-
user's file system (e.g., "file:///etc/hosts").
}}}
- clearly states, that URI's are valid, even if they clearly only 'make
sense' in a end-users local context.
As such - restricting django URLs to only Fully Qualified Domain
Names/IPs, (except localhost.. for whatever reason except inconsitency :-*
) - is a restriction that contradicts that notion.

== What i am proposing:

fully allowing for URLs as per rfc3986#section-3.2.2 - with a regex
solution for localhost (and whatever else is possible) instead of a
hardcoded < "magicnumber"-80%-"solution" >

To be Commited to django repository and pull requested. My earlier pull
request is more - a starting point for discussion.


== Why this is necessary & usefull:

Single-label URLs might be used
- in intranet situations
- for URLs that represent services / schemes that do not comply to
FQDNaming conventions
- for local testing (local DNS resolution that is not based on FQDN)
- mDNS [RFC 6762] solutions, operating under .local TLD (which as of that
RFC can be ommitted in a local context)
- the django validator is named URLValidator, not
FQDN_IP_LOCALHOST_URLValidator

== Further notes:

i already submitted a pull request - which probably isn't mature enough..
given i did not even check which tests would break..

but - there was one test, that should not have broken:

FAIL: test_urlfield_clean_invalid
(forms_tests.field_tests.test_urlfield.URLFieldTest.test_urlfield_clean_invalid)
[<object object at 0x000001C1038C1760>] (value='foo')

URL <= "foo" should not be valid, even with my little changes, replacing
'localhost' with hostname_re

It feels like there are some (- -) missing - but i did not check.. i
focused on providing a more solid ticket first..
So - if i am not mistaken, there is another issue besides what i propose.
It seems, limiting hosts via FQDN was the thing, preventing missing URI-
scheme's to be rejected by the validator, not a correct validation of uri-
schemes themselves.

== PS

its kindof late - i might polish this ticket tomorrow. if you feel like
i'm drunk or disorganized - its just my brain thats screaming for relief.
sry.
--
Ticket URL: <https://code.djangoproject.com/ticket/36131>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

[Django]

#36131: URLValidator not correctly validating URLs
-------------------------------+--------------------------------------

Reporter: Ludwig Kraatz | Owner: (none)

Type: Bug | Status: new
Component: Core (Other) | Version: 5.1

Severity: Normal | Resolution:

Keywords: URL Validator | Triage Stage: Unreviewed

Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1

Easy pickings: 1 | UI/UX: 0
-------------------------------+--------------------------------------

Changes (by Ludwig Kraatz):

* has_patch: 0 => 1
* needs_better_patch: 0 => 1

Comment:

[https://github.com/django/django/pull/19095]
--
Ticket URL: <https://code.djangoproject.com/ticket/36131#comment:1>

[Django]

#36131: URLValidator not correctly validating URLs
-------------------------------+--------------------------------------
Reporter: Ludwig Kraatz | Owner: (none)
Type: Bug | Status: new
Component: Core (Other) | Version: 5.1
Severity: Normal | Resolution:
Keywords: URL Validator | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 1 | UI/UX: 0
-------------------------------+--------------------------------------

Comment (by Ludwig Kraatz):

[https://github.com/django/django/pull/19096]

Test cofirmed: URL Validation fails for "localhost" => which will be
accepted, even though its not a valid URL. (it lacks scheme://)

Bottom line: whole regEx / Validation seems off on multiple layers.
--
Ticket URL: <https://code.djangoproject.com/ticket/36131#comment:2>

[Django]

#36131: URLValidator not correctly validating URLs

-------------------------------+-----------------------------------------
Reporter: Ludwig Kraatz | Owner: Ludwig Kraatz
Type: Bug | Status: assigned

Component: Core (Other) | Version: 5.1
Severity: Normal | Resolution:
Keywords: URL Validator | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 1 | UI/UX: 0

-------------------------------+-----------------------------------------
Changes (by Antoliny):

* owner: (none) => Ludwig Kraatz
* status: new => assigned

--
Ticket URL: <https://code.djangoproject.com/ticket/36131#comment:3>

[Django]

#36131: URLValidator not correctly validating URLs
-------------------------------+-----------------------------------------
Reporter: Ludwig Kraatz | Owner: Ludwig Kraatz

Type: Bug | Status: closed

Component: Core (Other) | Version: 5.1

Severity: Normal | Resolution: invalid

Keywords: URL Validator | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 1 | UI/UX: 0
-------------------------------+-----------------------------------------

Changes (by Sarah Boyce):

* resolution: => invalid
* status: assigned => closed

Comment:

This is rather hard to follow, `http://localhost` is a valid url and
passes. `localhost` is not a valid url and fails. I do not follow the
reasoning that there is an issue
--
Ticket URL: <https://code.djangoproject.com/ticket/36131#comment:4>

[Django]

#36131: URLValidator not correctly validating URLs
-------------------------------+-----------------------------------------
Reporter: Ludwig Kraatz | Owner: Ludwig Kraatz
Type: Bug | Status: closed
Component: Core (Other) | Version: 5.1
Severity: Normal | Resolution: invalid
Keywords: URL Validator | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 1 | UI/UX: 0
-------------------------------+-----------------------------------------

Comment (by Ludwig Kraatz):

hello=??

https://github.com/django/django/pull/19096

look at your own test cases. {{{localhost}}} is being allowed, even though
we agree it should not. so that issue stands as it is. Your current code
contradicts your own statement. It stands on its own - and has nothing
really to do with this ticket on its own. so why you close it with that
rational after it has been assigned to me - sry, i dont get it.

My ticket, initially, was about {{{http://somethingOtherThanLocalhost}}}
-> is valid as well. But is falsefully rejected by the URLvalidator.

Both issues combined say: The whole RegEx URLValidator logic is off.
as mentioned - on multiples layers

1. the issue of not conforming to reality, by not allowing
{{{https://resource}}} or {{{https://printer}}} or whatever 'local' but
non-localhost resource is to be referenced.
2. the issue of being a wrong regex, as it allows things that are clearly
not to be allowed.

please take some more time to reconsider closing this ticket in a hurry -
this is not thought through.
--
Ticket URL: <https://code.djangoproject.com/ticket/36131#comment:5>

[Django]

#36131: URLValidator not correctly validating URLs
-------------------------------+-----------------------------------------
Reporter: Ludwig Kraatz | Owner: Ludwig Kraatz
Type: Bug | Status: closed
Component: Core (Other) | Version: 5.1
Severity: Normal | Resolution: invalid
Keywords: URL Validator | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 1 | UI/UX: 0
-------------------------------+-----------------------------------------
Comment (by Ludwig Kraatz):

Replying to [comment:4 Sarah Boyce]:

> This is rather hard to follow, `http://localhost` is a valid url and
passes. `localhost` is not a valid url and fails. I do not follow the
reasoning that there is an issue

i have to correct you here:

{{{localhost}}} is not valid but passes.
--
Ticket URL: <https://code.djangoproject.com/ticket/36131#comment:6>

[Django]

#36131: URLValidator not correctly validating URLs
-------------------------------+-----------------------------------------
Reporter: Ludwig Kraatz | Owner: Ludwig Kraatz
Type: Bug | Status: closed
Component: Core (Other) | Version: 5.1
Severity: Normal | Resolution: invalid
Keywords: URL Validator | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 1 | UI/UX: 0
-------------------------------+-----------------------------------------
Comment (by Ludwig Kraatz):

Host components, and whether they are being validated correctly or not.

This - is the core issue of my ticket.

{{{
+---------------------+
| Local Environment |
+---------------------+
|
|--[localhost]---> VALID
|
|--[printer]------> FALSELY INVALIDATED
| (valid via local DNS, mDNS, or hosts)
| (although it was explicitly claimed a valid
utilization as of RFC6762)
|
|--[printer.local]-> VALID

+---------------------+
| Public Environment |
+---------------------+
|
|--[example.com]---> VALID
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/36131#comment:7>

[Django]

#36131: URLValidator not correctly validating URLs
-------------------------------+-----------------------------------------
Reporter: Ludwig Kraatz | Owner: Ludwig Kraatz
Type: Bug | Status: closed
Component: Core (Other) | Version: 5.1
Severity: Normal | Resolution: invalid
Keywords: URL Validator | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 1 | UI/UX: 0
-------------------------------+-----------------------------------------

Comment (by Sarah Boyce):

If you "look closely" at the test, you will notice it is testing
`URLField`, not `URLValidator`.

`URLField` has the feature
[https://docs.djangoproject.com/en/5.1/ref/forms/fields/#django.forms.URLField.assume_scheme
assume_scheme] which means the normalized value is `http://localhost` and,
therefore, `URLValidator` finds it valid.

If you can run the following code against `URLValidator`:
{{{
>>> from django.core.validators import URLValidator
>>> URLValidator()("http://localhost")
>>> URLValidator()("localhost")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/sarahboyce/Documents/django/django/core/validators.py", line
170, in __call__
raise ValidationError(self.message, code=self.code, params={"value":
value})
django.core.exceptions.ValidationError: <exception str() failed>
}}}

So, `URLValidator` raises a `ValidationError` when called against
`localhost`.
--
Ticket URL: <https://code.djangoproject.com/ticket/36131#comment:8>

[Django]

#36131: URLValidator not correctly validating URLs
-------------------------------+-----------------------------------------
Reporter: Ludwig Kraatz | Owner: Ludwig Kraatz
Type: Bug | Status: closed
Component: Core (Other) | Version: 5.1
Severity: Normal | Resolution: invalid
Keywords: URL Validator | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 1 | UI/UX: 0
-------------------------------+-----------------------------------------

Description changed by Ludwig Kraatz:

Old description:

> uri-schemes themselves.

>
> == PS
>
> its kindof late - i might polish this ticket tomorrow. if you feel like
> i'm drunk or disorganized - its just my brain thats screaming for relief.
> sry.

New description:

EDIT: ignore the following. it was an oversight on my end.
{{{

but - there was one test, that should not have broken:

FAIL: test_urlfield_clean_invalid
(forms_tests.field_tests.test_urlfield.URLFieldTest.test_urlfield_clean_invalid)
[<object object at 0x000001C1038C1760>] (value='foo')

URL <= "foo" should not be valid, even with my little changes, replacing
'localhost' with hostname_re

It feels like there are some (- -) missing - but i did not check.. i
focused on providing a more solid ticket first..
So - if i am not mistaken, there is another issue besides what i propose.
It seems, limiting hosts via FQDN was the thing, preventing missing URI-
scheme's to be rejected by the validator, not a correct validation of uri-
schemes themselves.
}}}
== PS

its kindof late - i might polish this ticket tomorrow. if you feel like
i'm drunk or disorganized - its just my brain thats screaming for relief.
sry.

--

--
Ticket URL: <https://code.djangoproject.com/ticket/36131#comment:9>

[Django]

#36131: URLValidator not correctly validating URLs
-------------------------------+-----------------------------------------
Reporter: Ludwig Kraatz | Owner: Ludwig Kraatz
Type: Bug | Status: closed
Component: Core (Other) | Version: 5.1
Severity: Normal | Resolution: invalid
Keywords: URL Validator | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 1 | UI/UX: 0
-------------------------------+-----------------------------------------

Comment (by Ludwig Kraatz):

Replying to [comment:8 Sarah Boyce]:

> If you "look closely" at the test, you will notice it is testing
`URLField`, not `URLValidator`.
>
> `URLField` has the feature
[https://docs.djangoproject.com/en/5.1/ref/forms/fields/#django.forms.URLField.assume_scheme
assume_scheme] which means the normalized value is `http://localhost` and,
therefore, `URLValidator` finds it valid.
>
> If you can run the following code against `URLValidator`:
> {{{
> >>> from django.core.validators import URLValidator
> >>> URLValidator()("http://localhost")
> >>> URLValidator()("localhost")
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>

> File "/path_to_django/django/core/validators.py", line 170, in

__call__
> raise ValidationError(self.message, code=self.code, params={"value":
value})
> django.core.exceptions.ValidationError: <exception str() failed>
> }}}
>
> So, `URLValidator` raises a `ValidationError` when called against
`localhost`.
>
>

would have been an nice addition to your closing comment - as it would
have pointed out an obvious oversight on my end.

still - has nothing to do with my actual ticket.
--
Ticket URL: <https://code.djangoproject.com/ticket/36131#comment:10>

[Django]

#36131: URLValidator not correctly validating URLs
-------------------------------+-----------------------------------------
Reporter: Ludwig Kraatz | Owner: Ludwig Kraatz
Type: Bug | Status: closed
Component: Core (Other) | Version: 5.1

Severity: Normal | Resolution: duplicate

Keywords: URL Validator | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1

Easy pickings: 0 | UI/UX: 0

-------------------------------+-----------------------------------------
Comment (by Ludwig Kraatz):

Replying to [comment:12 Tim Graham]:
> If the summary is accurate, it appears to be a duplicate of #25418.

It is not. It is related, thats for sure.
But the summary, how i put it, was more correct: {{{URLValidator not
correctly validating URLs}}}

Its more like a super-issue to the one referenced.
It may have started out, same as #25418, but now that i looked deeper into
the code, it for sure is way more than just that.

-wontfix- same as -duplicate- seems like not grasping the real issue here.
--
Ticket URL: <https://code.djangoproject.com/ticket/36131#comment:15>

[Django]

#36131: URLValidator not correctly validating URLs
-------------------------------+-----------------------------------------
Reporter: Ludwig Kraatz | Owner: Ludwig Kraatz
Type: Bug | Status: closed
Component: Core (Other) | Version: 5.1
Severity: Normal | Resolution: duplicate
Keywords: URL Validator | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------+-----------------------------------------

Comment (by Tim Graham):

The current implementation was a design decision. To change the behavior
now would need a discussion and a clear consensus. Deprecating URLField
and introducing new field types would be rather disruptive, and I don't
think it would happen. The fact that #25418 has gone unsolved for 9 years
suggests to me that the current behavior is good enough for most use
cases. Perhaps the documentation could be enhanced regarding what
`URLValidator` does and does not allow.

By the way, a ticket summary like "URLValidator not correctly validating
URLs" is too vague to be useful.
--
Ticket URL: <https://code.djangoproject.com/ticket/36131#comment:16>

[Django]

#36131: URLValidator not correctly validating URLs
-------------------------------+-----------------------------------------
Reporter: Ludwig Kraatz | Owner: Ludwig Kraatz

Type: Bug | Status: new

Component: Core (Other) | Version: 5.1
Severity: Normal | Resolution:

Keywords: URL Validator | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------+-----------------------------------------

Changes (by Ludwig Kraatz):

* resolution: duplicate =>
* status: closed => new

Comment:

Replying to [comment:16 Tim Graham]:

> The current implementation was a design decision. To change the behavior
now would need a discussion and a clear consensus. Deprecating URLField
and introducing new field types would be rather disruptive, and I don't
think it would happen. The fact that #25418 has gone unsolved for 9 years
suggests to me that the current behavior is good enough for most use
cases. Perhaps the documentation could be enhanced regarding what
`URLValidator` does and does not allow.
>
> By the way, a ticket summary like "URLValidator not correctly validating
URLs" is too vague to be useful.

I don't intend this as an offensive last comment - but as the person
responsible for this ticket, i see it in my role to respond by defending
this issue as resolut as i can - fighting for its right to be taken
serious - given, that this is the last time, I'll ever speak of it..

So please, take no offense.
It's purely.. for the sake of quality.

== I do see your point, i do.

It is difficult to roll back on mistakes made. Especially when they have
been made 'by design'.
But - I still am waiting for a substantial input from the [django
community], that could argue and weigh in on this URL-lazyness, to be a
reasonable thing to keep as is.

"It is inconvinient to change such a thing" - simply is not good enough.
Not for a framework. Not for "Django: The web framework for perfectionists
with deadlines" - (I just looked it up... still the same (: )

3 Years of deprecation followed by the actual replacement.. So what. thats
life.
Given this issue - more than adequate action. I really don't see your
point.

Either, there is a GOOD reason - then present it and everyone in the
future can be redirected to that rational and be silenced forever..
Or get constructive and think about how to remedy this unhappy-design-
decision.
Go get that consensus. Talk about it in your community. Thats the way to
go - i would never ask you to pass out on that step.

I mean.. it could have been as EAASY, as calling it "CustomURL"...
Everyone could have benefited.
The whole Lazy-scheme thing... PPPEEERFECT for a CUSTOM-url Field
(/Validator)..

Thats the issue with naming things.. it. actually means more than most
people make of it.....

== Motives || harsh, but meant with a warm smile

Seriously. Either you [django community] find your voice, or i deeply
question your motives.
I called out lazyness/comfort/being superficial - referenced it here once
more - and am not going to go down that rabbit hole any further, out of
respect for the work, all of you [django community] most certainly have
put into this great project over the years!

How many years does django exist now? 15+? More? 19! (Looked it up ;). ) I
BET - this 'design decision' dates back to the beginning. Or maybe
'changing what has been done in the beginning' - was decided at some
point.. because i seriously doubt there being any substantial reason (I
allready raised that issue - the lack of presentation of such reason).

But if its not for the quality-of-code and being a "high bar" of
(structural) integrity -- i simply don't see the point. NINETEEN YEARS!
With 19 years, i most certainly started to think about how my actions
impact the world around me. - Just stating this. -

I wouldn't have put in so much effort for 'some little project'. But
django has responsibility, for more than just itself.


== too vague? || this part is personal - still not meant to offend anyone

"too vague to be useful" -> kind of meets the criteria of how django's
naming conventions seem to go - as well as 'taking "standartized acronyms"
serious".
At least when talking about "URLValidator" or "URLField". I don't mean to
be rude here - just asking you, to really think about, if what i write is
being 'too vague to be useful', when its aimed at critisizing django's
implementation which (irrefutably) actually does meet that criteria.. ^^
To me - this kind of feels: exactly spot on.

Could not have nailed the title better - even though i did not know it
would go to such depth...
I do stand by that title - because there simply is no better way to
describe the issue here.

If you feel, it is too vague -- i ask you, from the bottom of my social-
responsibility-bucket: do you really understand the issue here?

This issue - is about a complete redesign of this aspect of the django
code. Because everything less - would ''probably'' be a joke.
As such - spot on.

== my last words regarding this matter || this is offensive. To the IETF.
And the whole process of standartization

-i do appoligize, i **AM** sorry - but i still am assigned as responsible
for this ticket - and i do take this role ''very'' serious-

If thats how the django community wants to ignore and redefine, what a
thoughtful process lead/published/?? by IETF has come up with - be my
guest.

Be rediculous.

== I feel like i finally overstepped.

this was the last statement i made regarding this topic - i ask @Antoliny
to unassign me from this ticket, because i no longer feel to be an
appropriate representative of this issue.

It is up to the django community to come up with approrpiate ways, to
'deal or not to deal' with this issue.
Going further, my presence does not seem to be of any more use.

== I ASK TO BE RELIEVED FROM MY DUTIES

i reopend this issue as a last resort of 'fighting back'. I feel like this
is not my place to do - because this is not 'my community' or 'my
project'.
But as i said. A measure of last resort.

== Keep on the the django spirit! You did great so far (:
--
Ticket URL: <https://code.djangoproject.com/ticket/36131#comment:17>