Hello Travis, and others: > > Sending markdown encoded as markdown has several benefits. > > But also many downsides, there is not really such a thing as a markdown > standard. There are different 'flavors', such as > github-flavored-markdown, and then there are just major/minor > differences in various markdown libraries. A newish effort is > CommonMark[1][2], and it is strictly defined, but has only a few > implementations at last check. > > Point being, you couldn't write a XEP talking about 'markdown' alone and > expect it to be very compatible across implementations. I'd instead > suggest client-side support for markdown, but sending it as HTML with > the raw markdown as the text alternative. > > [1]: http://commonmark.org/ > [2]: https://xkcd.com/927/ Yes, I'm aware of those efforts (and more). But they are not "downsides", as they don't limit or make things worse. The most that can happen, if you mark something as markdown, is that they payload is ignored. It's a similar situation with XHTML-IM I guess, even though it is more pronounced with markdown. And still, it does not resolve the issue when you actually want to send markdown (see my earlier responses why this would be so). It's always done in a client-side manner, the question is: Should it be implementation specific, or should there be a measure of interoperability here, between clients that desire to communicate using markdown? That is, should the XSF promote a standardized manner to communicate using markdown, or force everybody to use proprietary means? (The aim of course, is not to standardize markdown.) Best regards, Peter Waher
> > > ------------------------------ > > Message: 2 > Date: Wed, 6 Jan 2016 15:29:31 +0100 > From: Peter Waher <[email protected]> > To: "[email protected]" <[email protected]> > Subject: Re: [Standards] Markdown in XMPP IM > Message-ID: <[email protected]> > Content-Type: text/plain; charset="windows-1252" > > Hello Matthew, Florian & others > > Thanks for your input. Regarding your comments: > > > >> Isn't the point of markdown that it's perfectly readable as plain text, > > >> ie that there is no markup? I'd think sending straight markdown would > > >> be just fine. > > > > > > The point of markdown is that it's easy to write and edit (focus is not > > > reading, even though it's somewhat readable as well). I thought about > > > sending markdown just as-is as well, but after thinking about it for a > > > while > > > decided against it. > > > > Sorry, this is definitely incorrect. > > > > >From the author's site ( https://daringfireball.net/projects/markdown/ ): > > > > "Markdown allows you to write using an easy-to-read, easy-to-write > > plain text format [...]" > > > > and > > > > "The overriding design goal for Markdown?s formatting syntax is to > > make it as readable as possible. The idea is that a Markdown-formatted > > document should be publishable as-is, as plain text, without looking > > like it?s been marked up with tags or formatting instructions." > > Interesting to see how different people read the same text and come out with > different conclusions. From the same page: > > "Markdown?s syntax is intended for one purpose: to be used as a format for > writing for the web." > > and > > "The idea for Markdown is to make it easy to read, write, and edit prose. > HTML is a publishing format; Markdown is a writing format." > > So, the main purspose, and why it is used in CMS systems, is because it > should be as easy to write as possible, and yet, be as easy to read as > possible, under those circumstances. (If writability was not the main > concern, other ways create results that are easier to read.) > > > > > If you ask me, the best thing to do here would be to define a way to > > declare a message's body explicitly as being in Markdown syntax. Then > > clients will ignore that tag it and display it as text, unless they > > understand the tag, then they'll know they can run it through a > > Markdown processor and display a formatted version. > > I was thinking along these lines as well, and Steven also, in his reply. > > > Alternatively, if it's just about easier input, support Markdown on > > the sending side and use XHTML-IM. I don't think we really need more > > ways of formatting messages. > > You would not be able to recover the markdown this way, which might be of > interest (see my response earlier). > > > > > > > > If you ask me, the best thing to do here would be to define a way to > > > declare a message's body explicitly as being in Markdown syntax. Then > > > clients will ignore that tag it and display it as text, unless they > > > understand the tag, then they'll know they can run it through a > > > Markdown processor and display a formatted version. > > > > I wonder if this is even necessary. Maybe markdown libraries are able > > tell if a given String is in markdown or not. Worst thing that could > > happen are false positives, and I do think that this won't be often the > > case. > > This is definitely possible. It it might also be undesireable, as if a > non-markdown-compliant client sending a message to a markdown-compliant > client. Such text should be displayed as normal text. > > > > > I do not see any reason to wrap markdown in an extra element like it is > > done with XHTML-IM. I would simply put it into <body/>. > > That would force clients to support XHTML-IM, which, in the case of choosing > markdown in the first place, might be undesireable. > > Best regards, > Peter Waher > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://mail.jabber.org/pipermail/standards/attachments/20160106/591bab7b/attachment-0001.html> > > ------------------------------ > > Message: 3 > Date: Wed, 6 Jan 2016 15:33:25 +0100 > From: Tobias M <[email protected]> > To: XMPP Standards <[email protected]> > Subject: Re: [Standards] Proposed XMPP Extension: Jingle ICE Transport > Method > Message-ID: <[email protected]> > Content-Type: text/plain; charset="windows-1252" > > > > On 30.12.2015, at 22:48, Lance Stout <[email protected]> wrote: > > > > The prose has the original <ice-gathering-complete /> but the example shows > > <gathering-complete />. > > > > > > Aside from that nit, I'm +1 on publishing this version. > > Same goes for me. Also +1 on publishing. > > Cheers, > Tobias > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://mail.jabber.org/pipermail/standards/attachments/20160106/f45f674e/attachment-0001.html> > > ------------------------------ > > Message: 4 > Date: Wed, 6 Jan 2016 14:59:02 +0000 > From: Matthew Wild <[email protected]> > To: XMPP Standards <[email protected]> > Subject: Re: [Standards] Proposed XMPP Extension: Jingle ICE Transport > Method > Message-ID: > <cajt9-x5hu05csk11vuu_repcszlwso9obhprsbh1b2h4ohy...@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > and my +1 also. > > On 6 January 2016 at 14:33, Tobias M <[email protected]> wrote: > > > > On 30.12.2015, at 22:48, Lance Stout <[email protected]> wrote: > > > > The prose has the original <ice-gathering-complete /> but the example shows > > <gathering-complete />. > > > > > > Aside from that nit, I'm +1 on publishing this version. > > > > > > Same goes for me. Also +1 on publishing. > > > > Cheers, > > Tobias > > > > > > _______________________________________________ > > Standards mailing list > > Info: http://mail.jabber.org/mailman/listinfo/standards > > Unsubscribe: [email protected] > > _______________________________________________ > > > > > ------------------------------ > > Message: 5 > Date: Wed, 6 Jan 2016 16:38:07 +0100 > From: Philipp Hancke <[email protected]> > To: [email protected], "[email protected] >> Peter Saint-Andre" > <[email protected]> > Subject: Re: [Standards] Proposed XMPP Extension: Jingle ICE Transport > Method > Message-ID: <[email protected]> > Content-Type: text/plain; charset=windows-1252; format=flowed > > Am 17.12.2015 um 11:50 schrieb XMPP Extensions Editor: > > The XMPP Extensions Editor has received a proposal for a new XEP. > > > > Title: Jingle ICE Transport Method > > > > Abstract: This specification defines a Jingle transport method that results > > in sending media data using datagram associations via the User Datagram > > Protocol (UDP) or using end-to-end connections via the Transport Control > > Protocol (TCP). This transport method is negotiated via the Interactive > > Connectivity Establishment (ICE) methodology (which provides robust NAT > > traversal for media traffic) and also supports the ability to exchange > > candidates throughout the life of the session, consistent with so-called > > "Trickle ICE" (draft-ietf-ice-trickle). > > > > URL: http://xmpp.org/extensions/inbox/jingle-ice.html > > before publication, can we make a minor schema change: > <xs:attribute name='network' type='xs:unsignedByte' use='required'/> > shoulld be optional. I'm not sure about whether the type as unsignedByte > makes sense either. I seem to recall a network type (ethernet, wifi, 3g) > in libjingle, but can't find it right now. > > > ------------------------------ > > Message: 6 > Date: Wed, 6 Jan 2016 16:00:55 +0000 > From: Dave Cridland <[email protected]> > To: XMPP Standards <[email protected]> > Subject: Re: [Standards] Proposed XMPP Extension: Jingle ICE Transport > Method > Message-ID: > <CAKHUCzzL3VKyRe=zzcwti01dlqawc3wcuzhruiz9wadbtag...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > On 6 January 2016 at 15:38, Philipp Hancke <[email protected]> > wrote: > > > before publication > > > What? > > Why on earth do we want to make changes before publication as a XEP? > > Prior to publication as a XEP, this is not an XSF document. After, we > discuss it, make changes, and so on. I can understand making sure we fix > things prior to advancement as Draft or Final, but really - if it's worth > making changes to, it's worth publishing as an Experimental XEP first. > > Dave. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://mail.jabber.org/pipermail/standards/attachments/20160106/69f2705f/attachment-0001.html> > > ------------------------------ > > Message: 7 > Date: Wed, 6 Jan 2016 17:13:50 +0100 > From: Philipp Hancke <[email protected]> > To: XMPP Standards <[email protected]> > Subject: Re: [Standards] Proposed XMPP Extension: Jingle ICE Transport > Method > Message-ID: <[email protected]> > Content-Type: text/plain; charset=windows-1252; format=flowed > > Am 06.01.2016 um 17:00 schrieb Dave Cridland: > > On 6 January 2016 at 15:38, Philipp Hancke <[email protected]> > > wrote: > > > >> before publication > > > > > > What? > > > > Why on earth do we want to make changes before publication as a XEP? > > wouldn't such a change to the schema need a namespace bump? > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Standards mailing list > [email protected] > http://mail.jabber.org/mailman/listinfo/standards > > > ------------------------------ > > End of Standards Digest, Vol 146, Issue 6 > *****************************************
_______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
