# Re: Re[2]: CID url type

Rens Troost (rens@imsi.com)
Fri, 13 Oct 1995 16:53:39 -0400

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Eliot Christian: "Internet Client Search Freeware"
- Previous message: Ed Levinson: "Re: CID: url type"

    Message-Id: <9510132053.AA22295@lorax.imsi.com>

    To: Valdis.Kletnieks@vt.edu

    Subject: Re: Re[2]: CID url type

    In-Reply-To: Your message of "Fri, 13 Oct 1995 16:16:50 EDT."

                 <199510132016.QAA24314@black-ice.cc.vt.edu>

    Date: Fri, 13 Oct 1995 16:53:39 -0400

    From: Rens Troost <rens@imsi.com>

>>>>> "Valdis" == Valdis Kletnieks <Valdis.Kletnieks@vt.edu> writes:

Valdis> So indeed, we *do* need a way to say "a URL referencing
Valdis> another body part of the message <message ID>".

Valdis> The *real* fun starts when we start considering follow-ups
Valdis> and replies, where I may wish to say "see body part 7 of
Valdis> Fred's note from Tuesday", which would get expressed in
Valdis> terms of some combination of message-ID to identify Fred's
Valdis> note, and content-ID to flag part 7.

Content-ID is a globally unique bodypart identifier, so formally you
do not need a message ID in the URI; What is needed is some standard
for mapping content ID to messages, be it a naming convention,
distributed database, or some such thing.

It might be argued that to aid implementors, perhaps the CID URL
should encode the message ID. This starts begging the question,
though; should we also encode the message's 'domain' (news, email,
http, other?) to help find it. Hmmm. Gnarly.

In practice, I see the big usage being to refer to other bodyparts in
the same message, so my urge would be to defer content-id ->
message-id mapping to some other standard, and stick with CID as it
stands.

My 2 cents.

-Rens

- Next message: Eliot Christian: "Internet Client Search Freeware"
- Previous message: Ed Levinson: "Re: CID: url type"