Re: [Standards] UPDATED: XEP-0313 (Message Archive Management)

[Matthew Miller]

> On Sep 21, 2015, at 10:06, XMPP Extensions Editor  wrote:
> 
> Version 0.4 of XEP-0313 (Message Archive Management) has been released.
> 
> Abstract: This document defines a protocol to query and control an archive of 
> messages stored on a server.
> 
> Changelog: [See revision history] (ks/mw)
> 
> Diff: http://xmpp.org/extensions/diff/api/xep/0313/diff/0.3/vs/0.4
> 
> URL: http://xmpp.org/extensions/xep-0313.html
> 

The Editor Team apologizes for the confusion on this document.  At some point, 
a "0.4" was pushed into the repository before it was ready, and was picked up 
by the various tools.  This version of "0.4" should be correct.  We are working 
on ways to prevent this in the future.

Also, published version 0.3 is available in the attic at < 
http://xmpp.org/extensions/attic/xep-0313-0.3.html >.


--
- m&m

Matthew A. Miller
< http://goo.gl/LM55L >




signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] Carbons - inbound messages to bare jid

[Matthew Miller]

Right; this is what we intended the semantics to be.  I think the other
proposal is not a good idea.

- m&m
{mobile}
On Apr 25, 2014 6:58 AM, "Thijs Alkemade"  wrote:

>
> On 25 apr. 2014, at 13:32, Kim Alvefur  wrote:
>
> > Hello,
> >
> > It has been brought up that my Carbons implementation does not follow
> > the Receiving Messages to the Bare JID¹ section.  This section says
> > include carbons-enabled sessions in the normal forking of messages as
> > described by XMPP IM².
> >
> > What I implemented was instead to send carbons-wrapped messages to
> > carbons-enabled sessions that would not already receive them based on
> > the XMPP IM rules.  So a message will always be carbons-wrapped if it
> > was sent because carbons was enabled.  I believe this makes sense, does
> > anyone else?
> >
> > ¹ http://xmpp.org/extensions/xep-0280.html#inbound-bare (version 0.9)
> > ² http://xmpp.org/rfcs/rfc6121.html#rfc.section.8.5.2.1.1
>
> Hi Kim,
>
> Thinking about this a bit more, I actually disagree with this proposal.
>
> The semantics of receiving a carbon copy should be "hey this other resource
> has a conversation going, here's a copy of this message in case you want to
> follow along". That might imply, for example, that the client uses a
> different
> way of notifying the user: the user might have configured their client to
> not
> make a sound when receiving a carbon copy, as multiple devices making
> sounds
> gets annoying.
>
> A bare-JID message is a different situation. Sending one implies the
> sender is
> looking for a resource that will reply to start a conversation with it, so
> for
> these I think it would be fine if a carbons-enabled client notifies the
> user
> as if it were a normal message.
>
> Of course the client could add extra logic for this ("if it's a carbon
> copy,
> and the first message we've seen from this user this session/hour/day, play
> sounds"), but I think doing it in the way that is currently in the XEP is a
> much cleaner solution.
>
> Regards,
> Thijs Alkemade
>

Re: [Standards] Using .well-known/ to supplement XEP-0156

[Matthew Miller]

As a self-proclaimed member of the DNS anti-proliferation league, I fully
support this. (-:

I'd be happy to help out this together.  It would help solve some problems
we are facing.

- m&m
{mobile}
On May 18, 2013 7:38 AM, "Peter Saint-Andre"  wrote:

> +1. Yes there is a registry at IANA, I can provide pointers a bit later.
>
> Sent from mobile, might be terse
>
> On May 17, 2013, at 8:12 PM, Lance Stout  wrote:
>
> > So XEP-0156 details how to use DNS records to advertise alternative ways
> to connect to an XMPP server, namely BOSH and soon WebSocket. That's great,
> except that in the browser you can't make arbitrary DNS requests, which
> severely limits the usefulness of this method.
> >
> > Any interest in standardizing some .well-known/ document to expose
> alternative connection endpoints? There's probably something like this that
> already exists that we can profile or register with, right?
> >
> > -- Lance
>

Re: [Standards] BOSH and legacy auth

[Matthew Miller]

If I recall correctly, this issue is about what to do when, after
authentication, the client sends a restart=true, but the server does not
support that (since there is no way to discover the server's version of
support for XEP-0206).

- m&m
{mobile}
On Feb 7, 2013 5:50 AM, "Stefan Strigler"  wrote:

> Hi,
>
> On 07.02.2013, at 13:12, Winfried Tilanus  wrote:
>
> > On 02/06/2013 05:05 PM, Stefan Strigler wrote:
> >
> >
> >> regarding the issue listed at
> >>
> >>
> http://wiki.xmpp.org/web/BoshIssues#Stream_Creation:_missing_.3Cstream:features.2F.3E
> >
> > Is it correct you are addressing an issue that was not mentioned before
> > here, or do my notes of the BOSH sprint at summit 13 fail on this one?
>
> It was on the list, we discussed it and I volunteered to provide a patch.
>
> So yes, maybe it was not discussed here but it was discussed at the summit.
>
> > Then, if you are referring to xep-0078 with legacy auth, it is my
> > understanding that first a  is opened and the server still has
> > to send a stream features with  > xmlns='http://jabber.org/features/iq-auth'/> in it. Then over that
> > stream auth is done by  stanza's. So in that case, the client still
> > will get a stream features before authing. So I see no potential
> > confusion here.
>
> Stream features are only provided by non legacy servers which might accept
> legacy auth for backwards compatibility with legacy clients. Legacy servers
> don't know about stream features.
>
> .Steve
>
>

Re: [Standards] disco identity for "client/smartphone"?

[Matthew Miller]

On Nov 30, 2012, at 7:11 AM, Kozlov Konstantin  wrote:

> 
> 
> 30.11.2012, 12:26, "Kevin Smith" :
>> On Thu, Nov 29, 2012 at 11:39 PM, Peter Saint-Andre  
>> wrote:
>> 
>>>  Looking at http://xmpp.org/registrar/disco-categories.html I notice
>>>  that we have disco identities for "client/handheld" (e.g., PDA) and
>>>  "client/phone" (e.g., mobile phone), but I think those are a bit
>>>  old-fashioned by now. We might want to add an identity for
>>>  "client/smartphone" (i.e., a phone that can do a lot more than the
>>>  old-style phones we had in mind when we defined "client/phone").
>> 
>> If this thing is capable of running an XMPP client on it, it's a smartphone.
> Why?! Any cheap J2ME-enabled phone can run XMPP client without any problem.
> Usually we call "smartphones" only mobile devices with operating system 
> (Symbian, Windows CE/Mobile/Phone, iOS or Android).
> So, if you call any Java-enabled mobile phone "smartphone", you should agree 
> that no mobile phones produced today at all. Only smartphones!


While our current crop of smartphones can potentially support things like file 
transfer, A/V, and rich text, I do think the general usability concerns are not 
significantly different from feature phones; limited screen real estate, 
connectivity obstacles, limited text entry (http://www.damnyouautocorrect.com/ 
is evidence enough for me) to name a few.


- m&m

Matthew A. Miller
< http://goo.gl/LK55L >



smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] disco identity for "client/smartphone"?

[Matthew Miller]

So, I had always interpreted ”phone” to mean smartphone (-:

I'm probably in the minority, though.

- m&m
(mobile; terse)
On Nov 29, 2012 4:39 PM, "Peter Saint-Andre"  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Looking at http://xmpp.org/registrar/disco-categories.html I notice
> that we have disco identities for "client/handheld" (e.g., PDA) and
> "client/phone" (e.g., mobile phone), but I think those are a bit
> old-fashioned by now. We might want to add an identity for
> "client/smartphone" (i.e., a phone that can do a lot more than the
> old-style phones we had in mind when we defined "client/phone").
>
> Thoughts?
>
> Peter
>
> - --
> Peter Saint-Andre
> https://stpeter.im/
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with undefined - http://www.enigmail.net/
>
> iEYEARECAAYFAlC38joACgkQNL8k5A2w/vzX7QCg7bleJ+GmNfrtfsICQ7DqQF24
> AsYAn1kkmYza7ucyGMAT0ZEXAjbdlZeN
> =kcZl
> -END PGP SIGNATURE-
>

Re: [Standards] xep-027 encrypted filetransfers

[Matthew Miller]

On Oct 17, 2012, at 08:26, Peter Saint-Andre  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 10/17/12 5:57 AM, Александр wrote:
>> On Пятница, 12-окт-2012 00:46:57 Александр wrote:
>> 
>> On Четверг, 11-окт-2012 23:33:48 Andreas Kuckartz wrote:
>> 
>>> Александр:
>> 
 Hi all, i have implemented encrypted filetransfers in my
>> 
 realization of xep-027 in new_gpg plugin fro miranda im/ng,
 but
>> 
 currently it supported only in miranda, i would like to extend
>> 
 xep-027 to have defined encrypted filetransfers. is it possible
 ?
>> 
>>> 
>> 
>>> Did you look at XEP-0234 ?
>> 
>>> 
>> 
>>> Cheers,
>> 
>>> Andreas
>> 
>> 
>> 
>> not yet, but my method implement encrypted transfers for any type
>> of filetransfer, not just jingle (which as i know not supported by
>> most clients currently ?), but my method is very primitive 
>> 
>> 
>> 
>> i have looked on XEP-0234 and related XEP's, found only some
>> information about optional ssl/tls encryption, but this is not
>> end-to-end, and not pgp like, i mean it's vulnerable to man in
>> middle attack on server side, ot i have missed something ?
> 
> We have not yet defined end-to-end encryption of file transfers. One
> way would be for the sender to encrypt each stanza to the public key
> of the recipient, and then chunk out the file using XEP-0047. However,
> that won't work well for huge files because it will take a long time
> to transfer the file. Another way would be to run your own trusted
> file transfer proxy, use XEP-0065, and require SSL/TLS on both ends of
> the proxy. I'm sure there are other solutions, too (e.g., for a while
> we were discussing something called XTLS). It's not such an easy
> problem to solve, but your ideas are welcome.
> 

Right.

It's important to separate what the content is from how it is transported.  
Both [SI] and [JINGLE] do this to allow for agility in transport (Jingle more 
so than SI), increasing the chance of a successful transfer.  I don't see how 
relying purely on XEP-0047 does this.  Plus, I expect XMPP service operators 
would take exception to the transfer of extremely large data through a topology 
designed for lots of rather small chunks of information.

A more palatable approach is to define a new SI profile (similar to XEP-0096) 
or Jingle descriptor (similar to XEP-0234) that indicates the data to exchange 
is encrypted before entering the transport layer.  The actual key exchange 
could be done in a number of ways; < 
http://tools.ietf.org/html/draft-miller-xmpp-e2e> has one possible approach 
included.


- m&m

Matthew A. Miller




smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] UPDATED: XEP-0280 (Message Carbons)

[Matthew Miller]

On Oct 10, 2012, at 13:47, Matthew Wild  wrote:

> On 9 October 2012 15:46, XMPP Extensions Editor  wrote:
>> Version 0.8 of XEP-0280 (Message Carbons) has been released.
>> 
>> Abstract: In order to keep all IM clients for a user engaged in a 
>> conversation, outbound messages are carbon-copied to all interested 
>> resources.
>> 
>> Changelog: Updated use case text to match schema and examples. (mm)
> 
> Small typo in the changelog date for 0.7 - otherwise looks great!
> 

/-:  I though I fixed the 0.7 change log (it did originally say it was 
published 2012-10-14!).


- m&m

Matthew A. Miller




smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Comments on XEP-0301 -- Section 1 - TTY

[Matthew Miller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I think either of these is ok.  I'd still like at least some reference to how 
the technology works, since you are using this as a reference of prior art.  If 
you can't include a reference, then an internet search of the term needs to 
lead very quickly to a description of the technology.

Remember, this is a document primarily for technology implementers!  These 
implementer might not be (in fact, are likely not) intimately familiar with the 
technology in general, and might want to study it more in their efforts to 
implement 301.

If you're going to cite prior art, then you better make sure you can properly 
point to a description of how that prior art works.  I would STRONGLY RECOMMEND 
doing a Google/Bing/DuckDuckGo search on the terms, and make sure the first 5 
results describe the technology.


- - m&m

Matthew A. Miller
<http://goo.gl/LK55L>

On Aug 24, 2012, at 10:47, Mark Rejhon wrote:

> Since the spec targets all audiences,
> I may have to remove the "TTY" from the introduction, and simply say:
> 
> CHOICE #1 (preferred, to avoid expanding "TTY")
> -
> * Various text telephone technologies (e.g. TTY), used by the deaf and
> hard of hearing.
> 6.6.1 c/"TTY gateway"/"TTY/text telephone gateway"/
> (No other changes)
> -
> 
> CHOICE #2 (secondary, if I must remove TTY)
> -
> * Various text telephone technologies (used by the deaf and hard of hearing).
> 2.4 -- c/"TTY/text telephone alternatives"/"text telephone alternatives"/
> 6.6.1 -- c/"TTY gateway"/"text telephone gateway"/
> 8 - c/"This can include TTY and textphones"/"This can include text 
> telephones"/
> -
> 
> The term "text telephone" is disliked by some North Americans, but it
> is more worldwide-neutral, and I reintroduce the paranthesis to
> explain to the non-deaf, what they're for.   North Americans will
> quiclky figure out it means "TTY" and Europeans will quickly figure
> out it means "textphone" or "real-time text phone", etc.  And people
> who don't know what it is, "text telephone" is somewhat
> self-explanatory.However, a major target audience of XEP-0301 is
> North America, and therefore it's important to mention TTY.
> 
> I am proposing I go with CHOICE #1, since it already defines what a
> "TTY" is, without expanding the obsolete acronym not used in the deaf
> community.   Just like RADAR and SONAR, TTY is no longer considered an
> acronym in general use.
> 
> Government legislation about TTY
> http://www.access-board.gov/ada-aba/html/tech-07.html
> Do not even expand "TTY".   Why should we??
> 
> Thanks,
> Mark Rejhon
> 
> 
> On Thu, Aug 23, 2012 at 3:52 PM, Gunnar Hellström
>  wrote:
>> On 2012-08-23 18:31, Peter Saint-Andre wrote:
>>> 
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>> 
>>> On 8/23/12 10:22 AM, Matthew Miller wrote:
>>> 
>>>> I do realize this might seem pointless to some, but I really do
>>>> want to understand where this technology is coming from.
>>> 
>>> Matt, it's basically a matter of the history of computing at this
>>> point. Unfortunately, these days (when XML is considered old) few
>>> people care about such ancient technologies.
>>> 
>>> The best historical reference I've found is a pamphlet published by
>>> the Teletype Corporation in 1963 (Editors: R. A. Nelson; K. M. Lovitt,
>>> Editor; October 1963; Teletype Corporation,  West Touhy Avenue,
>>> Skokie, Illinois). I found a scanned-in copy here:
>>> 
>>> http://www.rtty.com/TTYSTORY/ttsindex.htm
>>> 
>>> Or did you want something more modern?
>>> 
>>> Peter
>>> 
>> Yes, that reference was the pre-history.
>> In the 1960-s deaf engineers in USA got surplus teletypewriters and designed
>> an FSK modem for them so they could be used for limited real-time text
>> communication over PSTN. I think the original Teletypewriters used DC
>> transmission, unsuitable for the PSTN, and needed that upgrade. Later,
>> purpose-built terminals were created, using the same transmission
>> technology, having the modem built-in. They continued to use the name TTY,
>> but are quite different from the original Teletypewriter TTY. That is why we
>> should not just refer to Teletypewriter in this use of the term 

Re: [Standards] Comments on XEP-0301 -- Section 1 - TTY

[Matthew Miller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On Aug 23, 2012, at 00:51, Gunnar Hellström wrote:

> On 2012-08-23 00:34, Matthew Miller wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>> 
>> 
>> On Aug 22, 2012, at 16:32, Gunnar Hellström wrote:
>> 
>> 
>>> /The US Access Board has the following definition in its latest proposal 
>>> for Accessible procurement, Section 508. E.103.4
>>> /http://www.access-board.gov/sec508/refresh/draft-rule.htm
>>> /
>>> TTY./  Equipment that enables interactive text based communications through 
>>> the transmission of frequency-shift-keying audio tones across the public 
>>> switched telephone network.  TTY includes devices for real time text 
>>> communications and voice and text intermixed communications.  Examples of 
>>> intermixed communications are voice carry over and hearing carry over.  One 
>>> example of a TTY is a computer with TTY emulating software and modem.
>>> 
>>> 
>>> It is a bit special that we have a North American and an international term.
>>> 
>> The citation does not need to be inline with the rest of the text.  The vast 
>> majority of the time, this is done using end notes in XEPs.
>> 
>>> It looks strange to devote so much space and effort to get the US term 
>>> properly explained. Shall we just delete TTY, and only say Text telephone ?
>>> 
>> That works, I believe you still need the reference.  See above.
> Here is a simple one from FCC that should at least meet the requirement to be 
> authoritative:
> 
> TTY
> A type of machine that allows people with hearing or speech disabilities to 
> communicate over the phone using a keyboard and a viewing screen. It is 
> sometimes called a TDD.
> 
> http://transition.fcc.gov/glossary.html
> 
> It however contains the TDD that should be depreciated. And has not the 
> indication that it is a North American subset term for more generally is 
> called text telephone.
> Sufficient?
> 
> /Gunnar

I do realize this might seem pointless to some, but I really do want to 
understand where this technology is coming from.  If we are going to reference 
a prior art, I really want to understand that prior art, and how it 
applies/influences/precedes this art.  This is why I harp on references.  That 
we are having the discussion tells me this isn't obvious technology, and I want 
to make sure our documents properly refer to the basis.

Given that, maybe it would be better to reference the protocols used by the 
devices in question.  The only one I could readily find is on Baudot, described 
in "Fax, Modem, and Text for IP Telephony" (Cisco Press, ISBN 
978-1-58795-761-8) and "EIA-TIA-825-A" < 
http://ftp.tiaonline.org/TR-30/TR-30.1/Public/TR-30.1/2000-01-BocaRaton/sp4628.pdf
 >.  Do either or both of these adequately describe the protocols in use?

I don't want a technical document mentioning prior art unless we can 
authoritatively reference a description of that prior art.  If that can't be 
done, then maybe we shouldn't mention it directly in this technical 
specification.


- - m&m

Matthew A. Miller
<http://goo.gl/LK55L>

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJQNljVAAoJEJq6Ou0cgrSPIAIH/ity8rk75Q6QnP9BpALrkdem
P2tshuwhi/zzgkDHlSm83WnbjOk01DQ9pZ+JKg5qVyMVtKV+MS6851ZqwO1039/i
eVxeeMhzMP1yOinKvvH7fwpoziyYaQb6TAPMmaHOtda+/frs90cJ39bk8GPERu6L
xQk8YmDbEVVXQQk2fZdLkMqTmk1H4Liix2ud4JxK5R1L/OboBA09ZSBwKEdiWwPC
Aux2ofH8OLuB23BVWrPAsn6/k+pNkILkL3mC7b5OGgXsGFxX26OJOO9ULSFWgVus
a0FW6hawjsBkG/3m8XgEPHaVH65+KELmlYuJAMXymacCTeqGdlJLfBw/vHlIwxs=
=vjz1
-END PGP SIGNATURE-

Re: [Standards] LAST CALL: XEP-0297 (Stanza Forwarding)

[Matthew Miller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On Aug 23, 2012, at 07:07, Matthew Wild wrote:

> Hi Jefry,
> 
> Thanks for the feedback.
> 
> On 23 August 2012 03:52, Jefry Lagrange  wrote:
>> I don't think the use case with message is enough. It would be more
>> clear if it had an use case with an IQ. It is not clear how one should
>> respond to a forwarded IQ.
> 
> Mmm :)
> 
> The specification used to be "message forwarding", and the last
> revision changed it to allow the forwarding of any stanza. I think
> this is fine, as I understand some protocols may want to forward all
> kinds of stanza.
> 
> However outside such a protocol, receiving a forwarded iq doesn't seem
> to make much sense to me. It certainly shouldn't be treated as an
> actual  in my opinion. There are far too many problems with that.
> 
>> Another question would be: Is it possible to bypass the middle man,
>> once you get the forwarded stanza (in case you need to reply)?
> 
> In the case of a forwarded message that is displayed to the user -
> it's the user's choice whether to send a reply, and who to.
> 
> In the case of any other kind of stanza, or one forwarded as part of
> another protocol - that's really something specific to that protocol,
> and not the forwarding mechanism.
> 
> If there are no objections to my line of thinking, I'll try and
> clarify the XEP - at least about s.

This fits with my interpretation, too.


- - m&m

Matthew A. Miller


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJQNjMxAAoJEJq6Ou0cgrSPB/QIAMW6iu2AkSZ6PyLuNF8H7doK
RSwrBb81sLowOTSg5VMVgzbmaJLCNFtTa/gRU30AF5ING5mg5otU1ADLDQQbByCv
mJdhovTK347Kjehg8mzdp1xEgOB08E0YD1drXB5OEQYmf4IkV+s9nwiEeisscGSo
0H4FvrSaLxaorzFFCrQ5N6RE0zEmauC8TcSN8I9Z/I1bJnVa8BDJOtYW29G7a9bD
oRBvoIjWNgexZCDUHLtSneV4utdsuwyhWY//ovAVmVhjt8u7PmIzteNnBx6QRU+4
XYP01FJD580efzOvPRJo9bW/SY4ymIlKcOvFI377K1B2ffAnW1qeDO953rWM51Q=
=teSF
-END PGP SIGNATURE-

Re: [Standards] Comments on XEP-0301 -- Section 1

[Matthew Miller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On Aug 22, 2012, at 16:33, Gregg Vanderheiden wrote:

> On Aug 22, 2012, at 5:05 PM, Matthew Miller  
> wrote:
> 
>> What would help most to alleviate this discussion further is to include an 
>> authoritative citation.
> 
> 
> here is one.  TTY takes you here - and it is all discussed. 
> 
> http://en.wikipedia.org/wiki/Telecommunications_device_for_the_deaf
> 

That actually brings up a different concern.  Wikipedia does not accept other 
wikipedia articles as authoritative citations, which most likely means we 
shouldn't accept wikipedia articles as authoritative citations, either.

A quick perusal of the article does have some other references that might be 
applicable.  I trust Mark can pick one that is most appropriate.


- - m&m

Matthew A. Miller
<http://goo.gl/LK55L>

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJQNXj8AAoJEJq6Ou0cgrSPrDsIALUxy8idUwh2LSnDTiH9kdfs
66Mf4IUemNwFYjsNkG15hox9bwEOc7R4CrBFCP2uVq//Mx8Y8PGgHVqqz4oi5woI
zQA9TuP5r0tkEh8MOSUm0mx0uUvTLYVTUHjHUXt1vDuKJn65hQYczrDO4zKA/fNO
K9NH1voIq6TmVbFiYaFL9dBNDcs+63Wd7CO6QYgo1FD6O8f0qPK1abFZpuRaoZVG
14gC1fW0MxJAK0Q2dpQrosgdR0H/E1J47kjTYTToHTH5p2rIsyOHqdCRLr9Npw5U
pDDr9oxWZcK4CE3YhIX9w0LwsFFpbRApGfAxWQeMWsfLLDAAUVb2oQk9itTOxj8=
=xgJt
-END PGP SIGNATURE-

[Standards] Fwd: [Council] Minutes -- 2012-08-22T15:00:00Z

[Matthew Miller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Begin forwarded message:

> From: Matthew Miller 
> Date: August 22, 2012 16:38:53 MDT
> To: XMPP Council 
> Subject: Minutes -- 2012-08-22T15:00:00Z
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> COUNCIL MEETING MINUTES - 2012-08-22T15:00:00Z
> ==
> 
> Logs: < http://logs.xmpp.org/council/120822/ >
> 
> 1) Roll Call
> - 
> 
> Tobias Markmann (TM), Ralph Meijer (RM), Matt Miller (MM), Kevin Smith (KS), 
> and Matthew Wild (MW) all present.
> 
> 2) XEP-0297 (Stanza Forwarding): Issue Last Call?
> - -
> 
> All present voted +1; Last Call to be issued by XEP Editor.
> 
> 3) XEP-0308 (Last Message Correction): Last Call Complete; Next Steps?
> - --
> 
> KS to incorporate feedback from LC, which will include stronger language 
> around "last". Council will decide whether to re-issue LC once changes are 
> made.
> 
> 4) Date of Next Meeting?
> - 
> 
> Next meeting to be held at 15:00 UTC on 2012-08-29.
> 
> 5) Any Other Business
> - -
> 
> 5.1) XEP-0301
> '''''''''''''
> 
> General discussion about the state of XEP-0301.  Some agreement among council 
> that the current tone might not be appropriate; MM to send comments to that 
> effect before end of day 2012-08-23 (MDT).  Peter Saint-Andre (PSA) to send 
> comments regarding sections 6-14 by end of week.
> 
> 5.2) FOSDEM
> '''''''''''
> Discussion regarding deadlines for devroom applications.  No actions for 
> council at this time.
> 
> 5.3) SRVs
> '''''''''
> 
> Some discussion around the state of SRV support in (client and server) 
> implementations.  PSA to gather more information, starting with a notice to 
> the jdev@ mailing list.
> 
> 6) EOM
> - --


- - m&m

Matthew A. Miller
<http://goo.gl/LK55L>

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJQNV+uAAoJEJq6Ou0cgrSPY3AH/iidaadVVA+9/h13yIjdfO9k
RIQDu6+aS/EXX5iFhirw1iKyfdSfNd9cXB91IGexN5t+vEJMRGxyQTQ9Ktnthmov
QmW9tmYljulSUgTq4cuZ4pg2JL7baE+lhkr/PUSB63VP1qSTPXLPJASsRNlcvEHS
EhBlZxdVyXInb2stlBNX05f2ilHOUvH3sXDMNbEHNy5EzhrydpW7P5IZm0BgHfF6
/cXZxnGrogON558EfsPv03ihjMlHSQyEGVuVyyin+pMxN02HySOlwZMVFNaO9nFW
lwdlGkb+BhasOvNzlsqdKujRQpSKEVo6RVjytWAskONcldX1PNv172jagfWdtZU=
=W8ON
-END PGP SIGNATURE-

Re: [Standards] Comments on XEP-0301 -- Section 1 - TTY

[Matthew Miller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On Aug 22, 2012, at 16:32, Gunnar Hellström wrote:


> /The US Access Board has the following definition in its latest proposal for 
> Accessible procurement, Section 508. E.103.4
> /http://www.access-board.gov/sec508/refresh/draft-rule.htm
> /
> TTY./  Equipment that enables interactive text based communications through 
> the transmission of frequency-shift-keying audio tones across the public 
> switched telephone network.  TTY includes devices for real time text 
> communications and voice and text intermixed communications.  Examples of 
> intermixed communications are voice carry over and hearing carry over.  One 
> example of a TTY is a computer with TTY emulating software and modem.
> 
> 
> It is a bit special that we have a North American and an international term.
> 

The citation does not need to be inline with the rest of the text.  The vast 
majority of the time, this is done using end notes in XEPs.

> It looks strange to devote so much space and effort to get the US term 
> properly explained. Shall we just delete TTY, and only say Text telephone ?
> 

That works, I believe you still need the reference.  See above.


- - m&m

Matthew A. Miller


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJQNV6KAAoJEJq6Ou0cgrSPA44H/io3UGGwY1bqHObs6qDPnMCI
zPRCAlkNsejQ7Kwohn6+EXQu5EjiwnWWfVRBhJyQRlZSl6BoY379mc9prwxqKUkG
Jr8PC9R8pPOkU8JQKquKIxg68BgCAXNf77KRIAwRas8+OpiOvi47twg3zo+HBpzm
c3G/g84D3xBJZCwuulgpYVwL2Rg9XS04g9bfmF5Q5q4OT5lJGCj62qOkC2xumrYo
fDpu3JRmKOd8No+YKGwdfzrBAq8RSC7OTvL0cs6JfweykdlvPwbIjO4si5Ak7vXv
p34MDTTBSyVX91Q52ALA5u98GAs35JYARTu8D4u0XLC0xzr8D9I0s674w/oGxoI=
=xlkv
-END PGP SIGNATURE-

Re: [Standards] Comments on XEP-0301 -- Section 1

[Matthew Miller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On Aug 22, 2012, at 15:51, Gunnar Hellström wrote:

> 
> On 2012-08-22 23:35, Gregg Vanderheiden wrote:
>> agree
>> 
>> You can say
>> 
>> TTY was derived from Teletypewriter - a device originally used by people who 
>> are deaf to communicate.  But today Teletypewriters no longer exist and TTY 
>> is used to refer to a type of telecommunications device used by people who 
>> are deaf that supports Baudot (and sometimes other coding schemes) over 
>> analog phone lines.
>> 
>> that however is probably too much history. but if you are using 
>> Teletypewriter - that would be the \correct way to use it.
>> 
>> 
>> /Gregg/
>> 
>> Gregg Vanderheiden Ph.D.
>> Director Trace R&D Center
>> Professor Industrial & Systems Engineering
>> and Biomedical Engineering
>> University of Wisconsin-Madison
> 
> I do not see TTY as an acronym anymore.
> 
> It is like BT that was read out British Telecom before, but is now just BT.
> 
> Or AT&T was read out American Telephone and Telegraph, but is now just AT&T
> 
> Wiktionary has solved it by putting (originally) after Teletypewriter. 
> http://en.wiktionary.org/wiki/TTY
> 
> Following that pattern it can be:
> 
> TTY (Teletypewriter (originally)) and other text telephones
> 
> 
> Gunnar

What would help most to alleviate this discussion further is to include an 
authoritative citation.


- - m&m

Matthew A. Miller


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJQNVeiAAoJEJq6Ou0cgrSPlNoIANTB6FoQGq139Aj+gMi1IIk+
Q2Q/kGL2+rKaM5/8NU0UnFixrBU2+3ga6so4KYqtFlyjMUGkRrj3LIHn/ic9sFIq
GleYhbFU+vDhfiLxtfEqbrAUjnFGK/txWaHidLxtBfCUXdYqn9yhLQXEv7XbZbAH
aM2C7tqYL/EFYX0swJ9ZrnrD4f7gVmvnNSCAommFAFwCnZ9onpNU0y/S2b82n1wm
KWzoPDJHB7RP/i4BkkQHLmU7U6LqGll8n163fBqzCa1aLZijKYxoGJhqWaQ+NA5s
Bn4HOLrtZxY8qjbeK1q9l/BOB2P/Fy/4LI2TcHdBNPwVIysjeRoGmLtiDyQaURs=
=qADA
-END PGP SIGNATURE-

Re: [Standards] Comments on XEP-0301 -- Section 1

[Matthew Miller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On Aug 22, 2012, at 15:42, Mark Rejhon wrote:

> Is this politics-proof:
> 
> "TTY (derived from teletypewriter) and text telephones"
> 
> I don't like it, but I am going to leave it unmodified (against M&M
> wishes) unless there's a consensus.
> 

Since it *WAS*, but is no longer, an acronym, I'm ok with this.  Is there an 
authoritative citation you can provide?

> 
> On Wed, Aug 22, 2012 at 5:35 PM, Gregg Vanderheiden  
> wrote:
>> agree
>> 
>> You can say
>> 
>> TTY was derived from Teletypewriter - a device originally used by people who
>> are deaf to communicate.  But today Teletypewriters no longer exist and TTY
>> is used to refer to a type of telecommunications device used by people who
>> are deaf that supports Baudot (and sometimes other coding schemes) over
>> analog phone lines.
>> 
>> that however is probably too much history. but if you are using
>> Teletypewriter - that would be the \correct way to use it.
>> 
>> 
>> Gregg
>> 
>> Gregg Vanderheiden Ph.D.
>> Director Trace R&D Center
>> Professor Industrial & Systems Engineering
>> and Biomedical Engineering
>> University of Wisconsin-Madison
>> 
>> On Aug 22, 2012, at 4:28 PM, Gunnar Hellström 
>> wrote:
>> 
>> On 2012-08-22 22:58, Mark Rejhon wrote:
>> 
>> On Wed, Aug 22, 2012 at 4:46 PM, Matthew Miller
>>  wrote:
>> 
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>> 
>> 
>> On Aug 22, 2012, at 14:42, Mark Rejhon wrote:
>> 
>> On Wed, Aug 22, 2012 at 2:30 PM, Matthew Miller
>>  wrote:
>> 
>> * Teletypewriter (TTY) and Text Device for the Deaf (TDD) telephones
>> [citations recommended]
>> 
>> Consulted with some peers.
>> 
>> TTY expansion to Teletypewriter -- OK, good idea.
>> TDD is actually correctly "Telecommunications Device for the Deaf",
>> but it is deprecated usage right now by most U.S. accessibility
>> organizations, in favour of TTY.  Europeans ofte use "textphones", and
>> variants thereof.
>> 
>> Also, the phrase "text telephones" is more compatible and
>> self-explanatory with the European equivalent of TTY, "textphones".
>> 
>> It's somewhat political behind the scenes in the various communities,
>> so changes to this bullet will need to be done very carefully.  I
>> spent many hours rewording just the Introduction as a result.
>> 
>> Mark Rejhon
>> 
>> That's fine.  I accept I operate under obsolete assumptions sometimes (-:
>> 
>> But it's important that all acronyms are expanded the first time they are
>> used, and even better to include an authoritative citation.
>> 
>> Oh, you might also be remembering I had
>> 
>> ... "TTY and text telephones for the deaf".
>> 
>> But I removed "for the deaf", when Peter/Kevin (one or both)
>> complained about three mentions of the word "deaf" due to the
>> overemphasis on the word, despite its clear application there.  So I
>> toned it down somewhat, reducing three mentions of "deaf" in
>> Introduction to just one mention.
>> 
>> I do not think expansion of TTY to Teletypewriter is a good idea. That tends
>> to mean the other use of the term TTY, the device that was often used as a
>> computer operator console terminal a long time ago and still lives in
>> language around such usage.
>> 
>> So TTY in this usage is more " A term used in North America for text
>> telephones, i.e. devices used for text and audio communication in the PSTN
>> mainly with deaf and hard-of-hearing persons."
>> 
>> Text telephones or textphones is the international term used by ITU-T ( E.g.
>> V.18 and F.703 )  3GPP ( e.g. TS 22.226 )
>> IETF ( e.g. RFC 4734 ).
>> Various countries in Europe have different names for the concept in their
>> national languages, so text telephone is not specifically European.
>> 
>> I hope it is clear by combining TTY with text telephone what it referred to,
>> so that we do not need to drag in a long descriptions of a peripheral item
>> into the spec.
>> 
>> Gunnar
>> 
>> 


- - m&m

Matthew A. Miller
<http://goo.gl/LK55L>

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJQNVdKAAoJEJq6Ou0cgrSPHeAH/2sX+65a9yiHGS+U6WXCztaF
1ku/80QIx2HdsxEPNR43x2UmfOuOLzpsStB9CPhMrXiKLPx6vXhI0w18phjvtxOd
4GNpjRWsrMCiys4pEbro5tCBVonvtJmRNxZx6HnaqwARJKTASHq6yia5Sc3c+3T6
gyhIFLtvCfE3k7JtZkgXsg5yChSz6zIcSyLOIipG1cyIoftJCRIvtvo4+Ph2m0cU
NzgC02pj66DSh1syNrCnpH09IJrQNbhOcnb5KeXVLZDSFjomvkgpWqzZ65LHZ7vR
65zpGPQ3ncnNuZNrEXxjgPAlDZilcLZZOCZFCKee0rEdms9Lp2rLiq4d1j4mJ5U=
=gOyw
-END PGP SIGNATURE-

Re: [Standards] Comments on XEP-0301 -- Section 1

[Matthew Miller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On Aug 22, 2012, at 15:28, Gunnar Hellström wrote:


> I do not think expansion of TTY to Teletypewriter is a good idea. That tends 
> to mean the other use of the term TTY, the device that was often used as a 
> computer operator console terminal a long time ago and still lives in 
> language around such usage.
> 
> So TTY in this usage is more " A term used in North America for text 
> telephones, i.e. devices used for text and audio communication in the PSTN 
> mainly with deaf and hard-of-hearing persons."
> 
> Text telephones or textphones is the international term used by ITU-T ( E.g. 
> V.18 and F.703 )  3GPP ( e.g. TS 22.226 )
> IETF ( e.g. RFC 4734 ).
> Various countries in Europe have different names for the concept in their 
> national languages, so text telephone is not specifically European.
> 
> I hope it is clear by combining TTY with text telephone what it referred to, 
> so that we do not need to drag in a long descriptions of a peripheral item 
> into the spec.
> 

If you use an acronym, you MUST expand it.  If Teletypewriter is not the 
correct expansion for TTY, then provide the correct one and include an 
authoritative citation.


- - m&m

Matthew A. Miller


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJQNVAgAAoJEJq6Ou0cgrSPJ9cIALp8BsVkzsmCcs7qwfyF7BMT
Ner6+ujUc8EOeXfmGk0LpJic24gyXF62T5jvP5JWcaZuGIgkS62tobzVNQnLRIp2
vWv2ni9M8/L3UCZ5JNLM+rh80iKVieQczhQ3dOG5KCWeb5UiBEWtkiMG7oM+uExc
zR4kKmiJVTd1bs+wrsfU3yTuJuFbrvghdtV2a5DFNpzgKi4DvtP76vEH/LKgtV8B
xEe500a75XB6LsFikA8mORqS7q6LI+rfcNvOR/wjuivrfPG9RFMCQAt2YhkQtde1
WCS5WMzcJO+UQYz+1556kCfpJr0Hp3Lp4qWNPbfsB6Pwa/F+K2xjgEoX1jY30oE=
=/eZf
-END PGP SIGNATURE-

Re: [Standards] Comments on XEP-0301 -- Section 1

[Matthew Miller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On Aug 22, 2012, at 14:42, Mark Rejhon wrote:

> On Wed, Aug 22, 2012 at 2:30 PM, Matthew Miller
>  wrote:
>> * Teletypewriter (TTY) and Text Device for the Deaf (TDD) telephones 
>> [citations recommended]
> 
> Consulted with some peers.
> 
> TTY expansion to Teletypewriter -- OK, good idea.
> TDD is actually correctly "Telecommunications Device for the Deaf",
> but it is deprecated usage right now by most U.S. accessibility
> organizations, in favour of TTY.  Europeans ofte use "textphones", and
> variants thereof.
> 
> Also, the phrase "text telephones" is more compatible and
> self-explanatory with the European equivalent of TTY, "textphones".
> 
> It's somewhat political behind the scenes in the various communities,
> so changes to this bullet will need to be done very carefully.  I
> spent many hours rewording just the Introduction as a result.
> 
> Mark Rejhon

That's fine.  I accept I operate under obsolete assumptions sometimes (-:

But it's important that all acronyms are expanded the first time they are used, 
and even better to include an authoritative citation.


- - m&m

Matthew A. Miller
<http://goo.gl/LK55L>

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJQNUUIAAoJEJq6Ou0cgrSPpTgIALSX5B5BtoNs9aX7cWYATnp4
iiUx63kkjyT5/zhuCZKKlRsZvWcr9hc5sQ2Dlhm0Uythc5VJhmYh2cCwqa6IxMDc
zc0wgy0yCodmouhVJQYJ/S7yNb2hSfaBzix6LwuS4WyySV2z+/wLQrrZrCOrU1ur
UfrBmUL6r7cpFKTsnCx3vK963Vl1/ez/ds1pLEFkeSXYpVU+qs7VHH5vLWcdQVIj
7aWEidVDH/+pU/l3WuXyzv9vwr1W6fIa2aOY8DUNyQWMlcZnjrVtisQ3oUQuIMtX
814rwLw6AJPWSwJZdNLKF6Er39c+NEiLQ3/Dk0eC0wsmYc4ncrrPVbCwP277pAQ=
=ILXr
-END PGP SIGNATURE-

Re: [Standards] Comments on XEP-0301 -- Section 1

[Matthew Miller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On Aug 22, 2012, at 13:35, Mark Rejhon wrote:

> Hello Matthew,
> 
> Thanks for your comments!
> I eager await your ongoing comments.  Just some brief reply:
> 
> 
> On Wed, Aug 22, 2012 at 2:30 PM, Matthew Miller
>  wrote:
>> * Reword the paragraph 3 in terms of the problems it is solving. One 
>> possible suggestion:
> 
> I like the inclusion of the following: It can also allow immediate
> conversation in situations where speech cannot be used (e.g. quiet
> environments, privacy, deaf and hard of hearing).
> 

That's fine.

> One potentially popular application that some end-users told me (plus
> potential users, like a friend of mine, who works in the military,
> where some secure text-messaging systems are used) is the ability to
> communicate quietly, privately, and covertly, using text -- and
> real-time text would also speed up communications without the sound of
> speaking, and without waiting for complete sentences of messages.  So
> any rewordings of the paragraph, should be able to adequately cover
> the above useful scenario of being able to communicate voice-style
> using text, without making noises.
> 

Just remember the target audience is implementers.  They'll usually already 
have a problem that this specification can solve.  You really really don't need 
to go into all possible problems this can solve.

> 
>> While XMPP CORE [RFC6120] and XMPP IM [RFC6121] provides for near real-time 
>> text conversation, this is often as sentences or sentence fragments that 
>> convey complete thought on the part of the sender, in a linear progression, 
>> as the user directs.
> 
> One observation -- by the deaf audience's eyes, instant message
> threads are not considered live (real-time) conversations because it
> implies forced waiting by recipients for sender messages.
>  This can be
> important during a deaf person's potential "fastest possible method of
> communicating".  So, I would prefer not to use the phrase "near
> real-time text" verbatim, because it's only as real-time as the sender
> wants it to be -- e.g. how frequently the sender hits Enter.   It
> could even be once every minute, which can lead to annoying waits, and
> is not near-real time.  I will try to find another synonym phrase.
> Also, in some accessible communities, the word "conversation" has a
> different definition.
> But you have a good point, my old text might not be good either to
> certain audiences.
> The challenge is, what text to replace with?
> 
> So, the challenge is, the paragraph needs to be written both
> geek-friendly (people like you and me) and deaf-friendly (one part of
> the audience).  The wording that you chose, will need to be tweaked.
> Although real-time text can be viewed (by some) as an accessible
> technology, it does have military and emergency applications, as well
> as teen texting applications, etc.  It's a challenge, fine balancing
> act, since I'm catering to so many potential audiences with this spec.
> 
> Mark Rejhon


Like it or not, XMPP fits the generally-accepted definition of "near real-time" 
(or "near-real-time" if you prefer hyphens). It has been applied to XMPP since 
(at least) internet-drafts of RFC3920 (circa 2003).

Also, this is a technical specification, not a marketing document.  You have 
realtimetext.org for marketing; XEP-0301 is for technicals.


- - m&m

Matthew A. Miller
<http://goo.gl/LK55L>

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJQNUEGAAoJEJq6Ou0cgrSPEn4H/2wIvFdYPOZBnDzYc4aHNdFY
FnBNCAMXaUXZA0z2Y1r6rTYfny9/j7iFpZUyqfja5d4PuAE5nuSZqDdzuAmjFcnX
SC5tJ6T1uq33zxrDJXiQ+ne2qpqXRikhLg7maSQwsj769lVUU0y3oL1gsoqlTBRM
h9ZXBxuyLPwKW3TZCAp9XuroMIIyfW4y+ox+awgtvOLzr+No19GUHt1C85rwiPxj
xIafH1EN+p48ClUrFSxuq5AKkABwaQ3dqZLtWSuQLO61XDmf6QzkRRPb2VodRMvf
3ZhkzAMFJKES9aQ0n8Xv7Do6F7RWiD56OBusJSxM+pf1zbYfcVSp017HTEyQ7Oo=
=Uviu
-END PGP SIGNATURE-

Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final

[Matthew Miller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On Aug 22, 2012, at 13:56, Joe Hildebrand (jhildebr) wrote:

> On 8/22/12 10:33 AM, "Matthew Miller"  wrote:
> 
>> I agree with Sergey.  If you received XHTML-IM, then any other rich text
>> transform ought to be disabled/bypassed.
> 
> What about URLs that are not in  elements?
> 

Frankly, "too bad so sad".  The sender really ought to have put them in anchors 
in the first place.


- - m&m

Matthew A. Miller
<http://goo.gl/LK55L>

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJQNToBAAoJEJq6Ou0cgrSPtFYH/R6RHTgw8V0vfb7SfLk+5Lgr
MZP7gbmxZapO7+JcW5blfTY96D7onAjQNQuOZy0kG5d3V2xZ7ORbFPlH+Axs55Ud
MzCPyKUBgT/7tNddFxhhyN1Vr6rVk0Mwf5scHqVI2Q0jUUEj62+w3j89Lvo8wHn7
SnRI4KKpGJfrFcPlD0v6zo0IQLXS+zjzcaNamJaLp0R47CPhAlaHa+hR3ff5lo60
DQgRkEZU9bdtsiI0ZSrUXEAm+gZN7Z6MG8YaMvSbDLOUrycNbmTtiEA8H8ejxtie
Yzp9c+MjjwlU2f5TutETqmiYDA+De/q0PEzp+W+nm9EA8BlzSUrGdvb1e3bhftk=
=s7XP
-END PGP SIGNATURE-

[Standards] Comments on XEP-0301 -- Section 1

[Matthew Miller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I'll slowly be commenting mostly on a section-by-section basis.

These are my comments regarding section 1 of XEP-0301: Real-Time Text.  There 
might be some mention of these earlier, but I've lost track.  If already 
addressed previously, then please ignore.

First, this section is written more as a marketing pitch and less as a 
technical description.  This bothers me enough that I strongly urge it be 
changed.

Specific suggestions:

* I think paragraphs 1 and 2 can be merged, in their current progression.
* De-emphasize the first sentence of paragraph 2. I personally do not see any 
technical reason for this call-out.
* Reword the paragraph 3 in terms of the problems it is solving. One possible 
suggestion:


##

While XMPP CORE [RFC6120] and XMPP IM [RFC6121] provides for near real-time 
text conversation, this is often as sentences or sentence fragments that convey 
complete thought on the part of the sender, in a linear progression, as the 
user directs. However, it is desirable to also provide to recipient clients the 
text as it is entered by the sending user. This behavior is particularly 
important for emergency situations or for speech-to-text transcription.

##


* Make a final paragraph about the previous implementations and where to find 
more information (eliminating the duplicates from other paragraphs). One 
possible suggestion:


##

The concept of real-time text is not recent.  Previous technologies that 
provide this functionality include:

* 'talk' command on UNIX systems [citation recommended]
* Teletypewriter (TTY) and Text Device for the Deaf (TDD) telephones [citations 
recommended]
* [RFC4103] and [ITU-T T.140] for Session Initiation Protocol (SIP)
* [Real-time IM] feature within AOL Instant Messenger (AIM)
* A component of Total Conversation, which is part of Responding to All 
Citizens needing Help [REACH112]

More information on this concept, including visual presentations on its use, 
can be found at [Real-time Text Taskforce].

##  


- - m&m

Matthew A. Miller


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJQNSU+AAoJEJq6Ou0cgrSP6p4IAMV6WDxB8Uf9Cw2LbxJBvgRc
2HUapMlUVCDQIJpGkpefDQy66LjwcNk7Retqy/bmLjud2Lm751wVCVgw8prm/wj7
zUE4OQcLBQfoz/zlbXBpPvri6GA/RQKqV7UvIvb36t2dGxQap3MR8Bs701U5bl/Q
ej6N5xsPOYEyXG/OLDUSyXCvbdW5J8eL++VqUOFBS8b9i7+R4+rYD/srp+uf6guC
D8wK7pqxLqucZNqt1XftsicCjCUlbec28vRyKyKiZbP6Eylcp8wtDpsDDvDDrp6Q
1CEFev5mLt2aSB3oZTCjOpM8XmBx40wLAcjd/Yzj6o3taLJACNK0ZS/NGKIKErI=
=9lR+
-END PGP SIGNATURE-

Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final

[Matthew Miller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I agree with Sergey.  If you received XHTML-IM, then any other rich text 
transform ought to be disabled/bypassed.


- - m&m

Matthew A. Miller



On Aug 22, 2012, at 02:35, Sergey Dobrov wrote:

> On 08/22/2012 02:31 AM, Joe Hildebrand (jhildebr) wrote:
>> Or suggest to change *this* to this or
>> *this*.
> 
> No, the thing is that a client changes this:
> 
> *this*that
> 
> in the *incoming* message to this:
> 
> thisthat
> 
> which is obviously wrong since a sender can make things strong without
> such plain text formatting :)
> 
>> 
>> On 8/21/12 2:57 AM, "Sergey Dobrov"  wrote:
>> 
>>> Btw, often implementation of XHTML-IM conflicts with internal
>>> hyperlinks/smiles/plain text formatting like *this*. Maybe it will be
>>> useful to add recommendation to switch any these parsers off when a
>>> client have a deal with XHTML-IM message?
>>> 
>>> On 08/01/2012 03:58 AM, Peter Saint-Andre wrote:
 At its meeting on July 25, 2012, the XMPP Council agreed to issue a
 "Call for Experience" regarding XEP-0071 (XHTML-IM), in preparation for
 perhaps advancing this specification from Draft to Final in the XSF's
 standards process. To help the Council decide whether this XEP is ready
 to advance to a status of Final, the Council would like to gather the
 following information:
 
 1. What software has implemented XEP-0071? Please note that the protocol
 must be implemented in at least two separate codebases (and preferably
 more) in order to advance from Draft to Final.
 
 2. Have developers experienced any problems with the protocol as defined
 in XEP-0071? If so, please describe the problems and, if possible,
 suggested solutions.
 
 3. Is the text of XEP-0071 clear and unambiguous? Are more examples
 needed? Is the conformance language (MAY/SHOULD/MUST) appropriate? Have
 developers found the text confusing at all? Please describe any
 suggestions you have for improving the text.
 
 If you have any comments about advancing XEP-0071 from Draft to Final,
 please provide them by the close of business on Friday, August 31, 2012.
 After the Call for Experience, this XEP might undergo revisions to
 address feedback received, after which it will be presented to the XMPP
 Council for voting to a status of Final.
 
 You can review the specification here:
 
 http://www.xmpp.org/extensions/xep-0071.html
 
 Please send all feedback to the standards@xmpp.org discussion list.
 
 Thanks!
 
 Peter
 
>>> 
>>> 
>>> -- 
>>> With best regards,
>>> Sergey Dobrov,
>>> XMPP Developer and JRuDevels.org founder.
>>> 
>> 
>> 
>> 
> 
> 
> -- 
> With best regards,
> Sergey Dobrov,
> XMPP Developer and JRuDevels.org founder.

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJQNQngAAoJEJq6Ou0cgrSPBE8H/0p+Vd00IUsT8aXWqhcDH4sJ
JXA+NntCufRkABSyKHdSpf8MBqWQySxIs09fBTPZZeB8YCecDnnWVxs6NX7fgGCQ
8e6GSR8iVO+5b76jkuoIZMxGbl3/vHmX6wuoujruCnsWmAXPfgcONZNXeaTpxMiD
zMMHou+ctdJQUstA3eIBN50ckgwQOTPPqDtwSV8F3Z3rOKp6wO5fYrP2867nuLOI
vhU5V1HrEVIMPfiesILgg+ckQuUrbQ6i2NcE+X+RckH9uilX3cPdXJlFOpaeaI2+
AHOEioszYLbD/yWSIOAaVLZ8USUVZbV8jAYmy6Cyu8qDfmCo9zjBTyIXFW+4kcI=
=Cupk
-END PGP SIGNATURE-

Re: [Standards] XEP-296 problem?

[Matthew Miller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On Aug 15, 2012, at 09:45, Yann Leboulanger wrote:

> Hi,
> 
> I was wonder what should I do in this situation:
> user A and B are connected with resource r1. They that, so messages go from 
> A/r1 to B/r1.
> 
> user B connects a second client with resource r2 with a higher priority.
> 
> Where should go next message of user A?
> 
> Someone pointed me to XEP-0296 which clearly answer the question: next 
> message should go to bare JID.
> 
> So I started thinking how to implement this XEP, and came to a problem:
> 
> let's imagine that r2 is LOWER prio than r1. XEP-0296 says that we still need 
> to go to "unlock state". This mean starting a new thread of course as we 
> don't know which resource will get it. But if the begining of the 
> conversation was crypted? or if we negociated the log options or anything in 
> XEP-0155, then we need to restart the negociation?
> 

Any presence change from another resource for an entity is a change in the 
user's state.  The next message ought to go to the bare JID to allow the 
infrastructure to account for this change.

For encrypted chat, see < http://tools.ietf.org/html/draft-miller-xmpp-e2e-02 > 
for one approach to the problem.

> Same thing if B just go away or na? so we cannot continue en encrypted 
> conversation if we go away?
> 

Per a separate reply, we can relax this if there is only ever a single resource 
available.


- - m&m

Matthew A. Miller


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJQK8uOAAoJEJq6Ou0cgrSPnqIH/RyEldOWQhGSt75ckbn02ZrV
r46YfQueN9z/C4YFas8PWkr7+pUnXXX7CmWzweaKAuGDNXh3UriWcAL1ov7C1e3D
4YHbv8zTMClq+JxB0sZYvcFJpQgOtWBH4TusX3bSrz+oPWQhGQK+5bUX/Vduc269
aFvE1meJoM8Ia9JNf54e75zWXpFPp7kChwmrJ76FKIfAgSn+08kwhEqI010UXjO5
eUmT0JhXDxy9gWb1xA65PaW/S0xgdiKH1L6iPSv5bAG2yMHLdtG2w1bz+gkE4Qq5
QMFKnMgaS9wUy3EC6i45s2vVIvPmksTwSf9ghtaWvKGLu6M5aiIwClmc/MB/Bm4=
=/n8G
-END PGP SIGNATURE-

Re: [Standards] XEP-296 problem?

[Matthew Miller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On Aug 15, 2012, at 09:49, Kevin Smith wrote:

> On Wed, Aug 15, 2012 at 4:45 PM, Yann Leboulanger  wrote:
>> Same thing if B just go away or na? so we cannot continue en encrypted
>> conversation if we go away?
> 
> Conversations with B shouldn't be unlocked while B has a single,
> unchanging, resource. (I think this may be in disagreement with 296)

It might be in disagreement, but I think we can change it.


- - m&m

Matthew A. Miller


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJQK8lCAAoJEJq6Ou0cgrSPJjsH/1efng8bjie1fEWiw1gNymZv
L1kO3YijDLDQfxwvmr3sMX2DzJVkx6xJxi5/dhArsRjecgPlO/H9IxY79koRqHCY
GyqXcSe/ECgKMoJPVCCnYwQl9LsCqRaonsRfA3uXuBXsTzQM1iAAuTJkJW8cjfej
vHoBIMQoB/EKVDbhNQ5+RAQEFcUwP7GVBmnLHdbdOlXGsM8QnEjTQwtX5uUCdWMW
ORyqM98XSnIOfFaHbxrum/WmtW8DiuuqmbYuRSxLhLz0qSDSAJ6Nq/EhWNPGtDdV
EJuw1n9PBYX9MTalIpH1xdgMeJ+ddBc8RF3DzAB+rgTR+tnflFrGeypig3oyV8k=
=XNS5
-END PGP SIGNATURE-

Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)

[Matthew Miller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On Aug 15, 2012, at 08:54, Kurt Zeilenga wrote:

> 
> On Aug 15, 2012, at 7:28 AM, Kevin Smith  wrote:
> 
>>> In fact, I'd argue that this spec is a technical solution to a social
>>> problem
>> 
>> I note, after drafting many more acerbic replies, that this is
>> consistent with all specs.
>> 
>> Messaging is a social problem.
> 
> Yes.
> 
> My concern is how effective our solution is in solving the social problem, 
> messaging between humans.
> 
> XMPP IM (without 308) has demonstrated itself to be an effective solution.  
> XMPP IM with 308 implemented universally would also likely an effective 
> solution.
> 
> It seems to me that XMPP IM, with some clients supporting 308 and some not, 
> will be less effective than either of the above solutions, simply because key 
> information (this message is a correction) is lost on fallback in clients not 
> supporting 308.
> 

I do not completely agree that key information will (always) be lost.  It does 
indeed matter significantly how a client renders corrected text:

1) delete of old, overwrite with new (lost information)
2) strikethrough of old, place new immediately next to it (no lost information)

And there's a couple of other ways I can see this going...


- - m&m

Matthew A. Miller


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJQK7meAAoJEJq6Ou0cgrSPlGgH/idyONFgZueMp0vHgieGX2jx
uaQ6JwlBrJ/QCSgf7IjOWDBSENxJhg2Th72TI9RjmBCJv9842qXHmaKu2cf5nCNb
cle6rThuvqCeI0BTgsg8d9hgj2jdA65Tn4ljnyrL05JQlPMeg8wSaHIK+kmh7Z+2
DViszYVZXvJPLgNC98ZpttvJZsL9GXYS+zc5UO1JC0Ehgdr3/WdPMai8J8KVpnGl
pqWHHVTUieZc+jv25WgnIa89V+6YlCQlAj8bl4/5Cs6r/Dzx3uB19T+twFW2b/oh
gDnj1xlk0coQ6FUxeTSruPaCDxC90vdxH1Te2cCyktdEU9KhXnR2/Pu0aLeyfTA=
=5hoj
-END PGP SIGNATURE-

Re: [Standards] XEP-0301 -- embedding small illustrative animated GIF into spec

[Matthew Miller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I have concerns embedding something into a document that reduces its 
printability.  As archaic as this sounds, I often print specifications in order 
to review them!

That said, I'm not immediately opposed to it, but would approach with caution. 
The text is still the record of authority here.


- - m&m

Matthew A. Miller


On Aug 1, 2012, at 07:46, Mark Rejhon wrote:

> Note: Precedent on image embeds exists -- an example image is embedded into
> XHTML-IM (XEP-0071).
> 
> On 2012-08-01 8:53 AM, "Peter Saint-Andre"  wrote:
>> 
>> On 7/23/12 1:17 PM, Mark Rejhon wrote:
>> 
>>> [Question]
>>> Understood -- animation really helps explains real-time text, if they
>>> haven't seen it before.
>>> Can we use a more well-known site (i.e. realtimetext.org
>>> ?) since we can put my animations there too?
>>> Alternatively, can we embed an image, like XEP-0071 has an embedded
>>> image?  (If I make a generic animation, and convert it to animated GIF
>>> format)
>> 
>> I think it would be great to host a sample animated GIF at xmpp.org, for
>> archival purposes.
> 
> For now, I have switched it to realtimetext.org in the already-published
> v0.6, but an embed (found in certain XEP's) would be even more preferable,
> though it obviously would have to be very small and very generic, which
> probably requires it to be hand-made or a special RealJabber mod.
> 
> Examples animations I have already made, which are probably not suitable,
> but useful to see:
> 
> 1. My animation of key press intervals
> http://www.realjabber.org/anim/real_time_text_demo.html
> - too big
> - too non-generic
> 
> 2. Facebook-style concept animation
> http://www.realjabber.org/anim/facebook_chat_concept.gif
> - closer to correct size
> - but too non-generic
> 
> 3. The animation on cover page
> http://www.realjabber.org
> - still too non-generic
> - this was my first animation ever
> 
> So, that means:
> As I will have to hand-make a genericization (something suitable even for a
> Wikipedia page, for the 'real-time text' entry)...
> ...If no other people at XSF objects technically to an image embed, what
> are the recommended criteria for an image embed in XEP-0301 demoing generic
> real time text:
> - minimal GUI elements (OS neutral)
> - small size
> - romeo/juliet names (recommended)
> - no cuecard introduction frame
> - compatible open source imagery only
> 
> Mark Rejhon

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJQGUZeAAoJEJq6Ou0cgrSPaSoIAMPf/LuE+8BglAnKF9ZvIl8+
BZxWsjKjsncS9tPU4WzE8dLSwW2eEilFU9jc0YXfJEwmwOmattPvQBYrdy16T6r7
Csc3Zcrm9gRDI5I1cAvUtcIBpFoI5njdYqf68yQQU1U06BGkBHldKf1t1JU/bi9F
8zn8CcurwR5U1Fd1D1jMLLmv2Yb0ij79boT1qDc1ilAhClz4+zvFTvsYuksLT+vR
JB+A3kv57Pc7/7cj1TxYjHQT4RN7ABHN25kdwhu7h15Qn4Yav9SeVLTNFedCY3ke
s8WzecA8IfzBpt8kfyyzJB1rNaLA6AmFdf3OPEO7PNHvNkK1Ftgw+ZbOeQFsAds=
=fB3j
-END PGP SIGNATURE-

Re: [Standards] NEW: XEP-0308 (Last Message Correction)- Interop with XEP 0301 RTT

[Matthew Miller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On Jul 20, 2012, at 00:45, Mark Rejhon wrote:

> About the agreed XEP-0308 and XEP-0301 compatibility:
> I would like to amend the list of advantages that I sent earlier, due to
> the improved retroactive editing protocol that is already agreed between
> myself, Peter, Kevin, and Lance.  (Except potential disagreement about
> whether to have a third separate 'disco' which I still think is unnecessary)
> 

I still don't understand your resistance to disco, and the argument "the 
software is buggy!" is specious at best.

However, I'm willing to reserve full judgement until I read through the updated 
versions.


> Advantages of the now-agreed 'id' attribute of 
> 
> It would still work in clients that didn't support either XEP-0301 or
> XEP-0308
> Result: The retroactive edit may appear as a separate message (third
> message)
> (If software persisted in trying to do this regardless of recommended disco)
> 
> It would still work in clients that supported XEP-0301 retroactive but
> didn't support XEP-0308
> Result: The retroactive edit shows up as a new real time message, and then
> transmitted as a separate message.
> (If software persisted in trying to do this regardless of recommended disco)
> 
> It would still work in clients that supported XEP-0308 retroactive but
> didn't support XEP-0301
> Result: The retroactive edit shows up only when the edit is finished (no
> real time at all)
> 
> It would still work in clients that supported XEP-0308 retroactive but
> only supported XEP-0301 non-retroactive
> *Result: Real-time text at all times, and real-time retroactive editing
> occurs where the "new message" normally is.*
> 
> It would still work in clients that supported both XEP-0301 retroactive
> mode and XEP-0308
> Result: Real-time text at all times, and real-time retroactive editing can
> occur "in-place". (enhanced user experience)
> 
> 
> Thanks,
> Mark Rejhon
> 
> On Fri, Jul 20, 2012 at 2:34 AM, Mark Rejhon  wrote:
> 
>> On Fri, Jul 20, 2012 at 2:16 AM, Gunnar Hellström <
>> gunnar.hellst...@omnitor.se> wrote:
>> 
>>> Your current sentence is:
>>> 
>>> "to have improved presentation of real-time text during message correction"
>>> 
>>> Without the added feature of real-time edit, there is no presentation of 
>>> real-time text during message correction. There will be a freeze and wait 
>>> until the edit is done and sent as an XEP-0308 replace. So there is nothing 
>>> there that can be enhanced or improved. Real-time text presentation during 
>>> correction is introduced by the feature.
>>> therefore my proposal is still:
>>> 
>>> "to have presentation of real-time text during message correction"
>>> 
>>> No -- Not necessarily.
>> It's still possible for software to support XEP-0301 and XEP-0308, and
>> still be able to do real-time text during retroactive, without supporting
>> the 'id' attribute.  The behavior is just slightly different.
>> I am re-quoting the behavior written in an earlier message.
>> 
>> *Backwards compatible behavior (End User Viewpoint)*
>> The retroactive real-time edit will temporarily appear as if it was a
>> brand new message.   Basically, the real-time message will be a *copy* of
>> the old message, while the retroactive edit is taking place.   When the
>> edit is finished, the real-time message disappears and the edit shows up
>> above in the last message.
>> 
>> *Backwards compatible behavior (Developer viewpoint)*
>> Technical reasoning in 0301+0308 clients that don't do 0301 retroactive:
>> Why this works 100% backwards compatible is due to section 4.2.2 and
>> section 4.3 of XEP-0301.   For retroactive RTT, to remain backwards
>> compatibility, I would always require event='reset' everytime you begin to
>> reference a retroactive edit.  Clients are REQUIRED to follow the
>> event='reset' behavior described in XEP-0301 section 4.2.2 
>> http://xmpp.org/extensions/xep-0301.html#event
>> The client doesn't know it's a retroactive edit (it ignores the id
>> attribute), so the real-time message temporarily shows up as a new message
>> -- a *copy* of the previous line.   It's as if the user copy and pasted the
>> previous line, and began editing.  When the retroactive edit begins, the
>> end user see a copy of the previous message, because the software thinks
>> it's a new real-time message being started.   (event='reset' is treated as
>> event='new' thanks to the current version 0.3 wording of section 4.2.2)
>> ... Now, when the retroactive edit is finished, the  gets
>> delivered, which forces the real-time message to be cleared. (Section 4.3
>> says so)
>> http://xmpp.org/extensions/xep-0301.html#body_element
>> Thus, the real-time message disappears when the edit is finished,
>> simultaneously with the previous message being replaced by this.  To the
>> user, it looks like the edit suddenly moves upwards to the previous line.
>> 
>> The "enhanced" user experience would occur, when the software deci

Re: [Standards] XEP-0301 Fallback Mechanism of Determining Support (Accessibility)

[Matthew Miller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On Jul 11, 2012, at 14:37, Mark Rejhon wrote:

> ETA is Monday but I will try to accelerate the changes to allow an
> additional interirm version for reviewers like you.
> 
> It is just mostly grammatical and wording choices, and section refinements
> discussed thus far.  v0.4 will be relatively minor update in comparison to
> the current v0.3.

Take your time, and do it right.  Monday is soon enough, IMO.

> On 2012-07-11 10:38 AM, "Kevin Smith"  wrote:
> 
>> On Tue, Jul 10, 2012 at 9:08 PM, Mark Rejhon  wrote:
 I'm still aiming to do a review of the XEP soon - I'll try to suggest
 appropriate text for bits that I suspect need it when I do.
>>> 
>>> 
>>> Please. Thanks!   Keep in mind of the big laundry lists of suggestions
>>> already submitted by others;
>> 
>> If there's still a list of expected changes I'll wait until those are
>> in before taking a look at it - reviewing stuff that's already changed
>> would serve little purpose.
>> 
>> /K
>> 


- - m&m

Matthew A. Miller


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJP/eSOAAoJEJq6Ou0cgrSPdGAIAKH19i4jipUTV7ToUvsXXVf9
vC7TPYCtEa0Hn8ZM67OWZRBa7Z41ePCp2r2qjTZdg5iwei+ULfyIdpuQ/KMBFqOj
wjWfpsCXtJQB4YXNxY6+L2ZksHI9KJ7rXMULU53JbNtghHiux+P6a2o+i0kxc2n/
DbYj37hqgENulHvKIkmRMb+mk34LlKLFOIgsaXs797PnKrtzGwavTE/4GDr4cMV7
22VMBMIsV6xeOO9+/GfeFMfDME8feYxWf6jKRs3ddx2SS9I+y9xCRLykH4Wjn1rH
gRiCPSV1rqkzU7Xjkc/ILlE4ycm/2MbhGc0X07q9KYVOlnLVxx2kBOwOn5bbo4E=
=GIvz
-END PGP SIGNATURE-

Re: [Standards] Proposed XMPP Extension: Data Forms XML Element

[Matthew Miller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On Jun 21, 2012, at 10:47, Peter Saint-Andre wrote:

> On 6/20/12 8:42 AM, Peter Saint-Andre wrote:
>> On 6/20/12 6:03 AM, Sergey Dobrov wrote:
>>> On 06/20/2012 01:32 AM, Peter Saint-Andre wrote:
 On 6/19/12 10:17 AM, XMPP Extensions Editor wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
> 
> Title: Data Forms XML Element
> 
> Abstract: This specification defines an XMPP protocol extension for 
> including XML-data in XEP-0004 data forms.
> 
> URL: http://xmpp.org/extensions/inbox/xml-media-element.html
 
 As Lance Stout pointed out in the j...@conference.jabber.org room...
 
 This proposal has an element name of:
 
   
 
 However, the core XML spec says:
 
 "This specification does not constrain the application semantics, use,
 or (beyond syntax) names of the element types and attributes, except
 that names beginning with a match to (('X'|'x')('M'|'m')('L'|'l')) are
 reserved for standardization in this or future versions of this
 specification."
 
 See: http://www.w3.org/TR/REC-xml/#NT-element
 
 So at least we need to change the element name. :)
>>> 
>>> Ok, I thought about such restrictions but was not be able to find them
>>> in specs, so thanks to Lance.
>>> 
>>> What other name can be used for that? I suppose to use just >> xmlns='urn:xmpp:xml-element/>
>> 
>> Anything but 'x' 'm' 'l' --  or  or whatever you
>> please. :)
> 
> Sergey fixed this, and I've pushed his update to git and to the website:
> 
> http://xmpp.org/extensions/inbox/xml-media-element.html
> 

That clears my objection, thanks!


- - m&m

Matthew A. Miller


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJP5HKOAAoJEJq6Ou0cgrSP4SYH/1ep8CZt9YUhG4wjeg9fL22x
zb4+PunDmRNliY07/RAVGeA31/BynV12ZAx+gWa2/uThNXmP7DLPYGW7Tj72UcOz
A3MeRhGeLthH3Gn6TWVqXHvTEthBYxIM+iUL8xf1SiIFxKd2bcq+w462XUZMK/VZ
nj4QZ7J7AcXfok28OR9hnyfpIUXTnVoUyCtbYTQm4+4L1B0+A06G1SXjgex9R7C6
+OklW0JcDO3z6D+G9aAjSUc65Ak94VWiswIpSB2qeahY9OXw49xTEPN+nty15pXQ
bVBfbiIzzLngcdJj/G9dWKpM8IgY1uxACxgiUfoseU3pd/JLYR1/pS+4co4d9Bk=
=llFI
-END PGP SIGNATURE-

[Standards] Fwd: [Council] Minutes - 2012-06-20T15:00:00Z

[Matthew Miller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

FYI

Begin forwarded message:

> From: Matthew Miller 
> Date: June 20, 2012 10:53:28 MDT
> To: XMPP Council 
> Subject: Minutes - 2012-06-20T15:00:00Z
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Meeting Log: < http://logs.xmpp.org/council/120620/ >
> 
> 0) Roll Call
> 
> Present:
> - - Tobias Markmann (TM)
> - - Ralph Meijer (RM)
> - - Matt Miller (MM)
> - - Matthew Wild (MW)
> 
> Scheduled Absence:
> - - Kevin Smith (KS)
> 
> 1) XEP-0047 - Advance to Final?
>  - text: < http://xmpp.org/extensions/tmp/xep-0047-2.0.html >
>  - diff: < http://xmpp.org/extensions/diff/api/xep/0047/diff/1.3/vs/2.0rc1 > 
> 
> RM, RM, MW, MM voted +1; KS to vote on list within one fortnight.
> 
> 2) XEP-0191 - Accept rev 1.2?
>  - text: < http://xmpp.org/extensions/tmp/xep-0191-1.2.html >
>  - diff: < http://xmpp.org/extensions/diff/api/xep/0191/diff/1.1/vs/1.2rc1 >
> 
> RM, TM, MM voted +1; MW, KS to vote on list within one fortnight.
> 
> 3) Proposed XMPP Extension: Data Forms XML Element - Accept as Experimental?
>  - < http://xmpp.org/extensions/inbox/xml-media-element.html >
> 
> The proposal is not accepted at this time; MM has sent formal objections to < 
> standards@xmpp.org >.
> 
> 4) Proposed XMPP Extension: Security Labels in PbuSb
>  - text: < http://xmpp.org/extensions/inbox/pubsub-labels.html >
> 
> No objections from RM, MM; TM, MW, KS to note objections (if any) on list 
> within one fortnight.
> 
> 5) Date of next meeting
> 
> Next meeting scheduled for 6/27 @ 15:00 UTC.  RM notes he may not be able to 
> attend.
> 
> 6) Any other Business
> 
> * MW noted changes to XEP-0297 ("Stanza Forwarding") are pending, and asked 
> if anyone objects to incompatible changes; none noted from those in 
> attendance, advice from KS to be sought later.
> 
> 
> - - m&m
> 
> Matthew A. Miller
> <http://goo.gl/LK55L>
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> 
> iQEcBAEBAgAGBQJP4gAJAAoJEJq6Ou0cgrSP54oIANSY5XlSs8j88ebD3kbGSC6f
> 1MbuIpb3KEVPzXOlk9rQPSzDz+IzeSLldRrkJT1G7zH1fTtzDedwtUbhLlV0eZH9
> /3P+betLLHWXVFBe1jY7O9Wdm3Dgm25Co6vYlN5Fj1NUHAXc3Zl20V2zIPjXgPGQ
> nJ+ZcWPgpSH6BambmN3bTteYvGu3cP7a3ulsh70LC/hqAC03DfaT8T2WiUk+0bX4
> OXxgAjI21r/4zWSWrAAMBtSL90bH9Y6TCOvhP1yetA397EKoY+u+IiNcPTfMjMZs
> /pkxfCPmbC2mI+Za1w/y1Z6t8yZ8t4KT0vxThtu5pkRtgWJFPkD9TV12NKVbQZY=
> =unwT
> -END PGP SIGNATURE-


- - m&m

Matthew A. Miller
<http://goo.gl/LK55L>

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJP4gAvAAoJEJq6Ou0cgrSPKp4H/Aw7+Wp9RuUBoRQdrgt742Em
qXIST2w6hpTZEHoZQfO9LJV441zaS/BWqjUnPZb02FO6sxTeqGyhXHfPirxKNMp6
IrRKD6/G568GQIOip1yr7ZuUrLfVrpZ3Gp+REnxi4UQetbMzGQCgZpstJSsTfFw4
Cv+cwEpGggxpLcq5796hRSa/c32Y0kqJohRiPQE+4Rqro2BSdaZ5YNgUGrepVf4a
+kDLlnsXoWSj91a77HaGeXbgnGaT+inNYItxyR/CdIQOdiDz88RKyoHkLyXDXl8H
wZ2BuIPNG8jhO4n+lPuTr/eakRBtz/HXUpomRmOQ8DdPjD1WJVfoSdHH5GYCJEo=
=i0ET
-END PGP SIGNATURE-

Re: [Standards] Proposed XMPP Extension: Data Forms XML Element

[Matthew Miller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The council as decided not to accept the proposal at this time.  The primary 
objections to date are:

* Malformed XML - As noted further in this thread, the name "xml" is not 
well-formed XML, and MUST be changed to something that is well-formed.


- - m&m

Matthew A. Miller


On Jun 19, 2012, at 10:17, XMPP Extensions Editor wrote:

> The XMPP Extensions Editor has received a proposal for a new XEP.
> 
> Title: Data Forms XML Element
> 
> Abstract: This specification defines an XMPP protocol extension for including 
> XML-data in XEP-0004 data forms.
> 
> URL: http://xmpp.org/extensions/inbox/xml-media-element.html
> 
> The XMPP Council will decide in the next two weeks whether to accept this 
> proposal as an official XEP.
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJP4fyOAAoJEJq6Ou0cgrSPUC0IALCSf+arMEvtLuh8XW9APXGq
GKPG2R9zHsObsYgeje29oEtJocMy45fpIZwNrjaLWxIEnB4YvZB61nJbZ43AQhKY
ChT1Pm9+E/Q1FXrSq2mng0ni/k6dtCzOJr4AhMHK8xtk+mcv5CGSedqMhaulCQI8
2HlbTkRibFcr7QrhlpXe06jsmq6KTgrbbO7PQ/EbgSOLBwUyRj69en/hcHFV+j+B
QicnLfIegUXsZvg5QxXth/PqJRLn4f65X2/lf5FzBDA6vo+I86jUhNkHIewho3wn
cV+hzVfjBSziWOTlqK4qvRewCFy5OBhW+JeUw/sNwIBnECItDjONAVrCkU4y+Sc=
=V/K7
-END PGP SIGNATURE-

Re: [Standards] Call for Experience: Advancement of XEP-0047 (In-Band Bytestreams) to Final

[Matthew Miller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On Jun 12, 2012, at 13:57, Peter Saint-Andre wrote:

> On 6/12/12 1:44 PM, Justin Karneges wrote:
>> On Tuesday, June 12, 2012 12:10:30 PM Peter Saint-Andre wrote:
>>> On 5/24/12 8:44 AM, Peter Saint-Andre wrote:
 On 5/24/12 1:01 AM, Sergey Dobrov wrote:
> On 05/23/2012 04:45 AM, Peter Saint-Andre wrote:
>> Old thread alert!
>> 
>> 
>> Well, the spec says that the length restriction applies to the
>> base64-encoded data, so I think we meant that this does *not* apply to
>> the raw data. However, you seem to be saying that this might be
>> difficult to implement. Have other folks experienced this problem?
> 
> Have other folks experienced this problem implementing things right ;)
> 
> I know that some implementations (maybe all?) measure raw data and not
> base64.
 
 If that's what all code does now, then I think it's fine for us to
 update the spec so that it reflects reality.
>>> 
>>> Does anyone object to making this change in the spec?
>> 
>> I think measuring the raw (pre-base64-encoded) data is the most sensible, 
>> and 
>> likely what I had originally intended but poorly conveyed in the XEP. So 
>> this 
>> is fine by me, especially if implementations are working this way.
> 
> Super.
> 
> I propose the following change.
> 
> OLD
> The base64-encoded data to be sent, prior to any wrapping in the 
> element and IQ or message stanza, MUST NOT be larger than the
> 'block-size' determined in the bytestream negotiation.
> 
> NEW
> The data to be sent, prior to base64-encoding and prior to any wrapping
> in XML, MUST NOT be larger than the 'block-size' determined in the
> bytestream negotiation.
> 

WFM


- - m&m

Matthew A. Miller


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJP159pAAoJEJq6Ou0cgrSPcNYH/0mZplvX4ra7LEVpsrLw0WTI
AS9P3xwqwFbVGvdfSIyGV4N9IZOQAn44/DanEK9kMbrxAaaDr83wGCCIpsnM1lgY
bILeet/v2yZh/vUezXJuCHISgPiJhozYBAraGJ2aPtRK4Pm2O5C+v0FUtv9eKs1K
eXdYoJgWQAdz5mV7tpVaFOTUvLKZhGvifcBPR5CXdjoIzdJ/NZLNjyG/jnn3s/jA
5G1n8vrW2i2B1bFl6MtiXAGXhdi9DhXEOklUYEYQKtmnXpKAFpE/vcjPDB+eDzUn
dyQJp43Ww24TjrJTaGi1madPh/xg1W54jDWbRZ7uarfZWAxOiozT57PeCfP2YIM=
=ir5O
-END PGP SIGNATURE-

Re: [Standards] invisibility

[Matthew Miller]

On May 29, 2012, at 10:53, Peter Saint-Andre wrote:

> On 5/29/12 10:36 AM, Matthew Wild wrote:
>> On 29 May 2012 17:12, Philipp Hancke  wrote:
 XEP-0186 move to Draft so that we can deprecate XEP-0018 and XEP-0126.
 
 Thoughts?
>>> 
>>> 
>>> I'd note that in 3.1.1. the server MUST NOT send presence probes when being
>>> the client is in invisible mode. Of course that makes invisibility much less
>>> useful ;-)
> 
> Perhaps that is my diabolical plan! ;-)
> 
>> I've mentioned before here that this is one of the few changes I would
>> like to make to the XEP - add an attribute such as probe='true' to
>> allow the client to ask the server to probe contacts (with the
>> consequence of not necessarily being so "invisible" any more).
> 
> That slightly complicates this ultra-simple extension. Since the 'probe'
> attribute would default to FALSE, I'd be fine with adding this feature
> (as long as people understand the implications).
> 

RFC 6121 specifies probes be sent 'from' a bare JID 'to' a bare JID.  I think 
this limits the presence leak severely, but that's my interpretation (-:


- m&m

Matthew A. Miller




smime.p7s
Description: S/MIME cryptographic signature


PGP.sig
Description: This is a digitally signed message part

Re: [Standards] invisibility

[Matthew Miller]

On May 29, 2012, at 10:04, Kevin Smith wrote:

> On Tue, May 29, 2012 at 5:03 PM, Matthew Miller
>  wrote:
>> On May 29, 2012, at 09:35, Peter Saint-Andre wrote:
>> 
>>> I'm not a big fan of invisibility, but if we're going to do it then we
>>> might as well do it right.
>>> 
>>> Some clients and servers use XEP-0018, but it violates the core XMPP
>>> specs, which seems like a bad idea.
>>> 
>>> Some clients and server use privacy lists (XEP-0016 + XEP-0126), but
>>> they're complicated and I'd prefer to deprecate them if possible (that's
>>> really a separate discussion topic).
>>> 
>>> Years ago I defined a "better" solution in XEP-0186, but we never pushed
>>> it forward from Experimental to Draft. I don't know if any clients and
>>> servers include support for XEP-0186, but if so it would be good to
>>> know. In any case, I'm wondering if folks are interested in seeing
>>> XEP-0186 move to Draft so that we can deprecate XEP-0018 and XEP-0126.
>>> 
>>> Thoughts?
>> 
>> Simpler invisibility would be very nice.
> 
> How would one make it simpler? 186 is already just one stanza.
> 

Let's say "Having a non-experimental protocol for invisibility would be very 
nice." d-:


- m&m

Matthew A. Miller
<http://goo.gl/LK55L>



smime.p7s
Description: S/MIME cryptographic signature


PGP.sig
Description: This is a digitally signed message part

Re: [Standards] invisibility

[Matthew Miller]

On May 29, 2012, at 09:35, Peter Saint-Andre wrote:

> I'm not a big fan of invisibility, but if we're going to do it then we
> might as well do it right.
> 
> Some clients and servers use XEP-0018, but it violates the core XMPP
> specs, which seems like a bad idea.
> 
> Some clients and server use privacy lists (XEP-0016 + XEP-0126), but
> they're complicated and I'd prefer to deprecate them if possible (that's
> really a separate discussion topic).
> 
> Years ago I defined a "better" solution in XEP-0186, but we never pushed
> it forward from Experimental to Draft. I don't know if any clients and
> servers include support for XEP-0186, but if so it would be good to
> know. In any case, I'm wondering if folks are interested in seeing
> XEP-0186 move to Draft so that we can deprecate XEP-0018 and XEP-0126.
> 
> Thoughts?

Simpler invisibility would be very nice.


- m&m

Matthew A. Miller




smime.p7s
Description: S/MIME cryptographic signature


PGP.sig
Description: This is a digitally signed message part

Re: [Standards] UPDATED: XEP-0198 (Stream Management)

[Matthew Miller]

On May 22, 2012, at 15:10, Peter Saint-Andre wrote:

> On 5/22/12 3:08 PM, Matthew Miller wrote:
>> 
>> On May 22, 2012, at 14:58, Peter Saint-Andre wrote:
>> 
>>> On 5/21/12 1:21 AM, Philipp Hancke wrote:
>>>> On Thu, 26 Apr 2012, Philipp Hancke wrote:
>>>> 
>>>>> old thread alert...
>>>>> 
>>>>>> Version 1.3 of XEP-0198 (Stream Management) has been released.
>>>>> 
>>>>> I implemented 0198 for s2s and am in general quite happy with it. Some
>>>>> notes I wrote down while implementing this. Thanks Dave for listening
>>>>> to my complaints and thanks Matthew for writing mod_smacks which was
>>>>> useful as the evil peer who did not send acknowledgments.
>>>>> 
>>>>> The only major issue is that the case of sm-after-dialback is not
>>>>> explicitly covered... Section 3 has the following text:
>>>>> The client MUST NOT attempt to negotiate stream management until it is
>>>>> authenticated; i.e., it MUST NOT send an  element until after
>>>>> authentication (such as SASL, Non-SASL Authentication [8] or Server
>>>>> Dialback [9]) has been completed successfully.
>>>>> 
>>>>> This does allow the usage of dialback together with session managment.
>>>>> However, there should be at least one example which shows how this is
>>>>> used, especially since the  element can only be sent after
>>>>> the  has been received.
>>>>>   (this is  violating my sense for protocol aesthetics but works
>>>>>reasonbly well)
>>>> 
>>>> I have to change my opinion after discovering similar issues related to
>>>> stream compression...
>>>> the requirement the client "MUST NOT attempt to negotiate" until after
>>>> authentication is not necessary in the case of server dialback (which
>>>> after all isn't an authentication mechanism anyway :-) and should be
>>>> removed.
>>>> 
>>>> There is no harm done if session managment is enabled before dialback.
>>>> In fact, since there are no stanzas flowing without authentication, the
>>>> counters won't get incremented.
>>>> In terms of implementation this keeps the sm negotiation in one place
>>>> (where stream features are handled).
>>>> 
>>>> I've not seen my peer servers (prosody and m-link) send
>>>>  so I think that changing this
>>>> requirement is possible without breaking anything.
>>> 
>>> I think you're right. I'd go farther and assert that it's wrong to say
>>> that a client must not negotiate stream management before resource
>>> binding (especially since resource binding uses stanzas!). So I suggest
>>> that we remove this sentence:
>>> 
>>> "For client-to-server connections, the client MUST NOT attempt to enable
>>> stream management until after it has completed Resource Binding unless
>>> it is resuming a previous session (see Resumption)."
>>> 
>> 
>> I think the proposed text goes too far.  I am aware of code that would break 
>> with this change, because it negotiates after authentication completes but 
>> before binding a resource.
> 
> I was proposing to remove that text, which seems in line with what you
> report.
> 

Ah, ok, I read "remove" and thought "add" (-:

ALl is well!


- m&m

Matthew A. Miller
<http://goo.gl/LK55L>



smime.p7s
Description: S/MIME cryptographic signature


PGP.sig
Description: This is a digitally signed message part

Re: [Standards] UPDATED: XEP-0198 (Stream Management)

[Matthew Miller]

On May 22, 2012, at 14:58, Peter Saint-Andre wrote:

> On 5/21/12 1:21 AM, Philipp Hancke wrote:
>> On Thu, 26 Apr 2012, Philipp Hancke wrote:
>> 
>>> old thread alert...
>>> 
 Version 1.3 of XEP-0198 (Stream Management) has been released.
>>> 
>>> I implemented 0198 for s2s and am in general quite happy with it. Some
>>> notes I wrote down while implementing this. Thanks Dave for listening
>>> to my complaints and thanks Matthew for writing mod_smacks which was
>>> useful as the evil peer who did not send acknowledgments.
>>> 
>>> The only major issue is that the case of sm-after-dialback is not
>>> explicitly covered... Section 3 has the following text:
>>> The client MUST NOT attempt to negotiate stream management until it is
>>> authenticated; i.e., it MUST NOT send an  element until after
>>> authentication (such as SASL, Non-SASL Authentication [8] or Server
>>> Dialback [9]) has been completed successfully.
>>> 
>>> This does allow the usage of dialback together with session managment.
>>> However, there should be at least one example which shows how this is
>>> used, especially since the  element can only be sent after
>>> the  has been received.
>>>(this is  violating my sense for protocol aesthetics but works
>>> reasonbly well)
>> 
>> I have to change my opinion after discovering similar issues related to
>> stream compression...
>> the requirement the client "MUST NOT attempt to negotiate" until after
>> authentication is not necessary in the case of server dialback (which
>> after all isn't an authentication mechanism anyway :-) and should be
>> removed.
>> 
>> There is no harm done if session managment is enabled before dialback.
>> In fact, since there are no stanzas flowing without authentication, the
>> counters won't get incremented.
>> In terms of implementation this keeps the sm negotiation in one place
>> (where stream features are handled).
>> 
>> I've not seen my peer servers (prosody and m-link) send
>>  so I think that changing this
>> requirement is possible without breaking anything.
> 
> I think you're right. I'd go farther and assert that it's wrong to say
> that a client must not negotiate stream management before resource
> binding (especially since resource binding uses stanzas!). So I suggest
> that we remove this sentence:
> 
> "For client-to-server connections, the client MUST NOT attempt to enable
> stream management until after it has completed Resource Binding unless
> it is resuming a previous session (see Resumption)."
> 

I think the proposed text goes too far.  I am aware of code that would break 
with this change, because it negotiates after authentication completes but 
before binding a resource.


- m&m

Matthew A. Miller




smime.p7s
Description: S/MIME cryptographic signature


PGP.sig
Description: This is a digitally signed message part

Re: [Standards] XEP-0068 & "x-"

[Matthew Miller]

From the original text, I think it's important to namespace, and I think it's 
important to agree how a namespace is included in the field name.  Precisely 
how the namespace substring is formatted is less important; it can be a URI, a 
URN, a Java reverse-domain, or something else.


On May 15, 2012, at 17:26, Peter Saint-Andre wrote:

> I've been thinking about this further, and I'm not sure about the MUST
> for the field name formatting, which in my working copy reads:
> 
> ###
> 
> The "namespace" of a field is assumed to be inherited from the
> FORM_TYPE. When an organization or project defines a field that is used
> in the context of a FORM_TYPE it does not manage (e.g., a non-XSF field
> contained in a form whose FORM_TYPE is managed by the XSF, or a
> third-party field contained in a form whose FORM_TYPE is managed by some
> other organization), the name of the field MUST be namespaced with a URI
> controlled by the extending organization or project, where the
> namespacing mechanism MUST be Clark Notation [8], e.g., a field name of
> "{http://example.com/pubsub}time_restrictions";.
> 
> ###
> 
> There are two reasons why I'm skeptical.
> 
> 1. For FORM_TYPE names, we say:
> 
>   For custom protocols, the name SHOULD be an HTTP URI
>   that is managed by the namespace owner (e.g.,
>   "http://example.com/foo";).
> 
> It seems strange for field names to be MUST and FORM_TYPEs to be SHOULD.
> We could change FORM_TYPE names to be MUST be an HTTP URI, too, but that
> runs into reason #2...
> 
> 2. Depending on the usage scenario, I can envision instances where an
> organization defining a custom form might use naming scheme (consistent
> with the xdash spec) other than HTTP URIs, e.g., Java-style reverse
> domain names (e.g., "com.example.foo"). I see no good reason to force
> such organizations to convert their field names into HTTP URIs.
> 
> Therefore, I conclude that "MUST be unique and SHOULD be namespaced with
> an HTTP URI using Clark Notation" is sufficient for field names, and
> "MUST be unique and SHOULD be an HTTP URI" is sufficient for FORM_TYPE
> names.
> 
> I'll raise this issue in the next Council meeting if there is no
> discussion on the list before then.
> 
> On 5/9/12 11:01 AM, Peter Saint-Andre wrote:
>> Based on further feedback from Ralph Meijer, I suggest that we might
>> want to add another paragraph to clarify existing usage:
>> 
>> ###
>> 
>> For reasons that are lost in the mists of time, some XMPP extension
>> protocols produced by the XSF, such as Multi-User Chat [9] and
>> Publish-Subscribe [10], prefix their field names with strings like
>> "muc#" and "pubsub#". There is no good reason to apply that convention
>> to new XSF extensions. Indeed, there is even no good reason to apply
>> that convention to the names of new fields defined by the XSF for those
>> existing XSF extensions; however, the practice is harmless for those
>> existing extensions (since a string such as
>> "{http://jabber.org/protocol/pubsub#subscribe_authorization}pubsub#subscriber_jid";
>> can be considered equivalent to a string such as
>> "pubsub#subscriber_jid"), and this document does not actively recommend
>> deprecating the convention.
>> 
>> ###
>> 
>> On 5/9/12 9:38 AM, Peter Saint-Andre wrote:
>>> In its meeting just now, the XMPP Council discussed [1] some changes to
>>> XEP-0068 (Field Standardization for Data Forms) to align this spec with
>>> a forthcoming recommendation at the IETF [2] to deprecate the "x-"
>>> prefix for protocol parameters.
>>> 
>>> As a result of that discussion, I'm proposing some adjusted wording in
>>> Section 3.4, as follows:
>>> 
>>> ###
>>> 
>>> 3.4 Field Names
>>> 
>>> For FORM_TYPEs that are registered with the XMPP Registrar, the
>>> following rules apply:
>>> 
>>> 1. If the field is defined by the XSF (i.e., in a XEP), the field name
>>> SHALL be determined in accordance with the usual XSF consensus process
>>> and the field MUST be registered with the XMPP Registrar.
>>> 
>>> 2. If the field is defined outside the XSF, the field name SHALL follow
>>> the extension rules described below and the field MAY be registered with
>>> the XMPP Registrar.
>>> 
>>> For FORM_TYPEs that are not registered with the XMPP Registrar, the
>>> field name SHALL follow the extension fules described below and the
>>> field typically will not be registered with the XMPP Registrar.
>>> 
>>> The "namespace" of a field is assumed to be inherited from the
>>> FORM_TYPE. When an organization or project defines a field that is used
>>> in the context of a FORM_TYPE it does not manage (e.g., a non-XSF field
>>> contained in a form whose FORM_TYPE is managed by the XSF, or a
>>> third-party field contained in a form whose FORM_TYPE is managed by some
>>> other organization), the name of the field MUST be namespaced with a URI
>>> controlled by the extending organization or project, where the
>>> namespacing mechanism MUST be Clark Notation [8], e.g., a field name of
>>> "{http://example.

Re: [Standards] XMPP WG meeting this week

[Matthew Miller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mar 28, 2012, at 14:18, Kevin Smith wrote:

> On Tue, Mar 27, 2012 at 12:58 AM, Peter Saint-Andre  
> wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>> 
>> The IETF’s XMPP Working Group will hold an in-person meeting this week
>> at IETF 83 in Paris. The topics will include end-to-end encryption,
>> server-to-server federation, and internationalization. Remote access
>> will also be accommodated. Here are the particulars:
>> 
>> Date: Wednesday, March 28
>> Time: 15:10-16:10 Central European Time (14:10 UTC)
> 
> Is this right? Looking at
> http://www.ietf.org/proceedings/83/agenda/agenda-83-xmpp.txt suggests
> it's 15:10 local time, (CEST), which'd make it 14:10 BST (UK) and
> 13:10 UTC.
> 
> /K

The time is 15:10 CEST, which is 14:10 UK and 13:10 UTC.


- - m&m

Matthew A. Miller


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJPcwKHAAoJEJq6Ou0cgrSPTP8H/2FijiLW5Lmv4dq2lS0t2ddk
k0OJweSt1TiUPIC6I5GHGhn75MLv6jPzJwoFo9qawv8RzcUjEGzvn3HXwlRrJXTT
m9+p5wbRWpOmAvGdI2gMI+g5vzk6EkODA3hHH+KCDTRDS9MILWQOVxhGO7A3qyas
Nq0QhSH20Wo4Z+Fdwf1Jx6BOyaICtrJbS2Cx4g//hpuXcBObk5MXn40PGOdMEDV2
1lJtIkcU+JzgGVvwhzjFYmNZADDFv0KpH13I2jZFmefYyDD6TaAizVtyQKx3YUrN
qL7aGMYrezc8X8XVAwaE3Z9sEbpgECIPM0nsk5GDE1XwYlX3ajHZVnu9MHpovRk=
=tpj5
-END PGP SIGNATURE-

[Standards] Fwd: Minutes 2012-02-08T16:00:00Z

[Matthew Miller]

FYI

Begin forwarded message:

> From: Matthew Miller 
> Date: February 8, 2012 10:27:26 MST
> To: XMPP Council 
> Subject: Minutes 2012-02-08T16:00:00Z
> 
> [room log: <http://logs.xmpp.org/council/120208/>]
> 
>  START 
> 
> 1) Roll Call
> 
> 
> Tobias Markmann (TM), Ralph Meijer (RM), Matthew Miller (M), Matthew Wild 
> (MW) present; Kevin Smith (KS) late
> 
> 1) XEP-237 <http://xmpp.org/extensions/xep-0237.html>
> Move to Obsolete? [replaced by RFC 6121]
> 
> 
> All present voted +1.
> 
> 3) Any other business
> =
> 
> 3.1) FOSDEM Report (RM)
> ---
> 
> [KS arrives here]
> 
> Overall was a good event.  The devroom was packed, and the real-time lounge 
> was awesome. Peter Saint-Andre posted notes for Summit 11 
> <http://mail.jabber.org/pipermail/summit/2012-February/001084.html>.
> 
> Suggested improvements for next year are:
> 
> * have one main-track speaker instead of a bigger room
> * move the XMPP Summit to the Thursday and Friday before FOSDEM, rather than 
> wrapping it on the Friday and Monday
> 
> Suggested to move to Wiki page to allow for updates, but no takers.
> 
> 3.2) XEP-0190 <http://xmpp.org/extensions/xep-0190.html>
> Move to Obsolete? [Replaced by RFC 6120]
> 
> 
> MM, RM, TM, and MW voted +1; KS to vote on list within a fortnight.
> 
> 3.3) XEP-0192 <http://xmpp.org/extensions/xep-0192.html>
> Move to Obsolete? [Replaced by RFC 6120]
> 
> 
> All present voted +1.
> 
> 3.4) XEP-0193 <http://xmpp.org/extensions/xep-0193.html>
> Move to Obsolete? [Replaced by RFC 6120]
> 
> 
> All present voted +1.
> 
> 3.5) Future Updates to XEPs -0045 and -0060
> ---
> 
> It has been suggested to mvoe certain features (e.g. magement) from XEPs 
> -0045 and -0060 into a separate XEPs make them more manageable.  Council to 
> have this ducssion at its next meeting.
> 
> 3.6) Thanks from Chair
> --
> 
> KS expressed thanks for MM for Chairing in his lateness.
> 
> 4) Date of next meeting
> ===
> 
> 2012-02-15T16:00:00Z
> 
>  END 
> 
> 
> - m&m
> 
> Matthew A. Miller
> <http://goo.gl/LK55L>
> 


- m&m

Matthew A. Miller
<http://goo.gl/LK55L>



smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] XEP-0096 (SI File Transfer): Where is a fallback mechanism described?

[Matthew Miller]

On Jan 12, 2012, at 02:56, Sergey Dobrov wrote:

> On 01/12/2012 03:57 PM, Marcus Lundblad wrote:
>> tor 2012-01-12 klockan 15:47 +0700 skrev Sergey Dobrov:
>>> Hello, I am reading the XEP-96 and see in the requirements section:
>>> "Enable seamless file transfer, including fall-back mechanisms as
>>> appropriate", then I see that socks5 and IBB are must be implemented in
>>> a XEP-96 compatible implementation. Ok, we can try to use socks5 and if
>>> it fail we will fallback to ibb and then we will guaranteed done with
>>> our transfer. But where is described HOW this fallback should be
>>> negotiated? The flow:
>>> 
>>> 1. SI Request. We are must to include both socks5 and IBB as our
>>> stream-methods.
>>> 2. SI Response will always reply with socks5 because it must support
>>> both of protocols and socks5 is with high priority.
>>> 3. SOCKS5 is failed to establish a stream.
>>> 4. What we have to do next? Send again a SI request with only IBB
>>> included as our stream-methods? Should the recipient to ask again about
>>> the file transfer? How should it determine that it should not, if it's
>>> not? That's really unclear with the current XEP.
>>> 
>>> The second thing is: maybe we should to remove the requirement to
>>> support both socks5 and ibb? Because it's not carried out de-facto by
>>> several implementations and not each platform can easily implement both
>>> bytestreams.
>>> 
>>> 
>> 
>> You should probably use JingleFT if you're implementing something new
>> today. Hopefully it will gain more popularity.
>> With Jingle this scenario is covered.
>> If you want to implement SI transfer as well (to maintain legacy
>> compatibility) you might do like you described above. There's also some
>> extension to SI that is used by telepathy to handle the fallback
>> scenario.
> 
> I am familiar with the JingleFT specification and I like it but the
> thing is that I need some specification that can be used right now to
> make it possible to inter operate with majority of clients. The
> situation with file transfer now is not the best and I don't think that
> it's a good choice now to force the transition to another specification.
> 
> Despite of everything, the standard has a fallback mechanism in it's
> requirements. But I can't find it. And I can't decide how to implement
> the XEP right at all. Should it be fixed? I think, yes. It should be
> fixed or marked as obsolete.

The fallback mechanisms for SI:FT were never codified.  I think there are 
implementations that tried to do something, but they barely interoperate with 
themselves.

At this point, I'd rather focus protocol effort on improving JingleFT.  
However, marking SI:FT as Deprecated before JingleFT is Draft is a mistake.


- m&m




smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Council Decision on DMUC3 Proto-XEP

[Matthew Miller]

On Jan 9, 2012, at 09:06, Wayne Franklin wrote:

> Matthew,
> 
> Sorry to hear that you didn't see the advantages to our approach.  We respect 
> the decision of the council and will provide feedback to XEP-0289.  Does this 
> mean that the other DMUC specs are out of the running?
> 

I personally don't have a comment regarding the other DMUC specs right now.

> The biggest problem with XEP-0289 is that it does not seem to address the 
> requirement for having the room be able to live on if the S2S link is 
> disconnected.  Our customer would like a 100 user chat room with 50 users on 
> one login server and 50 users on another login server to be able to continue 
> on as two 50 person chat rooms if the S2S link goes down (which is common for 
> their network).
> 
> Additionally, it seems as if the user needs to know that they want to connect 
> to a new mirror service rather than the actual chat room.  This seems as if 
> it will be a training issue for our users.
> 
> Unless I mis-understand, it seems as if the client will need to know that it 
> is talking to this new mirror service (and not a real MUC room) so that it 
> can construct this escaped JID.  Personally, I would rather make a change at 
> the server that did not require the client to create a new kind of JID.
> 
> As I said, we will respect the decision of the council and provide feedback 
> to XEP-0289, but if we can't satisfy the requirement for continued operation 
> while S2S is down, we may have to go our own way.  
> 

XEP-0289 is still EXPERIMENTAL, and so could (in theory) be influenced by such 
criteria.  I would strongly recommend you work with the author(s) of XEP-0289 
to see if an agreement or compromise can be reached.


- m&m





smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Carbons

[Matthew Miller]

On Jan 4, 2012, at 03:57, Kevin Smith wrote:


> I think we should be avoiding mandating (at least non-security
> critical) UI features - I think this is a simple tweak from normative
> 'SHOULD' to 'is suggested' or similar.
> 

The more I ponder this, the more I think there needs to be some mandating.  
What about the following:

Upon receiving an inbound or outbound gone chat state (as a 
carbon copy) for a given conversation, the client SHOULD visually indicate the 
conversation is terminated. It is suggested that the conversation be removed 
from user display as if the user on the copied client had terminated the 
conversation.


- m&m




smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Carbons

[Matthew Miller]

On Jan 5, 2012, at 09:03, Mike Wacker wrote:

> On 1/5/2012 7:43 AM, Matthew Miller wrote:
>> On Jan 5, 2012, at 08:41, Mike Wacker wrote:
>> 
>>> On 1/5/2012 7:31 AM, Matthew Miller wrote:
>>>> On Jan 5, 2012, at 08:24, Mike Wacker wrote:
>>>> 
>>>> 
>>>>> Let me suggest a bolder idea. Why do we need to wrap the carbons using 
>>>>> Message Forwarding at all instead of just delivering the message stanzas 
>>>>> as is? You will only receive these additional message carbons if your 
>>>>> client supports carbons and enables carbons. Thus, if a client has 
>>>>> carbons enabled, if it receives a message not sent to its bare JID or 
>>>>> full JID (either a message from one of its other resources to a buddy or 
>>>>> from a buddy to one of its other resources), it can reasonably infer that 
>>>>> the message is a carbon.
>>>>> 
>>>>> The standard use cases for message carbons is to ensure that a given 
>>>>> device will receive both sides of all conversations, and that use case is 
>>>>> covered regardless of whether we wrap carbons or not. I can't think of 
>>>>> any use case for the special wrapping logic, though.
>>>>> 
>>>>> This would greatly simplify the XEP (as well as eliminate a dependency on 
>>>>> an experimental XEP more complex than message carbons itself), as servers 
>>>>> would only have to route the messages and not modify them, and clients 
>>>>> won't need special parsing logic for carbons.
>>>>> 
>>>> The original version of XEP-0280 did just that.  However, while it appears 
>>>> to simplify the XEP, it complicated implementations.  It required routing 
>>>> a   to a client that did not match the 'to', which raised a 
>>>> number of concerns among client and server implementers.
>>>> 
>>>> And I disagree that XEP-0297 is more complex than carbons.
>>>> 
>>>> 
>>>> - m&m
>>>> <http://goo.gl/LK55L>
>>>> 
>>> Could you elaborate on those concerns? A client would only receive a 
>>> message that did not match the 'to' if it had message carbons enabled. 
>>> Thus, it would be reasonable that these clients would have special logic to 
>>> handle such messages if it supported carbons and if it had them enabled. 
>>> Clients not supporting message carbons do not need to make any changes.
>> The problem is not just with the clients; it's also with servers.  The 
>> server must route that message, and not every server implementation is 
>> readily prepared to deal with that radical of a departure for standard XMPP 
>> routing rules.
>> 
>> 
>> - m&m
>> <http://goo.gl/LK55L>
>> 
> Perhaps an actual case could help elaborate, in theory, all you need to do is 
> alter the routing logic and perhaps also alter some checks/assertions for 
> messages which don't match the 'to' field. Neither seems prohibitively 
> expensive. It doesn't seem that complex on the client either.
> 
> I'm just looking for a better rationale for it. If there's a client use case 
> or user experience which requires the wrapping, then we definitely need it. 
> If it's a task that can be offloaded from the server to the client, that is 
> also a valid reason. But I'm not a huge fan of altering the message just to 
> simplify server implementation details for a task that belongs to the server 
> [routing].
> 
> Unless there's a really compelling cost or scalability reason, I prefer that 
> we build the protocol around client use cases and user experiences instead of 
> building it around the server implementation.

I appreciate your feedback, but completely disagree with your assessment.  I 
know there are others that disagree, because I made the change based on their 
feedback on this list.


- m&m
<http://goo.gl/LK55L>



smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Carbons

[Matthew Miller]

On Jan 5, 2012, at 08:41, Mike Wacker wrote:

> On 1/5/2012 7:31 AM, Matthew Miller wrote:
>> On Jan 5, 2012, at 08:24, Mike Wacker wrote:
>> 
>> 
>>> Let me suggest a bolder idea. Why do we need to wrap the carbons using 
>>> Message Forwarding at all instead of just delivering the message stanzas as 
>>> is? You will only receive these additional message carbons if your client 
>>> supports carbons and enables carbons. Thus, if a client has carbons 
>>> enabled, if it receives a message not sent to its bare JID or full JID 
>>> (either a message from one of its other resources to a buddy or from a 
>>> buddy to one of its other resources), it can reasonably infer that the 
>>> message is a carbon.
>>> 
>>> The standard use cases for message carbons is to ensure that a given device 
>>> will receive both sides of all conversations, and that use case is covered 
>>> regardless of whether we wrap carbons or not. I can't think of any use case 
>>> for the special wrapping logic, though.
>>> 
>>> This would greatly simplify the XEP (as well as eliminate a dependency on 
>>> an experimental XEP more complex than message carbons itself), as servers 
>>> would only have to route the messages and not modify them, and clients 
>>> won't need special parsing logic for carbons.
>>> 
>> The original version of XEP-0280 did just that.  However, while it appears 
>> to simplify the XEP, it complicated implementations.  It required routing 
>> a  to a client that did not match the 'to', which raised a number 
>> of concerns among client and server implementers.
>> 
>> And I disagree that XEP-0297 is more complex than carbons.
>> 
>> 
>> - m&m
>> <http://goo.gl/LK55L>
>> 
> Could you elaborate on those concerns? A client would only receive a message 
> that did not match the 'to' if it had message carbons enabled. Thus, it would 
> be reasonable that these clients would have special logic to handle such 
> messages if it supported carbons and if it had them enabled. Clients not 
> supporting message carbons do not need to make any changes.

The problem is not just with the clients; it's also with servers.  The server 
must route that message, and not every server implementation is readily 
prepared to deal with that radical of a departure for standard XMPP routing 
rules.


- m&m
<http://goo.gl/LK55L>



smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Carbons

[Matthew Miller]

On Jan 5, 2012, at 08:24, Mike Wacker wrote:


> Let me suggest a bolder idea. Why do we need to wrap the carbons using 
> Message Forwarding at all instead of just delivering the message stanzas as 
> is? You will only receive these additional message carbons if your client 
> supports carbons and enables carbons. Thus, if a client has carbons enabled, 
> if it receives a message not sent to its bare JID or full JID (either a 
> message from one of its other resources to a buddy or from a buddy to one of 
> its other resources), it can reasonably infer that the message is a carbon.
> 
> The standard use cases for message carbons is to ensure that a given device 
> will receive both sides of all conversations, and that use case is covered 
> regardless of whether we wrap carbons or not. I can't think of any use case 
> for the special wrapping logic, though.
> 
> This would greatly simplify the XEP (as well as eliminate a dependency on an 
> experimental XEP more complex than message carbons itself), as servers would 
> only have to route the messages and not modify them, and clients won't need 
> special parsing logic for carbons.
> 

The original version of XEP-0280 did just that.  However, while it appears to 
simplify the XEP, it complicated implementations.  It required routing a 
 to a client that did not match the 'to', which raised a number of 
concerns among client and server implementers.

And I disagree that XEP-0297 is more complex than carbons.


- m&m




smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Carbons

[Matthew Miller]

On Jan 4, 2012, at 03:57, Kevin Smith wrote:

> I've just been reading through the current version of
> http://xmpp.org/extensions/xep-0280.html and have a couple of
> comments:
> 
> In example 14, we have:
>  from='ro...@example.net'
> to='ro...@example.net/home'
> type='chat'>
>  
>
>... 
>  
> 
> 
> I think it makes more sense to have the forwarded payload inside the
> received payload, instead of the reverse. I think this because the
> forwarded message is a feature of the carbon, rather than the reverse
> (Carbons depends on Forwarding, Forwarding doesn't depend on Carbons).
> 

See my comment in the other thread.

> Second is regarding
> "Upon receiving an inbound or outbound gone chat state (as a carbon
> copy) for a given conversation, that conversation SHOULD be removed
> from user display"
> 
> I think we should be avoiding mandating (at least non-security
> critical) UI features - I think this is a simple tweak from normative
> 'SHOULD' to 'is suggested' or similar.
> 
> /K

That's a fair suggestion.


- m&m




smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Use of Message Forwarding in other XEPs

[Matthew Miller]

On Jan 4, 2012, at 07:25, Dave Cridland wrote:

> On Wed Jan  4 14:22:30 2012, Kevin Smith wrote:
>> I think it'd be good to pick something and use it consistently,
>> whatever that thing is.
> 
> I'd like to paint it green.
> 

Only if you know the Mayor of Boston.


- m&m




smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Use of Message Forwarding in other XEPs

[Matthew Miller]

On Jan 4, 2012, at 05:46, Kim Alvefur wrote:

> On Wed, 2012-01-04 at 11:24 +, Kevin Smith wrote:
>> On Wed, Jan 4, 2012 at 11:18 AM, Dave Cridland  wrote:
>>> On Wed Jan  4 11:12:56 2012, Kevin Smith wrote:
 
>>> Isn't the  providing no information at all, here? (Not that it
>>> ever was).
>>> 
>>> Surely it's entirely and completely implied by the .
>> 
>> Other than making it nice and easy for clients to deal with the
>> forwarded message. It's true we could put the children of 
>> directly into every parent protocol that uses it (currently only two
>> or three, I realise), but it's nice to be able to reuse the 'oh, it's
>> a forward' parsing/serialising/whatever.
> 
> I think that either what Kev said or this:
> 
> 
> 
> 
>  
> 
> 
> 
> makes most sense.  (MattJs 137bis draft does this.)  With the later, you
> can have some separation of metadata and content.
> 
> But more importantly, I think that consistency among forwards-using XEPs
> would be nice.


I think this is a much better use than nesting  within whatever 
sub-protocol there is.  At that point, I'd rather just have carbons element 
contain the  directly and leave out the now-pointless

However, I don't see a problem with the way it is now, if we're willing to look 
at the other stuff in a forward as "context about the forward".  But I'm 
willing to change the carbons elements to be outside the  if that's 
the consensus.


- m&m




smime.p7s
Description: S/MIME cryptographic signature