headers
MURATA Makoto | 17 Aug 2000 01:55

Fwd: Last Call: XML Media Types to Proposed Standard

Dan, Simon, and I have very slightly revised the I-D, on the basis of 
comments in this ML and comments we directly received.  The new I-D is now 
available at:

	http://www.ietf.org/internet-drafts/draft-murata-xml-07.txt

We entered into the last call phase at IETF.

Cheers,

Makoto

> The IESG has received a request to consider XML Media Types
> <draft-murata-xml-07.txt> as a Proposed Standard.  This has been
> reviewed in the IETF but is not the product of an IETF Working Group.
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> iesg <at> ietf.org or ietf <at> ietf.org mailing lists by September 15, 2000.
> 
> Files can be obtained via
> http://www.ietf.org/internet-drafts/draft-murata-xml-07.txt
>
Permalink | Reply | 0 comments |
headers
Paul Grosso | 23 Aug 2000 22:53

Re: Fwd: Last Call: XML Media Types to Proposed Standard

At 08:55 2000 08 17 +0900, MURATA Makoto wrote:
>Dan, Simon, and I have very slightly revised the I-D, on the basis of 
>comments in this ML and comments we directly received.  The new I-D is now 
>available at:
>
>	http://www.ietf.org/internet-drafts/draft-murata-xml-07.txt

I note in section 3:

   For backward compatibility, application/xml and text/xml MAY, 
   but SHOULD NOT, also be used for "external parsed entities", 
   "external DTD subsets", and "external parameter entities".

I don't see how external DTD subsets or external parameter
entities could be parsed or accessed as application/xml or 
text/xml.  I'm concerned that, by allowing such entities
to be given an application/xml or text/xml MIME type, we
will be saying, for example, that XPointer can now be used
to access them (since XPointer is the fragment identifier
syntax for resources of MIME type application/xml and text/xml)
and yet such resources don't have infosets and accessing them
using an XPointer is not defined.

I don't fully understand the backward compatibility argument,
but I'd prefer not to allow application/xml and text/xml to be 
used on "external DTD subsets", and "external parameter entities".

paul
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Kohn | 23 Aug 2000 23:39
Gravatar

RE: Fwd: Last Call: XML Media Types to Proposed Standard

We would prefer that application/xml and text/xml did not allow these kinds
of entities as well, but they are explicitly allowed in the predecessor
document, RFC 2376.  It is generally considered bad form to invalidate
implementations that made a good faith effort to conform to the previous
form of the standard.

Thus, we used SHOULD NOT rather than MUST NOT.  Of course, we expect the
availability of text/xml-external-parsed-entity and
application/xml-external-parsed-entity will do more than any SHOULD/MUST
distinction to cause implementers not to overload */xml.

		- dan
--
Dan Kohn <mailto:dan <at> dankohn.com>
<http://www.dankohn.com>  <tel:+1-650-327-2600>

-----Original Message-----
From: Paul Grosso [mailto:pgrosso <at> arbortext.com]
Sent: Wednesday, 2000-08-23 13:53
To: ietf-xml-mime <at> imc.org
Subject: Re: Fwd: Last Call: XML Media Types to Proposed Standard

At 08:55 2000 08 17 +0900, MURATA Makoto wrote:
>Dan, Simon, and I have very slightly revised the I-D, on the basis of 
>comments in this ML and comments we directly received.  The new I-D is now 
>available at:
>
>	http://www.ietf.org/internet-drafts/draft-murata-xml-07.txt

I note in section 3:
(Continue reading)

Permalink | Reply | 504 comments |
headers
Larry Masinter | 28 Aug 2000 16:25
Picon

RE: Fwd: Last Call: XML Media Types to Proposed Standard

   For backward compatibility, application/xml and text/xml MAY, 
   but SHOULD NOT, also be used for "external parsed entities", 
   "external DTD subsets", and "external parameter entities".

I don't think "MAY but SHOULD NOT" is a valid state in RFC 2119
terminology, or called for. How about:

  application/xml and text/xml MUST NOT be used for "external parsed
  entities", "external DTD subsets", and "external parameter entities".
  Note that RFC 2376 (obsoleted) allowed this usage, although
  in practice it is likely to be rare.

The justification

> ... It is generally considered bad form to invalidate
> implementations that made a good faith effort to conform to the previous
> form of the standard.

isn't consistent with policy or practice; from RFC 2026 
section 4.1.1:

   A Proposed Standard specification is generally stable...
   However, further experience
   might result in a change or even retraction of the specification
   before it advances.

More often than not, people just fix specs that are broken, and pay
attention to backward compatibility when it affects deployed software,
not theoretical compatibility.
(Continue reading)

Permalink | Reply | 503 comments |
headers
Dave Peterson | 28 Aug 2000 18:11
Picon
Favicon

RE: Fwd: Last Call: XML Media Types to Proposed Standard

At 7:25 AM -0700 8/28/00, Larry Masinter wrote:

>More often than not, people just fix specs that are broken, and pay
>attention to backward compatibility when it affects deployed software,
>not theoretical compatibility.

For what it's worth, in my opinion blind worship at the altar of backward
compatibility is one thing that prevented SGML from accepting XML points
of view and caused XML to become a separate standard.  Don't do it again.
--

-- 
Dave Peterson
SGMLWorks!

davep <at> acm.org
Permalink | Reply | 0 comments |

Gmane