headers
Charles Lindsey | 23 Apr 2002 13:30
Picon
Picon

IANA Considerations

I don't think it is really worth putting the whole of section 9 and 10
up on Landfield just for this small change. The only other difference
in that section, apart from typos etc., is the wording in the security
section to cover the Disposition-Notification-To-header and similar
mailbombs, as already reported.

10.  IANA Considerations

   IANA is requested to register the following media types, described
   elsewhere in this standard for use with the Content-Type-header, in
   the IETF tree in accordance with the procedures set out in [RFC
   2048].

      application/news-transmission  (6.21.6.1)
      application/news-groupinfo     (7.2.1.2)
      application/news-checkgroups   (7.2.4.1)

   IANA is also requested to change the status of the following media
   type to "OBSOLETE".

      message/news                   (6.21.6.2)

        NOTE: "Application/news-transmission" is an update, with
        clarification and additional optional parameters, to an existing
        registration. "Message/rfc822" should now be used in place of
        the obsoleted "message/news".

Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: chl <at> clw.cs.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Unknown | 1 May 2002 16:42

Test message of the test <at> landfield.com mail address.

This is a test of your email address. If you receive this mail
please send an acknowledgement back so that I know it made it 
somewhere.  (Then I'll know if you are alive.. ;)) Thanks.

---
Kent Landfield                        Phone: 1-817-545-2502
Email: kent <at> landfield.com             http://www.landfield.com/
Search the Usenet FAQ Archive at http://www.faqs.org/faqs/
Search the RFC/FYI/STD/BCP Archive at http://www.faqs.org/rfcs/

*******************************************************
To unsubscribe send a message to majordomo <at> faqs.org as

	unsubscribe test Kent Landfield <kent>
*******************************************************
Permalink | Reply | 0 comments |
headers
Claus Färber | 1 Apr 2002 13:21
Picon

Re: 8.8.1. Duties of an Outgoing Gateway [yEnc]

Bruce Lilly <blilly <at> erols.com> schrieb/wrote:
> It is also possible to convey that additional information
> via other standard MIME extension headers, e.g.
> Content-Disposition and Content-Features.

No. All Content-* headers describe the same entity. If you chosse  
yEnc to be a Content-Type, then Content-Disposition describes the  
yEnc file.

It is ok, of course, to add mor parameters to the application/ 
[x-]yyencoded type but it should not conflict with the (non- 
standard but frequently used) filename parameter. internal- 
filename might be a better choice.

> There would almost certainly be interoperability problems;
> a minor defect of 2045 and its predecessors is that no
> domain is defined in the case of extension (none have yet
> appeared) or experimental tokens used as Content-Transfer-Encoding
> values.

The problem is, of course, that applications have to scan the body  
anyway: Due to bugs in implementation, the domain implied by the  
CTE is sometimes incorrect (i.e. 7bit instead of 8bit).

Claus
--

-- 
------------------------ http://www.faerber.muc.de/ ------------------------
OpenPGP: DSS 1024/639680F0 E7A8 AADB 6C8A 2450 67EA AF68 48A5 0E63 6396 80F0
(Continue reading)

Permalink | Reply | 0 comments |
headers
Charles Lindsey | 1 Apr 2002 17:58
Picon
Picon

Re: section_6.06.02

In <3CA29698.3B040307 <at> erols.com> Bruce Lilly <blilly <at> erols.com> writes:

>Charles Lindsey wrote:
>> 
>> --- 308,311 ----
>>           NOTE: This differs from the syntax of [RFC 2822] by requiring at
>> !         least one CFWS between the msg-ids (a SP at this point was an
>> !         [RFC 1036] requirement).
>> 
>> ***************

>There appears to be no such _requirement_ in RFC 1036.  At
>most there is the suggestion that a "blank" might precede
>an added msg-id.`

From RFC 1036, 2.2.5:

"If the original message does have a "References" line, the follow-up
message should have a "References" line containing the text of the
original "References" line, a blank, and the Message-ID of the original
message."

That is rather more than a "suggestion" that something "might precede".

In any case, we were told that a lot of existing software breaks without
that blank.

--

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
(Continue reading)

Permalink | Reply | 0 comments |
headers
Erland Sommarskog | 1 Apr 2002 21:39
Picon
Picon

Re: Comments on draft-ietf-usefor-article-06.txt

Bruce Lilly <blilly <at> erols.com> writes:
> "Clive D.W. Feather" wrote:
> > But it introduces the far more serious problems of English month names and
> > the disaster of alphabetic time zone "names".
>
> RFC 2822 forbids use of alphabetic zone designations for generation
> of date-time (while providing for recognition in old headers).
>
> Regarding months, the "names" (actually abbreviations in all but
> one case) have been standard and unchanged since RFC 561, and
> most are derived from Latin (and date from the introduction of
> the Julian calendar).  The main point is that while 04/10
> or 04-10 may be ambiguous "10 Apr", "Apr 10", "4 Oct", and "Oct 4"
> are not.  See the section on date and time in
> http://www.first.org/docs/international_comms.html.

However, month names may be localized, and then you don't know what
happens. "listopad" is the name of a month in both Polish and Croatian, 
but it is not the same month. And anyway, not much software will be
able to correctly interpret all those localized abbreviations.

Yeah, localization may not be permitted, but it is going to happen anyway.

On the other hand, the ISO 8601, with or without the T, is clearly
unambiguous as long as you use four digits for the year. On top of
that it is an international standard, and not a local homebrew for 
a certain community.

Then again, the fact that the RFC 2822 format is in wide use is quite
convincing argument for not using something else for what, after all,
(Continue reading)

Permalink | Reply | 2 comments |
headers
Henry Spencer | 1 Apr 2002 21:59

Re: Comments on draft-ietf-usefor-article-06.txt

On 1 Apr 2002, Erland Sommarskog wrote:
> However, month names may be localized, and then you don't know what
> happens...

Actually, it's easy to know what happens:  the articles get discarded as
soon as they hit a site which enforces the rules strictly. 

RFC 822/2822 months are specified clearly and unconditionally to use one
and only one set of three-letter abbreviations, those of the Norse/Latin
derived names used in English.  It's perfectly acceptable for reading
agents to translate these for viewing by local audiences, but localization
of the on-the-wire format is not permitted.  Not for mail, not for news.

> On the other hand, the ISO 8601, with or without the T, is clearly
> unambiguous as long as you use four digits for the year. On top of
> that it is an international standard, and not a local homebrew for 
> a certain community.

Uh, RFC 2822 *is* an international standard, not a "local homebrew".  It
came out of a different standards process than ISO 8601, but so what?

Note that we're already using RFC 2822 format for the Date header, which
is far more important to a lot of news software than NNTP-Posting-Date. 
You're *not* going to be able to change that.  So why add yet another
format?

                                                          Henry Spencer
                                                       henry <at> spsystems.net
(Continue reading)

Permalink | Reply | 1 comment |
headers
Charles Lindsey | 1 Apr 2002 18:11
Picon
Picon

Re: 8.8.1. Duties of an Outgoing Gateway [yEnc]

In <3caae0df.8524760 <at> mail.infostar.de> infstar <at> infostar.de (Juergen Helbing) writes:

>All these things do not affect the "Usenet message format" draft/RFC.
>Because it will result in a completely different "Usenet binary
>format" draft/RFC and a "how to post binaries to Usenet". 

Which will be yet another ad hoc solution to a problem to which
standardized solutions already exist. I cannot see the IESG allowing that
to be published.

>It was not my intention to "retrigger" the MIME discussion again. I
>did this (in vain) a few times with news-admins, nntp-programmers,
>mail-programmers, in the MIME newsgroup, with a MIME-RFC-creator...
>However it was interesting to follow it again here.

Well I will have a go myself on the ietf-822 list. To do it any other way
is plain crazy.

I supopose at a pinch this WG could define it in an extensions document,
for use in Netnews only.

--

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: chl <at> clw.cs.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
Permalink | Reply | 0 comments |
headers
Charles Lindsey | 1 Apr 2002 18:06
Picon
Picon

Re: section_6.06.02

In <87y9gayzmt.fsf <at> deneb.enyo.de> Florian Weimer <fw <at> deneb.enyo.de> writes:

>Charles Lindsey <chl <at> clw.cs.man.ac.uk> writes:

>> !    None of the headers appearing in this section is required to appear
>> !    in every article but some of them are required in certain types of
>> !    article, such as followups. Any header defined in this (or any other)
>       ^^^^^^^ "articles"?

No, that is correct English usage.

>>         Reply-To-content    = address-list

>   Reply-To: <somebody <at> example.com>

>is rather common.  Does your definition of address-list cover it?

Yes, exactly as RFC 2822.

>> !    1 M. Elkins, D. Del Torto, R. Levien, and T. Roessler,
>> !         "Introduction", RFC 3156, August 2001.

>The title is "MIME Security with OpenPGP".

Would you believe a missing blank line at the end of a file of references?
Oh well, I suppose the whole nroff suite hasn't been touched since AT&T
wrote it in the 1970s :-( .

--

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
(Continue reading)

Permalink | Reply | 0 comments |
headers
Charles Lindsey | 2 Apr 2002 20:43
Picon
Picon

IHAVE and SENDME

Currently, in the IHAVE control message, you can put a list of msg-ids
in the Control-header, or in the body of the control message, but not
both, the latter being the preferred form.

Son-of-1036, however, says both MUST be supported, and our draft
therefore says the same thing.

But on poking around in the code of CNews, I see that it does NOT
support the deprecated in-the-header form at all, and would thus be
non-compliant.

And that would be a pity :-( . So do you think the time has come to
demote the old in-the-header form to SHOULD NOT generate, MAY support?
After all, CNews is the nearest thing we have to a model implementation
of this old stuff.

Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: chl <at> clw.cs.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
Permalink | Reply | 1 comment |
headers
Charles Lindsey | 2 Apr 2002 18:58
Picon
Picon

Re: FW: [idn] Re: 7 bits forever!

	On Mon, 1 Apr 2002 21:21:12 -0800
	"Dan Kohn" <dan <at> dankohn.com> said...

> 
> I thought you might be interested in email below, given your USEFOR
> work.  Feel free to send to USEFOR, if appropriate.

Forwarded as suggested.

>  I would be
> interested in your views on making gateways support downconversion of
> parameter names to 2231 format.

I regard RFC 2231 as a mess that never ought to have happened (an
extension of the applicability of RFC 2047 would have made much more
sense). It's implementation seems to be very patchy. However, there it
is, so we cannot ignore it :-( .

Present plan, when I rewrite the gatewaying bit, is to leave it to
gateways whether they take a chance on leaving the 8bit stuff alone,
or whether to downconvert using RFC 2047 and/or RFC 2231. A particular
gateway will know who its intended clients are, and hence what it can
get away with, and whether it matters or not.
> 
> Also, here's a comment on your -06 USEFOR draft:
> 
> + I would seriously consider referencing RFC 2646 as a SHOULD in section
> 4.3.2, as it significantly improves the chance for automatic
> interpretation of multiple quoting blocks.
(Continue reading)

Permalink | Reply | 1 comment |

Gmane