Re: [jdev] RE: [Standards] Re: compliance levels for 2008
On 5/5/07, Chris Mullins [EMAIL PROTECTED] wrote: 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. I vote for the basic PEP XEP and do not specifically require any of the XEPs that require PEP (like User Avatar) 3 - VCards. Everyone expects VCards (especially Avatars and Friendly Names) in one form or another. This should be in the Basic Spec. Same remark 4 - Bookmarks. This should be in the Intermediate Spec alongside MUC. Not sure if this is needed 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. +1 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. I don't think this is useful to require. 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. Maybe 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. What about requiring all of them for strategic reasons? It'll make it easier for people that want to convert from IRC to Jabber. I would also, for BASIC clients, require: - An Install and uninstall mechanism that works with the target O/S I don't think this is useful to require (and btw: most Mac OS X software does not an uninstaller, and on most open-source systems the uninstall system is provided by the OS) - A means to quickly and easily report a bug against the client. I don't think this should be in the spec. Also, how would you define difficult terms like quickly and easily? I would include for Intermediate Clients: - A means to upgrade the client from one version to another. Also should not be in this spec IMO. - File transfer. Come on guys! :) Maybe -- Mvg, Sander Devrieze.
Re: [jdev] RE: [Standards] Re: compliance levels for 2008
On 5/5/07, Chris Mullins [EMAIL PROTECTED] wrote: - File transfer. Come on guys! :) Which of XEP-0047, XEP-0065, XEP-0066, XEP-0095, XEP-0137, XEP-0166, XEP-0176 are you thinking about in particular? -- - Norman Rasmussen - Email: [EMAIL PROTECTED] - Home page: http://norman.rasmussen.co.za/
Re: [jdev] RE: [Standards] Re: compliance levels for 2008
On Saturday 05 May 2007 7:16 am, Norman Rasmussen wrote: On 5/5/07, Chris Mullins [EMAIL PROTECTED] wrote: - File transfer. Come on guys! :) Which of XEP-0047, XEP-0065, XEP-0066, XEP-0095, XEP-0137, XEP-0166, XEP-0176 are you thinking about in particular? XEP-96 and its dependencies is the only standard file transfer. -Justin
Re: [jdev] RE: [Standards] Re: compliance levels for 2008
On 5 May 2007, at 01:18, Chris Mullins wrote: 1 - Avatars. We could have pep avatars come in as a dependency, but it does throw the requirement for PEP in there, and that means we should have PEP as a server dependency somewhere. 2 - Rich Messaging. I've had a couple of issues with xhtml-im in the past, but I still think it's the way to go, for reasons other people have expressed more eloquently than me already. On the other hand, I'm not sure that xhtml-im belongs in here, someone try and persuade me otherwise, but at the moment I don't see this as a major part of IM for most people (compare to avatars, vcards or file transfer). 3 - VCards. Probably fair. 4 - Bookmarks. This should be in the Intermediate Spec alongside MUC. I don't have much complaint about this, if people think it should be required. 5 - XMPP IRI's. I don't agree with this one, I think these /protocol/ compliance suites shouldn't address how the client interfaces with either the user or the operating system. 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. Again, I don't think this is protocol. These are features users may care about, but they're the things the user can easily see on a checklist on the client's site; I think the cert suites are for the features a user can't easily check - primarily compliance to the RFC/ XEPs. 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. Clients probably do need to support this, yeah. I could probably be persuaded either way. 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? 1:1-MUC's a thorny issue, but the rest, yeah. - An Install and uninstall mechanism that works with the target O/S - A means to quickly and easily report a bug against the client. - A means to upgrade the client from one version to another. I'm not keen on any of the above, for reasons I've covered already: they're not relevant to a client's compliance. For a Best client awards, possibly (although as noted earlier these are of varying relevance on different platforms), but not for XMPP compliance. - File transfer. Come on guys! :) Assuming you mean 96, yes, I do think this belongs in intermediate. ... that's some food for thought. Opinions? Now more mails to reply to :) /K -- Kevin Smith Psi XMPP Client Project Leader (http://psi-im.org)
Re: [jdev] RE: [Standards] Re: compliance levels for 2008
On 5 May 2007, at 10:13, Sander Devrieze wrote: I vote for the basic PEP XEP and do not specifically require any of the XEPs that require PEP (like User Avatar) I think PEP is an enabler XEP, you never use PEP on its own, so if we don't require anything which is based on PEP I'm not sure it makes sense for us to require PEP itself (although I do think it should be required through an avatar dependency). /K -- Kevin Smith Psi XMPP Client Project Leader (http://psi-im.org)
Re: [jdev] RE: [Standards] Re: compliance levels for 2008
On 5/5/07, Kevin Smith [EMAIL PROTECTED] wrote: On 5 May 2007, at 10:13, Sander Devrieze wrote: I vote for the basic PEP XEP and do not specifically require any of the XEPs that require PEP (like User Avatar) I think PEP is an enabler XEP, you never use PEP on its own, so if we don't require anything which is based on PEP I'm not sure it makes sense for us to require PEP itself (although I do think it should be required through an avatar dependency). IMO it makes sense because it has been said these compliance levels will be updated each year. You're right that implementing PEP on it's own is quite useless. But for this reason client developers will probably implement one of the XEPs that rely on it. And if we don't tell them which one they should implement, they will have to chose one themselves. The advantage of this is, is that we'll see next year which XEP that relies on PEP is the most popular, and then the decision for the new compliance levels can be made based on this information. -- Mvg, Sander Devrieze.
