W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > March 2004

RE: application/rdf+xml registration

From: Graham Klyne <gk@ninebynine.org>
Date: Thu, 18 Mar 2004 08:49:51 +0000
Message-Id: <5.1.0.14.2.20040318083957.02d37008@127.0.0.1>
To: "Scott Hollenbeck" <sah@428cobrajet.net>, "'Ted Hardie'" <hardie@qualcomm.com>
Cc: "'aaron Swartz'" <me@aaronsw.com>, "'RDF core WG'" <w3c-rdfcore-wg@w3.org>, <ned.freed@mrochek.com>

At 13:58 17/03/04 -0500, Scott Hollenbeck wrote:
>Let me know how you wish to proceed:
>
>- registration procedure to be followed
>- 3023 references
>- Informational or standards track

Scott,

My preference, because I think it is least additional work for all 
concerned, is:
- RFC2048 procedure
- Informational RFC
- 3023 references to be added as RFC editors note.  (I'll suggest that 
Aaron adds them and sends the corresponding XML2RFC source file to the RFC 
editor as soon as publication is approved;  cf. [1].)

Thanks for your consideration.

#g
--

[1] http://lists.xml.resource.org/pipermail/xml2rfc/2003-November/000957.html


At 13:58 17/03/04 -0500, Scott Hollenbeck wrote:
>Graham,
>
> > >... I'd prefer to use the procedures described in
> > >draft-freed-mime-p4-04.txt.  That document is sitting in the
> > RFC Editor's
> > >queue in anticipation of obsoleting RFC 2048.  I don't think
> > that means
> > >anything specific to this document would change other than
> > the reference to
> > >2048 (Ned -- would you agree?).
> >
> > I think that will be fine, but (just checking)...
>
>After talking this over a bit with Ted I think we're OK with either method.
>If you started this work assuming use of the older 2048 procedure, let's
>just continue along that path unless you want to use the newer procedures.
>
> > >Anyway, we can treat this document as an individual
> > submission to the IESG
> > >for publication as an Informational document as you
> > requested.  That means
> > >I'll adopt it, request an IETF-wide last call (consider my
> > comments above
> > >last call comments), and we'll follow the usual IESG review
> > and approval
> > >procedures from there.
> >
> > Ah, OK... I hadn't anticipated that IETF last-call was needed for
> > this  (but I don't see any problem with that).  Then I guess
> > it would make
> > sense to include the RFC 3023 reference after LC?
>
>Now that I think about this some more I think we can do without the IETF
>last call as this is just a registration document that's intended for
>Informational status.  I'll leave it up to you, though: Informational -> no
>last call needed, but I'd prefer a last call if this is intended to be a
>standards track document like 3023.  We can add the 3023 references as an
>RFC Editor note if nothing significant comes up during IESG discussion.  You
>can also add them now and rev the document before I take it to the IESG if
>you wish.
>
> > As a matter of procedure, if any issues are raised during the
> > IETF last
> > call that we can show were duly considered during the W3C
> > last call, would
> > you consider that to be an adequate "defence"?  (I have one
> > issue in mind
> > concerning removal of some text from an earlier version of this
> > registration draft, which has been the subject of some
> > ongoing debate, but
> > which I think really represents a rathole that we've
> > adequately explored.
>
>Yes -- if we go that route.  Let me know how you wish to proceed:
>
>- registration procedure to be followed
>- 3023 references
>- Informational or standards track
>
>-Scott-

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact
Received on Thursday, 18 March 2004 04:13:21 EST

This archive was generated by hypermail pre-2.1.9 : Thursday, 18 March 2004 04:13:23 EST