LISTSERV mailing list manager LISTSERV 15.5

Help for MHTML Archives


MHTML Archives

MHTML Archives


View:

Next Message | Previous Message
Next in Topic | Previous in Topic
Next by Same Author | Previous by Same Author
Chronologically | Most Recent First
Proportional Font | Monospaced Font

Options:

Join or Leave MHTML
Reply | Post New Message
Search Archives


Subject: Re: More on wrongly(?) formatted urls
From: Jacob Palme <[log in to unmask]>
Reply-To:IETF working group on HTML in e-mail <[log in to unmask]>
Date:Thu, 21 Aug 1997 18:25:20 +0200
Content-Type:text/plain
Parts/Attachments:
Parts/Attachments

text/plain (42 lines)


At 14.02 +0200 97-08-21, Martin J. Dürst wrote:
> On Wed, 20 Aug 1997, Jacob Palme wrote:
> >      Method (a) is not always easy. It may include cooperation
> >      with the user and the software which produced the faulty
> >      URL. The encoding method of RFC 1738 can make a correct
> >      URL faulty if not done the right way. Changing the URL of
> >      documents already available on the Internet or an Intranet
> >      may invalidate existing links to this document. Changing
> >      the HTML body may invalidate message integrity checks.
>
> Do we really want to propose a method that has that many
> ifs and whens? Do we assume implementors will all get all
> these things right? I seriously doubt it.

It sort of feels wrong to me that one should not recommend as one
option to correct what is wrong, and that one should recommend
as the only permitted option to send incorrect URLs.

At 10.14 -0500 97-08-21, Albert Lunde wrote:
> > Do we really want to propose a method that has that many
> > ifs and whens? Do we assume implementors will all get all
> > these things right? I seriously doubt it.
>
> I'd also agree with this. The RFC 2047 encoding seems to be
> unambigous, and it's something people writing e-mail software
> will have to do anyway. The %HH encoding of URLs is tied
> up with the notion of reserved characters and semantics
> in a way that causes trouble. You can't just apply it
> as a transport "wrapper" and undo it later.

But that is not what the text says. The text says that one
option is to go back and correct what is wrong. This correction
is not a transport wrapper, the text says that %nn encodings
are *not* to be reversed on receipt before comparing the
URLs in the HTML text and the content-headings.

What is the opinion of the other members of the working group
on this issue?

------------------------------------------------------------------------
Jacob Palme <[log in to unmask]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme

Back to: Top of Message | Previous Page | Main MHTML Page

Permalink



LISTSRV.NORDU.NET

CataList Email List Search Powered by the LISTSERV Email List Manager