Re: rfc publication suggestions
Vernon Schryver wrote: For "nroff guides" on your own systems, try `man -k roff` and `man -k mdoc`. Script started on Fri Mar 16 17:37:39 2001 % hostname rmsbase.vlsm.org % /sbin/kernelversion 2.2 % man -k roff roff: nothing appropriate % man -f mdoc mdoc: nothing appropriate % exit exit Script done on Fri Mar 16 17:38:18 2001 http://www.google.com/search?hl=enlr=safe=offq=nroff+macros finds 23,900 pages. This is exactly the problem: I could not find any Leslie-Lamport-quality-HOWTO-document for nroff. Who is still using this dino technology anyway? Most RFC authors use that "dino technology," First of all, I define "dino technology" as something where the average age of its producers (not just users) constantly increases. Jon Crowcroft wrote: (rhetorical question, dont answer that:-) Well, an eye for an eye, a rhetorical question for a rhetorical one :-). I am just wondering what you are going to do with your private video tapes. Keep them as is, or transfer them to VCDs, or transfer them to DVDs? Same question for QIC-150s, Reel tapes, etc. regards, -- Rahmat M. Samik-Ibrahim - VLSM-TJT - http://rms46.vlsm.org - Blowfish, n (coup d'poisson) --- a secure blow job -
Re: rfc publication suggestions
In message [EMAIL PROTECTED], "Rahmat M. Samik-Ibrahim" typed: No rocket science, but perhaps archaeology. In the early 1980s, a unix box (68ks, vaxen, et.al.) came with a multi-volume manuals, including an nroff guide. In this millennium, not all distros have nroff guides. Who is still using this dino technology anyway? i use it coz once you have a template, all wp packages are the same effort (esp. for standards) - i also have templatex for latex and word to do the same thing and have worked with people who use frame - i dont understand all this nonsense - they are all equally bad at somethings and some better at others - wysiwyg is pretty much a) bad for people with rsi b) none existent in reality anyhow given the whims of rendering and typesetting backend s/w - actually, groff man pages are not what you need - what you need are MACRO manual pages - groff_ms(7) refers you to ms(7) which is propietary as far as i know (otherise i'd post it:-) by the way, "dino" lasted 140M years - 70 times as long as humans so far, and 7M times as long as IPv4.do you have another 20 year old WP source file you can still process apart from groff? (rhetorical question, dont answer that:-) cheers jon
Re: rfc publication suggestions
I'm even more primitive. I don't use any nroff macros that I don't define myself in the source file. But once you have a template, it's trivial. Anyone who asks me, I send a copy of the source from some previous miscellaneous internet-draft I've done and then they, if they want, just like me, can simply leave the framework there are replace the content of that draft with the draft they want. I have no problems editing this source with emacs, MS Word, BBEdit, or whatever, depending what platform I'm on. Donald From: Jon Crowcroft [EMAIL PROTECTED] To: "Rahmat M. Samik-Ibrahim" [EMAIL PROTECTED] cc: [EMAIL PROTECTED] In-reply-to: Your message of "Thu, 15 Mar 2001 15:34:56 +0700." 3AB07EB0.8E8C2EB3@v lsm.org Date: Thu, 15 Mar 2001 09:22:50 + Message-ID: [EMAIL PROTECTED] X-Loop: [EMAIL PROTECTED] In message [EMAIL PROTECTED], "Rahmat M. Samik-Ibrahim" typed: No rocket science, but perhaps archaeology. In the early 1980s, a unix box (68ks, vaxen, et.al.) came with a multi-volume manuals, including an nroff guide. In this millennium, not all distros have nroff guides. Who is still using this dino technology anyway? i use it coz once you have a template, all wp packages are the same effort (esp. for standards) - i also have templatex for latex and word to do the same thing and have worked with people who use frame - i dont understand all this nonsense - they are all equally bad at somethings and some better at others - wysiwyg is pretty much a) bad for people with rsi b) none existent in reality anyhow given the whims of rendering and typesetting backend s/w - actually, groff man pages are not what you need - what you need are MACRO manual pages - groff_ms(7) refers you to ms(7) which is propietary as far as i know (otherise i'd post it:-) by the way, "dino" lasted 140M years - 70 times as long as humans so far, and 7M times as long as IPv4.do you have another 20 year old WP source file you can still process apart from groff? (rhetorical question, dont answer that:-) cheers jon
Re: rfc publication suggestions
At 12:07 15/03/01, Melinda Shore wrote: I reformatted it with nroff under UWIN, which really worked very well and held no surprises whatsoever. So, it's not even necessary to have access to a Unix or Unix-ish OS to use nroff for document production. Good point, but one doesn't even need UWIN. GNU runoff (groff) is available as a pre-packaged download for Windows. (No, I don't have a URL handy, interested folks should try their favourite search engine to locate a suitable binary). Ran
Re: rfc publication suggestions
At 12:07 PM -0500 3/15/01, Melinda Shore wrote: If you are a technical person and so a past, present, or potential RFC author, you will have your own systems and chances better than even that at least some of them will have `man` and `nroff`. A draft formatted with Word recently crossed my path, and the formatting was *so* bad that the document wasn't readable (for some reason something in the Word - text process deleted all vertical whitespace). I reformatted it with nroff under UWIN, which really worked very well and held no surprises whatsoever. So, it's not even necessary to have access to a Unix or Unix-ish OS to use nroff for document production. Melinda This one is because of a bad printer driver in Windows until 2K. Win2K generic text printer does not have this problem. Don't ask me how I know. Bora
Re: capitulation to closed organizaions (was Re: rfc publication suggestions)
On Tue, 13 Mar 2001 19:03:18 PST, "James P. Salsman" said: P.S. Valdis: TCP requires its input to be buffered. You must have been thinking of RTP or some other UDP-like destroyer of audio quality. No, I wasn't thinking of RTP. What I *specifically* stated was that an MUA would probably record any audio into a temporary file and THEN send it out. YOu don't hit 'SEND' and then 'RECORD' so you ship the data out in real time (at least not for any SMTP I've seen). The situation for HTTP upload is of course different - that *coould* be a case of hitting 'SUBMIT' first and then 'RECORD'. Think - where is your audio in Eudora during the time between when you stop recording and when you hit 'SEND'? Yes, it's in a disk file. ;)
Re: rfc publication suggestions
* however the editor queue can hold things for a very long time, and not just * due to waiting for an author to fix something. (gosh. we haven't * discussed THIS topic in a couple of years...) * * d/ * Dave, If the RFC is held for a long time, it is due to the IESG or to the WG or to the author or to normative references. It is NOT due to formatting, editing, or proof-reading. Bob Braden * * -- * Dave Crocker mailto:[EMAIL PROTECTED] * Brandenburg InternetWorking http://www.brandenburg.com * tel: +1.408.246.8253; fax: +1.408.273.6464 *
Re: capitulation to closed organizaions (was Re: rfc publication suggestions)
At 12:47 12/03/2001 -0800, James P. Salsman wrote: perhaps a more useful mode of discussion would be to determine what criteria should be used for the rfc publication process and whether incremental improvements are possible, independent of encoding changes. When someone submits a new Content-disposition value or parameter registration -- http://xml.resource.org/public/rfc/html/rfc2183.html -- the Area Directors and IESG would be best served to refrain from deferring the registration decision to secretive industry consortia who have only to do with one of the many uses of the header. Does anyone disagree? If so, why? If not, I will re-submit the "device" parameter registration. The registration procedure you refer to starts out 10. Registration of New Content-Disposition Values and Parameters New Content-Disposition values (besides "inline" and "attachment") may be defined only by Internet standards-track documents, or in Experimental documents approved by the Internet Engineering Steering Group. Could you also mention the I-D name of the draft that you think should be published as an Experimental or Standards-track RFC along with this? The reason for the relatively high bar on this one is that (from what I remember, vaguely, from last time, there were people who did not like your approach, but I don't even remember the I-D name) Note that like all IESG decisions, the appeals process can be used if you think that an IESG decision is wrongly done; see RFC 2026. -- Harald Tveit Alvestrand, [EMAIL PROTECTED] +47 41 44 29 94 Personal email: [EMAIL PROTECTED]
Re: capitulation to closed organizaions (was Re: rfc publication suggestions)
At 22:49 12/03/2001 -0800, James P. Salsman wrote: Good point, but here is another example: suppose I sent you a picture as an attachment to an email. Would you like to know whether it was attached from my camera or scanner (or filesystem)? Sure, the datestamps are important, but don't have everything you might want to know. actually all a standard that trusts the end-users can accomplish is whether *the sender wants you to react as if* the picture was sent straight from a camera; he can't verify the origin of the picture. for that purpose, I think "here's my hairdo of the day" in the text preceding the picture is more effective (and more informative) than a content-disposition header. (and I think overloading the content-disposition header is the Wrong Thing, anyway - how the sender composed the message is not a content disposition.) -- Harald Tveit Alvestrand, [EMAIL PROTECTED] +47 41 44 29 94 Personal email: [EMAIL PROTECTED]
RE: rfc publication suggestions
I didn't mean to imply the IESG is doing something wrong deliberately. From personal experience, documents are approved by the IESG that have unresolved IANA considerations. From observation, documents are approved by the IESG that have normative reference issues. The next event is some months later, when the RFC editor picks up the document, and authors are notified of the issues. Are you suggesting that in all, or even most of the cases, authors are unaware of these issues before the RFC was approved by the IESG? Brian -Original Message- From: Keith Moore [mailto:[EMAIL PROTECTED]] Sent: Monday, March 12, 2001 7:18 PM To: Rosen, Brian Cc: [EMAIL PROTECTED] Subject: Re: rfc publication suggestions What happens now is silliness due to the known queue length - we put things in we know are deficient, always assuming we will have the issues resolved before it wends it's way through the queue. Where in the world do you get that idea? I spent four years on IESG and I can't recall a single instance of this happening. Seems like what we have now is a lot of uninformed speculation. Keith
RE: rfc publication suggestions
From: "Rosen, Brian" [EMAIL PROTECTED] Subject: RE: rfc publication suggestions Date: Mon, 12 Mar 2001 16:57:03 -0500 Just as a practical matter from recent experience. Usually, an RFC originates as an IESG approved I-D. Usually, you don't submit nroff for an I-D. The RFC editor never asks if you have nroff The RFC editor sometimes forgets when you offer it. So, even if you have nroff source, you may have to work to get it to the right folks at the right time. Perhaps, the perils of a cost-plus-fixed-fee contract? (Note that I haven't seen the RFC Editor contract, nor have I checked to see if it is public.) Of course a big problem is the decreasing number of IETF people who know nroff, and even fewer that are fluent, and even fewer who would, if they had a choice, choose it. Back when SRI was running the NIC (registering domain names, for those not familiar with ancient history) I understand that they were running stuff on some big, ancient (even at the time) DEC system (DEC-10 or DEC-20 -- I forget because I'm not a DEC guy). Network Solutions apparently underbid SRI's (presumably cost-plus-fixed-fee) proposal and converted all the processes to some Unix platform, (Solaris, I think). So, maybe, just maybe, the use of nroff is an artifact of un-competed cost-plus-fixed-fee contracts, rather than any sort of intellectual sclerosis of the IETF. Or, we could go back to talking about NATs. Never mind... -tjs
Re: capitulation to closed organizaions (was Re: rfc publication suggestions)
James P. Salsman wrote: [...] suppose I sent you a picture as an attachment to an email. Would you like to know whether it was attached from my camera or scanner (or filesystem)? The human reading the email _might_ want to know, in which case the body of the message is the right place to put that information - not a header that they don't (and shouldn't) see. The Content-Disposition header should not be about where the body part _came_from_ - it is about where it should _go_to_ (its Disposition, not its Source). If you think that there is a reason to tell the MUA about the source (personally, I don't see what I would do with such a thing), then argue for a new header that does that (and get mired in the security/trust issues already cited elsewhere), but don't try to change the usage of Disposition.
RE: rfc publication suggestions
note that it is hard for the rfc edior to accept nroff too often people use their own macro packages which are incompatable also too often people change the text between the time that the iesg approves of a doc and when then send it to the rfc editor - so the rfc editor has to check for that Scott
RE: rfc publication suggestions
I didn't mean to imply the IESG is doing something wrong deliberately. From personal experience, documents are approved by the IESG that have unresolved IANA considerations. And things have changed as a result of this sort of past experience. IANA is now much more proactive in this regard than they used to be. In particular, careful review of IANA considerations is now done prior to IESG approval. Ned
RE: rfc publication suggestions
From: Scott Bradner [EMAIL PROTECTED] note that it is hard for the rfc edior to accept nroff too often people use their own macro packages which are incompatable Given the antediluvian, fossilized stability of nroff macros and the very small number of people in this century who have their own macro packages, that is a very strong statement about likely results of using any mark up language, including XML. For example, I guess HTML style sheets are like nroff macros. I recently dabbled with CSS, and tried to use the sample style sheet at http://www.w3.org/TR/REC-CSS2/sample.html. Can you guess what happened when I copied it into my document without changes and asked http://jigsaw.w3.org/css-validator/ ? (That my CSS problem was probably purely my own fault does not weaken the point.) also too often people change the text between the time that the iesg approves of a doc and when then send it to the rfc editor - so the rfc editor has to check for that Is that a comment about nroff or delays? `diff` should work equally well for detecting such changes whether applied to nroff or readable ASCII. Vernon Schryver[EMAIL PROTECTED]
Re: capitulation to closed organizaions (was Re: rfc publication suggestions)
On Mon, 12 Mar 2001 22:49:37 PST, "James P. Salsman" said: It's *conceivable* that your MUA reads directly from your system's equivalent of /dev/microphone, base64's and writes directly to the SMTP datastream outbound Yes, that is what two of my MUAs do on certain platforms, and I think that is also exactly what Qualcomm's Eudora does on multiple platforms. Ouch. What happens if you decide that you want to *cancel* what you've recorded? When I say *directly*, that's what I mean. When the 150th byte of audio is input from the microphone, the SMTP MAIL FROM and RCTP TO have already been sent, the RFC822 headers have been sent, the MIME headers for this recording have already been sent - makes it difficult to cancel at THAT point. A simple thought experiment shows that Eudora does *NOT* do this. Proof - after you finish recording, you *still* have to hit 'send'. Ergo, during the time between 'finish' and 'send', that audio is stored someplace. Certainly "Pocket Outlook" for WinCE also does it, bun until Microsoft gets their act together regarding address book access and scriptable message transmission, I'm not going near any Outlook family products. Whether the buffer is in RAM or on the filesystem is incidental. makes the attachment of multiple bodyparts "interesting" The "inline" vs. "attachment" are still there to indicate whether the part is intended to be presented or stored on arrival. No.. What I *meant* was that unless you spool the audio into a temporary file, as noted above, *creating* the e-mail with multiple attachments is interesting. That kind of thing, and the other scenarios you asked about, are really more of what the filename or internal description fields of audio file formats are for. Right. And your proposal adds more value how? you might make a .forward script to send all your inline audio sent from microphone devices to your wireles PDA or cellphone or voicemail, while ignoring inline audio from other devices. What's the worst Actually, that's probably a bad criterion - I've had people ramble into my voicemail until it fills up, and I don't want THAT being beamed to my cellphone, while ignoring a short but important 10-second audio clip just because it happened to have existed as a disk file at one time. And what do you propose to do about the distinction between an MUA that supports inline recording (and thus tags it "microphone") and the *SAME USER* with the *SAME INTENT* who's message gets tagged with "disk file" merely because the MUA he has installed on *this* machine doesn't support inline recording, so he was forced to attach an audio part he recorded to disk via an external program 15 seconds before? I send it with Eudora, you'll listen to it, I send it with Exmh plus a config hack, you'll listen to it, but I send it with Exmh without config hacks, you'll not listen because it wasn't recorded inline? What's the logic here? In addition, there's another issue here - if you send me an attachment flagged as "microphone", what is the proper handling if I forward the message? When I forward it, it's not microphone, it's a disk file. And it's quite possible that the headers can't be modified because they're covered by a PGP or S/MIME signature. -- Valdis Kletnieks Operating Systems Analyst Virginia Tech
Re: capitulation to closed organizaions (was Re: rfc publication suggestions)
Scott, Thanks for your message: From slawrence virata.com Tue Mar 13 07:38:11 2001 If you think that there is a reason to tell the MUA about the source (personally, I don't see what I would do with such a thing), then argue for a new header that does that (and get mired in the security/trust issues already cited elsewhere), but don't try to change the usage of Disposition. You are absolutly right. I should try a registration for a new part header, "Content-source-device:" and use "X-content-source-device:" in the mean time. Does anyone else think there would be value in such a header, even if it were incompletely reliable? Since this trancends just audio, would VPIM still be an acceptable WG? Cheers, James P.S. Valdis: TCP requires its input to be buffered. You must have been thinking of RTP or some other UDP-like destroyer of audio quality.
Re: rfc publication suggestions
dave have you ever really listened to jkr's presentations about the status of rfc's? i'm assuming that you have not, because if you did, you'd know that the big delays are things like - waiting for waiting for change/disclaimer text from the iesg - waiting for "minor" revisions from the author - waiting for linked documents to reach appropriate maturity levels (so we don't have, eg, an rfc citing an internet-draft). At 02:16 PM 3/12/01 +1100, Dave Crocker wrote: At 01:59 PM 3/12/2001, Steven M. Bellovin wrote: The RFC editor has stated that the conversion step is a minor annoyance, and not a significant source of delay. hmmm. I had heard a second-hand comment to the contrary, but am more than willing to concede the failings of such an information channel. however the editor queue can hold things for a very long time, and not just due to waiting for an author to fix something. (gosh. we haven't discussed THIS topic in a couple of years...) d/ -- Dave Crocker mailto:[EMAIL PROTECTED] Brandenburg InternetWorking http://www.brandenburg.com tel: +1.408.246.8253; fax: +1.408.273.6464
capitulation to closed organizaions (was Re: rfc publication suggestions)
perhaps a more useful mode of discussion would be to determine what criteria should be used for the rfc publication process and whether incremental improvements are possible, independent of encoding changes. When someone submits a new Content-disposition value or parameter registration -- http://xml.resource.org/public/rfc/html/rfc2183.html -- the Area Directors and IESG would be best served to refrain from deferring the registration decision to secretive industry consortia who have only to do with one of the many uses of the header. Does anyone disagree? If so, why? If not, I will re-submit the "device" parameter registration. Cheers, James
Re: rfc publication suggestions
At 02:16 PM 3/12/2001 +1100, Dave Crocker wrote: however the editor queue can hold things for a very long time, and not just due to waiting for an author to fix something. (gosh. we haven't discussed THIS topic in a couple of years...) the most common hold-up that I see is a wait for normative references. That held the MPLS documents up for a year.
RE: rfc publication suggestions
An interesting metric would be the time from the date something enters a queue to the time its status is first changed - i.e. the first time the editor looks at it. I believe that is some number of months. Once the editor picks it up, then its time in queue is more a function of outside influence (waiting for others to do something), then internal processing of the RFC editor. That's my recent experience anyway. I'd love to have a discussion of: What do we WANT the queue time to be What would we have to do to get it there I'd say that time to first action should be a couple of weeks to a month. I'd also like to see if there were some more processes we could put in place so that the text never entered the queue until things we KNOW have to be done, are actually done (like normative references, IANA considerations,). What happens now is silliness due to the known queue length - we put things in we know are deficient, always assuming we will have the issues resolved before it wends it's way through the queue. Of course, it rarely works out that way, and instead the RFC editor gets to be the nagging mother to us all. Maybe we change the process so that a document is looked at immediately for those missing things, and put in a hold queue until they are resolved, and THEN they get into the "real" queue. How much work would it be to scan the document for the normal missing items? Could we allocate people to do that as they enter the process? Brian -Original Message- From: Fred Baker [mailto:[EMAIL PROTECTED]] Sent: Monday, March 12, 2001 4:18 PM To: Dave Crocker Cc: Steven M. Bellovin; [EMAIL PROTECTED] Subject: Re: rfc publication suggestions At 02:16 PM 3/12/2001 +1100, Dave Crocker wrote: however the editor queue can hold things for a very long time, and not just due to waiting for an author to fix something. (gosh. we haven't discussed THIS topic in a couple of years...) the most common hold-up that I see is a wait for normative references. That held the MPLS documents up for a year. - This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by Harald Alvestrand.
Re: rfc publication suggestions
What happens now is silliness due to the known queue length - we put things in we know are deficient, always assuming we will have the issues resolved before it wends it's way through the queue. Where in the world do you get that idea? I spent four years on IESG and I can't recall a single instance of this happening. Seems like what we have now is a lot of uninformed speculation. Keith
Re: capitulation to closed organizaions (was Re: rfc publication suggestions)
Ned, Thanks for your message in reply: When someone submits a new Content-disposition value or parameter registration -- http://xml.resource.org/public/rfc/html/rfc2183.html -- the Area Directors and IESG would be best served to refrain from deferring the registration decision to secretive industry consortia who have only to do with one of the many uses of the header. First of all, since IANA is the resistration agency specified by RFC 2183, you appear to be asserting that IANA is "a secretive industry consortia". Sorry, I meant the W3C, which has multiple, specific, and far-reaching non-disclosure terms even for independent participants as part of its by-laws, completely unlike IANA. My opinion of the W3C's culture of secrecy is so low that I support reverting the entire text/html family of type registrations back to the IETF. I don't know how closely you are watching the progress of the W3C working groups, but many of them are more than a couple of years behind their own schedules. If they were IETF Working Groups, the stalled and blocked WGs would be reviewed and closed, but the W3C needs their lucrative membership fees, the participants love the deductable junkets and ill-informed prestege, so I predict the W3C WGs such as XForms (to which I was referred by the previos Applications AD) will probably be around soaking up time and resources for as long as HTML is being used. Worse yet, some of the people with the most authority in the W3C have clearly vested interests in closed, proprietary protocols such as WAP/WML. Can you think of one function of the W3C that would not be better served by the IESG and IETF? ...the registration of such things as type and disposition parameters has been shown to have nontrivial technical repercussions in fair number of cases. IANA has neither the expertise nor the desire to perform technical evaluations of this sort, so when they come up they usually contact the IESG and ask how to proceed. The way more modern registration procedures work is that the IANA refers registrations it receives to a reviewer appointed by the IESG. The reviewer then reviews the request, applying the registration criteria specified by the relevant standard. If the registration meets those criteria it is approved, it not it is returned with an explanation of what is wrong and how to fix it. That is all I would ask for the "device" disposition parameter registration. But that is nowhere near my experience. What actually happened, was that an Area Director at the time also assumed that the registration had no purpose outside of multipart/form-data HTML upload forms, and told me to wait and see what the W3C decided, when the whole reason that I had filed the registration is that the XForms working group chair and staff contact had told me that they would wait and see what the IESG did with the Content-disposition registration before further agendizing my device-upload proposal. When I pointed out that the situation was a Catch-22, the XForms chair apologized profusely but made it clear that I wasn't allowed to say anything about it. When I balked at that, the W3C complained to my company's Advisory Committee representative, who complained to my Cisco manager, and shortly thereafter I was fired without explaination. Although I still don't know, I suspect I was accused of violating my non-disclosure agreements. I will never forget how I was treated. Not having seen any previous attempt to register a "device" content-disposition parameter Perhaps you've revised this proposal so it uses a new "device" content-disposition parameter. If that's the case, while I see no obvious procedural problem with the registration separate from the overall proposal, I have to wonder what the value of such a parameter is in isolation. Consider multiple devices producing or accepting the same media type. For example, if I send you an email with an audio/basic attachment, is there value in your knowing whether it came directly from my microphone or off of my file system? I think there is. I would really like to know what you think. Is there some better way to communicate the source information? Does anyone disagree? If so, why? I certainly do. See above. And now that you know I was referring to W3C instead of IANA? Keith can probably point you to the original registration request, or let me know if you want me to send a copy. Cheers, James
Re: capitulation to closed organizaions (was Re: rfc publication suggestions)
Valdis, Thanks for your reply: First off, "directly from my microphone" is *highly* unlikely to be incredibly factual. No more or less so than the creation timestamp, which is almost always the first time a file was saved, sometime after it was created. It's *conceivable* that your MUA reads directly from your system's equivalent of /dev/microphone, base64's and writes directly to the SMTP datastream outbound Yes, that is what two of my MUAs do on certain platforms, and I think that is also exactly what Qualcomm's Eudora does on multiple platforms. Certainly "Pocket Outlook" for WinCE also does it, bun until Microsoft gets their act together regarding address book access and scriptable message transmission, I'm not going near any Outlook family products. Whether the buffer is in RAM or on the filesystem is incidental. makes the attachment of multiple bodyparts "interesting" The "inline" vs. "attachment" are still there to indicate whether the part is intended to be presented or stored on arrival. So... what you *really* care about, I suspect, is "was this audio clip recorded while composing the message" or "is this a clip from yesterday he attached". What you want is a *datestamp* of when the recoring was made, and an identification of *who/what* it is a recording of (is it me saying it yesterday, or a sound bite of something Steve Bellovin said at an IETF plenary a while ago)? Good point, but here is another example: suppose I sent you a picture as an attachment to an email. Would you like to know whether it was attached from my camera or scanner (or filesystem)? Sure, the datestamps are important, but don't have everything you might want to know. What if it's a composite of several different audio clips? ... That kind of thing, and the other scenarios you asked about, are really more of what the filename or internal description fields of audio file formats are for. And of course, there's the *biggest* issue - if it's *really* important to know whether it came off the microphone or file system, how do you *verify* the field values? Such source device information isn't any more or less secure than the datestamps -- both can be easily altered. But it is easy to make use of information that might not always be trustworthy. For example, you might make a .forward script to send all your inline audio sent from microphone devices to your wireles PDA or cellphone or voicemail, while ignoring inline audio from other devices. What's the worst that can happen? Someone spoofs your .forward script and you get spam in your cellphone, until you block it. So what? This sort of thing is going to be a problem eventually, and I don't see why it isn't better to address it sooner rather than later. Anyway, you know that you almost always have many Content- headers and this "single parameter" -- while not very useful in isolation -- would preserve important information that would otherwise be lost. Can you think of a better way to keep that information in band? Cheers, James
rfc publication suggestions
At 10:41 AM 3/12/2001, Marshall T. Rose wrote: perhaps a more useful mode of discussion would be to determine what criteria should be used for the rfc publication process and whether incremental improvements are possible, independent of encoding changes. egad, what a constructive suggestion. worthy of starting a new thread. I would like to see a small set of accepted "source" forms, with automated tools for converting them into a small set of presentation forms. The current RFC publication process has some astonishing delays apparently due to the process including a conversion of the source text to nroff. Eliminating that step, or at least automating its equivalent, could only help. d/ ps. I am strongly hopeful about long-term use of XML. My concerns are only about the stage of market development, and as I said, it is progressing nicely. -- Dave Crocker mailto:[EMAIL PROTECTED] Brandenburg InternetWorking http://www.brandenburg.com tel: +1.408.246.8253; fax: +1.408.273.6464
Re: rfc publication suggestions
From: Dave Crocker [EMAIL PROTECTED] ... The current RFC publication process has some astonishing delays apparently due to the process including a conversion of the source text to nroff. Eliminating that step, or at least automating its equivalent, could only help. ... I don't understand that statement. Has the RFC editor stopped accepting nroff? Has the old tool that generates nroff from simple ASCII been lost? Unless things have changed in unlikely and unannounced ways, that people either don't read RFC 2223 or refuse to submit nroff suggests something about some of the nominal issues, including whether the delays matter to authors and whether authors would use a better format. No rocket science (but maybe some patience) is required to write nroff. Thanks to groff, typesetting nroff has become free. Vernon Schryver[EMAIL PROTECTED]
Re: rfc publication suggestions
In message [EMAIL PROTECTED], Dave Cro cker writes: The current RFC publication process has some astonishing delays apparently due to the process including a conversion of the source text to nroff. Eliminating that step, or at least automating its equivalent, could only help. The RFC editor has stated that the conversion step is a minor annoyance, and not a significant source of delay. --Steve Bellovin, http://www.research.att.com/~smb
Re: rfc publication suggestions
At 01:59 PM 3/12/2001, Steven M. Bellovin wrote: The RFC editor has stated that the conversion step is a minor annoyance, and not a significant source of delay. hmmm. I had heard a second-hand comment to the contrary, but am more than willing to concede the failings of such an information channel. however the editor queue can hold things for a very long time, and not just due to waiting for an author to fix something. (gosh. we haven't discussed THIS topic in a couple of years...) d/ -- Dave Crocker mailto:[EMAIL PROTECTED] Brandenburg InternetWorking http://www.brandenburg.com tel: +1.408.246.8253; fax: +1.408.273.6464
Re: rfc publication suggestions
Dave Crocker [EMAIL PROTECTED] writes: ps. I am strongly hopeful about long-term use of XML. My concerns are only about the stage of market development, and as I said, it is progressing nicely. Just to throw out another random data point from someone who tends to rant against XML, my primary objection to XML is as an original source format. I find it very author-hostile due to the verbose tags, the need for rather a lot of markup in the document to take full advantage of the capabilities of the language, and the use of ASCII text for the tags as well as the content (which makes it hard to visually distinguish between content and markup). HTML has all of the same problems. The editors tend to be large black-box sorts of applications without much real control over the result and heavily slanted towards people who adore GUIs and compose documents with lots of pointing and clicking. What would bring me around to accepting the idea of XML as a standardized document format is better converters from markup languages that are either author-friendly (something like POD, SDF, or texinfo) or old enough that people already know them quite well (like LaTeX or *roff). I've seen a lot more things like that recently than I had before, which is hopefully a sign that the use of XML is expanding beyond the people who, due to whatever strange mental quirk :), actually like SGML syntax. Once those converters are pretty common and reasonably solid, I think XML will be a much easier sell. It's certainly pretty clear to me that manually paginated ASCII text with embedded "page headers" that pop up in the middle of the content when being read with a pager isn't ideal as an archival format. The best thing people who are in favor of XML for RFCs could do in my view is to write a few simple converters from much simpler languages that could handle the average RFC. (Even the very simple capabilities of POD are adequate for quite a few RFCs.) Then the people who are just trying to describe a protocol and don't want the document markup getting in their way can use something simple and the people who are trying to communicate complex information that needs a lot of semantic markup can use something with more expressive power. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
