Re: [Standards] well-formedness
Brendan Taylor wrote: > On Wed, Oct 15, 2008 at 06:11:56AM -0600, Peter Saint-Andre wrote: >> Brendan Taylor wrote: >>> I just noticed this clause: >>> >>> ... but MUST NOT return a stream error in response to the receipt >>> of [Bad XMLNS]. >>> >>> Why is that there? Silently dropping the stanza seems like a bad idea. >>> It also requires servers to be able to handle Bad XMLNS, which is a step >>> backward from where we are now. >> That is the nub of the issue being discussed here. :) > > Even if we're not willing to require servers to be draconian about Bad > XMLNS, the ones that are draconian about it should return the same kind > of error that they would have for Bad XML. > > I don't see any reason to say that they MUST NOT return a stream error. In draft-saintandre-rfc3920bis-08, Section 12.3 *currently* reads: *** 12.3. Well-Formedness There are two varieties of well-formedness: o "XML-well-formedness" in accordance with the definition of "well- formed" in Section 2.1 of [XML]. o "Namespace-well-formedness" in accordance with the definition of "namespace-well-formed" in Section 7 of [XML-NAMES]. The following rules apply. An XMPP entity MUST NOT generate data that is not XML-well-formed. An XMPP entity MUST NOT accept data that is not XML-well-formed; instead it MUST return an stream error and close the stream over which the data was received. An XMPP entity MUST NOT generate data that is not namespace-well- formed. An XMPP server SHOULD NOT route or deliver data that is not namespace-well-formed, and SHOULD return a stanza error of or a stream error of in response to the receipt of such data. 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. *** Further feedback is welcome. /psa
Re: [Standards] PDF versions of the specifications
Nicolas Roussel <[EMAIL PROTECTED]> writes: > Is anyone else interested in PDF documentation? I am. I have been thinking about writing a stylesheet for generating Texinfo from XEPs, which would give both PDF and Info output, the latter being especially interesting for Emacs users. Who knows, I might actually do it some day :) -- Magnus JID: [EMAIL PROTECTED]
Re: [Standards] well-formedness
On Wed, Oct 15, 2008 at 06:11:56AM -0600, Peter Saint-Andre wrote: > Brendan Taylor wrote: > > I just noticed this clause: > > > > ... but MUST NOT return a stream error in response to the receipt > > of [Bad XMLNS]. > > > > Why is that there? Silently dropping the stanza seems like a bad idea. > > It also requires servers to be able to handle Bad XMLNS, which is a step > > backward from where we are now. > > That is the nub of the issue being discussed here. :) Even if we're not willing to require servers to be draconian about Bad XMLNS, the ones that are draconian about it should return the same kind of error that they would have for Bad XML. I don't see any reason to say that they MUST NOT return a stream error. pgpuR8Tpjeuou.pgp Description: PGP signature
Re: [Standards] [Fwd: [jdev] How to handle SRV lookups when the root domain is referenced]
Jacek Konieczny wrote: > On Thu, Oct 16, 2008 at 01:08:09PM -0600, Peter Saint-Andre wrote: >> I did a bit of research on this. I propose the following text >> (specifically the parenthetical clause): >> >>The result of the SRV lookup will be one or more combinations of >>a port and hostname, which hostnames the initiating entity MUST >>resolve according to returned SRV record weight (if the result of >>the SRV lookup is a single RR with a Target of ".", i.e. the root >>domain, the initiating entity MUST abort SRV processing but >>SHOULD attempt a fallback resolution as described below). > > IMHO giving up the domain is a better choice. AFAIR SRV target of "." > is supposed to say "no such service at this address". > When a domain has only an A record, that any service may be running there. If > we do not want XMPP servers to poke the XMPP port and we have no XMPP server > for that domain how do we do that? Using SRV record pointing to "." seems > right to me and if I publish it I don't want the servers still try to use the > A record. > > And RFC2782 clearly says: > > A Target of "." means that the service is decidedly not > available at this domain. > > So, if we know the service is "decidely not available" then IMHO means that we > MUST NOT attempt to contact the service anyway. You may be right about RFC 3920, because there you're trying to connect only to an XMPP service. In RFC 3921 we talk about falling back to a service of _im._HOST or _pres._HOST, so you would not abort the entire process if you find a Target of "." for _xmpp-server. However, this aspect of SRV lookups seems to be a bit obscure -- some of the information I found in mailing list archives and such indicates that a Target of "." means "stop SRV processing for this particular service at this domain, but don't necessarily stop other DNS processing". What is the harm of trying the non-SRV-based fallbacks if the SRV record points to the root domain? In particular it might be helpful to try the alternative connection methods from XEP-0156 (e.g., a domain might not provide a service for _xmpp-client but it might offer a BOSH service instead). Perhaps it is more appropriate to change SHOULD to MAY here, but I don't want to say that you MUST NOT attempt other lookups because that seems overly restrictive. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] [Fwd: [jdev] How to handle SRV lookups when the root domain is referenced]
On Thu, Oct 16, 2008 at 01:08:09PM -0600, Peter Saint-Andre wrote: > I did a bit of research on this. I propose the following text > (specifically the parenthetical clause): > >The result of the SRV lookup will be one or more combinations of >a port and hostname, which hostnames the initiating entity MUST >resolve according to returned SRV record weight (if the result of >the SRV lookup is a single RR with a Target of ".", i.e. the root >domain, the initiating entity MUST abort SRV processing but >SHOULD attempt a fallback resolution as described below). IMHO giving up the domain is a better choice. AFAIR SRV target of "." is supposed to say "no such service at this address". When a domain has only an A record, that any service may be running there. If we do not want XMPP servers to poke the XMPP port and we have no XMPP server for that domain how do we do that? Using SRV record pointing to "." seems right to me and if I publish it I don't want the servers still try to use the A record. And RFC2782 clearly says: A Target of "." means that the service is decidedly not available at this domain. So, if we know the service is "decidely not available" then IMHO means that we MUST NOT attempt to contact the service anyway. Greets, Jacek
