From owner-ietf-msgtrk@mail.imc.org Sat Jul 17 15:51:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04112 for ; Sat, 17 Jul 2004 15:51:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6HJh3qh085237; Sat, 17 Jul 2004 12:43:03 -0700 (PDT) (envelope-from owner-ietf-msgtrk@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6HJh3fD085236; Sat, 17 Jul 2004 12:43:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-msgtrk@mail.imc.org using -f Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6HJh23P085230 for ; Sat, 17 Jul 2004 12:43:03 -0700 (PDT) (envelope-from blilly@erols.com) X-Info: This message was accepted for relay by smtp02.mrf.mail.rcn.net as the sender used SMTP authentication X-Trace: +QCcGwgWqJLqvg3WwMmsrLhLBqNHIHc68d6bM8amXqE= Received: from rrcs-nyc-24-105-138-208.biz.rr.com ([24.105.138.208] helo=mail.blilly.com) by smtp02.mrf.mail.rcn.net with asmtp (Exim 3.35 #7) id 1Blv5O-0006jz-00 for ietf-msgtrk@imc.org; Sat, 17 Jul 2004 15:43:06 -0400 Received: from marty.blilly.com (localhost [127.0.0.1]) by mail.blilly.com with ESMTP id i6HJh60F009457(8.12.10/8.12.10/mail.blilly.com sendmail.mc.mail 1.18 2004/05/15 07:23:45) ; Sat, 17 Jul 2004 15:43:06 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by marty.blilly.com with ESMTP id i6HJh6sO009456(8.12.10/8.12.10/blilly.com submit.mc 1.1 2003/08/26 22:21:33) ; Sat, 17 Jul 2004 15:43:06 -0400 Message-ID: <40F9814A.5010301@erols.com> Date: Sat, 17 Jul 2004 15:43:06 -0400 From: Bruce Lilly Reply-To: ietf-822 mailing list Organization: Bruce Lilly User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us MIME-Version: 1.0 To: ietf-msgtrk mailing list Subject: Has IANA gone mad? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Sent to ietf-822 and ietf-msgtrk mailing lists, cc to iana@iana.og, responses default to ietf-822 Yesterday, "message/tracking-status" appeared in the IANA registry for MIME message media types (http://www.iana.org/assignments/media-types/message/). It lists "RFC-ietf-msgtrk-trkstat-05.txt" as the reference document -- of course there is no such document. The closest existing document is a draft dated March 2003, more than a year old ("Internet drafts are valid for six months"). Why on Earth did this suddenly appear yesterday? The ietf-msgtrk mailing list appears to be dormant; in the last three months the only message to appear on that mailing list's archive are spam messages (http://www.imc.org/ietf-msgtrk/mail-archive/maillist.html). There are fewer than a dozen message in the mailing list archive in the past year, spam included. What's going on?!? From owner-ietf-msgtrk@mail.imc.org Sat Jul 17 18:03:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09819 for ; Sat, 17 Jul 2004 18:03:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6HLtFUk004850; Sat, 17 Jul 2004 14:55:15 -0700 (PDT) (envelope-from owner-ietf-msgtrk@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6HLtF3u004848; Sat, 17 Jul 2004 14:55:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-msgtrk@mail.imc.org using -f Received: from lakermmtao12.cox.net (lakermmtao12.cox.net [68.230.240.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6HLtELS004818; Sat, 17 Jul 2004 14:55:14 -0700 (PDT) (envelope-from sah@428cobrajet.net) Received: from A31P ([68.100.55.187]) by lakermmtao12.cox.net (InterMail vM.6.01.03.02 201-2131-111-104-20040324) with ESMTP id <20040717215510.HDCB25657.lakermmtao12.cox.net@A31P>; Sat, 17 Jul 2004 17:55:10 -0400 From: "Scott Hollenbeck" To: "'ietf-822 mailing list'" , "'ietf-msgtrk mailing list'" Subject: RE: Has IANA gone mad? Date: Sat, 17 Jul 2004 17:55:09 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <40F9814A.5010301@erols.com> Thread-Index: AcRsNnICUShVGnffSWCwaCrgQ6QScAAEXI9w Message-Id: <20040717215510.HDCB25657.lakermmtao12.cox.net@A31P> Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit IANA made the assignment because this document: http://www.ietf.org/internet-drafts/draft-ietf-msgtrk-trkstat-05.txt was approved for publication as a Proposed Standard by the IESG on 2004-03-23 and the document is now in the RFC Editor's queue. The IANA actions have to be completed before the document can be finished by the RFC Editor. The msgtrk working group will be closed once the remaining documents (all of which are in the RFC Editor's queue) are published as RFCs. -Scott- Area Advisor for MSGTRK > -----Original Message----- > From: Bruce Lilly [mailto:blilly@erols.com] > Sent: Saturday, July 17, 2004 3:43 PM > To: ietf-msgtrk mailing list > Subject: Has IANA gone mad? > > > Sent to ietf-822 and ietf-msgtrk mailing lists, cc to > iana@iana.og, responses default to ietf-822 > > Yesterday, "message/tracking-status" appeared in the IANA > registry for MIME message media types > (http://www.iana.org/assignments/media-types/message/). > It lists "RFC-ietf-msgtrk-trkstat-05.txt" as the reference > document -- of course there is no such document. The closest > existing document is a draft dated March 2003, more than a > year old ("Internet drafts are valid for six months"). > > Why on Earth did this suddenly appear yesterday? > > The ietf-msgtrk mailing list appears to be dormant; in the > last three months the only message to appear on that mailing > list's archive are spam messages > (http://www.imc.org/ietf-msgtrk/mail-archive/maillist.html). > There are fewer than a dozen message in the mailing list > archive in the past year, spam included. > > What's going on?!? > > From owner-ietf-msgtrk@mail.imc.org Sun Jul 18 16:22:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00596 for ; Sun, 18 Jul 2004 16:22:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6IKDYcU092561; Sun, 18 Jul 2004 13:13:34 -0700 (PDT) (envelope-from owner-ietf-msgtrk@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6IKDYpd092558; Sun, 18 Jul 2004 13:13:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-msgtrk@mail.imc.org using -f Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6IKDYbN092548; Sun, 18 Jul 2004 13:13:34 -0700 (PDT) (envelope-from blilly@erols.com) X-Info: This message was accepted for relay by smtp02.mrf.mail.rcn.net as the sender used SMTP authentication X-Trace: USOQUYyLwUl8ljR6jOULCuOHP/8HMT9atKRJsjep9FY= Received: from rrcs-nyc-24-105-138-208.biz.rr.com ([24.105.138.208] helo=mail.blilly.com) by smtp02.mrf.mail.rcn.net with asmtp (Exim 3.35 #7) id 1BmI2T-0001uD-00; Sun, 18 Jul 2004 16:13:37 -0400 Received: from marty.blilly.com (localhost [127.0.0.1]) by mail.blilly.com with ESMTP id i6IKDbki005999(8.12.10/8.12.10/mail.blilly.com sendmail.mc.mail 1.18 2004/05/15 07:23:45) ; Sun, 18 Jul 2004 16:13:38 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by marty.blilly.com with ESMTP id i6IKDbBV005997(8.12.10/8.12.10/blilly.com submit.mc 1.1 2003/08/26 22:21:33) ; Sun, 18 Jul 2004 16:13:37 -0400 Message-ID: <40FAD9F1.9050207@erols.com> Date: Sun, 18 Jul 2004 16:13:37 -0400 From: Bruce Lilly Reply-To: "'ietf-822 mailing list'" Organization: Bruce Lilly User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us MIME-Version: 1.0 To: Scott Hollenbeck CC: "'ietf-822 mailing list'" , "'ietf-msgtrk mailing list'" Subject: Re: Has IANA gone mad? References: <20040717215510.HDCB25657.lakermmtao12.cox.net@A31P> In-Reply-To: <20040717215510.HDCB25657.lakermmtao12.cox.net@A31P> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Scott Hollenbeck wrote: > IANA made the assignment because this document: > > http://www.ietf.org/internet-drafts/draft-ietf-msgtrk-trkstat-05.txt > > was approved for publication as a Proposed Standard by the IESG on > 2004-03-23 and the document is now in the RFC Editor's queue. The IANA > actions have to be completed before the document can be finished by the RFC > Editor. While I can understand the rationale, it does pose some difficulties for implementors; lacking an RFC, implementors are at somewhat of a loss to provide justification for handling the MUST, MUST NOT, REQUIRED, etc. provisions of the applicable specification ("Under no circumstances should an Internet-Draft be referenced [...[ nor should a vendor claim compliance with an Internet-Draft" -- RFC 2026). Some coordination between the rfc-editor and IANA would be helpful to implementors. Having the RFC first (which includes the registration template information for the relevant media type) would not be a problem, as I see it. whereas the current situation (registered media type with no document that can be referenced) does pose problems. Ideally the RFC and IANA registration would happen simultaneously; RFC first seems workable, but registration w/o RFC causes difficulties. > The msgtrk working group will be closed once the remaining documents (all of > which are in the RFC Editor's queue) are published as RFCs. It's a shame that the draft in question (16 months old) has a number of oddities -- being based on RFC 1894 -- which have been corrected in RFC 3464 (e.g. reference to "xtext", which would by analogy be equivalent to me pointing out that dictionaries provide a definition of the word "rhinoceros", which is otherwise not used anywhere in this message). So presumably comments such as the "xtext" issue would have to be directed to the RFC editor/authors once the RFC is published. From owner-ietf-msgtrk@mail.imc.org Sun Jul 18 16:49:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01790 for ; Sun, 18 Jul 2004 16:49:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6IKfcQn096674; Sun, 18 Jul 2004 13:41:38 -0700 (PDT) (envelope-from owner-ietf-msgtrk@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6IKfcHl096673; Sun, 18 Jul 2004 13:41:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-msgtrk@mail.imc.org using -f Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6IKfcLK096667 for ; Sun, 18 Jul 2004 13:41:38 -0700 (PDT) (envelope-from ned.freed@mrochek.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LCJQ9JJ7E800005R@mauve.mrochek.com> for ietf-msgtrk@imc.org; Sun, 18 Jul 2004 13:41:36 -0700 (PDT) Date: Sun, 18 Jul 2004 13:25:34 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: Has IANA gone mad? In-reply-to: "Your message dated Sun, 18 Jul 2004 16:13:37 -0400" <40FAD9F1.9050207@erols.com> To: Bruce Lilly Cc: Scott Hollenbeck , "'ietf-822 mailing list'" , "'ietf-msgtrk mailing list'" Message-id: <01LCLXC0O8DU00005R@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <20040717215510.HDCB25657.lakermmtao12.cox.net@A31P> <40FAD9F1.9050207@erols.com> Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > Scott Hollenbeck wrote: > > IANA made the assignment because this document: > > > > http://www.ietf.org/internet-drafts/draft-ietf-msgtrk-trkstat-05.txt > > > > was approved for publication as a Proposed Standard by the IESG on > > 2004-03-23 and the document is now in the RFC Editor's queue. The IANA > > actions have to be completed before the document can be finished by the RFC > > Editor. > While I can understand the rationale, it does pose some difficulties for > implementors; lacking an RFC, implementors are at somewhat of a loss to > provide justification for handling the MUST, MUST NOT, REQUIRED, etc. > provisions of the applicable specification ("Under no circumstances > should an Internet-Draft be referenced [...[ nor should a vendor claim > compliance with an Internet-Draft" -- RFC 2026). Some coordination > between the rfc-editor and IANA would be helpful to implementors. Bruce, I'm sorry, but this is simply absurd. The IANA and the RFC Editor already work together closely to coordinate this sort of thing. Specifically, the editing process has a phase during which the relevant registrations are completed. The actual RFC then gets published in fairly short order after IANA actions are completed. The notion that having dangling reference in the registry for the very short period of time while the publication process is completely is a problem does not pass the laugh test. I doubt very much that implemetors are going to to waste time prowling the registries looking for MIME types to support, and even if some people have taken sufficient leave of their senses to do this sort of thing it is not a practice we should condone. > Having > the RFC first (which includes the registration template information for > the relevant media type) would not be a problem, as I see it. I'm afraid you're dead wrong about this. The reality is that registration problems often don't turn up until the registration has been completed and reviewed as part of the publication process. Failure to perform these action prior to publication can and does lead to errors that have required republication in the past. The approach that's currently used is both practical and has not produced the many operational problems other approaches we've used in the past have had. > whereas > the current situation (registered media type with no document that can > be referenced) does pose problems. I disagree. > Ideally the RFC and IANA registration > would happen simultaneously; RFC first seems workable, but registration w/o > RFC causes difficulties. Ideally, perhaps, but it isn't practical. > > The msgtrk working group will be closed once the remaining documents (all of > > which are in the RFC Editor's queue) are published as RFCs. > It's a shame that the draft in question (16 months old) has a number of > oddities -- being based on RFC 1894 -- which have been corrected in RFC 3464 > (e.g. reference to "xtext", which would by analogy be equivalent to me > pointing out that dictionaries provide a definition of the word "rhinoceros", > which is otherwise not used anywhere in this message). > So presumably comments such as the "xtext" issue would have to be directed to > the RFC editor/authors once the RFC is published. The RFC Editor routinely checks for references to documents that have been obsoleted. So this is almost certainly going to be caught by the editing process. Of course you can always drop the RFC Editor or the authors a note to make sure it gets dealt with. Ned From owner-ietf-msgtrk@mail.imc.org Sun Jul 18 17:49:03 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04833 for ; Sun, 18 Jul 2004 17:49:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6ILeZwa005309; Sun, 18 Jul 2004 14:40:35 -0700 (PDT) (envelope-from owner-ietf-msgtrk@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6ILeZan005307; Sun, 18 Jul 2004 14:40:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-msgtrk@mail.imc.org using -f Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6ILeYvI005296; Sun, 18 Jul 2004 14:40:34 -0700 (PDT) (envelope-from blilly@erols.com) X-Info: This message was accepted for relay by smtp02.mrf.mail.rcn.net as the sender used SMTP authentication X-Trace: 2gaN33rnd+6jSIwHFGBFGEeAda1arYYB1BhFq4k09I0= Received: from rrcs-nyc-24-105-138-208.biz.rr.com ([24.105.138.208] helo=mail.blilly.com) by smtp02.mrf.mail.rcn.net with asmtp (Exim 3.35 #7) id 1BmJOc-0004oA-00; Sun, 18 Jul 2004 17:40:34 -0400 Received: from marty.blilly.com (localhost [127.0.0.1]) by mail.blilly.com with ESMTP id i6ILeZR5006347(8.12.10/8.12.10/mail.blilly.com sendmail.mc.mail 1.18 2004/05/15 07:23:45) ; Sun, 18 Jul 2004 17:40:35 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by marty.blilly.com with ESMTP id i6ILeYoD006345(8.12.10/8.12.10/blilly.com submit.mc 1.1 2003/08/26 22:21:33) ; Sun, 18 Jul 2004 17:40:34 -0400 Message-ID: <40FAEE52.5030109@erols.com> Date: Sun, 18 Jul 2004 17:40:34 -0400 From: Bruce Lilly Reply-To: "'ietf-822 mailing list'" Organization: Bruce Lilly User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us MIME-Version: 1.0 To: ned.freed@mrochek.com CC: "'ietf-822 mailing list'" , "'ietf-msgtrk mailing list'" Subject: Re: Has IANA gone mad? References: <20040717215510.HDCB25657.lakermmtao12.cox.net@A31P> <40FAD9F1.9050207@erols.com> <01LCLXC0O8DU00005R@mauve.mrochek.com> In-Reply-To: <01LCLXC0O8DU00005R@mauve.mrochek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit ned.freed@mrochek.com wrote: > Bruce, I'm sorry, but this is simply absurd. The IANA and the RFC Editor > already work together closely to coordinate this sort of thing. Specifically, > the editing process has a phase during which the relevant registrations are > completed. The actual RFC then gets published in fairly short order > after IANA actions are completed. > > The notion that having dangling reference in the registry for the very short > period of time while the publication process is completely is a problem does > not pass the laugh test. I doubt very much that implemetors are going to to > waste time prowling the registries looking for MIME types to support, and even > if some people have taken sufficient leave of their senses to do this sort of > thing it is not a practice we should condone. I guess we're going to have to agree to disagree about this. I do pay attention to the IANA registries, and I have implemented message/tracking-status including provision for 2.1.9 extended status, the extended action keywords, and the relevant REQUIRED, MUST, and MUST NOT provisions. But I am at a loss to provide a reference justifying doing so. Since the implementation is open source and is not sold, I suppose I could weasel out of the RFC 2026 "vendor" clause, but there is still the "Under no circumstances" clause that is troubling. > I'm afraid you're dead wrong about this. The reality is that registration > problems often don't turn up until the registration has been completed and > reviewed as part of the publication process. Failure to perform these action > prior to publication can and does lead to errors that have required > republication in the past. Is the registration template in the draft of a document intended to become a Proposed Standard not reviewed by the IESG? Doesn't registration in the IETF tree require IESG review and publication as an RFC [RFC 2048 section 2.1.1]? What about RFC 2048 [2.3.1] -- was this proposed registration posted to the ietf-types mailing list for review (I looked at the mailing list archives, but couldn't find anything in the past 4 months-- but there seems to be an awful lot of spam)? >>Ideally the RFC and IANA registration >>would happen simultaneously; RFC first seems workable, but registration w/o >>RFC causes difficulties. > > > Ideally, perhaps, but it isn't practical. In principle, it doesn't seem to me to be a big deal to withhold publication (review is a separate issue) in the registry until the RFC is published... >>So presumably comments such as the "xtext" issue would have to be directed to >>the RFC editor/authors once the RFC is published. > > > The RFC Editor routinely checks for references to documents that have been > obsoleted. So this is almost certainly going to be caught by the editing > process. Of course you can always drop the RFC Editor or the authors a note to > make sure it gets dealt with. In this case it seems that the specific issue mentioned arises because text from RFC 1894 was cloned, and when 1894 was obsoleted, it wasn't updated. It's not a case of "cite by reference", which might have avoided the issue, but of copying of text. From owner-ietf-msgtrk@mail.imc.org Sun Jul 18 19:07:03 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09304 for ; Sun, 18 Jul 2004 19:07:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6IMuNFq017432; Sun, 18 Jul 2004 15:56:23 -0700 (PDT) (envelope-from owner-ietf-msgtrk@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6IMuNBI017431; Sun, 18 Jul 2004 15:56:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-msgtrk@mail.imc.org using -f Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6IMuMu9017419 for ; Sun, 18 Jul 2004 15:56:22 -0700 (PDT) (envelope-from ned.freed@mrochek.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LCJQ9JJ7E800005R@mauve.mrochek.com> for ietf-msgtrk@imc.org; Sun, 18 Jul 2004 15:56:24 -0700 (PDT) Date: Sun, 18 Jul 2004 15:38:50 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: Has IANA gone mad? In-reply-to: "Your message dated Sun, 18 Jul 2004 17:40:34 -0400" <40FAEE52.5030109@erols.com> To: Bruce Lilly Cc: ned.freed@mrochek.com, "'ietf-822 mailing list'" , "'ietf-msgtrk mailing list'" Message-id: <01LCM2248W9W00005R@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <20040717215510.HDCB25657.lakermmtao12.cox.net@A31P> <40FAD9F1.9050207@erols.com> <01LCLXC0O8DU00005R@mauve.mrochek.com> <40FAEE52.5030109@erols.com> Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > > Bruce, I'm sorry, but this is simply absurd. The IANA and the RFC Editor > > already work together closely to coordinate this sort of thing. Specifically, > > the editing process has a phase during which the relevant registrations are > > completed. The actual RFC then gets published in fairly short order > > after IANA actions are completed. > > The notion that having dangling reference in the registry for the very short > > period of time while the publication process is completely is a problem does > > not pass the laugh test. I doubt very much that implemetors are going to to > > waste time prowling the registries looking for MIME types to support, and even > > if some people have taken sufficient leave of their senses to do this sort of > > thing it is not a practice we should condone. > I guess we're going to have to agree to disagree about this. I do pay attention > to the IANA registries, and I have implemented message/tracking-status including > provision for 2.1.9 extended status, the extended action keywords, and the > relevant REQUIRED, MUST, and MUST NOT provisions. But I am at a loss to provide > a reference justifying doing so. Since the implementation is open source and > is not sold, I suppose I could weasel out of the RFC 2026 "vendor" clause, but > there is still the "Under no circumstances" clause that is troubling. I think you worry too much. The fact of the matter is that people, including quite a few major vendors, implement internet-drafts all the time. Heck, they even implement _unapproved_ internet-drafts all the time. (IMO sometimes this is justified but often it isn't.) But AFAIK there have been no sightings of the protocol police swooping down and making arrests. > > I'm afraid you're dead wrong about this. The reality is that registration > > problems often don't turn up until the registration has been completed and > > reviewed as part of the publication process. Failure to perform these action > > prior to publication can and does lead to errors that have required > > republication in the past. > Is the registration template in the draft of a document intended to become a > Proposed Standard not reviewed by the IESG? Of course it is. But if review were the same as actually performing an action, we wouldn't have implementation requirements for progression along the standards track. The fact of the matter is that there can be problems that aren't apparent at the review stage and which only turn up during the registration process. Doesn't registration in the IETF > tree require IESG review and publication as an RFC [RFC 2048 section 2.1.1]? Of course it does. But again, review != actually performing an action. > What about RFC 2048 [2.3.1] -- was this proposed registration posted to the > ietf-types mailing list for review (I looked at the mailing list archives, but > couldn't find anything in the past 4 months-- but there seems to be an awful > lot of spam)? I doubt it, but this step is optional in any case. > >>Ideally the RFC and IANA registration > >>would happen simultaneously; RFC first seems workable, but registration w/o > >>RFC causes difficulties. > > > > > > Ideally, perhaps, but it isn't practical. > In principle, it doesn't seem to me to be a big deal to withhold publication > (review is a separate issue) in the registry until the RFC is published... It creates a situation where additional steps are necessary. IANA has more than enough to do as it is, and experience has shown that adding considerable coordination overhead just to achieve an _extremely_ slight increase in coherency is almost never a good idea. Even granting that such coordination wouldn't cause more problems than it solves, you're letting the costly best be the enemy of the much cheaper plenty good enough. > > > So presumably comments such as the "xtext" issue would have to be directed to > > > the RFC editor/authors once the RFC is published. > > The RFC Editor routinely checks for references to documents that have been > > obsoleted. So this is almost certainly going to be caught by the editing > > process. Of course you can always drop the RFC Editor or the authors a note to > > make sure it gets dealt with. > In this case it seems that the specific issue mentioned arises because text > from RFC 1894 was cloned, and when 1894 was obsoleted, it wasn't updated. > It's not a case of "cite by reference", which might have avoided the issue, > but of copying of text. Again, means exist to correct this sort of thing as part of the editing process. Ned From owner-ietf-msgtrk@mail.imc.org Sun Jul 18 19:44:49 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12160 for ; Sun, 18 Jul 2004 19:44:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6INXsPR024451; Sun, 18 Jul 2004 16:33:54 -0700 (PDT) (envelope-from owner-ietf-msgtrk@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6INXslq024450; Sun, 18 Jul 2004 16:33:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-msgtrk@mail.imc.org using -f Received: from lakermmtao10.cox.net (lakermmtao10.cox.net [68.230.240.29]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6INXqHC024404; Sun, 18 Jul 2004 16:33:52 -0700 (PDT) (envelope-from sah@428cobrajet.net) Received: from A31P ([68.100.55.187]) by lakermmtao10.cox.net (InterMail vM.6.01.03.02 201-2131-111-104-20040324) with ESMTP id <20040718233349.MOWI1052.lakermmtao10.cox.net@A31P>; Sun, 18 Jul 2004 19:33:49 -0400 From: "Scott Hollenbeck" To: "'ietf-822 mailing list'" , Cc: "'ietf-msgtrk mailing list'" Subject: RE: Has IANA gone mad? Date: Sun, 18 Jul 2004 19:33:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <40FAEE52.5030109@erols.com> thread-index: AcRtEAcl9lBchF8NSYuBy9UW17N9HAADojEA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Message-Id: <20040718233349.MOWI1052.lakermmtao10.cox.net@A31P> Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Is the registration template in the draft of a document > intended to become a Proposed Standard not reviewed by the > IESG? Doesn't registration in the IETF tree require IESG > review and publication as an RFC [RFC 2048 section 2.1.1]? > What about RFC 2048 [2.3.1] -- was this proposed registration > posted to the ietf-types mailing list for review (I looked at > the mailing list archives, but couldn't find anything in the > past 4 months-- but there seems to be an awful lot of spam)? Ned was the shepherding AD before I completed the IESG actions on this document. He knows the history better than I do, but I can confirm (as I said in my original reply) that this document _was_ reviewed and approved by the IESG. It _will_ become an RFC. You can check the status, including all of the relevant IESG comments and dates, using the I-D tracker: https://datatracker.ietf.org/public/pidtracker.cgi -Scott- From owner-ietf-msgtrk@mail.imc.org Mon Jul 19 20:06:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12928 for ; Mon, 19 Jul 2004 20:06:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JNnGJ6071078; Mon, 19 Jul 2004 16:49:16 -0700 (PDT) (envelope-from owner-ietf-msgtrk@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6JNnGV5071076; Mon, 19 Jul 2004 16:49:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-msgtrk@mail.imc.org using -f Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JNnGVQ071064; Mon, 19 Jul 2004 16:49:16 -0700 (PDT) (envelope-from blilly@erols.com) X-Info: This message was accepted for relay by smtp02.mrf.mail.rcn.net as the sender used SMTP authentication X-Trace: 1m+bwccM7sPAdZ1r72R/T5gqzTD/73uU+h0BStkfEWI= Received: from 65.105.220.34.ptr.us.xo.net ([65.105.220.34] helo=mail.blilly.com) by smtp02.mrf.mail.rcn.net with asmtp (Exim 3.35 #7) id 1Bmhsl-0000l8-00; Mon, 19 Jul 2004 19:49:19 -0400 Received: from marty.blilly.com (localhost [127.0.0.1]) by mail.blilly.com with ESMTP id i6JNnI8e007044(8.12.10/8.12.10/mail.blilly.com sendmail.mc.mail 1.18 2004/05/15 07:23:45) ; Mon, 19 Jul 2004 19:49:18 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by marty.blilly.com with ESMTP id i6JNnHoo007042(8.12.10/8.12.10/blilly.com submit.mc 1.1 2003/08/26 22:21:33) ; Mon, 19 Jul 2004 19:49:17 -0400 Message-ID: <40FC5DFD.6000708@erols.com> Date: Mon, 19 Jul 2004 19:49:17 -0400 From: Bruce Lilly Reply-To: blilly@erols.com Organization: Bruce Lilly User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us MIME-Version: 1.0 CC: "'ietf-822 mailing list'" , "'ietf-msgtrk mailing list'" Subject: Re: Has IANA gone mad? References: <20040717215510.HDCB25657.lakermmtao12.cox.net@A31P> <40FAD9F1.9050207@erols.com> <01LCLXC0O8DU00005R@mauve.mrochek.com> <40FAEE52.5030109@erols.com> <01LCM2248W9W00005R@mauve.mrochek.com> In-Reply-To: <01LCM2248W9W00005R@mauve.mrochek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit ned.freed@mrochek.com wrote: > I think you worry too much. The fact of the matter is that people, including > quite a few major vendors, implement internet-drafts all the time. Heck, they > even implement _unapproved_ internet-drafts all the time. (IMO sometimes this > is justified but often it isn't.) But AFAIK there have been no sightings of the > protocol police swooping down and making arrests. Sure, there's no enforcement -- but I still want to do the right thing w.r.t. not citing drafts as references. My case is perhaps a bit unusual (the implementation is a validating parser, which can emit a message including references when there's a standards violation or potential interoperability issue). >>>>Ideally the RFC and IANA registration >>>>would happen simultaneously; RFC first seems workable, but registration w/o >>>>RFC causes difficulties. >>> >>> >>>Ideally, perhaps, but it isn't practical. > > >>In principle, it doesn't seem to me to be a big deal to withhold publication >>(review is a separate issue) in the registry until the RFC is published... > > > It creates a situation where additional steps are necessary. IANA has more than > enough to do as it is, and experience has shown that adding considerable > coordination overhead just to achieve an _extremely_ slight increase in > coherency is almost never a good idea. It seems to me that having IANA update the registry *twice* (once with the media type and a bogus pointer to a non-RFC, and then again when the RFC is published) would be more work than updating it *once*. Alternatively, since the registry is in HTML format, the incomplete information could be commented out until RFC publication; if I recall correctly, it's not at all difficult to do in Adobe PageMill 3.0 (which is apparently what IANA uses). The msgtrk issue isn't the first or only (or even the worst) problem; sometime last November, IANA also introduced message/CPIM, and after 8 months or so, there still isn't any RFC reference -- and the draft had already passed its expiration date by last November (the cpim draft expired about a year ago, in July 2003). Now I'm not sure exactly what you meant earlier by "The actual RFC then gets published in fairly short order after IANA actions are completed", but I think we probably have a different idea of what constitutes "fairly short order". I don't want to belabor the point; message/CPIM with no RFC was an annoyance, but was until recently the only unresolved entry in the message media type registry. With the addition of message/tracking-status -- with message/CPIM still unresolved -- I hope I'm not seeing the continuation of a trend. From owner-ietf-msgtrk@mail.imc.org Tue Jul 20 03:11:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25477 for ; Tue, 20 Jul 2004 03:11:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6K72ZII095044; Tue, 20 Jul 2004 00:02:35 -0700 (PDT) (envelope-from owner-ietf-msgtrk@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6K72ZjD095042; Tue, 20 Jul 2004 00:02:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-msgtrk@mail.imc.org using -f Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6K72Y96095010 for ; Tue, 20 Jul 2004 00:02:34 -0700 (PDT) (envelope-from ned.freed@mrochek.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LCNVTXW2O000005R@mauve.mrochek.com> for ietf-msgtrk@imc.org; Tue, 20 Jul 2004 00:02:31 -0700 (PDT) Date: Mon, 19 Jul 2004 23:23:02 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: Has IANA gone mad? In-reply-to: "Your message dated Mon, 19 Jul 2004 19:49:17 -0400" <40FC5DFD.6000708@erols.com> To: Bruce Lilly Cc: "'ietf-822 mailing list'" , "'ietf-msgtrk mailing list'" Message-id: <01LCNXB6S2PY00005R@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <20040717215510.HDCB25657.lakermmtao12.cox.net@A31P> <40FAD9F1.9050207@erols.com> <01LCLXC0O8DU00005R@mauve.mrochek.com> <40FAEE52.5030109@erols.com> <01LCM2248W9W00005R@mauve.mrochek.com> <40FC5DFD.6000708@erols.com> Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > ned.freed@mrochek.com wrote: > > I think you worry too much. The fact of the matter is that people, including > > quite a few major vendors, implement internet-drafts all the time. Heck, they > > even implement _unapproved_ internet-drafts all the time. (IMO sometimes this > > is justified but often it isn't.) But AFAIK there have been no sightings of the > > protocol police swooping down and making arrests. > Sure, there's no enforcement -- but I still want to do the right thing w.r.t. > not citing drafts as references. If you really believe this you're completely missing the point of the IETF process. There are drafts and then there are drafts. Referencing a random draft that Joe Blow put out there is one thing, referencing a draft that has been approved for publication as an RFC is quite another. An approved draft in effect _is_ a standard; it just hasn't completed the publication process yet. I note in passing that it is easy to determine the status of any draft; this is what the datatracker is for. Now, you may argue that there's some chance that a document may change or even be withdrawn between the time it is approved and the time it comes out as an RFC. But the validity of this concern doesn't stand up when you examine the publication record -- there have only been a couple of times this sort of thing has happened. There have been many more cases where something that was approved as proposed standard was substantially changed when the document was revised and republished, so if you're going to get tense about stuff changing on you, you'd best not touch anything that hasn't made it to standard status. > My case is perhaps a bit unusual (the > implementation is a validating parser, which can emit a message including > references when there's a standards violation or potential interoperability > issue). I see nothing unusual about it, nor do I see any problem with such an implementation being based on an approved draft. > > It creates a situation where additional steps are necessary. IANA has more than > > enough to do as it is, and experience has shown that adding considerable > > coordination overhead just to achieve an _extremely_ slight increase in > > coherency is almost never a good idea. > It seems to me that having IANA update the registry *twice* (once with the media > type and a bogus pointer to a non-RFC, and then again when the RFC is published) > would be more work than updating it *once*. Performing several separate actions that require no special coordination is much, much easier than performing even one action that would have to be tightly coordinated. > Alternatively, since the registry > is in HTML format, the incomplete information could be commented out until RFC > publication; if I recall correctly, it's not at all difficult to do in Adobe > PageMill 3.0 (which is apparently what IANA uses). Sorry. The goal here is to get things checked, checked, and rechecked; a commented out registration entry isn't readily visible for authors to check and approve. So, while this might be easy for IANA to do, doing so breaks a much more important aspect of the process. > The msgtrk issue isn't the first or only (or even the worst) problem; sometime > last November, IANA also introduced message/CPIM, and after 8 months or so, there > still isn't any RFC reference -- and the draft had already passed its expiration > date by last November (the cpim draft expired about a year ago, in July 2003). First, draft-ietf-impp-cpim-msgfmt-08.txt was approved as a proposed standard back in October, 2003. (I again note that you could have determined this by checking the datatracker.) Drafts approved for publication do not expire; the notion that this registration was based on a draft that has now expired is totally bogus. Second, this document is currently in 48 hour author review (a fact you could have easily determined by checking the RFC Editor queue), so its publication is imminent. > Now I'm not sure exactly what you meant earlier by "The actual RFC then gets > published in fairly short order after IANA actions are completed", but I think > we probably have a different idea of what constitutes "fairly short order". The editing process for most documents is pretty quick. However, there are sometimes exceptions - a document will have some issue or other that prevents its publication as an RFC from occurring in a timely fashion. If memory serves, draft-ietf-impp-cpim-msgfmt-08.txt was delayed due to some normative references not being available. This sort of thing happens from time to time. > I don't want to belabor the point; message/CPIM with no RFC was an annoyance, but > was until recently the only unresolved entry in the message media type registry. > With the addition of message/tracking-status -- with message/CPIM still unresolved -- > I hope I'm not seeing the continuation of a trend. If the trend you refer to is the immediate appearance of IANA registrations of stuff that appears in approved drafts, it is a trend I for one would love to see continue, regardless of the time it takes for the drafts the registry refers to to complete the publication process. Ned From owner-ietf-msgtrk@mail.imc.org Tue Jul 20 08:12:05 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13431 for ; Tue, 20 Jul 2004 08:12:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KC1UW5007712; Tue, 20 Jul 2004 05:01:30 -0700 (PDT) (envelope-from owner-ietf-msgtrk@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6KC1UCQ007710; Tue, 20 Jul 2004 05:01:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-msgtrk@mail.imc.org using -f Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KC1TkF007698; Tue, 20 Jul 2004 05:01:29 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Received: from d154-5-18-205.bchsia.telus.net (d154-5-18-205.bchsia.telus.net [154.5.18.205]) (authenticated bits=0) by orthanc.ca (8.13.1.Alpha0/8.13.1.Alpha0) with ESMTP id i6KC1KXV061748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jul 2004 06:01:22 -0600 (MDT) Date: Tue, 20 Jul 2004 05:01:15 -0700 From: Lyndon Nerenberg To: ned+ietf-822@mrochek.com, Bruce Lilly cc: "'ietf-822 mailing list'" , "'ietf-msgtrk mailing list'" Subject: Re: Has IANA gone mad? Message-ID: <6D05B6DEF454ADDA7AC2A1E3@d154-5-18-205.bchsia.telus.net> In-Reply-To: <01LCNXB6S2PY00005R@mauve.mrochek.com> References: <20040717215510.HDCB25657.lakermmtao12.cox.net@A31P> <40FAD9F1.9050207@erols.com> <01LCLXC0O8DU00005R@mauve.mrochek.com> <40FAEE52.5030109@erols.com> <01LCM2248W9W00005R@mauve.mrochek.com> <40FC5DFD.6000708@erols.com> <01LCNXB6S2PY00005R@mauve.mrochek.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on orthanc.ca Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit --On 2004-7-19 11:23 PM -0700 ned+ietf-822@mrochek.com wrote: > I note in passing that it is easy to determine the status of any > draft; this is what the datatracker is for. And I note in passing, for the UMPTEENTH time, that the bloody datatracker is buried in such a non-obvious place that expecting anyone to use it is pointless. (Use it? How on earth do you expect anyone to even FIND it?) Either put the bloody thing UP FRONT ON THE RFC AND ID pages at ietf.org, or burn it. --lyndon From owner-ietf-msgtrk@mail.imc.org Tue Jul 20 08:43:39 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15457 for ; Tue, 20 Jul 2004 08:43:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KCWiE2012753; Tue, 20 Jul 2004 05:32:44 -0700 (PDT) (envelope-from owner-ietf-msgtrk@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6KCWilA012750; Tue, 20 Jul 2004 05:32:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-msgtrk@mail.imc.org using -f Received: from aaryn.lunarpages.com (aaryn.lunarpages.com [216.193.217.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KCWhT4012735; Tue, 20 Jul 2004 05:32:43 -0700 (PDT) (envelope-from sah@428cobrajet.net) Received: from h87.s239.netsol.com ([216.168.239.87] helo=dul1shollenbl1) by aaryn.lunarpages.com with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1Bmtng-0004Ab-1B; Tue, 20 Jul 2004 05:32:52 -0700 From: "Scott Hollenbeck" To: "'Lyndon Nerenberg'" Cc: "'ietf-822 mailing list'" , "'ietf-msgtrk mailing list'" Subject: RE: Has IANA gone mad? Date: Tue, 20 Jul 2004 08:32:27 -0400 Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF02E0F6FC@vsvapostal8.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <6D05B6DEF454ADDA7AC2A1E3@d154-5-18-205.bchsia.telus.net> Importance: Normal X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - aaryn.lunarpages.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - 428cobrajet.net Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6KCWhT4012736 Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit > And I note in passing, for the UMPTEENTH time, that the bloody > datatracker is buried in such a non-obvious place that > expecting anyone > to use it is pointless. (Use it? How on earth do you expect anyone to > even FIND it?) > > Either put the bloody thing UP FRONT ON THE RFC AND ID pages at > ietf.org, or burn it. Among any of those umpteen times, did you happen to mention the situation to the IETF Secretariat? If brought to their attention I'm sure they'd be willing to put a link to the tracker in an obvious place. I'll send a request myself momentarily. -Scott- From owner-ietf-msgtrk@mail.imc.org Tue Jul 20 09:52:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20056 for ; Tue, 20 Jul 2004 09:52:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KDgWQI025242; Tue, 20 Jul 2004 06:42:32 -0700 (PDT) (envelope-from owner-ietf-msgtrk@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6KDgWYO025240; Tue, 20 Jul 2004 06:42:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-msgtrk@mail.imc.org using -f Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KDgVXg025230; Tue, 20 Jul 2004 06:42:31 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Received: from d154-5-18-205.bchsia.telus.net (d154-5-18-205.bchsia.telus.net [154.5.18.205]) (authenticated bits=0) by orthanc.ca (8.13.1.Alpha0/8.13.1.Alpha0) with ESMTP id i6KDgS1w062085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jul 2004 07:42:30 -0600 (MDT) Date: Tue, 20 Jul 2004 06:42:22 -0700 From: Lyndon Nerenberg To: Scott Hollenbeck cc: "'ietf-822 mailing list'" , "'ietf-msgtrk mailing list'" Subject: RE: Has IANA gone mad? Message-ID: <81BA4F0360B27D328E4EB0A7@d154-5-18-205.bchsia.telus.net> In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF02E0F6FC@vsvapostal8.vcorp.ad.vrsn.com> References: <5BEA6CDB196A4241B8BE129D309AA4AF02E0F6FC@vsvapostal8.vcorp. ad.vrsn.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on orthanc.ca Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit --On 2004-7-20 8:32 AM -0400 Scott Hollenbeck wrote: > Among any of those umpteen times, did you happen to mention the > situation to the IETF Secretariat? If brought to their attention I'm > sure they'd be willing to put a link to the tracker in an obvious > place. Yes (via the AD (Ned), and to the RFC Editor). (And I suspect via ietf@, although it has been long enough that I no longer remember.) --lyndon From owner-ietf-msgtrk@mail.imc.org Tue Jul 20 20:05:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06519 for ; Tue, 20 Jul 2004 20:05:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KNuLwh004834; Tue, 20 Jul 2004 16:56:21 -0700 (PDT) (envelope-from owner-ietf-msgtrk@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6KNuLH0004833; Tue, 20 Jul 2004 16:56:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-msgtrk@mail.imc.org using -f Received: from PC_hipolito.net (dns.sil.edu.pe [64.76.72.108]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6KNuFOh004826 for ; Tue, 20 Jul 2004 16:56:20 -0700 (PDT) (envelope-from steve.hole@messagingdirect.com) Date: Tue, 20 Jul 2004 18:56:27 -0500 To: "Ietf-msgtrk" From: "Steve.hole" Subject: Re: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------ritsaelwzbucvmzspqmo" Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----------ritsaelwzbucvmzspqmo Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >fotogalary and Music


----------ritsaelwzbucvmzspqmo Content-Type: application/octet-stream; name="New_MP3_Player.scr" Content-Disposition: attachment; filename="New_MP3_Player.scr" Content-Transfer-Encoding: base64 ----------ritsaelwzbucvmzspqmo-- From owner-ietf-msgtrk@mail.imc.org Fri Jul 23 11:06:52 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00532 for ; Fri, 23 Jul 2004 11:06:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6NEuDgk039760; Fri, 23 Jul 2004 07:56:13 -0700 (PDT) (envelope-from owner-ietf-msgtrk@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6NEuDEO039758; Fri, 23 Jul 2004 07:56:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-msgtrk@mail.imc.org using -f Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6NEuCwi039743 for ; Fri, 23 Jul 2004 07:56:12 -0700 (PDT) (envelope-from ned.freed@mrochek.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LCRMW93E0W00005R@mauve.mrochek.com> for ietf-msgtrk@imc.org; Fri, 23 Jul 2004 07:52:02 -0700 (PDT) Date: Fri, 23 Jul 2004 07:46:22 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: Has IANA gone mad? In-reply-to: "Your message dated Tue, 20 Jul 2004 05:01:15 -0700" <6D05B6DEF454ADDA7AC2A1E3@d154-5-18-205.bchsia.telus.net> To: Lyndon Nerenberg Cc: ned+ietf-822@mrochek.com, Bruce Lilly , "'ietf-822 mailing list'" , "'ietf-msgtrk mailing list'" Message-id: <01LCSKLBW9D800005R@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <20040717215510.HDCB25657.lakermmtao12.cox.net@A31P> <40FAD9F1.9050207@erols.com> <01LCLXC0O8DU00005R@mauve.mrochek.com> <40FAEE52.5030109@erols.com> <01LCM2248W9W00005R@mauve.mrochek.com> <40FC5DFD.6000708@erols.com> <01LCNXB6S2PY00005R@mauve.mrochek.com> <6D05B6DEF454ADDA7AC2A1E3@d154-5-18-205.bchsia.telus.net> Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > --On 2004-7-19 11:23 PM -0700 ned+ietf-822@mrochek.com wrote: > > I note in passing that it is easy to determine the status of any > > draft; this is what the datatracker is for. > And I note in passing, for the UMPTEENTH time, that the bloody > datatracker is buried in such a non-obvious place that expecting anyone > to use it is pointless. (Use it? How on earth do you expect anyone to > even FIND it?) > Either put the bloody thing UP FRONT ON THE RFC AND ID pages at > ietf.org, or burn it. Yes, well, I've passed your concern about this on in the past. The response was to add a link at the top of the IESG Activities/Actions page, the logic being that the status tracker is an IESG entity. (I note that a link to the RFC Editor queue appears in a similar position under the "RFC Pages" link.) I personally would prefer to have a link on the main IETF page but nobody else seems to think this is appropriate. OTOH, there are these things called bookmarks. You only have to find it once... Ned From owner-ietf-msgtrk@mail.imc.org Fri Jul 23 11:32:02 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02311 for ; Fri, 23 Jul 2004 11:32:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6NFMrSZ042108; Fri, 23 Jul 2004 08:22:53 -0700 (PDT) (envelope-from owner-ietf-msgtrk@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6NFMrgT042106; Fri, 23 Jul 2004 08:22:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-msgtrk@mail.imc.org using -f Received: from aaryn.lunarpages.com (aaryn.lunarpages.com [216.193.217.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6NFMqBF042095; Fri, 23 Jul 2004 08:22:52 -0700 (PDT) (envelope-from sah@428cobrajet.net) Received: from h87.s239.netsol.com ([216.168.239.87] helo=dul1shollenbl1) by aaryn.lunarpages.com with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1Bo1t8-0006Nq-3F; Fri, 23 Jul 2004 08:23:10 -0700 From: "Scott Hollenbeck" To: , "'Lyndon Nerenberg'" Cc: "'ietf-822 mailing list'" , "'ietf-msgtrk mailing list'" Subject: RE: Has IANA gone mad? Date: Fri, 23 Jul 2004 11:22:44 -0400 Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF02E0F729@vsvapostal8.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <01LCSKLBW9D800005R@mauve.mrochek.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - aaryn.lunarpages.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - 428cobrajet.net Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Yes, well, I've passed your concern about this on in the > past. The response was > to add a link at the top of the IESG Activities/Actions page, > the logic being > that the status tracker is an IESG entity. (I note that a > link to the RFC > Editor queue appears in a similar position under the "RFC > Pages" link.) I > personally would prefer to have a link on the main IETF page > but nobody else > seems to think this is appropriate. FWIW there's now a link on the Internet-Drafts page: http://www.ietf.org/ID.html -Scott- From owner-ietf-msgtrk@mail.imc.org Sat Jul 24 00:09:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13855 for ; Sat, 24 Jul 2004 00:09:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6O3xsFF091071; Fri, 23 Jul 2004 20:59:54 -0700 (PDT) (envelope-from owner-ietf-msgtrk@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6O3xs3r091069; Fri, 23 Jul 2004 20:59:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-msgtrk@mail.imc.org using -f Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6O3xrpQ091057; Fri, 23 Jul 2004 20:59:53 -0700 (PDT) (envelope-from blilly@erols.com) X-Info: This message was accepted for relay by smtp02.mrf.mail.rcn.net as the sender used SMTP authentication X-Trace: Y/x6XyzVpGIDf8O649a5BG64gpz32pASJsR7GSQFDes= Received: from rrcs-nyc-24-105-138-208.biz.rr.com ([24.105.138.208] helo=mail.blilly.com) by smtp02.mrf.mail.rcn.net with asmtp (Exim 3.35 #7) id 1BoDhX-00078x-00; Fri, 23 Jul 2004 23:59:59 -0400 Received: from marty.blilly.com (localhost [127.0.0.1]) by mail.blilly.com with ESMTP id i6O3xwaX008601(8.12.10/8.12.10/mail.blilly.com sendmail.mc.mail 1.18 2004/05/15 07:23:45) ; Sat, 24 Jul 2004 00:00:00 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by marty.blilly.com with ESMTP id i6O3xvOx008599(8.12.10/8.12.10/blilly.com submit.mc 1.1 2003/08/26 22:21:33) ; Fri, 23 Jul 2004 23:59:57 -0400 Message-ID: <4101DEBC.1040103@erols.com> Date: Fri, 23 Jul 2004 23:59:56 -0400 From: Bruce Lilly Reply-To: "'ietf-822 mailing list'" Organization: Bruce Lilly User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us MIME-Version: 1.0 To: ned.freed@mrochek.com CC: "'ietf-822 mailing list'" , "'ietf-msgtrk mailing list'" Subject: Re: Has IANA gone mad? References: <20040717215510.HDCB25657.lakermmtao12.cox.net@A31P> <40FAD9F1.9050207@erols.com> <01LCLXC0O8DU00005R@mauve.mrochek.com> <40FAEE52.5030109@erols.com> <01LCM2248W9W00005R@mauve.mrochek.com> <40FC5DFD.6000708@erols.com> <01LCNXB6S2PY00005R@mauve.mrochek.com> In-Reply-To: <01LCNXB6S2PY00005R@mauve.mrochek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit ned.freed@mrochek.com wrote: > There are drafts and then there are drafts. Referencing a random draft > that Joe Blow put out there is one thing, referencing a draft that has been > approved for publication as an RFC is quite another. An approved draft in > effect _is_ a standard; it just hasn't completed the publication process yet. From the point of view of being able to say RFC NNNN section W.X.Y.Z says foo is prohibited/required, a draft is a draft and there is no RFC until there is an assigned RFC number. > I note in passing that it is easy to determine the status of any draft; > this is what the datatracker is for. I have no idea who this Darth Racker person is :-). I know about the rfc-index on the isi.edu ftp site. If RFC 3232 hadn't superseded the Assigned Numbers RFC with the IANA web-based "database" that prompted this discussion, I'd still be checking RFC XX00 (RFC 1700 successor) for the relevant assigned numbers. I haven't looked at the IESG home page in probably a year or more -- why should I; I haven't seen any RFC listed in the rfc-index declaring the rfc-index obsolete. > so if you're going to get tense about stuff changing on you, > you'd best not touch anything that hasn't made it to standard status. Change isn't the problem, it's having (or not having) a stable document which can be referenced w.r.t. specific requirements and/or prohibitions (recommendations, etc.). Since "published RFCs never change" (except when they're revised via errata), an RFC may be referenced, whereas referring to a draft is verboten. To give more perspective on the situation, I have no problem in referring to 30-year-old RFCs where appropriate (it is occasionally necessary to read old email, for example) with confidence that the referenced RFC hasn't changed since publication (modulo published errata), and that the referenced RFC is available to anybody who cares to refer to it (modulo hard disk crashes at ISI). > I see nothing unusual about it, nor do I see any problem with such an > implementation being based on an approved draft. Until publication, there's no RFC number to refer to. And the draft is ephemeral; it is (theoretically) removed after 6 months. A validating parser validates according to a collection of specifications and in the event of a violation of some provision, it is desirable (to say the least) to refer to the particular specification which applies. For example, while RFC 2822 has no requirement w.r.t. the number of message header fields specifying recipients, RFCs 822, 733, and 724 do/did require at least one of To, Cc, or Bcc header fields. And as you know, MIME message/rfc822 has yet a different set of requirements. It does no good (ignoring the prohibition against referring to drafts for the moment) to refer to draft-foo-bar-baz-MM as a specification, not only because that specification might change, but also because it may be unavailable in future to those who wish to consult that reference. > First, draft-ietf-impp-cpim-msgfmt-08.txt was approved as a proposed standard > back in October, 2003. (I again note that you could have determined this by > checking the datatracker.) Again, I know nothing about "datatracker", and judging by recent comments here, I'm not the only one. [And putting a link on some obscure web page isn't likely to change that.] If the draft was approved, what is its RFC number? > Drafts approved for publication do not expire; the > notion that this registration was based on a draft that has now expired is > totally bogus. So drafts expire after six months except when they don't. Okaaaaay... And when something suddenly appears in the IANA registry with no reference in the rfc-index, all there is is (maybe) some draft which nobody is supposed to refer to because "drafts are not standards". No RFC number to refer to. > Second, this document is currently in 48 hour author review (a fact you could > have easily determined by checking the RFC Editor queue), so its publication is > imminent. I see no mention of any "queue" in the rfc-index. And today, well over 48 hours after your message, I still see no RFC corresponding to either the CPIM or msgtrk drafts in the latest rfc-index. So not only do we apparently have a different concept of "fairly short order", but also of "48 hours" and/or "imminent". > If the trend you refer to is the immediate appearance of IANA registrations of > stuff that appears in approved drafts, it is a trend I for one would love to > see continue, regardless of the time it takes for the drafts the registry > refers to to complete the publication process. The trend is the departure from the situation prior to the discontinuation of the Assigned Numbers RFC, where the assigned numbers could be easily referenced back to a published RFC. The change to a web-based conglomeration has happened, and I have adapted -- despite many seemingly irrelevant changes to formatting, inconsistencies (text files for some items, HTML for others, etc.), spurious changes to the modification dates with no substantive change to the content, etc. However, the appearance of registered magic "numbers" prior to publication of an RFC that can be referenced is a great departure from the situation that existed when the Assigned Numbers RFC was periodically published. From owner-ietf-msgtrk@mail.imc.org Sat Jul 24 12:57:12 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28815 for ; Sat, 24 Jul 2004 12:57:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OGiYpV040259; Sat, 24 Jul 2004 09:44:34 -0700 (PDT) (envelope-from owner-ietf-msgtrk@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6OGiYFw040258; Sat, 24 Jul 2004 09:44:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-msgtrk@mail.imc.org using -f Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OGiWI9040245 for ; Sat, 24 Jul 2004 09:44:33 -0700 (PDT) (envelope-from ned.freed@mrochek.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LCT8L6LZHS00005R@mauve.mrochek.com> for ietf-msgtrk@imc.org; Sat, 24 Jul 2004 09:44:31 -0700 (PDT) Date: Sat, 24 Jul 2004 09:12:49 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: Has IANA gone mad? In-reply-to: "Your message dated Fri, 23 Jul 2004 23:59:56 -0400" <4101DEBC.1040103@erols.com> To: Bruce Lilly Cc: ned.freed@mrochek.com, "'ietf-822 mailing list'" , "'ietf-msgtrk mailing list'" Message-id: <01LCU2T4WZNM00005R@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <20040717215510.HDCB25657.lakermmtao12.cox.net@A31P> <40FAD9F1.9050207@erols.com> <01LCLXC0O8DU00005R@mauve.mrochek.com> <40FAEE52.5030109@erols.com> <01LCM2248W9W00005R@mauve.mrochek.com> <40FC5DFD.6000708@erols.com> <01LCNXB6S2PY00005R@mauve.mrochek.com> <4101DEBC.1040103@erols.com> Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > > There are drafts and then there are drafts. Referencing a random draft > > that Joe Blow put out there is one thing, referencing a draft that has been > > approved for publication as an RFC is quite another. An approved draft in > > effect _is_ a standard; it just hasn't completed the publication process yet. > From the point of view of being able to say RFC NNNN section W.X.Y.Z says > foo is prohibited/required, a draft is a draft and there is no RFC until > there is an assigned RFC number. But there is a document that has been approved at some standard level. Standard != RFC. > > I note in passing that it is easy to determine the status of any draft; > > this is what the datatracker is for. > I have no idea who this Darth Racker person is :-). I know about the > rfc-index on the isi.edu ftp site. If RFC 3232 hadn't superseded > the Assigned Numbers RFC with the IANA web-based "database" that prompted > this discussion, I'd still be checking RFC XX00 (RFC 1700 successor) > for the relevant assigned numbers. I haven't looked at the IESG home > page in probably a year or more -- why should I; I haven't seen any RFC > listed in the rfc-index declaring the rfc-index obsolete. Sigh. Nobody ever claimed that the RFC Index is obsolete, only that it doesn't tell the whole story. Reductio ad absurdum weakens your argument, it does not strengthen it. > > so if you're going to get tense about stuff changing on you, > > you'd best not touch anything that hasn't made it to standard status. > Change isn't the problem, it's having (or not having) a stable > document which can be referenced w.r.t. specific requirements and/or > prohibitions (recommendations, etc.). You're missing the point. An approved draft is a document that isn't supposed to change in any significant way prior to publication as an RFC. Cases where changes have occurred are much rarer than cases where an RFC is obsoleted by something that's substantially different than the original. > Since "published RFCs never > change" (except when they're revised via errata), an RFC may be > referenced, whereas referring to a draft is verboten. And if this concerns you you should wait until the RFC is out. > > First, draft-ietf-impp-cpim-msgfmt-08.txt was approved as a proposed standard > > back in October, 2003. (I again note that you could have determined this by > > checking the datatracker.) > Again, I know nothing about "datatracker", and judging by recent comments > here, I'm not the only one. [And putting a link on some obscure web page isn't > likely to change that.] The other comments, such as they are, were from people concerned that it was hard to find the tracker page. They most certainly weren't ignorant of its existance, as apparently you were. > If the draft was approved, what is its RFC number? You are being absurd again. Approval of documents has never coincided with RFC publication for at least as long as I've been a participant in the IETF - that is, since 1989. Maybe it did before that - I wouldn't know. > > Drafts approved for publication do not expire; the > > notion that this registration was based on a draft that has now expired is > > totally bogus. > So drafts expire after six months except when they don't. Okaaaaay... It most certainly is OK, your sarcasm notwithstanding. And when the document is published the draft is replaced with a tombstone pointing at the published RFC. > And when something suddenly appears in the IANA registry with no reference > in the rfc-index, all there is is (maybe) some draft which nobody is > supposed to refer to because "drafts are not standards". No RFC number to > refer to. > > Second, this document is currently in 48 hour author review (a fact you could > > have easily determined by checking the RFC Editor queue), so its publication is > > imminent. > I see no mention of any "queue" in the rfc-index. Your ignorance of the process the RFC Editor has been using for quite a while now doesn't do your argument any good. > And today, well over 48 > hours after your message, I still see no RFC corresponding to either the > CPIM or msgtrk drafts in the latest rfc-index. So not only do we apparently > have a different concept of "fairly short order", but also of "48 hours" > and/or "imminent". Once the RFC is complete the RFC Editor asks authors for review. The review is supposed to be done within 48 hours. However, since this is a volunteer organization the RFC Editor has no ability to insist on timely review. Rather than published something that the authors haven't had a chance to look at (which has been shown over and over and over again to result in documents full of errors), the RFC Editor generally will extend the period as needed. Additionally, if the author finds typographical errors in the draft the token goes back to the RFC Editor to deal with the errors. So the final step can take longer in some cases. > > If the trend you refer to is the immediate appearance of IANA registrations of > > stuff that appears in approved drafts, it is a trend I for one would love to > > see continue, regardless of the time it takes for the drafts the registry > > refers to to complete the publication process. > The trend is the departure from the situation prior to the discontinuation > of the Assigned Numbers RFC, where the assigned numbers could be easily > referenced back to a published RFC. The change to a web-based conglomeration > has happened, and I have adapted -- despite many seemingly irrelevant changes > to formatting, inconsistencies (text files for some items, HTML for others, > etc.), spurious changes to the modification dates with no substantive change > to the content, etc. However, the appearance of registered magic "numbers" > prior to publication of an RFC that can be referenced is a great departure > from the situation that existed when the Assigned Numbers RFC was periodically > published. Bruce, I'm afraid I find your position to be totally without merit, preposterous, and absurd. I also find your apparent ignorance of the IETF process and the tools used to support that process to be nothing short of appalling. Things like the RFC Editor queue and the datatracker were introduced years ago with not inconsiderable fanfare. They have also been discussed at great length on various lists. In any case, I no longer have time to waste on this silly arugment, so this will be my final message on the topic. Ned