W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2005

Re: location uri, ucs and the http scheme definition.

From: Max Clark <exported@sbcglobal.net>
Date: Tue, 23 Aug 2005 09:04:54 -0700
Message-ID: <1b5901c5a7fc$6763d440$64f17f42@yourx6k5fonaok>
To: "Jamie Lokier" <jamie@shareable.org>, "Robert Collins" <robertc@robertcollins.net>
Cc: "William A. Rowe, Jr." <wrowe@rowe-clan.net>, "Julian Reschke" <julian.reschke@gmx.de>, "HTTP Working Group" <ietf-http-wg@w3.org>

 Read the whole thing. This is an actual letter sent to a man
>  >>>     named Ryan DeVries by the Michigan Department of Environmental
>  >>>     Quality, State of Michigan. This guy's response is hilarious,
>  >>>     but read the State's letter before you get to the response letter
>  >>>     (This is the State's Letter!)
>  >>>     SUBJECT: DEQ File No.97-59-0023; T11N; R10W, Sec. 20; Montcalm
>  >>>     County
>  >>>
>  >>>     Dear Mr. DeVries:
>  >>>
>  >>>     It has come to the attention of the Department of Environmental
>  >>>     Quality that there has been recent unauthorized activity on the
>  >>>     above referenced parcel of property. You have been certified as
>  >>>     the legal landowner and/or contractor who did the following
>  >>>     unauthorized activity:
>  >>>
>  >>>     Construction and maintenance of two wood debris dams across the
>  >>>     outlet stream of Spring Pond.
>  >>>
>  >>>     A permit must be issued prior to the start of this type of
>  >>>     activity. A review of the department's files shows that no
>  >>>     permits have been issued. Therefore, the Department has
>  >>>     determined that this activity is in violation of Part 301,
>  >>>     Inland Lakes and Streams, of the Natural Resource and
>  >>>     Environmental Protection Act, Act 451 of the Public Acts of
>  >>>     1994, being sections 324.30101 to 324.30113 of the Michigan
>  >>>     Compiled Laws, annotated.
>  >>>
>  >>>     The Department has been informed that one or both of the dams
>  >>>     partially failed during a recent rain event, causing debris and
>  >>>     flooding at downstream locations. We find that dams of this
>  >>>     nature are inherently hazardous and cannot be permitted. The
>  >>>     Department therefore orders you to cease and desist all
>  >>>     activities at this location, and to restore the stream to a
>  >>>     free-flow condition by removing all wood and brush forming the
>  >>>     dams from the stream channel. All restoration work shall be
>  >>>     completed no later than January 31, 2005.
>  >>>
>  >>>     Please notify this office when the restoration has been
>  >>>     completed so that a follow-up site inspection may be scheduled
>  >>>     by our staff. Failure to comply with this request or any further
>  >>>     unauthorized activity on the site may result in this case being
>  >>>     referred for elevated enforcement action. We anticipate and
>  >>>     would appreciate your full cooperation in this matter.
>  >>>     Please feel free to contact me at this office if you have any
>  >>>     questions.
>  >>>
>  >>>     Sincerely,
>  >>>
>  >>>     David L. Price, District Representative
>  >>>     Land and Water Management Division
>  >>>
>  >>>     ** Here is the actual response sent back by Mr. DeVries: **
>  >>>     Re: DEQ File No. 97-59-0023; T11N; R10W, Sec. 20; Montcalm
County.
>  >>>
>  >>>     Dear Mr. Price,
>  >>>
>  >>>     Your certified letter dated 12/17/02 has been handed to me to
>  >>>     respond to. I am the legal landowner but not the Contractor at
>  >>>     2088 Dagget, Pierson, Michigan. A couple of beavers are in the
>  >>>     process of constructing and maintaining two wood "debris" dams
>  >>>     across the outlet stream of my Spring Pond.
>  >>>
>  >>>     While I did not pay for, authorize, nor supervise their dam
>  >>>     project, I think they would be highly offended that you call
>  >>>     their skillful use of natures building materials "debris." I
>  >>>     would like to challenge your department to attempt to emulate
>  >>>     their dam project any time and/or any place you choose.
>  >>>
>  >>>     I believe I can safely state there is no way you could ever
>  >>>     match their dam skills, their dam resourcefulness, their dam
>  >>>     ingenuity, their dam persistence, their dam determination and/or
>  >>>     their dam work ethic.
>  >>>
>  >>>     As to your request, I do not think the beavers are aware that
>  >>>     they must first fill out a dam permit prior to the start of this
>  >>>     type of dam activity.
>  >>>
>  >>>     My first dam question to you is: (1) Are you trying to
>  >>>     discriminate against my Spring Pond Beavers, or (2) do you
>  >>>     require all beavers throughout this state to conform to said dam
>  >>>     request? If you are not discriminating against these particular
>  >>>     beavers, through the Freedom of Information Act, I request
>  >>>     completed copies of all those other applicable beaver dam
>  >>>     permits that have been issued. Perhaps we will see if there
>  >>>     really is a dam violation of Part 301, Inland Lakes and Streams,
>  >>>     of the Natural Resource and Environmental Protection Act, Act
>  >>>     451 of the Public Acts of 1994, being sections 324.30101to
>  >>>     324.30113 of the Michigan Compiled Laws, annotated.
>  >>>
>  >>>     I have several concerns. My first concern is; aren't the beavers
>  >>>     entitled to legal representation? The Spring Pond Beavers are
>  >>>     financially destitute and are unable to pay for said
>  >>>     representation -- so the State will have to provide them with a
>  >>>     dam lawyer. The Department's dam concern that either one or both
>  >>>     of the dams failed during a recent rain event, causing flooding,
>  >>>     is proof that this is a natural occurrence, which the Department
>  >>>     is required to protect. In other words, we should leave the
>  >>>     Spring Pond Beavers alone rather than harassing them and calling
>  >>>     their dam names.
>  >>>
>  >>>     If you want the stream "restored" to a dam free-flow condition
>  >>>     please contact the beavers -- but if you are going to arrest
>  >>>     them, they obviously did not pay any attention to your dam
>  >>>     letter, they being unable to read English.
>  >>>
>  >>>     In my humble opinion, the Spring Pond Beavers have a right to
>  >>>     build their unauthorized dams as long as the sky is blue, the
>  >>>     grass is green and water flows downstream. They have more dam
>  >>>     rights than I do to live and enjoy Spring Pond. If the
>  >>>     Department of Natural Resources and Environmental Protection
>  >>>     lives up to its name, it should protect the natural
>  >>>     resources(Beavers) and the environment (Beavers' Dams).
>  >>>
>  >>>     So, as far as the beavers and I are concerned, this dam case can
>  >>>     be referred for more elevated enforcement action right now. Why
>  >>>     wait until 1/31/2005? The Spring Pond Beavers may be under the
>  >>>     dam ice then and there will be no way for you or your dam staff
>  >>>     to contact/harass them then.
>  >>>
>  >>>     In conclusion, I would like to bring to your attention to a real
>  >>>     environmental quality (health) problem in the area. It is the
>  >>>     bears! Bears are actually defecating in our woods. I definitely
>  >>>     believe you should be persecuting the defecating bears and leave
>  >>>     the beavers alone. If you are going to investigate the beaver
>  >>>     dam, watch your step! (The bears are not careful where they
dump!)
>  >>>     Being unable to comply with your dam request, and being unable
>  >>>     to contact you on your dam answering machine, I am sending this
>  >>>     response to your dam office.
>  >>>
>  >>>     THANK YOU.
>  >>>
>  >>>     RYAN DEVRIES & THE DAM BEAVERS
>  >>>
>  >>
>
>
>
>


----- Original Message ----- 
From: "Jamie Lokier" <jamie@shareable.org>
To: "Robert Collins" <robertc@robertcollins.net>
Cc: "William A. Rowe, Jr." <wrowe@rowe-clan.net>; "Julian Reschke" 
<julian.reschke@gmx.de>; "HTTP Working Group" <ietf-http-wg@w3.org>
Sent: Tuesday, August 23, 2005 8:53 AM
Subject: Re: location uri, ucs and the http scheme definition.


>
> Robert Collins wrote:
>> > > I'd be happy with a HTTP/1.1 errata that updates the http:// scheme 
>> > > to
>> > > declare it as utf8 before the escape encoding is done.
>> >
>> > Not reasonable.
>> >
>> > There are a significant number of HTTP/1.1-compliant servers which
>> > work with URLs that are derived from text in other encodings, and
>> > there are servers where the encoding depends on the URL (because the
>> > server's job is to pass along the URL unmodified to individual
>> > resource handlers).
>>
>> I put it to you that this has occured because of the lack of guidance in
>> rfc2616. Even though we can't retroactively change the standard, adding
>> in the std66 recommendation as a wg recommendation would be a positive
>> step IMO.
>
> Those web servers _far_ predate RFC2616.  Whatever guidance goes into
> an HTTP URI standard, it must remain backward compatible with what's
> widely deployed, which is precisely why the RFCs don't mandate it yet,
> even as they suggest further work is needed on it.
>
>> Anything compliant with any of the uri standards must continue to work
>> with any % escape uri representation. Sure - but it would be nice to
>> document what *should* work.
>
> It is documented.  According to documentation, any %-escaped octet
> sequence should work :)  Converting them to *characters for visual
> presentation* is outside the scope of HTTP.
>
>> > In principle, the escape-encoding represents an application-specific
>> > opaque octet stream, and it need not represent "characters" at all.
>>
>> For URIs in general, yes. but std66 section 2.5 does provide guidance
>> for this...
>> >     - How non-ASCII characters in documents in places such as an
>> >       "href" attribute are converted into proper URIs for HTTP.
>> >
>> >     - How non-ASCII characters in forms are converted into proper
>> >       URI query parts.  (This is covered somewhat already in HTTP 4).
>> >
>> >     - How non-ASCII characters in other parts of a typical client's
>> >       user interface such as the "location bar", are converted into
>> >       proper URLs for HTTP document retrieval.
>>
>> Which, given we started this thread on the Location header in http,
>> which sets the user interface location bar ... seems relevant to me.
>
> The Location header only has that effect in _web browsers_.
>
> There are lots of other programs which use HTTP for which the
> "characters" encoded in a URL are irrelevant.
>
> Increasingly, we may find that non-web-browser HTTP agents see
> non-ASCII characters in parts of a document that claim to be URIs, and
> must follow them.  Or, they see URIs containing %-encoded characters
> and need to convert those to presentable text in documents.
>
> Broadly, the UTF-8-ness affects programs which relate documents
> containing non-ASCII characters with URLs.  For example, a spider
> which indexes pages that happen to contain non-ASCII characters in the
> URLs in "href" attributes... those are actually not valid URLs, but
> the spider has to make a heuristic decision if it's to follow them.
>
> Unfortunately, if we mandate that non-ASCII characters found in "href"
> URL attributes should be %-escaped as UTF-8 to follow them, we'll find
> that this *breaks* some existing deployed sites.  Maybe this is for
> the best...
>
> In the other direction, a program which is generating index pages of
> links may wish to present the links visually as text, converting
> %-escape sequences into good looking text.  However, this may look
> nice but it's prone to causing security problems...
>
>> Anyway, what I'd like to see is some reference suggesting a best
>> practice for http uris, if that is able to be defined. Using whatever
>> guidelines are present for the next http protocol would be ideal ;0.
>
> It still has to be backward-compatible, if it's HTTP/1.2.
>
> So guidance for future applications is sensible.  Making it a
> requirement has to done much more carefully.
>
> -- Jamie
> 
Received on Tuesday, 23 August 2005 16:05:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:49:40 GMT