headers
David Paul Zimmerman | 6 Apr 1991 21:12
Picon

new 822 list is alive!

The IETF SMTP list's address is ietf-smtp <at> dimacs.rutgers.edu.  The list's
maintainer is ietf-smtp-request <at> dimacs.rutgers.edu.  An archive of the mailing
list is available via anonymous FTP from dimacs.rutgers.edu in
pub/ietf-smtp-archive.

The IETF 822 list's address is ietf-822 <at> dimacs.rutgers.edu.  The list's
maintainer is ietf-822-request <at> dimacs.rutgers.edu.  An archive of the mailing
list is available via anonymous FTP from dimacs.rutgers.edu in
pub/ietf-822-archive.

Except for two specific requests (Mark Needleman and Don Jackson), everyone
(including the redists) is currently on both of these lists.

					David
Permalink | Reply | 0 comments |
headers
Nathaniel Borenstein | 8 Apr 1991 16:41
Picon

text --> IA5 ?

I've started working on yet another draft RFC-XXXX, which I hope will,
as a result of our latest discussions, bring us much closer to a
consensus.  One of the things I'd like to do is get rid of
"Content-type: text" which, as Stef, has pointed out, is kind of
ambiguous.  Neither Stef nor I, however, are sure what the right
replacement would be.  Here are some possibilities:

Content-type:  IA5
Content-type: USASCII
Content-type: NVT-ASCII

Does anyone have a strong feeling about the "right" name for this
content-type, which is to be used as the formal designator for "the
established default"?  At this point, anyone with a strong opinion has a
very good chance of winning by default....  -- Nathaniel
Permalink | Reply | 1 comment |
headers
jwn2 | 8 Apr 1991 17:17

Re: text --> IA5 ?

>
>Content-type:  IA5
Too cryptic.
>Content-type: USASCII
Non-Americans will complain we're being chauvinistic :-)
>Content-type: NVT-ASCII
Too long.

If we're voting, I vote for USASCII.  Actually, the US is redundant...but
then we still have to distinguish 7-bit ASCII from 8-bit, eh?  (No offense
intended to citizens of
other "American" states...)

-jwn2
Permalink | Reply | 11 comments |
headers
Walt Daniels | 8 Apr 1991 17:37
Picon
Favicon

text --> IA5 ?

>Content-type:  IA5
>Content-type: USASCII
>Content-type: NVT-ASCII
IA5 is a character set.  USASCII is a codeset.  I don't know what
NVT-ASCII is.  I would prefer if it refered to an ISO standard.  I
think IA5 is ISO 6429.  In any case I think we are trying to specify
the character set not the codeset.  This mail is being sent from an
EBCDIC system and is in IA5 but not in USACII (at least until it
leaves here :-).
Permalink | Reply | 0 comments |
headers
Nathaniel Borenstein | 8 Apr 1991 20:58
Picon

Re: text --> IA5 ?

Between the answers posted to this list and the answers sent to me as
mail, it's obvious that none of my suggested alternatives was good
enough.  The real problem, I think, is that the current default
content-type for mail has never been well-enough defined for any of the
more specific terms to properly apply.  Thus, for example, calling it
"NVT-ASCII" or "IA5" might actually be strengthening the constraints on
it.  While that might be desirable, it opens a major can of worms, and
was not the intent.  What I'm seeking is just a descriptive term for
"what mail bodies are now assumed to be."

How about simply

Content-type:  US-7-bit

which is, at least, a non-technical term that somewhat describes the
status quo....
Permalink | Reply | 9 comments |
headers
Vincent Lau | 8 Apr 1991 22:22
Picon

Re: text --> IA5 ?

> One of the things I'd like to do is get rid of
> "Content-type: text" which, as Stef, has pointed out, is kind of
> ambiguous.  Neither Stef nor I, however, are sure what the right
> replacement would be.  Here are some possibilities:
> 

Although "text" may sound ambiguous, the contents should be human readable.
I would like to suggest a slightly different approach.  Warning: it may
be controversial.  That is to create a new header (e.g. Codeset: )
to identify the codeset being used in the contents.

Why?  I have an NROFF document which uses tbl and mm macros, but it contains
ISO-8859-1 characters.  According to RFC 1148, the content-type becomes:

Content-Type: nroff; null; tbl, ms

There is no place to identify the character set/codeset.  If a new header
is created, I can specify it as:

Content-Type: nroff; null; tbl, ms
Codeset: ISO-8859-1 (or whatever the convention we define)

Note, it is merely a suggestion.  It is controversial because some
mailers don't care if nroff document contains non-7-bit-ASCII as long
as Content-Encoding does the right thing.  If you feel that it is too
controversial, I will not mention it again.  

Some people may feel that Content-Type should contain the semantic
meaning, but not the actual implementation.  I am not saying that it is
a right way, but it brings up an interesting question.  Should we
(Continue reading)

Permalink | Reply | 7 comments |
headers
Einar Stefferud | 8 Apr 1991 21:09
Picon

Re: text --> IA5 ?


I would hope that the winner (see below) would be someone with a
strong logical case for the choice, like "Here is the formal, unique,
adopted International Standard, designation for exactly what RFC822
intended all along!"  Best...\Stef

>  Here are some possibilities:

> Content-type:  IA5
> Content-type: USASCII
> Content-type: NVT-ASCII

> Does anyone have a strong feeling about the "right" name for this
> acontent-type, which is to be used as the formal designator for "the
> established default"?  At this point, anyone with a strong opinion has a
> very good chance of winning by default....  -- Nathaniel
Permalink | Reply | 0 comments |
headers
Einar Stefferud | 9 Apr 1991 00:15
Picon

Re: text --> IA5 ?

Well;-)

I guess I now feel that my instincts were right on the mark.  

We don't know for sure what "text" means, do we!

Best...\Stef
Permalink | Reply | 8 comments |
headers
Einar Stefferud | 9 Apr 1991 00:22
Picon

Re: Inline excerpts (was: Re: Another look at 8 bit transport for...)

I am bothered by the comments shown below (with > prefixes).

It seems to me that multi-part adn multi-media parts are very
different beasts, whcih we should understand.  We sho9uld avoid mixing
them to gether too much.

I don't see any point in trying to make out multi-part mechainsm into
ODA where I can mix all sortsof theings to gether in a single body
part.

What I want is to be able to carry an ODA body part when I need such a
thing, and to carry other body-parts when they suit my needs, but I do
not want to convert all of RFC822bis into a new form of ODA, or even a
partial form of ODA.  A half baked RFC822oda is not of much value as I
see it.

Lets abandon trying to too far beyond hierarchical multi-part
structures.  Best...\Stef

>>However, would it be reasonable to have inline parts as
>>part of multipart messages? You could use some flag to indicate that the
>>part should be positioned right after the previous EOL, not starting a
>>new line. 
>
>I suppose that if one wanted to do something with "content order" (I'm 
>not sure what happened with that thread) it would be quite natural to 
>attach this sort of thing to it, along with very precise language about 
>where the embedded part actually stopped and ended, possibly by adding 
>some special bracketing characters that would not be EOL sensitive.  
>E.g.,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Einar Stefferud | 9 Apr 1991 01:40
Picon

Re: text --> IA5 ?

I note that you did not suggest that IA5 is too unambiguous!

>>Content-type:  IA5
>Too cryptic.
>>Content-type: USASCII
>Non-Americans will complain we're being chauvinistic :-)
>>Content-type: NVT-ASCII
>Too long.
>
>If we're voting, I vote for USASCII.  Actually, the US is redundant...but
>then we still have to distinguish 7-bit ASCII from 8-bit, eh?  (No offense
>intended to citizens of other "American" states...)    -jwn2

How is it that something can be redundant, and its absence can then
cause a failure to distinguish.  )-:-)

I vote for the one that is most unambiguous, believing that accepting
ambiguity in the interests of avoiding things like "too cryptic"
"chauvanistic" is just not useful in terms of our objectives.

I am becoming very baffled by this discussion.  Is this a standards
meeting, or am I really at the IMPROV in Hollywood?  I always did want
to be a stand-up comic, but I never thought to do it here.

Best...\Stef
Permalink | Reply | 0 comments |

Gmane