There has been some discussion recently about how to
send SGML documents along with DTDs and oetr things
which they reference in MIME messages. (see SGML-MIME ID).
SGML documents refer to external entities
as either "PUBLIC", in which case a special "Formal
Public Identifier" (FPI) space is used and everyone
is supposed o know what's in it, or "SYSTEM" in which
case the significance is purely local.
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