Re: [Standards] well-formedness
Waqas wrote: > On Mon, Oct 20, 2008 at 9:01 PM, Dave Cridland <[EMAIL PROTECTED]> wrote: > >> If you receive invalid XMLNS, however, it might have come from anywhere, and >> merely been forwarded on to you. ANd there's at least three ways of handling >> it. >> >> a) Assume that undeclared prefixes are bound to an arbitrary "unknown" >> namespace. (This is what Gajim does, now). From there, process the stanza as >> much as is possible, which might include doing nothing at all, or rejecting >> it with , just as with any other unrecognized >> namespace. >> >> b) Detect unbound namespaces as a special case, and bounce the stanza. >> >> c) Emit a stream error. This is what Gajim did previously, and what you're >> recommending everyone does. >> > > I am NOT suggesting everyone does that, or should do that. I'm saying > everyone tends to do that because server implementations (e.g., > ejabberd) do not conform to [XML-NAMES]. > > [XML-NAMES] does say "To conform to this specification, a processor > MUST report violations of namespace well-formedness", and parsers I > have tested with all seem to interpret that as a required fatal error. For our purposes, does it need to be a fatal error instead of a warning, or (that is) a stream error instead of a stanza error? >>> Just discarding it has a problem. Someone could send a message with >>> invalid namespaces to a >>> conference.jabber.org room. Everyone (human) would see that, except >>> entities which care about >>> namespaces. From the protocol's perspective this would be "correct", >>> but not from a normal user's >>> perspective. >> And this will have exactly the same effect with any of the above solutions, >> unless one is mandated. And the interesting thing is if a server passes >> through - as existing servers do, essentially doing (a) - and the clients >> all do (c). >> >> Because then, sending invalid XMLNS via a chat room kicks out all the users, >> and this doesn't seem to be appreciated. Believe me, we've see it in the jdev room (not everyone gets kicked, but it's still a selective DoS). > Yep, and while servers should indeed support this until the majority > of servers are namespace aware, this should be considered a bug, and > not legitimized by the spec. I tend to agree, but I'm also sympathetic to concerns about whether this can be implemented reasonably. >>> Sorry if this sounds like a rant. I just don't like where we are headed. >> I don't like where we are. I don't like where some people want us to go, >> because they seem to want to send us off into a fantasy land, where servers >> are redeployed in seconds. >> > > I understand this. But I do think that we should be stricter in the > long term. What you are suggesting (and did in Gajim) is basically a > hack. Something which needed to be done to cope with xmlns-unaware > servers. All client developers should roll their own XMLNS processing > code? They do, but they shouldn't have had to. I just don't think we > should legitimize a hack. > > What I'm saying is that yes, we do need to support the existing > deployments, but their (IMHO) incorrect behavior should be declared as > non-conforming. Right, and that's what the text I proposed (mostly) does. BTW, "where we are" is really a function of jabberd 1.x, which in 2004 (not sure about now) was not namespace-aware or namespace-correct in conformance with XML-NAMES, so we just punted and said it was OK to be out of compliance with XML-NAMES. Perhaps not such a good precedent, but we didn't want to break backwards-compatibility at the time -- in fact that was an explicit goal of the XMPP WG. >> 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 >> > > I understand developers today simply have to accept this non-XML-NAMES > conforming XML. But let's not force the developers writing clients in > 2015 to face the same problems. I think most would agree that that > would be pretty sad. Indeed. > Please understand that even if we use MUST instead of SHOULD with > respect to namespace-awareness, the existing servers are not going to > be left behind. Newer servers and server versions are still going to > continue to support their legacy counterparts. The benefit of course > would be that eventually we will have a sterilized network, where > clients wouldn't need to worry about rolling out their own > (non-conforming) namespace handling. In my opinion this is a better > long term direction. I too think that is a worthy goal. The question is: how can we get there in a reasonable fashion? Peter
Re: [Standards] IM spec errata
Sorry again... Clearing the browser cache fixed it... Brett
Re: [Standards] IM spec errata
Brett Zamir wrote: > My errata was for RFC3921, at http://www.ietf.org/rfc/rfc3921.txt : IM > and Presence. As I mentioned, the draft copy has already corrected the > problem, but I just mentioned it in case you want to fix the non-draft > copies until the draft one is ready. Ah, OK. :) I cannot "fix" RFC 3921 because the IETF doesn't edit documents in place like we do. They have an errata process, but it's cumbersome, and in any case we're way beyond that now with rfc3921bis (and rfc3920bis). If it's fixed in rfc3921bis, please be happy that someone before you reported it or I fixed it when I noticed the error. However, if you have the time to give both rfc3920bis and rfc3921bis a careful review, I would be most appreciative, because the way we'll move forward is to get those two specs done and approved by the IESG. I've read them so many times now that I miss errors in the text, so more eyeballs will help quite a bit. Thanks! Peter
Re: [Standards] IM spec errata
I meant to say the copy at http://xmpp.org/rfcs/rfc3921.html but mistakenly pasted the text version from ietf.org. Oddly, RFC3921 is blocked for me here in China, but only that page (I can get to it via a proxy)! Brett
Re: [Standards] IM spec errata
My errata was for RFC3921, at http://www.ietf.org/rfc/rfc3921.txt : IM and Presence. As I mentioned, the draft copy has already corrected the problem, but I just mentioned it in case you want to fix the non-draft copies until the draft one is ready. Brett Peter Saint-Andre wrote: Brett Zamir wrote: Sorry, was relying on the subject line--IM spec... That is, draft-saintandre-rfc3921bis?
Re: [Standards] IM spec errata
Brett Zamir wrote: > Sorry, was relying on the subject line--IM spec... That is, draft-saintandre-rfc3921bis?
Re: [Standards] IM spec errata
Sorry, was relying on the subject line--IM spec... Brett Peter Saint-Andre wrote: Brett Zamir wrote: If you're still taking errata on the non-draft spec... (the draft spec has fixed it already) Which spec? We have an awful lot of them... Peter
Re: [Standards] IM spec errata
Brett Zamir wrote: > If you're still taking errata on the non-draft spec... (the draft spec > has fixed it already) Which spec? We have an awful lot of them... Peter
Re: [Standards] PDF versions of the specifications
Thomas Charron wrote: > On Mon, Oct 20, 2008 at 6:11 PM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: >>> Feel free to comment and do whatever you want with the stylesheet! >> Do you have any recommendations for running FOP on Debian? ;-) > > apt-get install fop Er yeah, I tried that: # apt-get install fop Reading package lists... Done Building dependency tree... Done Package fop is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package fop has no installation candidate I'll look into this more tomorrow, probably I need to update or modify the package lists. That's more of a topic for the infrastructure team anyway... Peter -- Peter Saint-Andre https://stpeter.im/
[Standards] IM spec errata
If you're still taking errata on the non-draft spec... (the draft spec
has fixed it already)
In the last example in section 7.4, both 's have a @to, though they
are not supposed to per Core spec 9.1.1 ("a stanza sent from a client to
a server for handling by that server (e.g., presence sent to the server
for broadcasting to other entities) SHOULD NOT possess a 'to' attribute.")
In section 7.5, the has a @subscription attribute not set to
remove (from section 7.6: "a compliant server MUST ignore any other
values of the 'subscription' attribute when received from a client").
thanks,
Brett
Re: [Standards] well-formedness
---snip--- I should clarify my position. I would like: "An XMPP entity MUST NOT send out data that is not namespace-well-formed" This includes data which it generates, and data which it routes or delivers. What an entity which is routing or delivering may do is accept data which is not namespace-well-formed, sanitize it, and then route or deliver it. > Note: Because these restrictions were underspecified in an earlier > revision of this specification, it is possible that > implementations based on that revision will send data that does > not comply with the restrictions; an entity SHOULD be liberal in > accepting such data. I agree with this. What this liberal acceptance needs to involve is sanitization.
Re: [Standards] PDF versions of the specifications
On Mon, Oct 20, 2008 at 6:11 PM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: >> Feel free to comment and do whatever you want with the stylesheet! > Do you have any recommendations for running FOP on Debian? ;-) apt-get install fop :-D -- -- Thomas
Re: [Standards] well-formedness
On Mon, Oct 20, 2008 at 9:01 PM, Dave Cridland <[EMAIL PROTECTED]> wrote: > On Mon Oct 20 04:40:56 2008, Waqas wrote: >> >> On Tue, Oct 14, 2008 at 3:28 AM, Peter Saint-Andre <[EMAIL PROTECTED]> >> wrote: >> > "an entity SHOULD be liberal in accepting such data." >> >> This translates to: >> >> "an entity SHOULD NOT use a namespace-validating parser (as defined >> in [XML-NAMES])" >> >> > No, I disagree, it translates as "an entity SHOULD NOT use a parser that > produces an unrecoverable fatal error on an undeclared namespace prefix". I > disagree that's the same thing at all. > The expat parser (as an example) in namespace-aware mode reports a fatal error on undeclared prefixes. This was added in response to this bug report: http://sourceforge.net/tracker/index.php?func=detail&aid=695401&group_id=10127&atid=110127 which references this section of XML Names: http://www.w3.org/TR/REC-xml-names/#ns-qualnames >> This is indeed the case. Entities in the XMPP world tend not to use >> namespace aware parsers. > > Um, wait... > >> In >> fact most do not care about namespaces at all (aside from a few >> specific cases where the XEPs use >> a namespace prefix in the examples, the implementations are often >> coded to look for that prefix). >> >> > ... because... > > >> Testing with ejabberd and gajim (quite a popular combination), it was >> quickly clear that both did >> not deal with valid s where a prefix was used, and both did >> deal with s with a >> namespace other than jabber:client. >> >> > ... Gajim was using, and still does use, a namespace aware parser. > > Ah yes, a namespace aware parser (expat) is indeed being used with namespace awareness disabled... I looked at the Gajim sources, and using 'http://www.gajim.org/xmlns/undeclared-root' as the namespace of all undeclared prefixes clearly does not conform with [XML-NAMES]. See: http://www.w3.org/TR/REC-xml-names/#ProcessorConformance >> All implementations must be namespace non-aware if they don't wish to >> have the disconnection bug >> that gajim had. I would like to argue that it was not a bug at all. >> >> > And Gajim is most certainly namespace aware. Please, review the code and > tell me where it doesn't conform to XML-NAMES. > Gajim does not conform to XML-NAMES. I reviewed the code, and it appears to act correctly for most XML. But it does not act correctly for prefixes on attributes. And it does not have a single one of all those required checks for non-conforming XML (except the undeclared prefix check on tag names). XML-NAMES requires a number of checks for conformance, some of which are in http://www.w3.org/TR/REC-xml-names/#Conformance while others are sprinkled throughout the spec. Dave, I don't think you want to conform to XML-NAMES. I think you'd prefer to sanitize the XML instead to make it conform to XML-NAMES. One step closer to HTML ;) You might wish to view the expat sources. Some of what it does is here: http://expat.cvs.sourceforge.net/viewvc/expat/expat/lib/xmlparse.c?revision=1.162&view=markup#l_2942 > There are a few cases in it's higher layers where it ignores the namespace, > and switches only based on the local-name of the element - this is, indeed, > an error, but it's one that has nothing at all to do with this. The fact > that these existed when the namespace handling in Expat was used somewhat > defeats your argument. > >> The behavior when a server receives a badly-namespaced stanza needs to >> be clarified. I have >> been working with Matthew Wild on a not-yet-released server. We are >> wondering whether we should >> discard the stanza, the element, or raise a stream error. After all, >> there really is no reason >> that any (non-malicious) entity should be sending invalid namespaces. >> If they do then it is a bug, >> just the same as if they sent invalid XML. >> >> > Wrong. It's impossible, in the current infrastructure, to receive invalid > XML except via a error in the entity you're actually connected to. > > If you receive invalid XML, there is no way to handle it in any useful > manner. > > If you receive invalid XMLNS, however, it might have come from anywhere, and > merely been forwarded on to you. ANd there's at least three ways of handling > it. > > a) Assume that undeclared prefixes are bound to an arbitrary "unknown" > namespace. (This is what Gajim does, now). From there, process the stanza as > much as is possible, which might include doing nothing at all, or rejecting > it with , just as with any other unrecognized > namespace. > > b) Detect unbound namespaces as a special case, and bounce the stanza. > > c) Emit a stream error. This is what Gajim did previously, and what you're > recommending everyone does. > I am NOT suggesting everyone does that, or should do that. I'm saying everyone tends to do that because server implementations (e.g., ejabberd) do not conform to [XML-NAMES]. [XML-NAMES] does say "To conform to this specification, a processor MUST report violations of namespace well-form
Re: [Standards] PDF versions of the specifications
Peter Saint-Andre wrote: > Nicolas Roussel wrote: > >> The stylesheet failed on 10 XML files. In most cases, that's because of >> a duplicate anchor name: >> >> http://insitu.lri.fr/~roussel/pub/xep2pdf/major-problems.txt > > I'll fix those. Done: http://svn.xmpp.org:18080/changelog/XMPP/?cs=2415 /psa
Re: [Standards] PDF versions of the specifications
Nicolas Roussel wrote: > Hi, > > I've created a new XSL stylesheet to convert the XEPs from XML to PDF: > > http://insitu.lri.fr/~roussel/pub/xep2pdf/fo.xsl > > I've used it with fop (http://xmlgraphics.apache.org/fop/) to convert > the xep-*.xml files. The resulting PDFs can be obtained from: > > http://insitu.lri.fr/~roussel/pub/xep2pdf/ That's great! > The stylesheet failed on 10 XML files. In most cases, that's because of > a duplicate anchor name: > > http://insitu.lri.fr/~roussel/pub/xep2pdf/major-problems.txt I'll fix those. > Feel free to comment and do whatever you want with the stylesheet! Do you have any recommendations for running FOP on Debian? ;-) Peter
Re: [Standards] PDF versions of the specifications
Hi, I've created a new XSL stylesheet to convert the XEPs from XML to PDF: http://insitu.lri.fr/~roussel/pub/xep2pdf/fo.xsl I've used it with fop (http://xmlgraphics.apache.org/fop/) to convert the xep-*.xml files. The resulting PDFs can be obtained from: http://insitu.lri.fr/~roussel/pub/xep2pdf/ The stylesheet failed on 10 XML files. In most cases, that's because of a duplicate anchor name: http://insitu.lri.fr/~roussel/pub/xep2pdf/major-problems.txt Feel free to comment and do whatever you want with the stylesheet! Nicolas --- Nicolas Rousselhttp://insitu.lri.fr/~roussel/ In Situ, Univ. Paris-Sud (LRI) & INRIA Saclay - Île-de-France
[Standards] UPDATED: XEP-0177 (Jingle Raw UDP Transport Method)
Version 0.12 of XEP-0177 (Jingle Raw UDP Transport Method) has been released. Abstract: This specification defines a Jingle transport method that results in sending media data using raw datagram sockets via the User Datagram Protocol (UDP). This simple transport method does not provide NAT traversal, and the ICE-UDP transport method should be used if NAT traversal is required. Changelog: For consistency with the ICE-UDP transport method, added component attribute to handle RTCP candidates and allowed multiple child elements. (psa) Diff: http://is.gd/4r1W URL: http://www.xmpp.org/extensions/xep-0177.html
[Standards] poll: element in XEP-0080 (User Location)
If you have implemented XEP-0080, I would like to hear from you regarding support for the element in your code. Currently this element is defined in terms of arc minutes instead of meters, and I'm wondering if anyone's code supports these rather arcane units for location offsets. Thanks! Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] XEP-0174: Serverless Messaging interactions with XEP-0115 Entity Capabilities
Alban Crequy wrote: > Le Tue, 14 Oct 2008 10:33:20 -0600, > Peter Saint-Andre <[EMAIL PROTECTED]> a écrit : > >> Alban Crequy wrote: >>> Hi, >>> >>> To start a link-local conversation with XEP-0174 between two >>> clients, any of the 2 clients can initiate the stream. If the 2 >>> contacts start to chat at the same time, we may have 2 streams >>> initiated in both directions. It seems this case does not happen >>> often because users usually don't start to chat precisely at the >>> same time. >>> >>> You suggested that having several streams between 2 clients was not >>> a problem: >>> >>> Le Thu, 14 Aug 2008 10:51:06 -0600, >>> Peter Saint-Andre <[EMAIL PROTECTED]> a écrit : Alban Crequy wrote: > If we want the XEP to say there can be only one stream between two > clients, we should define the correct behaviour when two clients > initiate a TCP connection to each other at the same time. Do we > want one connection to win and the second to be closed? I don't think we need to restrict clients to one stream at a time. >>> However, if the 2 clients both implement XEP-030 Service Discovery >>> and XEP-0115 Entity Capabilities, they will both initiate a stream >>> in order to send a discovery request as soon as they appear online >>> via DNS-SD, without user intervention. >> Really? I thought we were advertising caps in DNS TXT. See the "ver" >> record here: >> >> http://xmpp.org/extensions/xep-0174.html#registrar-linklocal-reg > > Indeed, we know the "ver" record without opening a stream. But the > "ver" record is not enough to know all the caps. > >> So I think that opening a stream to everyone who appears online via >> DNS-SD is a bad idea. >> >> Thus I would say that if you know the "ver", you'll know what the >> other entity is. But if you don't know the "ver", don't automatically >> open a stream to the other entity just to do all the caps lookup >> magic via disco. > > I need to know all the contact capabilities in Telepathy, even if there > is no open stream. If an application want to display a contact chooser > to start a VNC session, a game, or whatever on top of XMPP, I need to > know which contacts are able to do VNC or a specific game. > > I implemented an automatic caps lookup via disco in telepathy-salut > (the XEP-0174 implementation in the Telepathy framework). It opens a > stream only if a "ver" TXT record is advertised *and* if the "ver" > record is not already known. Right, I see the need for that. But it's unfortunate. Still thinking... Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] XEP-0174: Serverless Messaging interactions with XEP-0115 Entity Capabilities
Le Tue, 14 Oct 2008 10:33:20 -0600, Peter Saint-Andre <[EMAIL PROTECTED]> a écrit : > Alban Crequy wrote: > > Hi, > > > > To start a link-local conversation with XEP-0174 between two > > clients, any of the 2 clients can initiate the stream. If the 2 > > contacts start to chat at the same time, we may have 2 streams > > initiated in both directions. It seems this case does not happen > > often because users usually don't start to chat precisely at the > > same time. > > > > You suggested that having several streams between 2 clients was not > > a problem: > > > > Le Thu, 14 Aug 2008 10:51:06 -0600, > > Peter Saint-Andre <[EMAIL PROTECTED]> a écrit : > >> Alban Crequy wrote: > >>> If we want the XEP to say there can be only one stream between two > >>> clients, we should define the correct behaviour when two clients > >>> initiate a TCP connection to each other at the same time. Do we > >>> want one connection to win and the second to be closed? > >> I don't think we need to restrict clients to one stream at a time. > > > > However, if the 2 clients both implement XEP-030 Service Discovery > > and XEP-0115 Entity Capabilities, they will both initiate a stream > > in order to send a discovery request as soon as they appear online > > via DNS-SD, without user intervention. > > Really? I thought we were advertising caps in DNS TXT. See the "ver" > record here: > > http://xmpp.org/extensions/xep-0174.html#registrar-linklocal-reg Indeed, we know the "ver" record without opening a stream. But the "ver" record is not enough to know all the caps. > So I think that opening a stream to everyone who appears online via > DNS-SD is a bad idea. > > Thus I would say that if you know the "ver", you'll know what the > other entity is. But if you don't know the "ver", don't automatically > open a stream to the other entity just to do all the caps lookup > magic via disco. I need to know all the contact capabilities in Telepathy, even if there is no open stream. If an application want to display a contact chooser to start a VNC session, a game, or whatever on top of XMPP, I need to know which contacts are able to do VNC or a specific game. I implemented an automatic caps lookup via disco in telepathy-salut (the XEP-0174 implementation in the Telepathy framework). It opens a stream only if a "ver" TXT record is advertised *and* if the "ver" record is not already known. -- Alban
Re: [Standards] XEP-0174: TXT record format
Justin Karneges wrote: > On Monday 20 October 2008 09:06:44 Peter Saint-Andre wrote: >> If I'm right, this is a fairly serious spec bug. > > You're right, it is one TXT record, not many. I didn't notice this in the > XEP > because I don't really understand that text-based DNS record notation. > > Fortunately, it's doubtful anyone implemented this wrongly, since iChat would > always be tested against. Right. The power of a reference implementation. :) I'll fix this in the spec. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] XEP-0174: TXT record format
On Monday 20 October 2008 09:06:44 Peter Saint-Andre wrote: > If I'm right, this is a fairly serious spec bug. You're right, it is one TXT record, not many. I didn't notice this in the XEP because I don't really understand that text-based DNS record notation. Fortunately, it's doubtful anyone implemented this wrongly, since iChat would always be tested against. -Justin
Re: [Standards] XEP-0174: TXT record format
Kevin Smith wrote: >> If I'm right, this is a fairly serious spec bug. > > Are people doing this in the wild? Not sure. I'm checking with some implementers about this... /psa
Re: [Standards] XEP-0174: TXT record format
> If I'm right, this is a fairly serious spec bug. Are people doing this in the wild? /K
Re: [Standards] "connected" and "available" resources
Fabio Forno wrote: > Hi everybody, > > accordingly to rfc3921 connected resources are resources that have > established a binding, and they become available after sending the > first presence stanza. > > Section 11.1 tells: > * Else if the JID is of the form <[EMAIL PROTECTED]/resource> and no > available resource matches the full JID, the recipient's server (a) > SHOULD silently ignore the stanza (i.e., neither deliver it nor > return an error) if it is a presence stanza, (b) MUST return a > stanza error to the sender if it is an IQ > stanza, and (c) SHOULD treat the stanza as if it were addressed to > <[EMAIL PROTECTED]> if it is a message stanza. > > This seems that if a resource is connected and not online, that > resource can't receive any xmpp stanza from other entities, unless it > goes fully online. However server implementations behave slightly > different (e.g. ejabberd seems to deliver anything if the resource is > correct), and clients ask the roster (or send other iqs to the server) > before going online, which should not work if the above rules are > strictly enforced. > > I think that we should better define this point. My position is that > we should explicitily allow the delivery of any packets if the > resource belongs to a connected user, even if not online. In this way > clients could perform some queries to well known services before > going online, thus eliminating one of the few useful cases for > invisibility I think that's a spec bug: s/available/connected/ Peter -- Peter Saint-Andre https://stpeter.im/
[Standards] XEP-0174: TXT record format
While reviewing draft-cheshire-dnsext-dns-sd this morning, I think I found a serious error in the documentation for the _presence._tcp service, as defined in XEP-0174: http://xmpp.org/extensions/xep-0174.html XEP-0174 says that a compliant client publishes *multiple* TXT records, one for each parameter (e.g., one record for txtvers, one for 1st name, one for email address, and so on). However, draft-cheshire-dnsext-dns-sd says that an entity publishes *one* TXT with multiple key-value pairs, where the name of the TXT record is the same as the name of the SRV record and the value of the TXT record is a binary object that contains one or more strings, where each string is (usually) a key-value pair and the strings are separated by a single length byte that specifies the length of the key-value pair. So currently XEP-0174 says that in our hypothetical example the client would publish the following TXT records: juliet IN TXT "txtvers=1" juliet IN TXT "1st=Juliet" juliet IN TXT "[EMAIL PROTECTED]" juliet IN TXT "hash=sha-1" juliet IN TXT "[EMAIL PROTECTED]" juliet IN TXT "last=Capulet" juliet IN TXT "msg=Hanging out downtown" juliet IN TXT "nick=JuliC" juliet IN TXT "node=http://www.adiumx.com"; juliet IN TXT "phsh=a3839614e1a382bcfebbcf20464f519e81770813" juliet IN TXT "port.p2pj=5562" juliet IN TXT "status=avail" juliet IN TXT "vc=CA!" juliet IN TXT "ver=66/0NaeaBKkwk85efJTGmU47vXI=" However, if I'm reading draft-cheshire-dnsext-dns-sd correctly then it seems that the client would publish a single TXT record, as follows (line breaks provided for readability). [EMAIL PROTECTED] TXT " 0x09txtvers=1 0x101st=Juliet [EMAIL PROTECTED] 0x10hash=sha-1 [EMAIL PROTECTED] 0x12last=Capulet 0x12msg=Hanging out downtown 0x10nick=JuliC 0x26node=http://www.adiumx.com 0x45phsh=a3839614e1a382bcfebbcf20464f519e81770813 0x14port.p2pj=5562 0x12status=avail 0x06vc=CA! 0x33ver=66/0NaeaBKkwk85efJTGmU47vXI\= " If I'm right, this is a fairly serious spec bug. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] well-formedness
On Mon Oct 20 04:40:56 2008, Waqas wrote: On Tue, Oct 14, 2008 at 3:28 AM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > "an entity SHOULD be liberal in accepting such data." This translates to: "an entity SHOULD NOT use a namespace-validating parser (as defined in [XML-NAMES])" No, I disagree, it translates as "an entity SHOULD NOT use a parser that produces an unrecoverable fatal error on an undeclared namespace prefix". I disagree that's the same thing at all. This is indeed the case. Entities in the XMPP world tend not to use namespace aware parsers. Um, wait... In fact most do not care about namespaces at all (aside from a few specific cases where the XEPs use a namespace prefix in the examples, the implementations are often coded to look for that prefix). ... because... Testing with ejabberd and gajim (quite a popular combination), it was quickly clear that both did not deal with valid s where a prefix was used, and both did deal with s with a namespace other than jabber:client. ... Gajim was using, and still does use, a namespace aware parser. All implementations must be namespace non-aware if they don't wish to have the disconnection bug that gajim had. I would like to argue that it was not a bug at all. And Gajim is most certainly namespace aware. Please, review the code and tell me where it doesn't conform to XML-NAMES. There are a few cases in it's higher layers where it ignores the namespace, and switches only based on the local-name of the element - this is, indeed, an error, but it's one that has nothing at all to do with this. The fact that these existed when the namespace handling in Expat was used somewhat defeats your argument. The behavior when a server receives a badly-namespaced stanza needs to be clarified. I have been working with Matthew Wild on a not-yet-released server. We are wondering whether we should discard the stanza, the element, or raise a stream error. After all, there really is no reason that any (non-malicious) entity should be sending invalid namespaces. If they do then it is a bug, just the same as if they sent invalid XML. Wrong. It's impossible, in the current infrastructure, to receive invalid XML except via a error in the entity you're actually connected to. If you receive invalid XML, there is no way to handle it in any useful manner. If you receive invalid XMLNS, however, it might have come from anywhere, and merely been forwarded on to you. ANd there's at least three ways of handling it. a) Assume that undeclared prefixes are bound to an arbitrary "unknown" namespace. (This is what Gajim does, now). From there, process the stanza as much as is possible, which might include doing nothing at all, or rejecting it with , just as with any other unrecognized namespace. b) Detect unbound namespaces as a special case, and bounce the stanza. c) Emit a stream error. This is what Gajim did previously, and what you're recommending everyone does. Just discarding it has a problem. Someone could send a message with invalid namespaces to a conference.jabber.org room. Everyone (human) would see that, except entities which care about namespaces. From the protocol's perspective this would be "correct", but not from a normal user's perspective. And this will have exactly the same effect with any of the above solutions, unless one is mandated. And the interesting thing is if a server passes through - as existing servers do, essentially doing (a) - and the clients all do (c). Because then, sending invalid XMLNS via a chat room kicks out all the users, and this doesn't seem to be appreciated. Sorry if this sounds like a rant. I just don't like where we are headed. I don't like where we are. I don't like where some people want us to go, because they seem to want to send us off into a fantasy land, where servers are redeployed in seconds. 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
