- From: John Stracke <francis@ecal.com>
- Date: 1999年2月26日 02:46:28 +0000
- To: w3c-dist-auth@w3.org
- Message-ID: <36D60B04.EB53EAF5@ecal.com>
james anderson wrote: > while i won't assert, given a cursory reading of rfc 1521, that multipart is > obsolete, i wouldn't deny it either. I would certainly deny it. RFC1521 is six years old; it was replaced by RFCs 2045-2049 three years ago. Multipart/related was updated just last August (RFC2387); multipart/form-data was defined in RFC2388. MIME objects can be signed and encrypted (S/MIME [RFC1847] and the upcoming PGPMIME). > John Stracke wrote: > > > > > > Advantages of doing structured documents as multipart/related instead of > > collections: > > > > * There are obviously going to be types of structured documents; > > multipart/related already has a mechanism and namespace for specifying > > these types. > > as does xml - dtd's - or whatever schema form follows on. xml has the > disadvantage that it does not permit inline encoding variations, I believe this is a crippling disadvantage; if you want to publish a compound document, encoding everything inline is really useful, because it means that people can download a single resource and know they got the whole thing. > but it does > permit references to arbitrary external encodings (including those covered by > mime types) and it does offer better means to discover document structure. > > > * Given a multipart/related document with external parts, there's an > > obvious way to serialize the document for transport. > > xml is incomplete in this regard, but only in the sense the the possible > semantics of links is not yet "ratified". I think I'm missing something; above, you say that XML doesn't permit inline encoding variations. Serializing the compound requires the ability to include components inline. > > * Structural sharing: if two structured documents use the same image (for > > example), and the DAV server doesn't support references, then a > > collections-based approach requires that that image be copied, since > > there's no way for a client to tell the server to have it show up in both > > collections. With a multipart/related approach, you just have both > > documents reference the same image. > > wouldn't href="..." or imgsrc="..." accomplish the same thing. Then why have a compound document at all? Why not just use XML? > > * Cross-server documents: with multipart/related, the external body parts > > can live anywhere on the Net (well, anywhere accessible to the client, > > anyway ;-). With collections, this works only if the DAV server supports > > references. > > i have to look back at the webdav spec for this.... > i'm not sure what the issue is in this paragraph. "reference" does not appear > to be a special term w.r.t dav collections. See the advanced collections work. > which i would take to mean that > uri's suffice - which i would expect any http-capable server to support... ? -- /=============================================================\ |John Stracke | My opinions are my own | S/MIME & HTML OK | |francis@ecal.com|============================================| |Chief Scientist | NT's lack of reliability is only surpassed | |eCal, Inc. | by its lack of scalability. -- John Kirch | \=============================================================/
Received on Wednesday, 3 March 1999 09:03:37 UTC