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