muraw3c | 7 Sep 16:30 2000
Picon

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


In the IETF-XML-MIME ML, Larry Masinter made proposed to slightly
revise the latest draft (draft-murata-xml-07.txt).  Dave Peterson 
agreed.

>    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.

I spoke with my co-authors: Dan Kohn and Simon St. Laurent.  We 
have agreed to accept the proposed change.

Sincerely yours,

IBM Tokyo Research Lab &
International University of Japan, Research Institute

MURATA Makoto (FAMILY Given)

ned.freed | 7 Sep 17:56 2000

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

> In the IETF-XML-MIME ML, Larry Masinter made proposed to slightly
> revise the latest draft (draft-murata-xml-07.txt).  Dave Peterson
> agreed.

> >    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.

> I spoke with my co-authors: Dan Kohn and Simon St. Laurent.  We
> have agreed to accept the proposed change.

Sounds fine to me. Please submit an updated version of the draft.
Unfortunately, given that this is a change to requirements language I think
we'll have to restart the last call, so the sooner the better on this.

				Ned

muraw3c | 8 Sep 07:02 2000
Picon

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

Ned wrote:
> Sounds fine to me. Please submit an updated version of the draft.

I slightly changed Larry's wording, since some external parsed 
entities are well-formed XML documents and are also used as 
XML documents.

    application/xml and text/xml MUST NOT be used for "external DTD
    subsets" and "external parameter entities", and MUST NOT be used for
    "external parsed entities" unless they are also well-formed "document
    entities" and used as such.  Note that RFC2376 (obsoleted) allowed
    this usage, although in practice it is likely to be rare.

> Unfortunately, given that this is a change to requirements language I think
> we'll have to restart the last call, so the sooner the better on this.

I am surprised to hear that this slight change requires four week
review again.  But I will follow your instruction.

IBM Tokyo Research Lab &
International University of Japan, Research Institute

MURATA Makoto

Dan Kohn | 8 Sep 09:06 2000

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

Ned, as you are the Area Director reviewing this spec, we (the co-authors)
will defer to your judgement on the need to restart the Last Call period.

For obvious reasons, we would rather skip the extra month necessary to do
so.  I will also note that Section 6.1.2 of RFC 2026 doesn't set any
specific guidelines for what level of change does or does not require a
restart of Last Call.  Given that the suggested change does not affect the
normal operation of the protocol (where external parsed entities are
supposed to use their own MIME type), and that the issue comes down to how
deal with any existing implementations that (could possibly) differ from the
new spec, I would suggest that it is not a significant change.  We don't
actually have any examples from the wild of software or messages that would
even be affected by this change.  Again, however, we defer to your judgement
as to whether any changes to requirements language mandates a Last Call
restart.

In either event, we'll be submitting the -08 draft tomorrow.

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

-----Original Message-----
From: ned.freed <at> INNOSOFT.COM [mailto:ned.freed <at> INNOSOFT.COM]
Sent: Thursday, 2000-09-07 08:56
To: muraw3c <at> attglobal.net
Cc: ietf-xml-mime <at> imc.org; iesg <at> ietf.org
Subject: RE: Fwd: Last Call: XML Media Types to Proposed Standard

(Continue reading)

muraw3c | 13 Sep 18:15 2000
Picon

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

From: ned.freed <at> INNOSOFT.COM
Subject: RE: Fwd: Last Call: XML Media Types to Proposed Standard
Date: Thu, 07 Sep 2000 08:56:12 -0700 (PDT)

> Sounds fine to me. Please submit an updated version of the draft.
> Unfortunately, given that this is a change to requirements language I think
> we'll have to restart the last call, so the sooner the better on this.

After the minor modification, a new I-D has been published. 
Its URL is:

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

The second edition of XML 1.0 is being prepared and is expected to be
published in the very near future.  At present, it references to RFC
2376.  If the last call has to be really restarted, the second edition
will probably have to continue to reference to RFC 2376.

Cheers,

IBM Tokyo Research Lab &
International University of Japan, Research Institute

MURATA Makoto

Dan Kohn | 14 Sep 08:14 2000

draft-ietf-roamops-phonebook-xml-05.txt

I would recommend adding an appendix to
<http://www.ietf.org/internet-drafts/draft-ietf-roamops-phonebook-xml-05.txt
> where you register a MIME type for a roamops phonebook based on the advice
provided in <http://www.ietf.org/internet-drafts/draft-murata-xml-08.txt>.

It would appear that application/phonebook+xml may be a good choice.

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

pcalhoun@eng.sun.com | 14 Sep 16:03 2000
Picon

Re: draft-ietf-roamops-phonebook-xml-05.txt

Dan,

Given that this particular document has already been through WG, IESG *and*
IETF last call, how strongly do you feel about this proposed appendix?

PatC
> I would recommend adding an appendix to
> <http://www.ietf.org/internet-drafts/draft-ietf-roamops-phonebook-xml-05.txt
> > where you register a MIME type for a roamops phonebook based on the advice
> provided in <http://www.ietf.org/internet-drafts/draft-murata-xml-08.txt>.
> 
> It would appear that application/phonebook+xml may be a good choice.
> 
> 		- dan
> --
> Dan Kohn <mailto:dan <at> dankohn.com>
> <http://www.dankohn.com>  <tel:+1-650-327-2600>

Glen Zorn | 14 Sep 17:26 2000
Picon

RE: draft-ietf-roamops-phonebook-xml-05.txt

I'd be a little stronger -- too late, too bad, write another draft.

> -----Original Message-----
> From: owner-roamops <at> tdmx.rutgers.edu
> [mailto:owner-roamops <at> tdmx.rutgers.edu]On Behalf Of pcalhoun <at> eng.sun.com
> Sent: Thursday, September 14, 2000 7:04 AM
> To: Dan Kohn
> Cc: roamops <at> tdmx.rutgers.edu; ietf-xml-mime <at> imc.org
> Subject: Re: draft-ietf-roamops-phonebook-xml-05.txt
> 
> 
> Dan,
> 
> Given that this particular document has already been through WG, 
> IESG *and*
> IETF last call, how strongly do you feel about this proposed appendix?
> 
> PatC
> > I would recommend adding an appendix to
> > 
> <http://www.ietf.org/internet-drafts/draft-ietf-roamops-phonebook-
> xml-05.txt
> > > where you register a MIME type for a roamops phonebook based 
> on the advice
> > provided in 
> <http://www.ietf.org/internet-drafts/draft-murata-xml-08.txt>.
> > 
> > It would appear that application/phonebook+xml may be a good choice.
> > 
> > 		- dan
(Continue reading)

Dan Kohn | 14 Sep 18:56 2000

RE: draft-ietf-roamops-phonebook-xml-05.txt

Given that <http://www.ietf.org/internet-drafts/draft-murata-xml-08.txt> is
still in IETF last call, I do not think it is necessary to modify your
draft.

Instead, I would suggest an informational supplement with the registration,
or just making a registration straight to IANA (as described in RFC 2048,
with review on ietf-types <at> iana.org).

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

-----Original Message-----
From: pcalhoun <at> eng.sun.com [mailto:Pat.Calhoun <at> Eng.Sun.COM]
Sent: Thursday, 2000-09-14 07:04
To: Dan Kohn
Cc: roamops <at> tdmx.rutgers.edu; ietf-xml-mime <at> imc.org
Subject: Re: draft-ietf-roamops-phonebook-xml-05.txt

Dan,

Given that this particular document has already been through WG, IESG *and*
IETF last call, how strongly do you feel about this proposed appendix?

PatC
> I would recommend adding an appendix to
>
<http://www.ietf.org/internet-drafts/draft-ietf-roamops-phonebook-xml-05.txt
> > where you register a MIME type for a roamops phonebook based on the
(Continue reading)

Mark Baker | 20 Sep 20:48 2000
Picon

Conformance value of "+xml"?

Greetings,

I've been writing the registration of a new media type in the HTML WG
for XHTML using draft-murata-xml-0[78].  In doing this, I've come to the
conclusion that the draft does not provide implementors and authors
enough guarantees in order to be able to do anything more than is done
today without the "+xml" convention.

Before actually implementing the recommendations in this draft, I was
under the impression that using or seeing a media type suffixed with
"+xml" could provide me, as a user agent implementor, certain
guarantees.  However, because of a lack of any MUSTs in 7.1, I am not
guaranteed that *any* of those things in 7.1 actually hold.  It is quite
possible that I could receive a document described as "text/foo+xml",
yet not be able to do anything with it except fallback as text/plain. 
Granted, that isn't any worse than today, but if I wanted that
behaviour, I don't need "+xml" to get it.

Therefore, I'd like to propose the following modifications for 7.1;

- first paragraph; SHOULD to MUST
- second; SHOULD to MUST
- forth; SHOULD to MUST

For the fifth paragraph I'd recommend changing the wording to reflect
that for fragment identifiers at least, registrations are free to
*extend* the syntax, but must at least support the XML syntax;

"These registrations SHOULD also make reference to RFC XXXX in
specifying magic numbers, but MUST reference it for base URIs and use of
(Continue reading)


Gmane