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: New version of the MHTML ietf draft
From: Jacob Palme <[log in to unmask]>
Reply-To:IETF working group on HTML in e-mail <[log in to unmask]>
Date:Sat, 22 Nov 1997 10:10:34 +0100
Content-Type:text/plain
Parts/Attachments:
Parts/Attachments

text/plain (49 lines)


At 21.17 +0000 97-11-21, [log in to unmask] wrote:
> > I am a little wondering about one change which Nick Shelness made:
> >
> > He changed
> >
> >       Content-Location: ietflogo.gif
> >       Content-Base: http://www.ietf.cnri.reston.va.us/images/
> >       ; Note that the fact that the Content-Base comes after the
> >       ; Content-Location within the same Content-Heading will not
> >       ; influence their interpretation
> >       Content-Type: IMAGE/GIF
> >       Content-Transfer-Encoding: BASE64
> >
> > to
> >
> >       Content-Location:
> http://www.ietf.cnri.reston.va.us/images/ietflogo.gif
> >       Content-Type: IMAGE/GIF
> >       Content-Transfer-Encoding: BASE64
> >
> > I have made the change, but is not sure why Nick wanted this change.
> > There is too little time left before the ietf draft submission
> > deadline for me to ask him why he made this change.
>
> I guess, I felt that the use of Content-Base to resolve relative
> Content-Locations (though legal) as opposed to referencing URIs makes
> little sense and should not be encouraged. This is probably a case of my
> overstepping my copy editor's remit. If you view it as such, then I
> apologize.

The standard should say clearly what is permitted and not permitted.
To discourage what you do not like by not mentioning it is dangerous,
some implementors may implement it, others not, and then their software
may not co-work well. Thus, a standard may have to include explicit
mention and examples of not-very-nice practice in order to ensure
that implementors will support it at receipt. If a standard wants
certain practice to be allowed on receipt, but not recommended in
what you send, the standard should say so explicitly.

I have always been critical of the IETF golden rule "be liberal in
what you accept, conservative in what you send", because it is too
vague, I think a standard should explicitly state, when needed,
a different send and receipt format, i.e. explain what ins included
in "liberal" but not in "conservative", and not leave this decision
up to the implementors.

------------------------------------------------------------------------
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