[jdev] RE: [Standards] Re: compliance levels for 2008

[Chris Mullins]

I've got a few issues that I think need being brought up:

1 - Avatars. It's a feature users expect, and a client without them
can't even be considered a toy these days. None of these client specs
talk about Avatars. This is something that needs to at least be in the
Intermediate spec. 

2 - Rich Messaging. It's no secret that I don't like the XHTML spec, and
I think requiring it is a mistake. Our new client, for example, uses
Rich Text messaging. We may swap this out with HTML messaging at some
point in the future, but it will probably never be XHTML as defined by
the XEP. 

3 - VCards. Everyone expects VCards (especially Avatars and Friendly
Names) in one form or another. This should be in the Basic Spec.

4 - Bookmarks. This should be in the Intermediate Spec alongside MUC.

5 - XMPP IRI's. For example, if I have Exodus or Pandion running, and
click on an XMPP IRI in FireFox, the behavior works (mostly) as I expect
it to. This should be a required client feature for the Intermediate
(Advanced? Complete?) Spec.

6 - We should require an XML Debug Window of some sort. Tie it to a
standard Keystroke (Exodus, Pandion, and our new Communicator all use
F12), so that it's practical to have a debug session with someone. This
should be in the Basic Spec.

7 - We should require clients to support Start-TLS streams. This is an
optional thing in the RFC, but clients really need to support it. This
should be in the Basic Spec.

8 - Which MUC features do we want to require in the Intermediate spec?
All of them? (Kick / Ban / Voice / Configure / History / 1:1->MUC,
invites, etc) Or just the basic ones? I would say an intermediate client
MUST support joining a room, chatting in a room, and responding to
invites. I would continue to say that it's not required to be able to
configure a room, or perform admin features in the room. 

I would also, for BASIC clients, require: 
- An Install and uninstall mechanism that works with the target O/S
- A means to quickly and easily report a bug against the client.

I would include for Intermediate Clients:
- A means to upgrade the client from one version to another.
- File transfer. Come on guys! :)


... that's some food for thought. Opinions?

--
Chris Mullins

	


-----Original Message-----
From: standards-bounces at xmpp.org [mailto:standards-bounces at xmpp.org] On
Behalf Of Peter Saint-Andre
Sent: Friday, May 04, 2007 1:40 PM
To: standards at xmpp.org
Cc: jdev at jabber.org
Subject: [Standards] Re: compliance levels for 2008

So far there has been no discussion of this topic. I know that some XMPP

Council members voiced concerns about some features in a recent meeting 
but they have not yet posted to the list. Silence will be taken as 
agreement. Please speak up if you have questions or concerns. These 
compliance levels will be used for testing purposes and to issue shiny 
little icons you can put on your website or in your clients. And who 
doesn't like shiny little icons?

Thanks!

/psa

Peter Saint-Andre wrote:
> At the "XMPP Summit" held after FOSDEM in late February, we decided to

> more clearly define compliance levels for XMPP servers and clients. As

> part of that effort, the XMPP Council promised to:
> 
> 1. Define updated compliance levels each year.
> 
> 2. Complete definition of the next year's levels by June 30.
> 
> Since 2007-06-30 is fast approaching, we need to complete our work on 
> the 2008 compliance levels soon. To that end we recently published
three 
> XEPs:
> 
> XEP-0211: XMPP Basic Client 2008
>           http://www.xmpp.org/extensions/xep-0211.html
> 
> XEP-0212: XMPP Basic Server 2008
>           http://www.xmpp.org/extensions/xep-0212.html
> 
> XEP-0213: XMPP Intermediate Client 2008
>           http://www.xmpp.org/extensions/xep-0213.html
> 
> (There is no "intermediate server" level because the intermediate 
> features we have defined so far are all client-side features, but that

> may change as a result of discussion on this list.)
> 
> These documents are on a "fast track" so that the XMPP Council can 
> approve them by June 30. I propose the following schedule:
> 
> 1. April 30 - May 30
> 
>    Open discussion on standards at xmpp.org list.
> 
> 2. May 30
> 
>    XMPP Council issues Last Call on XEPs 211-213.
> 
> 3. May 30 - June 20
> 
>    Last Call discussion on standards at xmpp.org list.
> 
> 4. June 27
> 
>    XMPP Council votes on advancing XEPs 211-213 to Draft.
> 
> Please provide your feedback sooner rather than later.
>