Re: [Standards] Request for Clarification on the Editor's Job Description

2011-07-26 Thread Dave Cridland 

On Tue Jul 26 16:54:40 2011, Carlo v. Loesch wrote:
Alright, now that we had some off-topic chatter on technical point  
of

views, let's get back on topic.


I think you may find that the topic of this list *is* actually  
technical points of view.


I'd personally argue that the majority of points you raise are water  
under the bridge - no pun intended - but if you are keen on getting  
some kind of official statement out of the XSF, I'd suggest this is  
the wrong list.


Maybe try sending to the XSF Board?

Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

Re: [Standards] Request for Clarification on the Editor's Job Description

2011-07-26 Thread Carlo v. Loesch 
Alright, now that we had some off-topic chatter on technical point of
views, let's get back on topic. I have not received any answer on the
questions raised in

http://mail.jabber.org/pipermail/standards/2011-July/024756.html

nor has there been a statement on the normality of these points:

+ the authors of the submitted XEP were not given any written explanation
  for any of council members' -1 votes as is stated in
  http://xmpp.org/extensions/xep-0001.html#approval

+ no meeting minutes were published. According to
  http://mail.jabber.org/pipermail/council/2006-June/thread.html
  2006-06-14 is possibly the only meeting that officially yielded no results.

Re: [Standards] Request for Clarification on the Editor's Job Description

2011-07-22 Thread Dave Cridland 

On Fri Jul 22 20:41:23 2011, Carlo v. Loesch wrote:
It wasn't my plan to wash dirty laundry five years later, but here  
you go..




Yes, it was your plan, that's why you raised it in such hazy terms.

I shouldn't have fed the troll, apparently.

The problem wasn't very theoretical. Matthias Wimmer provided  
figures just

months earlier:

http://mail.jabber.org/pipermail/standards/2006-May/011158.html and
http://mail.jabber.org/pipermail/standards/2006-May/011182.html

Over 70% of XMPP messages were  stanzas of which almost
60% were duplicate resends over the same TCP line. In the grand
total that means that over 40% of stanzas in interserver XMPP  
traffic

are redundant. Presumably still today, although I would love fresh
and independent figures.


So you assume that this is, in itself, a problem - one that  
compression cannot mitigate sufficiently. I'm just not convinced, in  
no small part because nobody seems to complain about the situation. I  
don't mean complain about the aesthetics of it, plenty of folk do  
that, but the actual server operators don't really seem to care - the  
issue of S2S  bandwidth simply doesn't appear on people's radars.


We've got a ton of wasteful traffic, actually, around the network,  
and none of it seems to cause a problem on the internet. (I think  
there's more XEP-0115/XEP-0030 redundant traffic than presence,  
actually, but that's just a guess - I base this in part on a guess at  
how well that traffic would compress). As far as I can see, no server  
operators are complaining that boy, those S2S links chew through  
bandwidth.


So this was a theoretical problem at best, at least in 2006, and  
that's before we look to consider any mitigations available due to  
S2S compression (now far more commonplace than it was in 2006).


Now, it's of interest only in military tactical networks, only it's  
all MUC there so presence broadcast from rosters is a non-issue.


We also couldn't believe someone would even suggest stream  
compression

can achieve similar savings. Of course it can't, because each of
those 40% redundant stanzas has a different to="" recipient.
Only fixing the protocol does the job.


Yeah, so if you have a bunch of similar stanzas differing only by one  
address, that'll nnever compress well, right?


I said then that compression could substantially mitigate the  
bandwidth issue, and I demonstrated it as I recall, providing  
figures. But they didn't back up your assertion, and you seem to have  
conveniently forgotten them. Or maybe you couldn't be bothered, or  
you didn't understand.


Later, there was a shift to CPU resources on the server as the real  
problem we were apparently trying to solve all along, but I was never  
convinced this was actually a problem either.



I didn't even bother to find out if the way we were dismissed
was intentional or out of distraction.


There were a number of reasons given on the mailing list at the time,  
in the (very lengthy, as I recall) thread on it. There were a number  
of reasons given for similar proposals, too, as they were raised  
again. The fact that yours was rejected at a meeting for which the  
minutes happened to slip you assume has some deep rooted  
significance, verging on paranoia, and you wheel out this frankly  
unprofessional attack every now and then.


There have, incidentally, been dozens of attempts at doing this kind  
of work, but of course you only count your own. Yours got rejected  
because you dared to be an outsider, presumably, rather than on  
technical merit. Personally I think they're all a waste of time  
compared to other, more pressing, issues.


Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

Re: [Standards] Request for Clarification on the Editor's Job Description

2011-07-22 Thread Carlo v. Loesch 
It wasn't my plan to wash dirty laundry five years later, but here you go..

> On Fri Jul 22 07:59:44 2011, Carlo v. Loesch wrote:
>> I've seen the council decide upon proposed XEPs without even reading/
>> understanding them, so I wouldn't be surprised about other atypical  
>> habits.

On Fri, Jul 22, 2011 at 04:58:37PM +0100, Dave Cridland wrote:
> No, you've seen Council decide on proposed XEPs in a way that you didn't 
> like, and you assume that must mean they either didn't read, or didn't 
> understand your view - not that, perhaps, they simply disagreed with your 
> assessment.

Of course your impression may differ from mine, but it sure is unusual
that this is one of the very few council meetings where

+ the authors of the submitted XEP were not given any written explanation
  for any of council members' -1 votes as is stated in
  http://xmpp.org/extensions/xep-0001.html#approval

+ no meeting minutes were published. According to
  http://mail.jabber.org/pipermail/council/2006-June/thread.html
  2006-06-14 is possibly the only meeting that officially yielded no results.

All we have is this council chatroom log:

[15:26:51]  so, let's go forward with it. I will read up on my list
[15:26:56]  "smart" presence distribution
[15:27:07]  I have to admit that I've not read every last message on 
the threads about this!!!
[15:27:08]  |-:
[15:27:09]  does anyone have a short summary
[15:27:12]  I bailed out
[15:27:22]  IMO...
[15:27:33]  it's basically an optional modification to XMPP so that 
it's more like IRC, right lw?

Wow... it has little to do with IRC.. who came up with that idea?
Was it because we said IRC does one thing better than Jabber: Multicast?

[15:27:35]  the discussion didn't seem too "smart"
[15:27:35]  ...it's the worst of IRC brought to jabber!

linuxwolf either didn't understand IRC or our proposal.
The worst of IRC is its distributed database which Jabber luckily doesn't have.
Now he's posting pictures of trolls. Go figure.

[15:28:13]  in theory, it makes distributing presence use less 
bandwidth/bytes

At least one thing stuck.
Not enough to see that it wasn't only theory.

[15:28:17]  hmm, I recollect thinking about IRC when I saw JL's 
drawings. Was that related?
[15:28:19]  the psyced guys are old IRC folks, their objections to 
XMPP have traditionally been that it's not enough like IRC :-)

I stopped using IRC regularely in the mid 90's so you also have a very
interesting notion of who Philipp and I are. We usually criticize
design failures in both IRC and XMPP, which doesn't mean they shouldn't
be addressed. That's why we ended up writing XEPs in the first place.
IRC is too hopeless to fix. XMPP stood a chance. But here we are in 2011
and IMHO none of the really important S2S issues are fixed.

But.. besides.. what does this have to do with the XEP?
Is the council meeting about some people's backgrounds rather than work?

[15:28:23]  it seemed to me that the savings was negligible
[15:28:42]  at least they have chosen their name carefully then
[15:28:42]  and the liabilities are unacceptable (sync issues)

We had worked those issues all out after discussion on the list
but I presume you didn't look at the final version we submitted.

It made us feel like we had spent weeks for nothing that you judged
our work by our very first submission which I admit did not handle
all the Jabber-specific security and consistency issues. We discussed
hard with you on these things and worked your feedback into the
final version... and we even implemented it and had it running.

[15:28:44]  a lot less than say compressing the stream would giet you
[15:29:06]  maybe they can implement it and deploy it over a private 
network and then come back with some hard data?
[15:29:29]  and contrast it with stream compression
[15:29:48]  yes
[15:29:51]  since I agree that I don't see major benefits here and the 
argument is theoretical rather that practical
[15:29:51]  -1

"All members of the Council must vote, with the possible values being +1 
(approve), 0 (neutral), or -1 (disapprove, with reasons)."

Reasons, Ralph? I know them now after we met at the FSW in June..
but that's like.. 5 years late!

[15:29:55]  possibly
[15:30:12]  but I'm -1 until they can disprove current experience (-:

The problem wasn't very theoretical. Matthias Wimmer provided figures just
months earlier:

http://mail.jabber.org/pipermail/standards/2006-May/011158.html and
http://mail.jabber.org/pipermail/standards/2006-May/011182.html

Over 70% of XMPP messages were  stanzas of which almost
60% were duplicate resends over the same TCP line. In the grand
total that means that over 40% of stanzas in interserver XMPP traffic
are redundant. Presumably still today, although I would love fresh
and independent figures.

We had also implemented the XEP in psyced, but the saving were obvious:
about 40% of stanzas less! And nobody bothered to give us an official
statement or acknowledge that "hard data" had already been there at
the tim

Re: [Standards] Request for Clarification on the Editor's Job Description

2011-07-22 Thread Dave Cridland 

On Fri Jul 22 07:59:44 2011, Carlo v. Loesch wrote:
I've seen the council decide upon proposed XEPs without even  
reading/
understanding them, so I wouldn't be surprised about other atypical  
habits.


No, you've seen Council decide on proposed XEPs in a way that you  
didn't like, and you assume that must mean they either didn't read,  
or didn't understand your view - not that, perhaps, they simply  
disagreed with your assessment.


Still, it's nice to see you've not changed your habit of attempting  
to slander anyone who disagrees with you.


Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

Re: [Standards] Request for Clarification on the Editor's Job Description

2011-07-22 Thread Matthew A. Miller 
On Jul 22, 2011, at 08:32, Carlo v. Loesch wrote:

> On Fri, Jul 22, 2011 at 08:11:07AM -0600, Matthew A. Miller wrote:
>> 
> 
> I take that as a request not to be taken seriously.
> 
Frankly, I cannot take you seriously.  Yet, I am still waiting for your 
evidence regarding the council.


- m&m





smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Request for Clarification on the Editor's Job Description

2011-07-22 Thread Carlo v. Loesch 
On Fri, Jul 22, 2011 at 08:11:07AM -0600, Matthew A. Miller wrote:
> 

I take that as a request not to be taken seriously.

Re: [Standards] Request for Clarification on the Editor's Job Description

2011-07-22 Thread Matthew A. Miller 
On Jul 22, 2011, at 00:59, Carlo v. Loesch wrote:

> On Tue, Jul 19, 2011 at 03:43:03PM -0600, Peter Saint-Andre wrote:
>> Your complaint is not about the role of the XMPP Extensions Editor, but  
>> with me personally.
> 
> No. Why are you trying to take it personally?
> I didn't even say I'm complaining.
> I am always willing to accept that this is the way we do things at XSF.
> I've seen the council decide upon proposed XEPs without even reading/
> understanding them, so I wouldn't be surprised about other atypical habits.
> 

What evidence do you have to back up your assertion about the council?


- m&m


smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Request for Clarification on the Editor's Job Description

2011-07-22 Thread Carlo v. Loesch 
On Tue, Jul 19, 2011 at 03:43:03PM -0600, Peter Saint-Andre wrote:
> Your complaint is not about the role of the XMPP Extensions Editor, but  
> with me personally.

No. Why are you trying to take it personally?
I didn't even say I'm complaining.
I am always willing to accept that this is the way we do things at XSF.
I've seen the council decide upon proposed XEPs without even reading/
understanding them, so I wouldn't be surprised about other atypical habits.

> I also serve in these roles:
>
> - Executive Director
> - list admin of this list
> - hostmaster of xmpp.org
> - etc.

Anybody who is in all of these roles and does things the way you do
would have received those questions from me.

> You could just as well say you want clarification about the role of the  
> XSF's Executive Director.

Correct. If this person has special rights editing other people's
protocols without prior discussion and agreement, then that's exactly
what has been missing in my understanding of such actions.
Is this expected behaviour for an XSF-ED?

> Further, your concern is about a particular specification (XEP-0220),  

No, it's not just about 0220.
I inquired about the procedure in any such case.

>> 1. editing XEPs and adding himself to the list of authors accordingly,
>> at times without asking permission by the original authors.
>> May not be the case with the XEP currently in question.
>
> That does not apply to XEP-0220. To which XEPs does it apply?

XEP-0185 AFAIR

>> 2. publishing substantial (not necessarily in size but in semantics)
>> changes to XEPs without consulting the original authors or seeking
>> permission from them.
>
> When you say "original authors" are you referring to XEP-0220 or to some  
> other specification(s)?

Oh okay, Philipp is not the "original author" of 0220, then it's about
modifying parts of what Philipp wrote in there up to a point that the 
original semantics is no longer kept and keeping quiet about your
changes, as if he was no longer involved.

I warned you that I wasn't sure if these points even apply.

Philipp has gone into details about several of the other points.


-- 
   _//  Carlo v. Loesch

Re: [Standards] Request for Clarification on the Editor's Job Description

2011-07-20 Thread Philipp Hancke 

Pulling this to the front...
> This is not a matter of the role of the XMPP Extensions Editor, but a
> matter of me personally.

Well, this is partially a procedural problem.
Feel free to follow-up on the technical side of things at 
http://mail.jabber.org/pipermail/standards/2011-May/024559.html


[...]


1. editing XEPs and adding himself to the list of authors accordingly,
at times without asking permission by the original authors.
May not be the case with the XEP currently in question.


That does not apply to XEP-0220. To which XEPs does it apply?


XEP-0185. As I told you off-list before, I don't really mind that 
because you made some good changes in 0.4 and we discussed removing the 
section on attacks during LC. But still it is rather uncommon to add 
yourself without even asking - I did not notice until some months later.



2. publishing substantial (not necessarily in size but in semantics)
changes to XEPs without consulting the original authors or seeking
permission from them.


When you say "original authors" are you referring to XEP-0220 or to some
other specification(s)?


3. publishing changes that make the XEP dysfunctional and, since there is
no independent Extensions Editor but himself, advanced these changes
for examination by the XSF Council.


XEP-0220 underwent a Last Call. Feedback was received. I was incredibly
busy with finishing the XMPP RFC revision process, and did not process
that feedback until many months had passed.
I tried my best to incorporate the feedback, but perhaps I did not succeed.


The 0.7 change was about the only thing that made sense.


4. ignoring requests by the original author to make changes (fix errors)
to the XEP.


Some "requests" by one of the (not original) authors I did not process
because I disagreed with them. Other requests were not incorporated
because of oversights on my part.


This was specificially about the patch
http://mail.jabber.org/pipermail/standards/2011-April/024439.html
which you had received the night before via xmpp (and the stanza was not 
lost). Next time I will formally submit such things via email to 
edi...@xmpp.org if that is required.


As an editor, it is not your role to disagree with changes made by 
authors, especially not if those changes merely are fixing known errors.


Theoretically, what would happen if I submitted my current version to 
edi...@xmpp.org? Would that get published without asking my co-authors?


[...]

See above. This is not a matter of the role of the XMPP Extensions
Editor, but a matter of me personally. I found Philipp's comments to be


Well, you can only publish things without my agreement because you are 
the XMPP editor. As such, you have a conflict of interest here. This 
should typically be avoided, see #A.6 in

http://www.agu.org/pubs/authors/manuscript_tools/journals/pub_guidelines.shtml

Also note #B.8 - you (with your XMPP editor hat on) have known since 
May, 18th officially that I do not approve the submissions - as an 
author you knew that long before that I had not seen the final versions 
before submission.


Publishing further versions is hardly the right thing to do in that 
situation. I would not have had to send the email with that snarky tone 
if this change had been (not) published under /tmp/.



unnecessarily snarky. That is a matter of common courtesy, not a matter
of XSF rules and regulations.


See above, it is generally considered common courtesy to let your 
(active) co-authors review and approve things before publication. You 
have been demonstrating the reasons for that...


philipp

Re: [Standards] Request for Clarification on the Editor's Job Description

2011-07-19 Thread Peter Saint-Andre 

On 7/9/11 5:18 AM, Carlo v. Loesch wrote:

On Wed, Jul 06, 2011 at 11:21:22AM -0600, Peter Saint-Andre wrote:

It was published without Jeremie's approval as a co-author, too. :P


As far as I could tell, the Extensions Editor has been


Your complaint is not about the role of the XMPP Extensions Editor, but 
with me personally.


I also serve in these roles:

- Executive Director
- list admin of this list
- hostmaster of xmpp.org
- etc.

You could just as well say you want clarification about the role of the 
XSF's Executive Director.


Further, your concern is about a particular specification (XEP-0220), 
not about all specifications. So you have a complaint about me as a XEP 
author, not as XMPP Extensions Editor.


Now that we've cleared up that little question of scope...


1. editing XEPs and adding himself to the list of authors accordingly,
at times without asking permission by the original authors.
May not be the case with the XEP currently in question.


That does not apply to XEP-0220. To which XEPs does it apply?


2. publishing substantial (not necessarily in size but in semantics)
changes to XEPs without consulting the original authors or seeking
permission from them.


When you say "original authors" are you referring to XEP-0220 or to some 
other specification(s)?



3. publishing changes that make the XEP dysfunctional and, since there is
no independent Extensions Editor but himself, advanced these changes
for examination by the XSF Council.


XEP-0220 underwent a Last Call. Feedback was received. I was incredibly 
busy with finishing the XMPP RFC revision process, and did not process 
that feedback until many months had passed. I tried my best to 
incorporate the feedback, but perhaps I did not succeed.



4. ignoring requests by the original author to make changes (fix errors)
to the XEP.


Some "requests" by one of the (not original) authors I did not process 
because I disagreed with them. Other requests were not incorporated 
because of oversights on my part.



I may be wrong, this is just the impression I got from the distance
since I don't have all that much time to devote to XMPP.

I also am not sure if there is anything wrong with these 4 behaviors,
so let us look up the XSF documentation on the Editor's job:

Neither in http://xmpp.org/extensions/xep-0001.html nor in
http://xmpp.org/about-xmpp/xsf/xsf-people/#extensions do I see a
description of the job of the Extensions Editor sufficiently specific
to make it clear if the behaviors described above are either legitimate
or inappropriate according to XSF regulations.

One passage of "Appendix C: Legal Notices" might at best be applicable,
but I don't know exactly how:

 "Unless separate permission is granted, modified works that are redistributed 
shall not contain misleading information regarding the authors, title, number, or 
publisher of the Specification, and shall not claim endorsement of the modified works by 
the authors, any organization or project to which the authors belong, or the XMPP 
Standards Foundation."

So I would kindly like to ask if the 4 behaviors described above are
expected legitimate behavior of the XSF Extensions Editor according
to the regulations of the XSF.

If this is the case, I would recommend Philipp to apologize to Peter
for the snarkiness.


See above. This is not a matter of the role of the XMPP Extensions 
Editor, but a matter of me personally. I found Philipp's comments to be 
unnecessarily snarky. That is a matter of common courtesy, not a matter 
of XSF rules and regulations.


Peter

--
Peter Saint-Andre
https://stpeter.im/

[Standards] Request for Clarification on the Editor's Job Description

2011-07-09 Thread Carlo v. Loesch 
On Wed, Jul 06, 2011 at 11:21:22AM -0600, Peter Saint-Andre wrote:
> It was published without Jeremie's approval as a co-author, too. :P

As far as I could tell, the Extensions Editor has been

1. editing XEPs and adding himself to the list of authors accordingly,
   at times without asking permission by the original authors.
   May not be the case with the XEP currently in question.

2. publishing substantial (not necessarily in size but in semantics)
   changes to XEPs without consulting the original authors or seeking
   permission from them.

3. publishing changes that make the XEP dysfunctional and, since there is
   no independent Extensions Editor but himself, advanced these changes
   for examination by the XSF Council.

4. ignoring requests by the original author to make changes (fix errors)
   to the XEP.

I may be wrong, this is just the impression I got from the distance
since I don't have all that much time to devote to XMPP.

I also am not sure if there is anything wrong with these 4 behaviors,
so let us look up the XSF documentation on the Editor's job:

Neither in http://xmpp.org/extensions/xep-0001.html nor in
http://xmpp.org/about-xmpp/xsf/xsf-people/#extensions do I see a
description of the job of the Extensions Editor sufficiently specific
to make it clear if the behaviors described above are either legitimate
or inappropriate according to XSF regulations.

One passage of "Appendix C: Legal Notices" might at best be applicable,
but I don't know exactly how:

"Unless separate permission is granted, modified works that are 
redistributed shall not contain misleading information regarding the authors, 
title, number, or publisher of the Specification, and shall not claim 
endorsement of the modified works by the authors, any organization or project 
to which the authors belong, or the XMPP Standards Foundation."

So I would kindly like to ask if the 4 behaviors described above are
expected legitimate behavior of the XSF Extensions Editor according
to the regulations of the XSF.

If this is the case, I would recommend Philipp to apologize to Peter
for the snarkiness.