RE: Apparently the practice was prevalent

["Shawn K. Hall \(RA/Security\)" <Security () ReliableAnswers com>]

> > rfc2396 describes URI's, rfc1945 and rfc2616 describe
> > the HTTP **protocol**. They're far from the same thing.
>
> Agreed, but you see, RFC 2616 defines more than just the
> HTTP protocol.

No, it doesn't. It defines the protocol. It imports necessary values
from other specs and recommendations by reference, like those you
quoted below - which, had you actually read both RFC's you'd see that
authority, as defined in 2396 does include userinfo. Period. As
referenced in 2616 3.2.1, it imports "authority" as defined in 2396
which includes 'userinfo.'


> It seems the authors of RFC 2616 thought they _were_
> defining the HTTP URL syntax and semantics, but perhaps
> you really do know better...

Again - ONLY 2396 is definitive for the URI scheme. Other RFC's
provide special handling instructions for scheme and fragment
identifiers, but do not, by design, incorporate their own URI
derivatives. This is part of the design behind the segregation of
function within the RFC's.


> Thus, your charge that RFC 2616 is largely irrelevant
> to understanding HTTP URLs is very wrong and
> dangerously misleading.

That's not what I said. I said that it was not definitive, but
abbreviated - having most of it's value by reference. 'An informed
reading' of the RFC's would demonstrate how misguided you are.


> > A highly applicable reference is rfc1736 which is the
> > functional recommendations for internet resource locators:
> >    3. Resource Access and Availability
> >       A locator never guarantees access, but establishing
> >       access is by far the most important intended
> >       application of a resource locator. ...
>
> So?
>
> I don't see what relevance access considerations, per se,
> have to this debate.

Color me surprised. The point is that URI's, BY THEIR NATURE, DESIGN
AND INTENT, SHOULD be able to provide ALL relevant data necessary to
gain access to a resource. MS removing this ability goes against not
only the letter, but the intent of the standards. Security be damned -
if you can't follow standards and protocols in basic practice then
security is the least of your concerns. If your application doesn't
FUNCTION then the security considerations are a moot point.


> My main claim is that MS was especially right to make this
> fix because it establishes standards conforming behaviour...

Which is why you're wrong. It doesn't.



> In fact, if you go back far enough to, say, RFC 1738...
>    No user name or password is allowed. ...
> ...
> If you follow the rest of the "development" of HTTP URLs
> through the various RFCs you will find that "userinfo"
> was not "re-instituted" (if, in fact, it ever was an
> RFC-sanctioned component of HTTP URLs...).

It was never user:password, but 'authority.' You seem to be missing
that.


> What concerns me is that this practice has become
> somewhat common because folk who should be savvy
> enough to know better took Microsoft's advice
> and/or simply cannot read and fully understand the
> RFCs.  I mean, what part of "No user name or
> password is allowed" from RFC 1738 did you not
> understand?

What part of "authority !==  user+password" do YOU not understand?

Regards,

Shawn K. Hall
http://ReliableAnswers.com/

'// ========================================================
    Truth will always be truth, regardless of lack of
    understanding, disbelief or ignorance.
      -- W. Clement Stone


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html