Re: [Standards] [Fwd: SASL to draft questionnaire]
Hey Peter, Openfire uses the SASL support provided by Java. That means that SASL PLAIN, DIGEST-MD5, GSSAPI, etc. are provided by Java. The only SASL mechanisms that we manually implemented on the server are SASL ANONYMOUS and SASL EXTERNAL. On the Smack side I recall implementing SASL PLAIN but we might now be using the one provied by Java. Regards, -- Gato On 7/30/08 12:34 PM, "Peter Saint-Andre" <[EMAIL PROTECTED]> wrote: > This may be of interest here -- the SASL folks are working to advance > RFC 4422 to Draft and are looking for implementation reports. Has anyone > on this list developed their own SASL implementation, or are all the > XMPP clients, servers, and libraries incorporating specialized SASL code? > > Thanks! > > /psa > > Original Message > Date: Tue, 29 Jul 2008 17:14:32 +0100 > From: Chris Newman <[EMAIL PROTECTED]> > Subject: SASL to draft questionnaire > To: [EMAIL PROTECTED] > > > Here's a proposed questionnaire for an implementation report. > > I am not volunteering to compile responses to the questions, but I am > willing to answer these questions for my implementations. > > - Chris > > --- > RFC 4422 Implementation Questionnaire > === > 0. Contact and Description > Organization Name: > Implementation (Software or Service) Name: > > > 1. Have you implemented SASL and/or SASL mechanism? > > 2. Which SASL mechanisms have you implemented? > > 3. For how long has it been deployed? > > 4. What features have NOT been implemented from SASL? > > 5. What features of SASL or SASL mechanisms are problematic for your > implementation? > > 6. Please add any other comments you wish to share: > >
Re: [Standards] presence priority -1 issues
On Wed Jul 30 20:40:13 2008, Peter Saint-Andre wrote: Dave Cridland wrote: On Wed Jul 30 13:55:56 2008, Pedro Melo wrote: The most important part of -1 resources are their caps. For example, I can have a calendar app logged in with my own jid, accepting some namespace for calendar updates or meeting requests. Are you suggesting a sort of negative disco feature which indicates that the XMPP entity is not an IM resource at all? Could this be done with a suitable category/type? Moving forward, this would allow clever clients to observe that it wasn't a IM client capable of handling calendaring requests, but a dumb calendaring bot working on behalf of the user. If you're not suggesting this, can I suggest it? :-) I think he's suggesting that the disco identity of your calendar would be something like this: So you know that it's not something like this: That's what I was hoping he was suggesting. Since if you see it's not a client, but an automaton, then you know not to strike up a conversation with it. Whereas a client/* presumably might have a human on the other end, and so is reasonable to talk to under some circumstances. Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] rfc3920bis -06
Dirk Meyer wrote: Peter Saint-Andre wrote: Dirk Meyer wrote: Peter Saint-Andre wrote: So you are suggesting that a message addressed to a full JID would never be delivered to another resource (or stored offline?) if that resource does not exist. Correct? I hadn't considered that option. [...] A message that is addressed to a resource with a negative priority is delivered to that resource. The only thing that negative priority does is prohibit delivery to that resource if the message was addressed to the bare JID, not the full JID. Interessting question. What should happen if you send a message to the full JID of a resource that does not exist anymore. And to combine it with a negative priority: what happens if that resource had a negative priority before indicating non-chat. 1. Discard? Always a bad idea without letting the sender know. 2. Store? Possible, but may not make any sense. Depends on the context. 3. Send to someone else? Makes no sense in some contexts? If I have a message based IBB a different receiver can not handle it. Right now the spec says that you treat it as if the message was addressed to the bare JID. If you want fancier delivery handling, you need to use Advanced Message Processing (XEP-0079). For example the IBB spec says you'd want to use AMP for just the reason you cite. /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] presence priority -1 issues
Dave Cridland wrote: On Wed Jul 30 13:55:56 2008, Pedro Melo wrote: The most important part of -1 resources are their caps. For example, I can have a calendar app logged in with my own jid, accepting some namespace for calendar updates or meeting requests. Are you suggesting a sort of negative disco feature which indicates that the XMPP entity is not an IM resource at all? Could this be done with a suitable category/type? Moving forward, this would allow clever clients to observe that it wasn't a IM client capable of handling calendaring requests, but a dumb calendaring bot working on behalf of the user. If you're not suggesting this, can I suggest it? :-) I think he's suggesting that the disco identity of your calendar would be something like this: So you know that it's not something like this: Peter smime.p7s Description: S/MIME Cryptographic Signature
[Standards] [Fwd: SASL to draft questionnaire]
This may be of interest here -- the SASL folks are working to advance RFC 4422 to Draft and are looking for implementation reports. Has anyone on this list developed their own SASL implementation, or are all the XMPP clients, servers, and libraries incorporating specialized SASL code? Thanks! /psa Original Message Date: Tue, 29 Jul 2008 17:14:32 +0100 From: Chris Newman <[EMAIL PROTECTED]> Subject: SASL to draft questionnaire To: [EMAIL PROTECTED] Here's a proposed questionnaire for an implementation report. I am not volunteering to compile responses to the questions, but I am willing to answer these questions for my implementations. - Chris --- RFC 4422 Implementation Questionnaire === 0. Contact and Description Organization Name: Implementation (Software or Service) Name: 1. Have you implemented SASL and/or SASL mechanism? 2. Which SASL mechanisms have you implemented? 3. For how long has it been deployed? 4. What features have NOT been implemented from SASL? 5. What features of SASL or SASL mechanisms are problematic for your implementation? 6. Please add any other comments you wish to share: smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] ICE/UDP and NAT
On Wed, 30 Jul 2008 17:21:43 +0200 "Sylvain Mundialco" <[EMAIL PROTECTED]> wrote: > Hi. > > Can I have more clarity on these: > > We are implementing jingle and all is going all but the configuration > NAT/Firewall for both peer is not working. I'm thinking to use relayed > candidate but I know that there is a way of punching hole in > Nat/Firewall. > > 1) Is it the possible to use the UDP firewall punching hole technique > of waiting the NAT to map the inbound and outbound IP to allow > comunication This is more of a question for your network/firewall administrator, not for XMPP people. For the XMPP part, refer to *XEP-0176: Jingle ICE-UDP Transport Method* > 2) when should we use relay candidate in jingle negotiation. You should generally avoid it. > 3) how with jingle can we get a usable pair of candidates behind > firewall and NAT. I believe it's answered in (1). > Sylvain. -- Web: http://www.pavlix.net/ Jabber & Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] rfc3920bis -06
Peter Saint-Andre wrote: > Dirk Meyer wrote: >> Sorry for the late answer, I've been very busy the last weeks. >> >> Peter Saint-Andre wrote: >>> Dirk Meyer wrote: The same is true for presence (in RFC 39210. I found the presence handling much too complicate to implement. It took me longer than adding PubSub and XTLS support. >>> Yes, presence is complex. Sorry about that. Did you implement it in a >>> server or a client? >> >> Only client but IIRC adding a friend to the roster resulted in getting >> an iq result without sending a get or set. Very confusing. > > So you sent and you received an IQ result > from your server? That sounds like a server bug. I'm not sure what it was, but something like that. I will have time to clean up my implementation next week and I will do some more testing with my server (I now use ejabberd 2 which I did not use before). If the JID contained in the 'to' attribute is of the form <[EMAIL PROTECTED]/resource> and there is a connected resource that exactly matches the full JID, the server SHOULD deliver the stanza to that connected resource. I would prefer MUST >>> It needs to be a conditional MUST, because the server MUST NOT deliver >>> a message stanza to you if: >>> >>> 1. According to XEP-0016 you are blocking messages from the sender. >>> >>> 2. According to RFC 3920 your resource has negative presence priority. >> >> So maybe not "MUST send to this resource" but "MUST NOT send the >> message to a different resource". This keeps XEP-0016 in place. > > So you are suggesting that a message addressed to a full JID would > never be delivered to another resource (or stored offline?) if that > resource does not exist. Correct? I hadn't considered that option. [...] > A message that is addressed to a resource with a negative priority is > delivered to that resource. The only thing that negative priority does > is prohibit delivery to that resource if the message was addressed to > the bare JID, not the full JID. Interessting question. What should happen if you send a message to the full JID of a resource that does not exist anymore. And to combine it with a negative priority: what happens if that resource had a negative priority before indicating non-chat. 1. Discard? Always a bad idea without letting the sender know. 2. Store? Possible, but may not make any sense. Depends on the context. 3. Send to someone else? Makes no sense in some contexts? If I have a message based IBB a different receiver can not handle it. Regards, Dirk -- "Either toss the Windows out of your computer, or toss your computer out the window!" -- Richard Stallman
Re: [Standards] XEP-0231 (Data Element) - local caching
On Wed, 30 Jul 2008 07:04:16 -0600 Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > Pavel Simerda wrote: > > On Tue, 29 Jul 2008 19:49:01 -0600 > > Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > > > >> Ahoj Pavle! > >> > >> Pavel Simerda wrote: > >>> Hello, > >>> > >>> I have some suggestions for XEP-0231 (Data Element). > >> Thanks for looking at this spec so thoroughly. > >> > > I actually have some questions. First, lolek from the jabbim.cz > > project is going to propose a XEP for text emoticons. > > Similar to XEP-0038? We can bring that back if someone wants to > maintain it. Similar but more powerful and not file-based but most probably based on Data Elements. There may be a lot of other extensive changes. If these changes can be made, I believe Martin would maintain it if he gets the chance. > > I like his ideas but I > > suggested him to use Data Element instead of a custom solution. > > +1 > > > He still has doubts but I promised him to try to sort it out and to > > help him with language corrections of his document too. > > Great, thanks. > > > I didn't find in the specs what should be used for domain ID in the > > CID. The examples apparently use the domain part of JID that is not > > unique for the clients. I looked at the RFC and still don't know a > > proper mapping to XMPP. > > > > His original idea was to use a cryptographic hash function and not a > > CID. > > I think your idea of a UUID followed by the domain part of the JID > would work well. > > > He also pointed out he misses a feature that would allow a client to > > advertise which mimetypes it supports. > > Yes we can add a disco feature for that. > > > This is another questions... if it's just emoticons, should we just > > support png and mng types or add some accept-advertisement facility? > > I don't think it hurts to define a way to advertise what MIME types > you support. We'll use the data element for things other than > emoticons, but IMHO the simplest approach would be to advertise in > general which MIME types you support, not "I support these mime types > for emoticons" and "I support these other mime types for file > transfer thumbnails" etc. Does anyone think that level of complexity > is needed? I'm not sure. Let's wait for other comments. > > Is there a written policy for image formats in XMPP extensions? > > Not yet. PNG for static raster images, MNG for animated raster images, SVG for vector images? That's something I would expect from every client. > >>> Right now, as the example shows: > >>> > >>> >>> to='[EMAIL PROTECTED]' > >>> type='groupchat'> > >>> Yet here's a spot. > >>> > >>> > >>> > >>> Yet here's a spot. > >>> >>> > >>> src='cid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@shakespeare.lit'/> > >>> > >>> > >>> > >>>>>> alt='A spot' > >>> cid='[EMAIL PROTECTED]' > >>> type='image/png'> > >>> iVBORw0KGgoNSUhEUgoKCAYAAACNMs+9BGdBTUEAALGP > >>> C/xhBQlwSFlzAAALEwAACxMBAJqcGAd0SU1FB9YGARc5KB0XV+IA > >>> AAAddEVYdENvbW1lbnQAQ3JlYXRlZCB3aXRoIFRoZSBHSU1Q72QlbgAAAF1J > >>> REFUGNO9zL0NglAAxPEfdLTs4BZM4DIO4C7OwQg2JoQ9LE1exdlYvBBeZ7jq > >>> ch9//q1uH4TLzw4d6+ErXMMcXuHWxId3KOETnnXXV6MJpcq2MLaI97CER3N0 > >>> vr4MkhoXe0rZigBJRU5ErkJggg== > >>> > >>> > >>> > >>> Note: in this particular example the data is very short, this may > >>> not be the case in real world where people tend to ignore the size > >>> of data they send. > >> Yes, that's just about the smallest image I could find. The spec > >> says that the image should not be more than 8k (which is twice the > >> suggested size of an IBB chunk) but we don't know if people will > >> typically send images that are smaller or larger than 8k -- I think > >> smaller but I don't know that yet. > >> > > > > Might it be advertised by the client/server? And rejected if the > > other party tries to send a bigger one (just to force them to fix > > it)? > > I think that's handled at a different layer (e.g., rate limiting). > But we do need to define better handling for stanzas that are too > large (there is a proto-XEP about it but the Council didn't accept it > and I never incorporated their feedback). > Hmm. I know that people at jabbim.cz use a roster-renaming utility (for icq transport). They wait a long time between stanzas and the renaming can often takes more than just several minutes. > >>> We send data once for every session (and omit for subsequent > >>> messages). > >> In this case it's important to define "session" (see rfc321bis). Is > >> it a chat session, a presence session, or something else? > >> > > > > Exactly. > > > >>> This has two important implications: > >>> > >>> 1) The other entity may or may not cache it for the session and > >>> reuse it. That is good. > >>> > >>> 2) If an entity keeps the data for a longer time (e.g. for weeks > >>> or even permanently), this cache wil
Re: [Standards] presence priority -1 issues
On Wed Jul 30 13:55:56 2008, Pedro Melo wrote: The most important part of -1 resources are their caps. For example, I can have a calendar app logged in with my own jid, accepting some namespace for calendar updates or meeting requests. Are you suggesting a sort of negative disco feature which indicates that the XMPP entity is not an IM resource at all? Could this be done with a suitable category/type? Moving forward, this would allow clever clients to observe that it wasn't a IM client capable of handling calendaring requests, but a dumb calendaring bot working on behalf of the user. If you're not suggesting this, can I suggest it? :-) Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] ICE/UDP and NAT
Hi. Can I have more clarity on these: We are implementing jingle and all is going all but the configuration NAT/Firewall for both peer is not working. I'm thinking to use relayed candidate but I know that there is a way of punching hole in Nat/Firewall. 1) Is it the possible to use the UDP firewall punching hole technique of waiting the NAT to map the inbound and outbound IP to allow comunication 2) when should we use relay candidate in jingle negotiation. 3) how with jingle can we get a usable pair of candidates behind firewall and NAT. Sylvain.<>
Re: [Standards] Questions about xhtml-im
Jehan wrote:
Peter Saint-Andre;1984 Wrote:
Please quote the entire section:
***
A user agent that implements this specification MUST conform to Section
3.5 ("XHTML Family User Agent Conformance") of Modularization of XHTML.
Many of the requirements defined therein are already met by Jabber
clients simply because they already include XML parsers.
However, "ignore" has a special meaning in XHTML modularization
(different from its meaning in XMPP). Specifically, criteria 4 through
6
of Section 3.5 of Modularization of XHTML state:
4.
W3C TEXT: If a user agent encounters an element it does not
recognize, it must continue to process the children of that element. If
the content is text, the text must be presented to the user.
XSF COMMENT: This behavior is different from that defined by
XMPP
Core, and in the context of XHTML-IM implementations applies only to
XML
elements qualified by the 'http://www.w3.org/1999/xhtml' namespace as
defined herein. This criterion MUST be applied to all XHTML 1.0
elements
except those explicitly included in XHTML-IM as described in the
XHTML-IM Integration Set and Recommended Profile sections of this
document. Therefore, an XHTML-IM implementation MUST process all XHTML
1.0 child elements of the XHTML-IM element even if such child
elements are not included in the XHTML 1.0 Integration Set defined
herein, and MUST present to the recipient the XML character data
contained in such child elements.
***
What I understand is
that when I encounter a tag which I recognize as being xhtml, but
which
is not in the xhtml-im subset, then I must display it "as is"?
Let's say you receive this:
I like the Extensible Messaging and Presence Protocol
(XMPP).
In this case you would display the XML character data of the
element even though it's not part of the XHTML-IM integration set.
That's just one example.
/psa
Sorry I did not understand (or at least as much as the original).
Don't worry about that. XHTML modularization is a bit strange. :)
So when you write to "display the XML character data", you mean that
you just dump the tag element, and display its content ("XMPP") ?
So you display this:
I like the Extensible Messaging and Presence Protocol (XMPP)
This would look natural to me (and I think to have understood this is
also how the W3C recommends it for the core xhtml .
Correct.
Anyway for the part about semantic/structure versus style/display,
probably there can be discussions about this (and you already had
apparently), but even though I am completely partisan of structure, I
understood well the two points here which are that this XEP is for IM,
and that normal users cannot be asked to think about structure when they
just care about style.
Yet just to answer shortly about this point:
The style should come from the meaning of the tag, like in the web!
How so? Remember that we don't have external CSS here.
In case where structure would have been chosen above style (even
though, as I remind, I understand now why style is chosen in IM), there
may be a small CSS just for the few available tags in xhtml-im on client
side (then a user could even modify their personal CSS).
Well, I agree with you about structural markup and I don't remember the
discussions that led to a more stylistic focus in XEP-0071. I think
people argued that users really want to send (say) italicized text, not
emphasized text. I'm sure we could check out the list archives for
historical details, but the real question is: how do we want to proceed now?
I'd be willing to relax our usage of the Text Module so that we
encourage more structural markup. As far as I can see, the following
elements would be most useful:
blockquote
cite
em
q
strong
In some applications I could also see an argument for:
abbr
acronym
code
dfn
h1 through h6
kbd
pre
Those are not forbidden in XHTML-IM right now, just not encouraged. But
we could change that if we think it's a good idea.
/psa
smime.p7s
Description: S/MIME Cryptographic Signature
[Standards] xep-0077: account removal... and after?
This XEP defines how to remove an account. I was wondering if somewhere it is explained (I did not find) how it is dealt for all the "registration" stuffs. Most especially the roster: shouldn't your server unsubscribe you from all people in your roster? If it did not do so, first inconvenience is obviously that people may continue to send you messages sometimes (and would not understand receiving errors of unreceived messages); but worse if someone registers with the same jid (on purpose for a scam, or just by chance), could he just pretend to be you? And possibly this shall be extended to all other kind of registration: to services, pubsub, etc. It is important that the new user does not get disturbed by what the previous user of same jid has subscribed (imagine one would receive publication on a node the previous user had subscribed), but also that the new user cannot have access to what the previous user had access (if he had some moderation rights on a pubsub node or any other kind of service, there should be removed when the jid is deleted). So this is a severe protection for the former as well as the current user of a single jid after an account removal. Is this dealt in some XEP? Thanks. Jehan -- Jehan Jehan's Profile: http://www.jabberforum.org/member.php?userid=16911 View this thread: http://www.jabberforum.org/showthread.php?t=484
Re: [Standards] XEP-0231 (Data Element) - local caching
Pavel Simerda wrote: On Tue, 29 Jul 2008 19:49:01 -0600 Peter Saint-Andre <[EMAIL PROTECTED]> wrote: Ahoj Pavle! Pavel Simerda wrote: Hello, I have some suggestions for XEP-0231 (Data Element). Thanks for looking at this spec so thoroughly. I actually have some questions. First, lolek from the jabbim.cz project is going to propose a XEP for text emoticons. Similar to XEP-0038? We can bring that back if someone wants to maintain it. I like his ideas but I suggested him to use Data Element instead of a custom solution. +1 He still has doubts but I promised him to try to sort it out and to help him with language corrections of his document too. Great, thanks. I didn't find in the specs what should be used for domain ID in the CID. The examples apparently use the domain part of JID that is not unique for the clients. I looked at the RFC and still don't know a proper mapping to XMPP. His original idea was to use a cryptographic hash function and not a CID. I think your idea of a UUID followed by the domain part of the JID would work well. He also pointed out he misses a feature that would allow a client to advertise which mimetypes it supports. Yes we can add a disco feature for that. This is another questions... if it's just emoticons, should we just support png and mng types or add some accept-advertisement facility? I don't think it hurts to define a way to advertise what MIME types you support. We'll use the data element for things other than emoticons, but IMHO the simplest approach would be to advertise in general which MIME types you support, not "I support these mime types for emoticons" and "I support these other mime types for file transfer thumbnails" etc. Does anyone think that level of complexity is needed? Is there a written policy for image formats in XMPP extensions? Not yet. Right now, as the example shows: Yet here's a spot. Yet here's a spot. alt='A spot' cid='[EMAIL PROTECTED]' type='image/png'> iVBORw0KGgoNSUhEUgoKCAYAAACNMs+9BGdBTUEAALGP C/xhBQlwSFlzAAALEwAACxMBAJqcGAd0SU1FB9YGARc5KB0XV+IA AAAddEVYdENvbW1lbnQAQ3JlYXRlZCB3aXRoIFRoZSBHSU1Q72QlbgAAAF1J REFUGNO9zL0NglAAxPEfdLTs4BZM4DIO4C7OwQg2JoQ9LE1exdlYvBBeZ7jq ch9//q1uH4TLzw4d6+ErXMMcXuHWxId3KOETnnXXV6MJpcq2MLaI97CER3N0 vr4MkhoXe0rZigBJRU5ErkJggg== Note: in this particular example the data is very short, this may not be the case in real world where people tend to ignore the size of data they send. Yes, that's just about the smallest image I could find. The spec says that the image should not be more than 8k (which is twice the suggested size of an IBB chunk) but we don't know if people will typically send images that are smaller or larger than 8k -- I think smaller but I don't know that yet. Might it be advertised by the client/server? And rejected if the other party tries to send a bigger one (just to force them to fix it)? I think that's handled at a different layer (e.g., rate limiting). But we do need to define better handling for stanzas that are too large (there is a proto-XEP about it but the Council didn't accept it and I never incorporated their feedback). We send data once for every session (and omit for subsequent messages). In this case it's important to define "session" (see rfc321bis). Is it a chat session, a presence session, or something else? Exactly. This has two important implications: 1) The other entity may or may not cache it for the session and reuse it. That is good. 2) If an entity keeps the data for a longer time (e.g. for weeks or even permanently), this cache will never be used. As the sending entity always resends the data for a new session. What I propose is: * By default the sending entity would not send the data. It would merely reference it by its cid url. * Let the recieving client follow "3.4 Retrieving Uncached Media Data" if the data is not cached (no real change, this is already being done). I think I like that approach. It introduces a round trip for the IQ, which might introduce some latency. But it puts the burden for "storing" and "serving" the image on the sender, which might discourage abuse of in-band images. * Reserve the possibility of sending the data immediately with the message for the *specific* case that the sending client actually knows the recieving party cannot have the data cached (e.g. the data was never sent before). This behavior should be considered optional. In that case the sender needs to keep a list of every JID to which it has ever sent the image. That seems suboptimal. I didn't write it exactly as I meant it. There may be cases we are knowingly sending something really new. But we might just as well drop this feature if you think it's better. If it's optional, it does no great harm. In fact it's not even a feature, just an implementation note.
Re: [Standards] presence priority -1 issues
Hi, (sorry to be late at the discussion) :) On Jul 27, 2008, at 8:26 PM, Kevin Smith wrote: It's possible this is just a UI problem. I remember chatting to Pedro Melo about this back in February, and I believe our conclusion back then was just that clients will start showing -1 as a non-chat resource, or somesuch, depending on how general usage pans out +1. The most important part of -1 resources are their caps. For example, I can have a calendar app logged in with my own jid, accepting some namespace for calendar updates or meeting requests. That would show up on "regular clients" at most with a small calendar icon. But it should not represent a "online" resource, of course. Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP!
Re: [Standards] Questions about xhtml-im
On Wed, 30 Jul 2008 13:04:33 +0200
Jehan <[EMAIL PROTECTED]> wrote:
>
> Peter Saint-Andre;1984 Wrote:
> >
> > Please quote the entire section:
> >
> > ***
> >
> > A user agent that implements this specification MUST conform to
> > Section
> >
> > 3.5 ("XHTML Family User Agent Conformance") of Modularization of
> > XHTML.
> >
> > Many of the requirements defined therein are already met by Jabber
> > clients simply because they already include XML parsers.
> >
> > However, "ignore" has a special meaning in XHTML modularization
> > (different from its meaning in XMPP). Specifically, criteria 4
> > through 6
> > of Section 3.5 of Modularization of XHTML state:
> >
> > 4.
> >
> > W3C TEXT: If a user agent encounters an element it does not
> > recognize, it must continue to process the children of that
> > element. If
> >
> > the content is text, the text must be presented to the user.
> >
> > XSF COMMENT: This behavior is different from that defined by
> > XMPP
> > Core, and in the context of XHTML-IM implementations applies only to
> > XML
> > elements qualified by the 'http://www.w3.org/1999/xhtml' namespace
> > as defined herein. This criterion MUST be applied to all XHTML 1.0
> > elements
> > except those explicitly included in XHTML-IM as described in the
> > XHTML-IM Integration Set and Recommended Profile sections of this
> > document. Therefore, an XHTML-IM implementation MUST process all
> > XHTML
> >
> > 1.0 child elements of the XHTML-IM element even if such
> > child elements are not included in the XHTML 1.0 Integration Set
> > defined herein, and MUST present to the recipient the XML character
> > data contained in such child elements.
> >
> > ***
> >
> > > What I understand is
> > > that when I encounter a tag which I recognize as being xhtml, but
> > which
> > > is not in the xhtml-im subset, then I must display it "as is"?
> >
> > Let's say you receive this:
> >
> > I like the Extensible Messaging and Presence
> > Protocol (XMPP).
> >
> > In this case you would display the XML character data of the
> > element even though it's not part of the XHTML-IM
> > integration set.
> >
> > That's just one example.
> >
> > /psa
>
> Sorry I did not understand (or at least as much as the original).
>
> So when you write to "display the XML character data", you mean that
> you just dump the tag element, and display its content ("XMPP") ?
> So you display this:
> > I like the Extensible Messaging and Presence Protocol (XMPP)
>
> This would look natural to me (and I think to have understood this is
> also how the W3C recommends it for the core xhtml .
>
> Or do you mean that you display the unknown (in xhtml-im subset) tag
> element itself to the simple user view, so this:
> > I like the Extensible Messaging and Presence Protocol
> > (XMPP)
>
> So one will see unprocessed tag (and if the user does not know what is
> xhtml, it would look like strange unknown words)...
>
> I am sorry if I don't understand this... That's probably about word
> definition here where I am not sure about what you call the XML
> character data of an element:
> 1/ character data in XML being the "normal" text between the tag
> elements;
That's it.
> 2/ or character data as a graphical character/pictogram in an alphabet
> (what we call a "character set" in computer science)?
> Thanks.
>
> Jehan
>
> P.S.: for the rest of my questions, thanks for the answers. I guess I
> shall read and try and understand the concept of modularization of
> xhtml, as you suggest. :-)
>
> Anyway for the part about semantic/structure versus style/display,
> probably there can be discussions about this (and you already had
> apparently), but even though I am completely partisan of structure, I
> understood well the two points here which are that this XEP is for IM,
> and that normal users cannot be asked to think about structure when
> they just care about style.
>
> Yet just to answer shortly about this point:
> > > The style should come from the meaning of the tag, like in the
> > > web!
> >
> > How so? Remember that we don't have external CSS here.
>
> In case where structure would have been chosen above style (even
> though, as I remind, I understand now why style is chosen in IM),
> there may be a small CSS just for the few available tags in xhtml-im
> on client side (then a user could even modify their personal CSS).
>
>
I cannot talk for XHTML-IM as it's the first thing I turn off. But I
generally like the idea of using and and similar for
structural markup even in instant messaging.
It's markup vs. styling. I particularly dislike any styling... as this
will be often misused to put bright colors or fancy fonts into the
chatrooms which is annoying and...
If you see it... it's bad.
If you don't, you can't kick the people for huge font sizes, big fancy
pictures. For me xhtml-im is just a headache.
But... if I could disable the styling and use it for murkup like
emphasizing, links or even structuring s
Re: [Standards] Questions about xhtml-im
Peter Saint-Andre;1984 Wrote:
>
> Please quote the entire section:
>
> ***
>
> A user agent that implements this specification MUST conform to Section
>
> 3.5 ("XHTML Family User Agent Conformance") of Modularization of XHTML.
>
> Many of the requirements defined therein are already met by Jabber
> clients simply because they already include XML parsers.
>
> However, "ignore" has a special meaning in XHTML modularization
> (different from its meaning in XMPP). Specifically, criteria 4 through
> 6
> of Section 3.5 of Modularization of XHTML state:
>
> 4.
>
> W3C TEXT: If a user agent encounters an element it does not
> recognize, it must continue to process the children of that element. If
>
> the content is text, the text must be presented to the user.
>
> XSF COMMENT: This behavior is different from that defined by
> XMPP
> Core, and in the context of XHTML-IM implementations applies only to
> XML
> elements qualified by the 'http://www.w3.org/1999/xhtml' namespace as
> defined herein. This criterion MUST be applied to all XHTML 1.0
> elements
> except those explicitly included in XHTML-IM as described in the
> XHTML-IM Integration Set and Recommended Profile sections of this
> document. Therefore, an XHTML-IM implementation MUST process all XHTML
>
> 1.0 child elements of the XHTML-IM element even if such child
> elements are not included in the XHTML 1.0 Integration Set defined
> herein, and MUST present to the recipient the XML character data
> contained in such child elements.
>
> ***
>
> > What I understand is
> > that when I encounter a tag which I recognize as being xhtml, but
> which
> > is not in the xhtml-im subset, then I must display it "as is"?
>
> Let's say you receive this:
>
> I like the Extensible Messaging and Presence Protocol
> (XMPP).
>
> In this case you would display the XML character data of the
> element even though it's not part of the XHTML-IM integration set.
>
> That's just one example.
>
> /psa
Sorry I did not understand (or at least as much as the original).
So when you write to "display the XML character data", you mean that
you just dump the tag element, and display its content ("XMPP") ?
So you display this:
> I like the Extensible Messaging and Presence Protocol (XMPP)
This would look natural to me (and I think to have understood this is
also how the W3C recommends it for the core xhtml .
Or do you mean that you display the unknown (in xhtml-im subset) tag
element itself to the simple user view, so this:
> I like the Extensible Messaging and Presence Protocol
> (XMPP)
So one will see unprocessed tag (and if the user does not know what is
xhtml, it would look like strange unknown words)...
I am sorry if I don't understand this... That's probably about word
definition here where I am not sure about what you call the XML
character data of an element:
1/ character data in XML being the "normal" text between the tag
elements;
2/ or character data as a graphical character/pictogram in an alphabet
(what we call a "character set" in computer science)?
Thanks.
Jehan
P.S.: for the rest of my questions, thanks for the answers. I guess I
shall read and try and understand the concept of modularization of
xhtml, as you suggest. :-)
Anyway for the part about semantic/structure versus style/display,
probably there can be discussions about this (and you already had
apparently), but even though I am completely partisan of structure, I
understood well the two points here which are that this XEP is for IM,
and that normal users cannot be asked to think about structure when they
just care about style.
Yet just to answer shortly about this point:
> > The style should come from the meaning of the tag, like in the web!
>
> How so? Remember that we don't have external CSS here.
In case where structure would have been chosen above style (even
though, as I remind, I understand now why style is chosen in IM), there
may be a small CSS just for the few available tags in xhtml-im on client
side (then a user could even modify their personal CSS).
--
Jehan
Jehan's Profile: http://www.jabberforum.org/member.php?userid=16911
View this thread: http://www.jabberforum.org/showthread.php?t=435
Re: [Standards] presence priority -1 use case
Hello, folks at jabbim.cz are working on a service for a single-contact webchat (visitors of your website may chat with you in a simple UI). There are various issues with the implementation on XMPP. Especially the JID of the web user. 1) It could be [EMAIL PROTECTED] The problem is with presence, as this JID is not subscribed. 2) Otherwise [EMAIL PROTECTED]/[nick] (I was told [service]/[nick] is not handled well by some clients, I can ask for more info if needed) Then they would use negative priority to prevent the user from sending messages to a different nick than he wants. This component actually mimics a chat client intended for recieving messages but priority -1 serves well. Pavel -- Web: http://www.pavlix.net/ Jabber & Mail: pavlix(at)pavlix.net OpenID: pavlix.net
