Subject: RE: line breaks in text/plain

From: <[email-masked]>
Date: Tue, 7 Sep 2004 12:38:18 +0300

> There are two assumptions here that should be considered:
> 
>  1) <content> is the right element for submitting, syndicating, or
>     archiving the unprocessed user input

This sounds like a reasonable assumption to me.  IMO, Atom should be treated as a transport only for the most part.  The less we assume of the payload, the less there will be interop issues and misunderstandings.

Unless, of course, Atom would become the standard for exchanging weblog entries between different weblog platforms, but even then I would rather see the payload treated as a separate issue.

Let the servers worry about displaying and formatting.

(Especially with content @src, it does suddenly become a source for unprocessed input...)

>  2) text/plain is the right media type for Wiki markup.  The
>     specification of text/plain[1] excludes markup of any kind:

Hm.  I guess that you are right.  But then the only reasonable alternative is probably application/octet-stream...

Of course, we are not tied to MIME types, unless we want to do it.  Should we drag with us the confusion that is text/plain, or should we just define "text" and sow it with our own confusion?

>     There is work in progress to register a text/wiki media type, but
>     it needs help to avoid being tied to one particular markup style
>     (tiki).

I'd rather see a text/free, which could be interpreted at-will at the other end.  I have plenty of issues with WikiMarkup anyway (and attempted standardization of it - I think people are going at it the wrong way), but they're not matters for this list :)
 
/Janne

---

From: Sam Ruby <[email-masked]>
Date: Tue, 07 Sep 2004 11:25:39 -0400

[email-masked] wrote:
> Hm.  I guess that you are right.  But then the only reasonable
> alternative is probably application/octet-stream...
> 
> Of course, we are not tied to MIME types, unless we want to do it.
> Should we drag with us the confusion that is text/plain, or should we
> just define "text" and sow it with our own confusion?

It seems to me that the right thing to do is to register a new MIME 
type.  According to Mark Nottingham[1], it is really easy to register a 
mime type in either the vnd.* or prs.* trees.

- Sam Ruby

[1]<http://blogs.law.harvard.edu/crimson1/discuss/msgReader$1571?mode=day>

---

From: [email-masked]
Date: Tue, 07 Sep 2004 09:16:43 -0700 (PDT)

> mime type in either the vnd.* or prs.* trees.

That's true in general but not in this case. The fact that this group is
producing a standars-track specification means that any registration it
produces will undergo IESG review regardless of the tree you put it in.

Additionally, IMO it is totally inappropriate to register a vnd. or prs. type
for use in a standards-track protocol. Such registrations belong in the
standards tree.

				Ned

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 12 Sep 2004 01:16:35 +0200

On Tue, 07 Sep 2004 09:16:43 -0700 (PDT), <[email-masked]> wrote:

> Additionally, IMO it is totally inappropriate to register a vnd. or prs.  
> type for use in a standards-track protocol. Such registrations belong in
> the standards tree.

I agree. A way to differ flowed plain textual content from static textual  
content, is to use the 'format'[1] parameter in the MIME type:

   text/plain; format=flowed

<url: http://www.joeclark.org/ffaq.html>

So, basically, when a parser encounters <content type="text/plain;  
format=flowed">, it should render the content flowed as defined in RFC  
2646. Whenever 'format=flowed' is absent, 'text/plain' content should be  
rendered with all line breaks intact.

Would this help?

____
[1] <url: http://www.ietf.org/rfc/rfc2646.txt>

-- 
Asbjørn Ulsberg    -=|=-     http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»

---

From: [email-masked]
Date: Sat, 11 Sep 2004 16:21:36 -0700 (PDT)

> Would this help?

This is exactly what I was suggesting. I guess I wasn't being clear.

If need be additional format parameter values could also be defined.

The alternative would be to register one or more additional text subtypes for
use in ATOM with the specific characteristics ATOM wants. There's nothing wrong
with this per se; but reuse of existing mechanisms is better IMO.

				Ned

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 12 Sep 2004 12:26:32 +0200

> If need be additional format parameter values could also be defined.

Yes. I'm not sure how RFC 2646 can be extended in that way, but I guess it  
should be simple to find that out if we need to.

> The alternative would be to register one or more additional text  
> subtypes for use in ATOM with the specific characteristics ATOM wants.

I don't think this is necessary. It's still 'text/plain', but we need a  
way to assert how it should be parsed and rendered.

> [...] reuse of existing mechanisms is better IMO.

Yep.