In article , Wolf K
wrote:

it was*you* who made irrelevant comments about mime, specifically
network packet headers, which has absolutely nothing whatsoever to do
with file system metadata. zero.

I pointed out that data packets have metadata included as an example of
the principle of including metadata with the data file. The context was
"Should metadata be included with the file, or should it be external,
e.g., in the file system or elsewhere?"

network packets do not have metadata. period. full stop.

you've been told this by myself and several others.

Quoting myself:

and further embarrassing yourself.

"The internet works because the necessary data for routing the data
packets are inside the data packet, not external. That principle should
apply to all forms of data. Including programs, but that's a another
issue. "

There's nothing about MIME in there. Zip. Zero.

exactly the point.

network packets have *nothing* to do with mime or metadata. zip. zero.

It was you who thought I
was talking about MIME.

nope.

i knew that you *couldn't* have been talking about mime because network
packets and mime are two totally different and unrelated things.

the fact you continue to insist they're somehow related shows just how
little you understand about the topic, something which you *continue*
to do despite several people telling you that you're completely wrong.

I guess you a) ignored "routing"; and b) didn't get the referent of
"that principle". Too bad.

of course i ignored 'routing' because network routing is not relevant
to mime or file system metadata.

I'll spell it out for you: "The principle of
including file-type (and other) metadata with the file instead of
storing it elsewhere." (The "storing it elsewhere" part led to the
argy-bargy about how Apple did/does it with "forks". Instead of with
spoons.) I'm in favour of that principle, although user convenience may
break rigid adherence, eg, by attaching file-type data to the filename.

i'll spell it out for *you* (although i'm quite sure you *still* won't
understand it):

tl;dr - there is more than one type of metadata so there's no single
answer to where it must go or should go, and in some cases, there are
multiple options with various tradeoffs.

file system metadata (e.g., access permissions) *must* be stored
*separate* from the file itself (something which should be obvious, but
likely is not), while other metadata, such as id3 tags or exif data,
are usually stored inside the file but in some cases are not.

for example, title/artist/album should be in the mp3 song itself, while
play/skip counts and song ratings has to be external to it.

album artwork is often in each song, but since multiple songs from the
same album will have the same artwork, that artwork could be shared in
a separate library file, thereby saving space, something which is very
important for portable music players that have limited storage
capacity.

for photos, the camera writes assorted metadata (camera model, camera
settings, geotag data etc.) to exif tags, while photo management apps
write *different* assorted metadata (exposure adjustments, colour
balance, sharpening level, etc.) to a database and/or individual
sidecar files.

metadata also has nothing whatsoever to do with data/resource forks (or
microsoft's alternate data streams for that matter).

old time mac app developers could (and did) store whatever they want in
either or both forks, depending on what worked best for their app. file
metadata was *separate*.

there were accepted standards, but nothing (not even apple) required
anyone to adhere to those standards. as the saying goes, rules are made
to be broken.

for example, it was possible to treat the resource fork as a second
data fork, something which could potentially cause the computer to
crash if not done carefully. there were also several apps that put
executable code in the data fork, with a shim in a code resource to
jump to it. both are considered very bad practice, but both happened.