My understanding is that there's one level of indirection implicit in SGML
to begin with. Specifically, the actual documents references things by
names which are then bound to actual objects by the DTD.
> 1. In an Internet context, the SGML "SYSTEM" identifiers
> should be conventionally URIs. As there are URIs
> which refer to a local file system, this does not
> rule out refering to local files too.
This sounds like a good idea to me.
> 2. The FPI space should be registered as a URN.
As I understand it, the FPI space has a lot in common with several other things
in OSI. Specifically, while it does provide a convenient space for public
usage, the lack of any authoritative registration process makes it very
difficult for things to really interoperate. (Many other aspects of OSI have
similar problems, such as BP15 OID usage, FTAM file formats, and so on.)
Given that this is a fair representation of the current situation, I think
having the Internet provide such a process would be a wonderful thing. In
addition, if that process can be piggybacked on top of some existing or
soon-to-exist scheme like URNs, so much the better.
> 3. Some space inside FPI space should be found for
> the URN tree as well.
I'm not sure how you'd do this in any authoritative way. Any SGML experts (I'm
certainly nothing of the kind) care to comment?
> 4. For the case of mail transport, both message-id values
> (identifeirs of mail messages) and content-ids
> (identifiers of parts of a multpart MIME message)
> should be registered as URNs. They will of course
> only be dereferencable by people who have been
> sent the relevant mail, but that is fine.
Are these really URNs? Aren't they actually URIs since the access method is
implicit in the name?
> 5. The convention is adopted that when a multipart/related
> document is sent, that the first part is consuleted for
> information about the relationships.
Expect to see some documents clarifying the handling of multipart MIME
objects in the near future.
> 7. HTTP should be specified to include support
> for MIME multipart/related, to solve the problem
> of servers which like to send a document with all
> its included graphics in one respone.
Interesting idea. I like it.
I think we also need some kind of message subtype in MIME that does things
similar to message/external-body but resolves URIs and/or URNs. I don't see
this as being something that can be just another access-type under
message/external-body because of the semantics peculiar to the HTTP way of
resolving URIs (specifically, that the content-type is selected by the server
in response to what the client indicates it can handle).
Ned