John,
JCK> Does that agree with your analysis, at least to a first order
JCK> approximation?
well (harumph!) i can't let the question stand without answering it...
I trust the assessments you folks have been making about the document,
and I have not seen counter-arguments that looked at a
--On Tuesday, 17 August, 2004 17:38 -0700 Dave Crocker
<[EMAIL PROTECTED]> wrote:
> John,
>
>>> Global parameters are useless if the parser is intelligent
>>> enough to figure out the message structure independently.
>>> Given that such intelligence is a prerequisite to having a
>>> half-baked
On Aug 17, 2004, at 8:38 PM, Dave Crocker wrote:
If someone can summarize where
this thread is going and/or should go, I'd appreciate it.
my recommendation to the author -
- do another edit on the draft, mostly for nits and clarity, and
resubmit for Informational
- don't try to specify the appli
John,
>> Global parameters are useless if the parser is intelligent
>> enough to figure out the message structure independently.
>> Given that such intelligence is a prerequisite to having a
>> half-baked parser, the global parameters are always
>> unnecessary.
JCK> This is a minor point compared
On Mon, 16 Aug 2004, David Meyer wrote:
> David Meyer:inaddr-required draft, very little activity.
>
> Rob Austein:This one's come up before. One issue is that some
> people never get past draft filename. If you look at
> the title it doesn't match that. We
On 8/17/2004 4:06 PM, John C Klensin wrote:
> In that context, unless I completely misunderstand what is going
> on here, the "...prerequisite to having a half-baked parser..."
> assertion borders on the silly. Take the example to which Tony
> has been pointing. Apparently the Solaris version
> You know how many times I go to conferences and end up just
> leaving the bag or whatever the gift is in the hotel room?
> Every single one.
>
> Though, I must say, the bag from Salt Lake City is the best
> one I've ever been given and still use that. So unless
> there is a really high quality b
--On Tuesday, 17 August, 2004 15:09 -0400 "Eric A. Hall"
<[EMAIL PROTECTED]> wrote:
>> To be clear about this, I think there are three choices which
>> we might prefer in descending order:
>>
>> (1) There is a single canonical "wire" format in which
>> these things are transmitted.
>
>
On 8/17/2004 2:09 PM, John C Klensin wrote:
> To be clear about this, I think there are three choices which we
> might prefer in descending order:
>
> (1) There is a single canonical "wire" format in which
> these things are transmitted.
Such a specification would surely dictate "a
--On Tuesday, 17 August, 2004 13:05 -0400
[EMAIL PROTECTED] wrote:
>...
> So - where is the *one true canonical* definition of an mbox
> that actually answers all these basic questions that an
> implementer *needs* to know the answer to?
Or, as an alternative, where is the set of required param
On Mon, 16 Aug 2004 22:47:52 EDT, Tony Hansen said:
> The claim in Appendix A is that there were no authoritative sources of
> documentation for the mbox formats and otherwise it's "only documented
> in anecdotal form". I'm sorry, but the the definitions ARE there, and
> ARE almost always autho
*> From [EMAIL PROTECTED] Tue Aug 17 07:43:22 2004
*> Mime-Version: 1.0 (Apple Message framework v619)
*> Content-Transfer-Encoding: 7bit
*> To: [EMAIL PROTECTED]
*> From: Iljitsch van Beijnum <[EMAIL PROTECTED]>
*> Date: Tue, 17 Aug 2004 16:29:57 +0200
*> X-Spam-Score: 0.0 (/)
*>
Why is the list of internet standards so hard to find?
It seems to me this list deserves top ranking on the first page at
www.ietf.org, but that's certainly not the case. (Try to find it and
see what I mean.)
___
Ietf mailing list
[EMAIL PROTECTED]
htt
13 matches
Mail list logo
