Subject: [apps-discuss] Call for Adoption: draft-seantek-text-markdown-media-type

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 21 Jul 2014 12:25:19 -0400

Call For Adoption: draft-seantek-text-markdown-media-type

Colleagues,

This note begins a Call For Adoption for the above document to be adopted
as an APPSAWG working group item.  The Call ends on August 8, 2014.

Keep in mind that adoption of a document does not mean the document as-is
is ready for publication.  It is merely acceptance of the document as a
starting point for what will be some later final product of APPSAWG.  The
working group is free to make changes to the document according to the
normal consensus process.

We have already seen some favorable discussion toward adoption on the
apps-discuss list, and these comments will be included in the resolution of
this Call.

Please reply on this thread with expressions of support or opposition,
preferably with comments, regarding accepting this as a work item of
APPSAWG (as opposed to some other venue).  Feel free to include discussion
of constraints that the WG should consider with respect to its mini-charter.

-MSK, APPSAWG co-chair

---

From: Tony Hansen <[email-masked]>
Date: Mon, 21 Jul 2014 13:18:00 -0400

On 7/21/14, 12:25 PM, Murray S. Kucherawy wrote:
> This note begins a Call For Adoption for the above document to be 
> adopted as an APPSAWG working group item.  The Call ends on August 8, 
> 2014.

+1

I think having the media type is a good thing. I have quibbles with some 
of the things in the document, but those can be ironed out.

     Tony

---

From: Ned Freed <[email-masked]>
Date: Mon, 21 Jul 2014 10:57:27 -0700 (PDT)

> of the things in the document, but those can be ironed out.

Agreed. This work seems entirely appropriate to do here.

				Ned

---

From: Eric Burger <[email-masked]>
Date: Mon, 21 Jul 2014 14:51:04 -0400

The biggest issue seems to be that there are a whole bunch of *almost* compatible markups.

I would offer one of two directions. One is to punt and do what the draft says - acknowledge incompatible dialects and ignore compatibility. The other is to define an official Markdown markup, presumably based on the Gruber Web site.

Option one does not offer any interoperability. However, if an appendix defines a ‘default’ markup, that may be a way to migrate the industry to a single standard. Option two clearly does promote interoperability.

Option one with no baseline will not result in interoperability and will be a waste of our time.

On Jul 21, 2014, at 1:57 PM, Ned Freed <[email-masked]> wrote:

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Dave Crocker <[email-masked]>
Date: Mon, 21 Jul 2014 15:44:42 -0400

On 7/21/2014 12:25 PM, Murray S. Kucherawy wrote:
> adopted as an APPSAWG working group item

+1.  Appropriate work to do here.

The argument against a separate wg is well-taken.  In effect, it would
encourage making the effort irrelevant.

While the concern for overly-elaborate handling of variants is also
well-taken, I'm concerned with a media type that has the semantic "it's
this 'class' of thing, with the specific variant, version or deviation
being determined by cultural context."  And yes, that's what it sounds
like the proposal is going towards.

I think that a legitimate packaging convention needs to provide enough
reliable and accurate information to allow reliable and accurate
dispatching into a processing engine that will correctly handle the
data.  This is not usually accomplished very well by a dispatching to an
engine that needs to informal conventions to 'figure out' what it's been
handed.

This all might be easy to resolve.  I can't tell yet.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "John Levine" <[email-masked]>
Date: 21 Jul 2014 19:50:32 -0000

In article <[email-masked]> you write:
>-=-=-=-=-=-
>-=-=-=-=-=-
>I would offer one of two directions. One is to punt and do what the draft
>says - acknowledge incompatible dialects and ignore compatibility. The other
>is to define an official Markdown markup, presumably based on the Gruber Web
>site.

Another approach is to do what RFC 4263 did for text/troff.  There's a
process= parameter which gives the recipient a hint about which
subflavor of troff it is.  Their example is:

  Content-Type: text/troff ; process="dformat | pic -n | troff -ms"

R's,
John

---

From: Ned Freed <[email-masked]>
Date: Mon, 21 Jul 2014 14:11:21 -0700 (PDT)

> >says - acknowledge incompatible dialects and ignore compatibility.

See my previously posting on this topic. The "incompatibility" we're talking
about here is being overstated.

> > The other

Which would be counter to the stated goals of the format.

>   Content-Type: text/troff ; process="dformat | pic -n | troff -ms"

I had completely forgotten about text/troff. Variants of troff really are
completely incompatible, to the point where attempting to process them in the
wrong way results in total gibberish. So there is running code for an even more
extreme variant along these lines.

I'd also argue that text/html and even text/plain have "incompatibilities"
similar to those of different markdown variants in actual usage, albeit for
different underlying reasons.

				Ned

---

From: Sean Leonard <[email-masked]>
Date: Tue, 22 Jul 2014 17:07:39 -0400

Just wanted to add some observations that I made at the APPSAWG presentation:

Quoting Ned Freed <[email-masked]>:

>> In article  
>> <[email-masked]> you write:
>> >-=-=-=-=-=-
>> >-=-=-=-=-=-
>> >

Correct. All Markdown content is compatible with Markdown processors.

There is no concept of "valid" Markdown. A Markdown processor  
identifies magical sequences of characters (aka markup) and converts  
them to the formal markup. If the processor does not recognize it, it  
is passed through to the output. Markdown processors therefore rarely  
reject content for being invalid. Many Markdown processors are  
implemented as a series of regular expressions, or as an  
implementation of PEG (parsing expression grammar).

> extreme variant along these lines.

In my presentation, I rejected the flavor parameter, replacing it with  
variants (or rulesets) and processor. The latter parameter is  
semantically the same as the "process" and "versions" in text/troff  
(thanks!--I did not notice that), indicating that there is precedent  
for it. The main difference is that RFC 4263, those parameters are  
"human-readable"--in my proposal for text/markdown, the parameters are  
structured with identifiers that can be used by automated processes  
(i.e., without substantial human interaction).

See: https://tools.ietf.org/agenda/90/slides/slides-90-appsawg-6.pdf

-Sean

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 22 Jul 2014 17:32:35 -0400

+1 (support adoption).

> On 21 Jul 2014, at 12:25, "Murray S. Kucherawy" <[email-masked]> wrote:
> 
> This note begins a Call For Adoption for the above document to be adopted as an APPSAWG working group item.  The Call ends on August 8, 2014.
> 
> Keep in mind that adoption of a document does not mean the document as-is is ready for publication.  It is merely acceptance of the document as a starting point for what will be some later final product of APPSAWG.  The working group is free to make changes to the document according to the normal consensus process.
> 
> We have already seen some favorable discussion toward adoption on the apps-discuss list, and these comments will be included in the resolution of this Call.
> 
> Please reply on this thread with expressions of support or opposition, preferably with comments, regarding accepting this as a work item of APPSAWG (as opposed to some other venue).  Feel free to include discussion of constraints that the WG should consider with respect to its mini-charter.
> 
> -MSK, APPSAWG co-chair

---

From: "John Levine" <[email-masked]>
Date: 22 Jul 2014 22:11:00 -0000

>+1 (support adoption).

It needs a little work (not a lot) and it's worth adopting.

---

From: Matt Miller <[email-masked]>
Date: Tue, 22 Jul 2014 18:14:10 -0400

On 7/21/14, 12:25 PM, Murray S. Kucherawy wrote:
> adopted as an APPSAWG working group item.  The Call ends on August 
> 8, 2014.
> 
> Keep in mind that adoption of a document does not mean the document
> as-is is ready for publication.  It is merely acceptance of the
> document as a starting point for what will be some later final
> product of APPSAWG.  The working group is free to make changes to
> the document according to the normal consensus process.
> 
> We have already seen some favorable discussion toward adoption on 
> the apps-discuss list, and these comments will be included in the 
> resolution of this Call.
> 
> Please reply on this thread with expressions of support or 
> opposition, preferably with comments, regarding accepting this as
> a work item of APPSAWG (as opposed to some other venue).  Feel
> free to include discussion of constraints that the WG should
> consider with respect to its mini-charter.
> 
> -MSK, APPSAWG co-chair
> 
> 
> _______________________________________________ apps-discuss 
> mailing list [email-masked] 

I support adopting this draft.

- -- 
- - m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

---

From: Matt Miller <[email-masked]>
Date: Tue, 22 Jul 2014 18:14:10 -0400

- -- 
- - m&m