Extensible Messaging and Presence Protocol (XMPP) - Core PDF

5/17/2016
ExtensibleMessagingandPresenceProtocol(XMPP):Core
InternetEngineeringTaskForce(IETF)
P.SaintAndre
RequestforComments:6120
Cisco
RFC
6120
Obsoletes:3920
March2011
TOC
Category:StandardsTrack
ISSN:20701721
ExtensibleMessagingandPresenceProtocol
(XMPP):Core
Abstract
TheExtensibleMessagingandPresenceProtocol(XMPP)isanapplicationprofileof
theExtensibleMarkupLanguage(XML)thatenablesthenearrealtimeexchangeof
structuredyetextensibledatabetweenanytwoormorenetworkentities.This
documentdefinesXMPP'scoreprotocolmethods:setupandteardownofXML
streams,channelencryption,authentication,errorhandling,andcommunication
primitivesformessaging,networkavailability("presence"),andrequestresponse
interactions.ThisdocumentobsoletesRFC3920.
StatusofThisMemo
ThisisanInternetStandardsTrackdocument.
ThisdocumentisaproductoftheInternetEngineeringTaskForce(IETF).It
representstheconsensusoftheIETFcommunity.Ithasreceivedpublicreviewand
hasbeenapprovedforpublicationbytheInternetEngineeringSteeringGroup
(IESG).FurtherinformationonInternetStandardsisavailableinSection2ofRFC
5741.
Informationaboutthecurrentstatusofthisdocument,anyerrata,andhowto
providefeedbackonitmaybeobtainedathttp://www.rfceditor.org/info/rfc6120.
CopyrightNotice
Copyright(c)2011IETFTrustandthepersonsidentifiedasthedocumentauthors.
Allrightsreserved.
ThisdocumentissubjecttoBCP78andtheIETFTrust'sLegalProvisionsRelatingto
IETFDocuments(http://trustee.ietf.org/licenseinfo)ineffectonthedateof
publicationofthisdocument.Pleasereviewthesedocumentscarefully,asthey
describeyourrightsandrestrictionswithrespecttothisdocument.Code
ComponentsextractedfromthisdocumentmustincludeSimplifiedBSDLicensetext
asdescribedinSection4.eoftheTrustLegalProvisionsandareprovidedwithout
warrantyasdescribedintheSimplifiedBSDLicense.
TableofContents
1.Introduction
1.1.Overview
1.2.History
1.3.FunctionalSummary
1.4.Terminology
2.Architecture
2.1.GlobalAddresses
2.2.Presence
http://xmpp.org/rfcs/rfc6120.html
RFC
6120
TOC
1/164
5/17/2016
2.3.PersistentStreams
2.4.StructuredData
2.5.DistributedNetworkofClientsandServers
3.TCPBinding
3.1.Scope
3.2.ResolutionofFullyQualifiedDomainNames
3.2.1.PreferredProcess:SRVLookup
3.2.2.FallbackProcesses
3.2.3.WhenNottoUseSRV
3.2.4.UseofSRVRecordswithAddOnServices
3.3.Reconnection
3.4.Reliability
4.XMLStreams
4.1.StreamFundamentals
4.2.OpeningaStream
4.3.StreamNegotiation
4.3.1.BasicConcepts
4.3.2.StreamFeaturesFormat
4.3.3.Restarts
4.3.4.ResendingFeatures
4.3.5.CompletionofStreamNegotiation
4.3.6.DeterminationofAddresses
4.3.7.FlowChart
4.4.ClosingaStream
4.5.Directionality
4.6.HandlingofSilentPeers
4.6.1.DeadConnection
4.6.2.BrokenStream
4.6.3.IdlePeer
4.6.4.UseofCheckingMethods
4.7.StreamAttributes
4.7.1.from
4.7.2.to
4.7.3.id
4.7.4.xml:lang
4.7.5.version
4.7.6.SummaryofStreamAttributes
4.8.XMLNamespaces
4.8.1.StreamNamespace
4.8.2.ContentNamespace
4.8.3.XMPPContentNamespaces
4.8.4.OtherNamespaces
4.8.5.NamespaceDeclarationsandPrefixes
4.9.StreamErrors
4.9.1.Rules
4.9.1.1.StreamErrorsAreUnrecoverable
4.9.1.2.StreamErrorsCanOccurDuringSetup
4.9.1.3.StreamErrorsWhentheHostIsUnspecifiedorUnknown
4.9.1.4.WhereStreamErrorsAreSent
4.9.2.Syntax
4.9.3.DefinedStreamErrorConditions
4.9.3.1.badformat
4.9.3.2.badnamespaceprefix
4.9.3.3.conflict
4.9.3.4.connectiontimeout
4.9.3.5.hostgone
4.9.3.6.hostunknown
4.9.3.7.improperaddressing
4.9.3.8.internalservererror
4.9.3.9.invalidfrom
4.9.3.10.invalidnamespace
2/164
5/17/2016
4.9.3.11.invalidxml
4.9.3.12.notauthorized
4.9.3.13.notwellformed
4.9.3.14.policyviolation
4.9.3.15.remoteconnectionfailed
4.9.3.16.reset
4.9.3.17.resourceconstraint
4.9.3.18.restrictedxml
4.9.3.19.seeotherhost
4.9.3.20.systemshutdown
4.9.3.21.undefinedcondition
4.9.3.22.unsupportedencoding
4.9.3.23.unsupportedfeature
4.9.3.24.unsupportedstanzatype
4.9.3.25.unsupportedversion
4.9.4.ApplicationSpecificConditions
4.10.SimplifiedStreamExamples
5.STARTTLSNegotiation
5.1.Fundamentals
5.2.Support
5.3.StreamNegotiationRules
5.3.1.MandatorytoNegotiate
5.3.2.Restart
5.3.3.DataFormatting
5.3.4.OrderofTLSandSASLNegotiations
5.3.5.TLSRenegotiation
5.3.6.TLSExtensions
5.4.Process
5.4.1.ExchangeofStreamHeadersandStreamFeatures
5.4.2.InitiationofSTARTTLSNegotiation
5.4.2.1.STARTTLSCommand
5.4.2.2.FailureCase
5.4.2.3.ProceedCase
5.4.3.TLSNegotiation
5.4.3.1.Rules
5.4.3.2.TLSFailure
5.4.3.3.TLSSuccess
6.SASLNegotiation
6.1.Fundamentals
6.2.Support
6.3.2.Restart
6.3.3.MechanismPreferences
6.3.4.MechanismOffers
6.3.6.SecurityLayers
6.3.7.SimpleUserName
6.3.8.AuthorizationIdentity
6.3.9.Realms
6.3.10.RoundTrips
6.4.Process
6.4.2.Initiation
6.4.3.ChallengeResponseSequence
6.4.4.Abort
6.4.5.SASLFailure
6.4.6.SASLSuccess
6.5.SASLErrors
6.5.1.aborted
6.5.2.accountdisabled
3/164
5/17/2016
6.5.3.credentialsexpired
6.5.4.encryptionrequired
6.5.5.incorrectencoding
6.5.6.invalidauthzid
6.5.7.invalidmechanism
6.5.8.malformedrequest
6.5.9.mechanismtooweak
6.5.10.notauthorized
6.5.11.temporaryauthfailure
6.6.SASLDefinition
7.ResourceBinding
7.1.Fundamentals
7.2.Support
7.3.2.Restart
7.4.AdvertisingSupport
7.5.GenerationofResourceIdentifiers
7.6.ServerGeneratedResourceIdentifier
7.6.1.SuccessCase
7.6.2.ErrorCases
7.6.2.1.ResourceConstraint
7.6.2.2.NotAllowed
7.7.ClientSubmittedResourceIdentifier
7.7.1.SuccessCase
7.7.2.ErrorCases
7.7.2.1.BadRequest
7.7.2.2.Conflict
7.7.3.Retries
8.XMLStanzas
8.1.CommonAttributes
8.1.1.to
8.1.1.1.ClienttoServerStreams
8.1.1.2.ServertoServerStreams
8.1.2.from
8.1.3.id
8.1.4.type
8.1.5.xml:lang
8.2.BasicSemantics
8.2.1.MessageSemantics
8.2.2.PresenceSemantics
8.2.3.IQSemantics
8.3.StanzaErrors
8.3.1.Rules
8.3.2.Syntax
8.3.3.DefinedConditions
8.3.3.1.badrequest
8.3.3.2.conflict
8.3.3.3.featurenotimplemented
8.3.3.4.forbidden
8.3.3.5.gone
8.3.3.7.itemnotfound
8.3.3.8.jidmalformed
8.3.3.9.notacceptable
8.3.3.10.notallowed
8.3.3.13.recipientunavailable
4/164
5/17/2016
8.3.3.14.redirect
8.3.3.15.registrationrequired
8.3.3.16.remoteservernotfound
8.3.3.17.remoteservertimeout
8.3.3.19.serviceunavailable
8.3.3.20.subscriptionrequired
8.3.3.22.unexpectedrequest
8.4.ExtendedContent
9.DetailedExamples
9.1.ClienttoServerExamples
9.1.1.TLS
9.1.2.SASL
9.1.3.ResourceBinding
9.1.4.StanzaExchange
9.1.5.Close
9.2.ServertoServerExamples
9.2.1.TLS
9.2.2.SASL
9.2.4.Close
10.ServerRulesforProcessingXMLStanzas
10.1.InOrderProcessing
10.2.GeneralConsiderations
10.3.No'to'Address
10.3.1.Message
10.3.2.Presence
10.3.3.IQ
10.4.RemoteDomain
10.4.1.ExistingStream
10.4.2.NoExistingStream
10.4.3.ErrorHandling
10.5.LocalDomain
10.5.1.domainpart
10.5.2.domainpart/resourcepart
10.5.3.localpart@domainpart
10.5.3.1.NoSuchUser
10.5.3.2.UserExists
10.5.4.localpart@domainpart/resourcepart
11.XMLUsage
11.1.XMLRestrictions
11.2.XMLNamespaceNamesandPrefixes
11.3.WellFormedness
11.4.Validation
11.5.InclusionofXMLDeclaration
11.6.CharacterEncoding
11.7.Whitespace
11.8.XMLVersions
12.InternationalizationConsiderations
13.SecurityConsiderations
13.1.Fundamentals
13.2.ThreatModel
13.3.OrderofLayers
13.4.ConfidentialityandIntegrity
13.5.PeerEntityAuthentication
13.6.StrongSecurity
13.7.Certificates
13.7.1.CertificateGeneration
13.7.1.1.GeneralConsiderations
5/164
5/17/2016
13.7.1.2.ServerCertificates
13.7.1.3.ClientCertificates
13.7.1.4.XmppAddrIdentifierType
13.7.2.CertificateValidation
13.7.2.3.CheckingofCertificatesinLongLivedStreams
13.7.2.4.UseofCertificatesinXMPPExtensions
13.8.MandatorytoImplementTLSandSASLTechnologies
13.8.1.ForAuthenticationOnly
13.8.2.ForConfidentialityOnly
13.8.3.ForConfidentialityandAuthenticationwithPasswords
13.8.4.ForConfidentialityandAuthenticationwithoutPasswords
13.9.TechnologyReuse
13.9.1.UseofBase64inSASL
13.9.2.UseofDNS
13.9.3.UseofHashFunctions
13.9.4.UseofSASL
13.9.5.UseofTLS
13.9.6.UseofUTF8
13.9.7.UseofXML
13.10.InformationLeaks
13.10.1.IPAddresses
13.10.2.PresenceInformation
13.11.DirectoryHarvesting
13.12.DenialofService
13.13.Firewalls
13.14.InterdomainFederation
13.15.NonRepudiation
14.IANAConsiderations
14.1.XMLNamespaceNameforTLSData
14.2.XMLNamespaceNameforSASLData
14.3.XMLNamespaceNameforStreamErrors
14.4.XMLNamespaceNameforResourceBinding
14.5.XMLNamespaceNameforStanzaErrors
14.6.GSSAPIServiceName
14.7.PortNumbersandServiceNames
15.ConformanceRequirements
16.References
16.1.NormativeReferences
16.2.InformativeReferences
AppendixA.XMLSchemas
A.1.StreamNamespace
A.2.StreamErrorNamespace
A.3.STARTTLSNamespace
A.4.SASLNamespace
A.5.ClientNamespace
A.6.ServerNamespace
A.7.ResourceBindingNamespace
A.8.StanzaErrorNamespace
AppendixB.ContactAddresses
AppendixC.AccountProvisioning
AppendixD.DifferencesfromRFC3920
AppendixE.Acknowledgements
1.Introduction
TOC
6/164
5/17/2016
1.1.Overview
TOC
TheExtensibleMessagingandPresenceProtocol(XMPP)isanapplicationprofileof
theExtensibleMarkupLanguage [XML]thatenablesthenearrealtimeexchangeof
structuredyetextensibledatabetweenanytwoormorenetworkentities.This
documentdefinesXMPP'scoreprotocolmethods:setupandteardownofXML
streams,channelencryption,authentication,errorhandling,andcommunication
primitivesformessaging,networkavailability("presence"),andrequestresponse
interactions.
TOC
1.2.History
ThebasicsyntaxandsemanticsofXMPPweredevelopedoriginallywithinthe
Jabberopensourcecommunity,mainlyin1999.Inlate2002,theXMPPWorking
GroupwascharteredwithdevelopinganadaptationofthebaseJabberprotocolthat
wouldbesuitableasanIETFinstantmessaging(IM)andpresencetechnologyin
accordancewith [IMPREQS].InOctober2004, [RFC3920]and [RFC3921]were
published,representingthemostcompletedefinitionofXMPPatthattime.
Since2004theInternetcommunityhasgainedextensiveimplementationand
deploymentexperiencewithXMPP,includingformalinteroperabilitytestingcarried
outundertheauspicesoftheXMPPStandardsFoundation(XSF).Thisdocument
incorporatescomprehensivefeedbackfromsoftwaredevelopersandXMPPservice
providers,includinganumberofbackwardcompatiblemodificationssummarized
under AppendixD.Asaresult,thisdocumentreflectstheroughconsensusofthe
InternetcommunityregardingthecorefeaturesofXMPP1.0,thusobsoletingRFC
3920.
1.3.FunctionalSummary
TOC
Thisnonnormativesectionprovidesadeveloperfriendly,functionalsummaryof
XMPPrefertothesectionsthatfollowforanormativedefinitionofXMPP.
ThepurposeofXMPPistoenabletheexchangeofrelativelysmallpiecesof
structureddata(called"XMLstanzas")overanetworkbetweenanytwo(ormore)
entities.XMPPistypicallyimplementedusingadistributedclientserver
architecture,whereinaclientneedstoconnecttoaserverinordertogainaccess
tothenetworkandthusbeallowedtoexchangeXMLstanzaswithotherentities
(whichcanbeassociatedwithotherservers).Theprocesswherebyaclient
connectstoaserver,exchangesXMLstanzas,andendstheconnectionis:
1.DeterminetheIPaddressandportatwhichtoconnect,typicallybased
onresolutionofafullyqualifieddomainname(Section3.2)
2.OpenaTransmissionControlProtocol [TCP]connection
3.OpenanXMLstreamoverTCP(Section4.2)
4.PreferablynegotiateTransportLayerSecurity [TLS]forchannel
encryption(Section5)
5.AuthenticateusingaSimpleAuthenticationandSecurityLayer [SASL]
mechanism(Section6)
6.Bindaresourcetothestream(Section7)
7.ExchangeanunboundednumberofXMLstanzaswithotherentitieson
thenetwork(Section8)
8.ClosetheXMLstream(Section4.4)
9.ClosetheTCPconnection
7/164
5/17/2016
WithinXMPP,oneservercanoptionallyconnecttoanotherservertoenableinter
domainorinterservercommunication.Forthistohappen,thetwoserversneedto
negotiateaconnectionbetweenthemselvesandthenexchangeXMLstanzasthe
processfordoingsois:
1.DeterminetheIPaddressandportatwhichtoconnect,typicallybased
onresolutionofafullyqualifieddomainname(Section3.2)
2.OpenaTCPconnection
3.OpenanXMLstream(Section4.2)
4.PreferablynegotiateTLSforchannelencryption(Section5)
5.AuthenticateusingaSimpleAuthenticationandSecurityLayer [SASL]
mechanism(Section6)*
6.ExchangeanunboundednumberofXMLstanzasbothdirectlyforthe
serversandindirectlyonbehalfofentitiesassociatedwitheachserver,
suchasconnectedclients(Section8)
7.ClosetheXMLstream(Section4.4)
8.ClosetheTCPconnection
*InteroperabilityNote:Atthetimeofwriting,mostdeployedservers
stillusetheServerDialbackprotocol [XEP0220]toprovideweak
identityverificationinsteadofusingSASLwithPKIXcertificatesto
providestrongauthentication,especiallyincaseswhereSASL
negotiationwouldnotresultinstrongauthenticationanyway(e.g.,
becauseTLSnegotiationwasnotmandatedbythepeerserver,or
becausethePKIXcertificatepresentedbythepeerserverduringTLS
negotiationisselfsignedandhasnotbeenpreviouslyaccepted)for
details,see [XEP0220].Thesolutionsspecifiedinthisdocumentoffer
asignificantlystrongerlevelofsecurity(seealso Section13.6).
Thisdocumentspecifieshowclientsconnecttoserversandspecifiesthebasic
semanticsofXMLstanzas.However,thisdocumentdoesnotdefinethe"payloads"
oftheXMLstanzasthatmightbeexchangedonceaconnectionissuccessfully
establishedinstead,thosepayloadsaredefinedbyvariousXMPPextensions.For
example, [XMPPIM]definesextensionsforbasicinstantmessagingandpresence
functionality.Inaddition,variousspecificationsproducedintheXSF'sXEPseries
[XEP0001]defineextensionsforawiderangeofapplications.
1.4.Terminology
TOC
Thekeywords"MUST","MUSTNOT","REQUIRED","SHALL","SHALLNOT",
"SHOULD","SHOULDNOT","RECOMMENDED","NOTRECOMMENDED","MAY",and
"OPTIONAL"inthisdocumentaretobeinterpretedasdescribedinRFC2119
[KEYWORDS].
Certainsecurityrelatedtermsaretobeunderstoodinthesensedefinedin
[SECTERMS]suchtermsinclude,butarenotlimitedto,"assurance","attack",
"authentication","authorization","certificate","certificationauthority","certification
path","confidentiality","credential","downgrade","encryption","hashvalue",
"identity","integrity","signature","selfsignedcertificate","sign","spoof",
"tamper","trust","trustanchor","validate",and"verify".
Certaintermsrelatedtocertificates,domains,andapplicationserviceidentityare
tobeunderstoodinthesensedefinedin [TLSCERTS]theseinclude,butarenot
limitedto,"PKIXcertificate","sourcedomain","deriveddomain",andtheidentifier
types"CNID","DNSID",and"SRVID".
Othersecurityrelatedtermsaretobeunderstoodinthesensedefinedinthe
referencedspecifications(forexample,"denialofservice"asdescribedin [DOS]or
8/164
5/17/2016
"endentitycertificate"asdescribedin [PKIX]).
Theterm"whitespace"isusedtorefertoanycharacterorcharactersmatchingthe
"S"productionfrom [XML],i.e.,oneormoreinstancesoftheSP,HTAB,CR,orLF
rulesdefinedin [ABNF].
Theterms"localpart","domainpart",and"resourcepart"aredefinedin
[XMPPADDR].
Theterm"bareJID"referstoanXMPPaddressoftheform
<localpart@domainpart>(foranaccountataserver)oroftheform<domainpart>
(foraserver).
Theterm"fullJID"referstoanXMPPaddressoftheform
<localpart@domainpart/resourcepart>(foraparticularauthorizedclientordevice
associatedwithanaccount)oroftheform<domainpart/resourcepart>(fora
particularresourceorscriptassociatedwithaserver).
Theterm"XMLstream"(also"stream")isdefinedunder Section4.1.
Theterm"XMLstanza"(also"stanza")isdefinedunder Section4.1.Thereare
threekindsofstanzas:message,presence,andIQ(shortfor"Info/Query").These
communicationprimitivesaredefinedunderSections 8.2.1, 8.2.2,and 8.2.3,
respectively.
Theterm"originatingentity"referstotheentitythatfirstgeneratesastanzathatis
sentoveranXMPPnetwork(e.g.,aconnectedclient,anaddonservice,ora
server).Theterm"generatedstanza"referstothestanzasogenerated.
Theterm"inputstream"designatesanXMLstreamoverwhichaserverreceives
datafromaconnectedclientorremoteserver,andtheterm"outputstream"
designatesanXMLstreamoverwhichaserversendsdatatoaconnectedclientor
remoteserver.Thefollowingtermsdesignatesomeoftheactionsthataservercan
performwhenprocessingdatareceivedoveraninputstream:
route:
passthedatatoaremoteserverfordirectprocessingbythe
remoteserveroreventualdeliverytoaclientassociatedwith
theremoteserver
deliver:
passthedatatoaconnectedclient
ignore:
discardthedatawithoutactinguponitorreturninganerrorto
thesender
Whentheterm"ignore"isusedwithregardtoclientprocessingofdataitreceives,
thephrase"withoutactinguponit"explicitlyincludesnotpresentingthedatatoa
humanuser.
Followingthe"XMLNotation"usedin [IRI]torepresentcharactersthatcannotbe
renderedinASCIIonlydocuments,someexamplesinthisdocumentusetheform
"&#x...."asanotationaldevicetorepresent [UNICODE]characters(e.g.,the
string"&#x0159"standsfortheUnicodecharacterLATINSMALLLETTERRWITH
CARON)thisformisdefinitelynottobesentoverthewireinXMPPsystems.
Consistentwiththeconventionusedin [URI]torepresentUniformResource
Identifiers,XMPPaddressesinrunningtextareenclosedbetween'<'and'>'
(althoughnativelytheyarenotURIs).
Inexamples,lineshavebeenwrappedforimprovedreadability,"[...]"means
elision,andthefollowingprependedstringsareused(theseprependedstringsare
nottobesentoverthewire):
9/164
5/17/2016
C:=aclient
E:=anyXMPPentity
I:=aninitiatingentity
P:=apeerserver
R:=areceivingentity
S:=aserver
S1:=server1
S2:=server2
Readersneedtobeawarethattheexamplesarenotexhaustiveandthat,in
examplesforsomeprotocolflows,thealternatestepsshownwouldnotnecessarily
betriggeredbytheexactdatasentinthepreviousstepinallcasestheprotocol
definitionsspecifiedinthisdocumentorinnormativelyreferenceddocumentsrule
overanyexamplesprovidedhere.Allexamplesarefictionalandtheinformation
exchanged(e.g.,usernamesandpasswords)doesnotrepresentanyexistingusers
orservers.
2.Architecture
TOC
XMPPprovidesatechnologyfortheasynchronous,endtoendexchangeof
structureddatabymeansofdirect,persistentXMLstreamsamongadistributed
networkofgloballyaddressable,presenceawareclientsandservers.Becausethis
architecturalstyleinvolvesubiquitousknowledgeofnetworkavailabilityanda
conceptuallyunlimitednumberofconcurrentinformationtransactionsinthecontext
ofagivenclienttoserverorservertoserversession,welabelit"Availabilityfor
ConcurrentTransactions"(ACT)todistinguishitfromthe"RepresentationalState
Transfer" [REST]architecturalstylefamiliarfromtheWorldWideWeb.Although
thearchitectureofXMPPissimilarinimportantwaystothatofemail(see
[EMAILARCH]),itintroducesseveralmodificationstofacilitatecommunicationin
closetorealtime.ThesalientfeaturesofthisACTivearchitecturalstyleareas
follows.
2.1.GlobalAddresses
TOC
Aswithemail,XMPPusesgloballyuniqueaddresses(basedontheDomainName
System)inordertorouteanddelivermessagesoverthenetwork.AllXMPPentities
areaddressableonthenetwork,mostparticularlyclientsandserversbutalso
variousadditionalservicesthatcanbeaccessedbyclientsandservers.Ingeneral,
serveraddressesareoftheform<domainpart>(e.g.,<im.example.com>),
accountshostedataserverareoftheform<localpart@domainpart>(e.g.,
<juliet@im.example.com>,calleda"bareJID"),andaparticularconnecteddevice
orresourcethatiscurrentlyauthorizedforinteractiononbehalfofanaccountisof
theform<localpart@domainpart/resourcepart>(e.g.,
<juliet@im.example.com/balcony>,calleda"fullJID").Forhistoricalreasons,XMPP
addressesareoftencalledJabberIDsorJIDs.Becausetheformalspecificationof
theXMPPaddressformatdependsoninternationalizationtechnologiesthatarein
fluxatthetimeofwriting,theformatisdefinedin [XMPPADDR]insteadofthis
document.Theterms"localpart","domainpart",and"resourcepart"aredefined
moreformallyin [XMPPADDR].
2.2.Presence
TOC
XMPPincludestheabilityforanentitytoadvertiseitsnetworkavailabilityor
10/164
5/17/2016
"presence"tootherentities.InXMPP,thisavailabilityforcommunicationissignaled
endtoendbymeansofadedicatedcommunicationprimitive:the<presence/>
stanza.Althoughknowledgeofnetworkavailabilityisnotstrictlynecessaryforthe
exchangeofXMPPmessages,itfacilitatesrealtimeinteractionbecausethe
originatorofamessagecanknowbeforeinitiatingcommunicationthattheintended
recipientisonlineandavailable.Endtoendpresenceisdefinedin [XMPPIM].
TOC
2.3.PersistentStreams
Availabilityforcommunicationisalsobuiltintoeachpointtopoint"hop"through
theuseofpersistentXMLstreamsoverlonglivedTCPconnections.These"always
on"clienttoserverandservertoserverstreamsenableeachpartytopushdatato
theotherpartyatanytimeforimmediateroutingordelivery.XMLstreamsare
definedunder Section4.
TOC
2.4.StructuredData
ThebasicprotocoldataunitinXMPPisnotanXMLstream(whichsimplyprovides
thetransportforpointtopointcommunication)butanXML"stanza",whichis
essentiallyafragmentofXMLthatissentoverastream.Therootelementofa
stanzaincludesroutingattributes(suchas"from"and"to"addresses),andthechild
elementsofthestanzacontainapayloadfordeliverytotheintendedrecipient.XML
stanzasaredefinedunder Section8.
2.5.DistributedNetworkofClientsandServers
TOC
Inpractice,XMPPconsistsofanetworkofclientsandserversthatinter
communicate(however,communicationbetweenanytwogivendeployedserversis
strictlydiscretionaryandamatteroflocalservicepolicy).Thus,forexample,the
user<juliet@im.example.com>associatedwiththeserver<im.example.com>
mightbeabletoexchangemessages,presence,andotherstructureddatawiththe
user<romeo@example.net>associatedwiththeserver<example.net>.This
patternisfamiliarfrommessagingprotocolsthatmakeuseofglobaladdresses,
suchastheemailnetwork(see [SMTP]and [EMAILARCH]).Asaresult,endto
endcommunicationinXMPPislogicallypeertopeerbutphysicallyclienttoserver
toservertoclient,asillustratedinthefollowingdiagram.
example.net<>im.example.com
^^
||
vv
romeo@example.netjuliet@im.example.com
Figure1:DistributedClientServerArchitecture
InformationalNote:Architecturesthatemploy XMLstreamsand XML

stanzasbutthatestablishpeertopeerconnectionsdirectlybetween
clientsusingtechnologiesbasedon [LINKLOCAL]havebeendeployed,
butsucharchitecturesarenotdefinedinthisspecificationandarebest
11/164
5/17/2016
describedas"XMPPlike"fordetails,see [XEP0174].Inaddition,XML
streamscanbeestablishedendtoendoveranyreliabletransport,
includingextensionstoXMPPitselfhowever,suchmethodsareoutof
scopeforthisspecification.
Thefollowingparagraphsdescribetheresponsibilitiesofclientsandserversonthe
network.
AclientisanentitythatestablishesanXMLstreamwithaserverbyauthenticating
usingthecredentialsofaregisteredaccount(via SASLnegotiation)andthatthen
completes resourcebindinginordertoenabledeliveryofXMLstanzasbetween
theserverandtheclientoverthenegotiatedstream.TheclientthenusesXMPPto
communicatewithitsserver,otherclients,andanyotherentitiesonthenetwork,
wheretheserverisresponsiblefordeliveringstanzastootherconnectedclientsat
thesameserverorroutingthemtoremoteservers.Multipleclientscanconnect
simultaneouslytoaserveronbehalfofthesameregisteredaccount,whereeach
clientisdifferentiatedbytheresourcepartofanXMPPaddress(e.g.,
<juliet@im.example.com/balcony>vs.<juliet@im.example.com/chamber>),as
definedunder [XMPPADDR]and Section7.
Aserverisanentitywhoseprimaryresponsibilitiesareto:
Manage XMLstreamswithconnectedclientsanddeliver XMLstanzas
tothoseclientsoverthenegotiatedstreamsthisincludesresponsibility
forensuringthataclientauthenticateswiththeserverbeforebeing
grantedaccesstotheXMPPnetwork.
Subjecttolocalservicepoliciesonservertoservercommunication,
manage XMLstreamswithremoteserversandroute XMLstanzasto
thoseserversoverthenegotiatedstreams.
Dependingontheapplication,thesecondaryresponsibilitiesofanXMPPservercan
include:
Storingdatathatisusedbyclients(e.g.,contactlistsforusersof
XMPPbasedinstantmessagingandpresenceapplicationsasdefinedin
[XMPPIM])inthiscase,therelevantXMLstanzaishandleddirectly
bytheserveritselfonbehalfoftheclientandisnotroutedtoaremote
serverordeliveredtoaconnectedclient.
HostingaddonservicesthatalsouseXMPPasthebasisfor
communicationbutthatprovideadditionalfunctionalitybeyondthat
definedinthisdocumentorin [XMPPIM]examplesincludemultiuser
conferencingservicesasspecifiedin [XEP0045]andpublishsubscribe
servicesasspecifiedin [XEP0060].
3.TCPBinding
3.1.Scope
TOC
TOC
AsXMPPisdefinedinthisspecification,aninitiatingentity(clientorserver)MUST
openaTransmissionControlProtocol [TCP]connectiontothereceivingentity
(server)beforeitnegotiatesXMLstreamswiththereceivingentity.Thepartiesthen
maintainthatTCPconnectionforaslongastheXMLstreamsareinuse.Therules
specifiedinthefollowingsectionsapplytotheTCPbinding.
InformationalNote:ThereisnonecessarycouplingofXMLstreamsto
TCP,andothertransportsarepossible.Forexample,twoentitiescould
12/164
5/17/2016
connecttoeachotherbymeansof [HTTP]asspecifiedin [XEP0124]

and [XEP0206].However,thisspecificationdefinesonlyabindingof
XMPPtoTCP.
3.2.ResolutionofFullyQualifiedDomainNames
TOC
BecauseXMLstreamsaresentoverTCP,theinitiatingentityneedstodeterminethe
IPv4orIPv6address(andport)ofthereceivingentitybeforeitcanattempttoopen
anXMLstream.Typicallythisisdonebyresolvingthereceivingentity'sfully
qualifieddomainnameorFQDN(see [DNSCONCEPTS]).
3.2.1.PreferredProcess:SRVLookup
TOC
ThepreferredprocessforFQDNresolutionistouse [DNSSRV]recordsasfollows:
1.TheinitiatingentityconstructsaDNSSRVquerywhoseinputsare:
aServiceof"xmppclient"(forclienttoserver
connections)or"xmppserver"(forservertoserver
connections)
aProtoof"tcp"
aNamecorrespondingtothe"origindomain"
[TLSCERTS]oftheXMPPservicetowhichthe
initiatingentitywishestoconnect(e.g.,
"example.net"or"im.example.com")
2.Theresultisaquerysuchas"_xmppclient._tcp.example.net."or
"_xmppserver._tcp.im.example.com.".
3.Ifaresponseisreceived,itwillcontainoneormorecombinationsofa
portandFDQN,eachofwhichisweightedandprioritizedasdescribedin
[DNSSRV].(However,iftheresultoftheSRVlookupisasingle
resourcerecordwithaTargetof".",i.e.,therootdomain,thenthe
initiatingentityMUSTabortSRVprocessingatthispointbecause
accordingto [DNSSRV]suchaTarget"meansthattheserviceis
decidedlynotavailableatthisdomain".)
4.TheinitiatingentitychoosesatleastoneofthereturnedFQDNsto
resolve(followingtherulesin [DNSSRV]),whichitdoesbyperforming
DNS"A"or"AAAA"lookupsontheFDQNthiswillresultinanIPv4or
IPv6address.
5.TheinitiatingentityusestheIPaddress(es)fromthesuccessfully
resolvedFDQN(withthecorrespondingportnumberreturnedbythe
SRVlookup)astheconnectionaddressforthereceivingentity.
6.IftheinitiatingentityfailstoconnectusingthatIPaddressbutthe"A"
or"AAAA"lookupsreturnedmorethanoneIPaddress,thenthe
initiatingentityusesthenextresolvedIPaddressforthatFDQNasthe
connectionaddress.
7.IftheinitiatingentityfailstoconnectusingallresolvedIPaddressesfor
agivenFDQN,thenitrepeatstheprocessofresolutionandconnection
forthenextFQDNreturnedbytheSRVlookupbasedonthepriorityand
weightasdefinedin [DNSSRV].
8.IftheinitiatingentityreceivesaresponsetoitsSRVquerybutitisnot
abletoestablishanXMPPconnectionusingthedatareceivedinthe
response,itSHOULDNOTattemptthefallbackprocessdescribedinthe
nextsection(thishelpstopreventastatemismatchbetweeninbound
andoutboundconnections).
9.IftheinitiatingentitydoesnotreceivearesponsetoitsSRVquery,it
13/164
5/17/2016
SHOULDattemptthefallbackprocessdescribedinthenextsection.
3.2.2.FallbackProcesses
TOC
ThefallbackprocessSHOULDbeanormal"A"or"AAAA"addressrecordresolution
todeterminetheIPv4orIPv6addressoftheorigindomain,wheretheportusedis
the"xmppclient"portof5222forclienttoserverconnectionsorthe"xmppserver"
portof5269forservertoserverconnections(thesearethedefaultportsas
registeredwiththeIANAasdescribedunder Section14.7).
IfconnectionsviaTCPareunsuccessful,theinitiatingentitymightattempttofind
andusealternativeconnectionmethodssuchastheHTTPbinding(see [XEP0124]
and [XEP0206]),whichmightbediscoveredusing [DNSTXT]recordsas
describedin [XEP0156].
3.2.3.WhenNottoUseSRV
TOC
IftheinitiatingentityhasbeenexplicitlyconfiguredtoassociateaparticularFQDN
(andpotentiallyport)withtheorigindomainofthereceivingentity(say,to
"hardcode"anassociationfromanorigindomainofexample.nettoaconfigured
FQDNofapps.example.com),theinitiatingentityisencouragedtousethe
configurednameinsteadofperformingthepreferredSRVresolutionprocessonthe
origindomain.
3.2.4.UseofSRVRecordswithAddOnServices
TOC
ManyXMPPserversareimplementedinsuchawaythattheycanhostaddon
services(beyondthosedefinedinthisspecificationand [XMPPIM])atDNSdomain
namesthattypicallyare"subdomains"ofthemainXMPPservice(e.g.,
conference.example.netfora [XEP0045]serviceassociatedwiththeexample.net
XMPPservice)or"subdomains"ofthefirstleveldomainoftheunderlyingservice
(e.g.,muc.example.comfora [XEP0045]serviceassociatedwiththe
im.example.comXMPPservice).IfanentityassociatedwitharemoteXMPPserver
wishestocommunicatewithsuchanaddonservice,itwouldgeneratean
appropriateXMLstanzaandtheremoteserverwouldattempttoresolvetheaddon
service'sDNSdomainnameviaanSRVlookuponresourcerecordssuchas
"_xmppserver._tcp.conference.example.net."or"_xmpp
server._tcp.muc.example.com.".Therefore,iftheadministratorsofanXMPPservice
wishtoenableentitiesassociatedwithremoteserverstoaccesssuchaddon
services,theyneedtoadvertisetheappropriate"_xmppserver"SRVrecordsin
additiontothe"_xmppserver"recordfortheirmainXMPPservice.IncaseSRV
recordsarenotavailable,thefallbackmethodsdescribedunder Section3.2.2can
beusedtoresolvetheDNSdomainnamesofaddonservices.
3.3.Reconnection
TOC
ItcanhappenthatanXMPPservergoesofflineunexpectedlywhileservicingTCP
connectionsfromconnectedclientsandremoteservers.Becausethenumberof
suchconnectionscanbequitelarge,thereconnectionalgorithmemployedby
entitiesthatseektoreconnectcanhaveasignificantimpactonsoftware
14/164
5/17/2016
performanceandnetworkcongestion.Ifanentitychoosestoreconnect,it:
SHOULDsetthenumberofsecondsthatexpirebeforereconnectingto
anunpredictablenumberbetween0and60(thishelpstoensurethat
notallentitiesattempttoreconnectatexactlythesamenumberof
secondsafterbeingdisconnected).
SHOULDbackoffincreasinglyonthetimebetweensubsequent
reconnectionattempts(e.g.,inaccordancewith"truncatedbinary
exponentialbackoff"asdescribedin [ETHERNET])ifthefirst
reconnectionattemptdoesnotsucceed.
ItisRECOMMENDEDtomakeuseofTLSsessionresumption [TLSRESUME]when
reconnecting.Afutureversionofthisdocument,oraseparatespecification,might
providemoredetailedguidelinesregardingmethodsforspeedingthereconnection
process.
3.4.Reliability
TOC
TheuseoflonglivedTCPconnectionsinXMPPimpliesthatthesendingofXML
stanzasoverXMLstreamscanbeunreliable,sincethepartiestoalonglivedTCP
connectionmightnotdiscoveraconnectivitydisruptioninatimelymanner.Atthe
XMPPapplicationlayer,longconnectivitydisruptionscanresultinundelivered
stanzas.AlthoughthecoreXMPPtechnologydefinedinthisspecificationdoesnot
containfeaturestoovercomethislackofreliability,thereexistXMPPextensionsfor
doingso(e.g., [XEP0198]).
4.XMLStreams
4.1.StreamFundamentals
TOC
TOC
Twofundamentalconceptsmakepossibletherapid,asynchronousexchangeof
relativelysmallpayloadsofstructuredinformationbetweenXMPPentities:XML
streamsandXMLstanzas.Thesetermsaredefinedasfollows.
DefinitionofXMLStream:
AnXMLstreamisacontainerfortheexchangeofXMLelementsbetween
anytwoentitiesoveranetwork.ThestartofanXMLstreamisdenoted
unambiguouslybyanopening"streamheader"(i.e.,anXML<stream>
tagwithappropriateattributesandnamespacedeclarations),whilethe
endoftheXMLstreamisdenotedunambiguouslybyaclosingXML
</stream>tag.Duringthelifeofthestream,theentitythatinitiatedit
cansendanunboundednumberofXMLelementsoverthestream,either
elementsusedtonegotiatethestream(e.g.,tocomplete TLS
negotiationor SASLnegotiation)orXMLstanzas.The"initialstream"is
negotiatedfromtheinitiatingentity(typicallyaclientorserver)tothe
receivingentity(typicallyaserver),andcanbeseenascorrespondingto
theinitiatingentity's"connectionto"or"sessionwith"thereceivingentity.
Theinitialstreamenablesunidirectionalcommunicationfromtheinitiating
entitytothereceivingentityinordertoenableexchangeofstanzasfrom
thereceivingentitytotheinitiatingentity,thereceivingentityMUST
negotiateastreamintheoppositedirection(the"responsestream").
DefinitionofXMLStanza:
AnXMLstanzaisthebasicunitofmeaninginXMPP.Astanzaisafirst
levelelement(atdepth=1ofthestream)whoseelementnameis
15/164
5/17/2016
"message","presence",or"iq"andwhosequalifyingnamespaceis
'jabber:client'or'jabber:server'.Bycontrast,afirstlevelelement
qualifiedbyanyothernamespaceisnotanXMLstanza(streamerrors,
streamfeatures,TLSrelatedelements,SASLrelatedelements,etc.),nor
isa<message/>,<presence/>,or<iq/>elementthatisqualifiedbythe
'jabber:client'or'jabber:server'namespacebutthatoccursatadepth
otherthanone(e.g.,a<message/>elementcontainedwithinan
extensionelement(Section8.4)forreportingpurposes),norisa
<message/>,<presence/>,or<iq/>elementthatisqualifiedbya
namespaceotherthan'jabber:client'or'jabber:server'.AnXMLstanza
typicallycontainsoneormorechildelements(withaccompanying
attributes,elements,andXMLcharacterdata)asnecessaryinorderto
conveythedesiredinformation,whichMAYbequalifiedbyanyXML
namespace(see [XMLNAMES]aswellas Section8.4inthis
specification).
Therearethreekindsofstanzas:message,presence,andIQ(shortfor
"Info/Query").Thesestanzatypesprovidethreedifferentcommunicationprimitives:
a"push"mechanismforgeneralizedmessaging,aspecialized"publishsubscribe"
mechanismforbroadcastinginformationaboutnetworkavailability,anda"request
response"mechanismformorestructuredexchangesofdata(similarto [HTTP]).
FurtherexplanationsareprovidedunderSections 8.2.1, 8.2.2,and 8.2.3,
respectively.
Considertheexampleofaclient'sconnectiontoaserver.TheclientinitiatesanXML
streambysendingastreamheadertotheserver,preferablyprecededbyanXML
declarationspecifyingtheXMLversionandthecharacterencodingsupported(see
Section11.5and Section11.6).Subjecttolocalpoliciesandserviceprovisioning,
theserverthenreplieswithasecondXMLstreambacktotheclient,again
preferablyprecededbyanXMLdeclaration.Oncetheclienthascompleted SASL
negotiationand resourcebinding,theclientcansendanunboundednumberof
XMLstanzasoverthestream.Whentheclientdesirestoclosethestream,itsimply
sendsaclosing</stream>tagtotheserverasfurtherdescribedunder
Section4.4.
Inessence,then,oneXMLstreamfunctionsasanenvelopefortheXMLstanzassent
duringasessionandanotherXMLstreamfunctionsasanenvelopefortheXML
stanzasreceivedduringasession.Wecanrepresentthisinasimplisticfashionas
follows.
+++
|INITIALSTREAM|RESPONSESTREAM|
+++
|<stream>||
|||
||<stream>|
|||
|<presence>||
|<show/>||
|</presence>||
|||
|<messageto='foo'>||
|<body/>||
|</message>||
|||
|<iqto='bar'||
|type='get'>||
|<query/>||
16/164
5/17/2016
|</iq>||
|||
||<iqfrom='bar'|
||type='result'>|
||<query/>|
||</iq>|
|||
|[...]||
|||
||[...]|
|||
|</stream>||
|||
||</stream>|
+++
Figure2:ASimplisticViewofTwoStreams
ThosewhoareaccustomedtothinkingofXMLinadocumentcentricmannermight
findthefollowinganalogiesuseful:
ThetwoXMLstreamsareliketwo"documents"(matchingthe
"document"productionfrom [XML])thatarebuiltupthroughthe
accumulationofXMLstanzas.
Theroot<stream/>elementislikethe"documententity"foreach
"document"(asdescribedinSection4.8of [XML]).
TheXMLstanzassentoverthestreamsarelike"fragments"ofthe
"documents"(asdescribedin [XMLFRAG]).
However,thesedescriptionsaremerelyanalogies,becauseXMPPdoesnotdealin
documentsandfragmentsbutinstreamsandstanzas.
TheremainderofthissectiondefinesthefollowingaspectsofXMLstreams(along
withrelatedtopics):
Howtoopenastream(Section4.2)
Thestreamnegotiationprocess(Section4.3)
Howtocloseastream(Section4.4)
ThedirectionalityofXMLstreams(Section4.5)
Howtohandlepeersthataresilent(Section4.6)
TheXMLattributesofastream(Section4.7)
TheXMLnamespacesofastream(Section4.8)
ErrorhandlingrelatedtoXMLstreams(Section4.9)
4.2.OpeningaStream
TOC
AfterconnectingtotheappropriateIPaddressandportofthereceivingentity,the
initiatingentityopensastreambysendingastreamheader(the"initialstream
header")tothereceivingentity.
I:<?xmlversion='1.0'?>
<stream:stream
from='juliet@im.example.com'
to='im.example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
17/164
5/17/2016
Thereceivingentitythenrepliesbysendingastreamheaderofitsown(the
"responsestreamheader")totheinitiatingentity.
R:<?xmlversion='1.0'?>
<stream:stream
from='im.example.com'
id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
to='juliet@im.example.com'
version='1.0'
xml:lang='en'
Theentitiescanthenproceedwiththeremainderofthestreamnegotiationprocess.
4.3.StreamNegotiation
4.3.1.BasicConcepts
TOC
TOC
Becausethereceivingentityforastreamactsasagatekeepertothedomainsit
services,itimposescertainconditionsforconnectingasaclientorasapeer
server.Ataminimum,theinitiatingentityneedstoauthenticatewiththereceiving
entitybeforeitisallowedtosendstanzastothereceivingentity(forclientto
serverstreamsthismeansusingSASLasdescribedunder Section6).However,the
receivingentitycanconsiderconditionsotherthanauthenticationtobemandatory
tonegotiate,suchasencryptionusingTLSasdescribedunder Section5.The
receivingentityinformstheinitiatingentityaboutsuchconditionsbycommunicating
"streamfeatures":thesetofparticularprotocolinteractionsthattheinitiatingentity
needstocompletebeforethereceivingentitywillacceptXMLstanzasfromthe
initiatingentity,aswellasanyprotocolinteractionsthatarevoluntarytonegotiate
butthatmightimprovethehandlingofanXMLstream(e.g.,establishmentof
applicationlayercompressionasdescribedin [XEP0138]).
Theexistenceofconditionsforconnectingimpliesthatstreamsneedtobe
negotiated.Theorderoflayers(TCP,thenTLS,thenSASL,thenXMPPasdescribed
under Section13.3)impliesthatstreamnegotiationisamultistageprocess.
Furtherstructureisimposedbytwofactors:(1)agivenstreamfeaturemightbe
offeredonlytocertainentitiesoronlyaftercertainotherfeatureshavebeen
negotiated(e.g.,resourcebindingisofferedonlyafterSASLauthentication),and(2)
streamfeaturescanbeeithermandatorytonegotiateorvoluntarytonegotiate.
Finally,forsecurityreasonsthepartiestoastreamneedtodiscardknowledgethat
theygainedduringthenegotiationprocessaftersuccessfullycompletingthe
protocolinteractionsdefinedforcertainfeatures(e.g.,TLSinallcasesandSASLin
thecasewhenasecuritylayermightbeestablished,asdefinedinthespecification
fortherelevantSASLmechanism).Thisisdonebyflushingtheoldstreamcontext
andexchangingnewstreamheadersovertheexistingTCPconnection.
4.3.2.StreamFeaturesFormat
TOC
Iftheinitiatingentityincludesintheinitialstreamheaderthe'version'attributeset
18/164
5/17/2016
toavalueofatleast"1.0"(see Section4.7.5),aftersendingtheresponsestream
headerthereceivingentityMUSTsenda<features/>childelement(typically
prefixedbythestreamnamespaceprefixasdescribedunder Section4.8.5)tothe
initiatingentityinordertoannounceanyconditionsforcontinuationofthestream
negotiationprocess.Eachconditiontakestheformofachildelementofthe
<features/>element,qualifiedbyanamespacethatisdifferentfromthestream
namespaceandthecontentnamespace.The<features/>elementcancontainone
child,containmultiplechildren,orbeempty.
ImplementationNote:Theorderofchildelementscontainedinany
given<features/>elementisnotsignificant.
Ifaparticularstreamfeatureisorcanbemandatorytonegotiate,thedefinitionof
thatfeatureneedstodooneofthefollowing:
1.Declarethatthefeatureisalwaysmandatorytonegotiate(e.g.,thisis
trueofresourcebindingforXMPPclients)or
2.Specifyawayforthereceivingentitytoflagthefeatureasmandatory
tonegotiateforthisinteraction(e.g.,forSTARTTLS,thisisdoneby
includinganempty<required/>elementintheadvertisementforthat
streamfeature,butthatisnotagenericformatforallstreamfeatures)
itisRECOMMENDEDthatstreamfeaturedefinitionsfornewmandatory
tonegotiatefeaturesdosobyincludinganempty<required/>element
asisdoneforSTARTTLS.
InformationalNote:Becausethereisnogenericformatforindicating
thatafeatureismandatorytonegotiate,itispossiblethatafeature
thatisnotunderstoodbytheinitiatingentitymightbeconsidered
mandatorytonegotiatebythereceivingentity,resultinginfailureof
thestreamnegotiationprocess.Althoughsuchanoutcomewouldbe
undesirable,theworkinggroupdeemeditrareenoughthatageneric
formatwasnotneeded.
Forsecurityreasons,certainstreamfeaturesnecessitatetheinitiatingentityto
sendanewinitialstreamheaderuponsuccessfulnegotiationofthefeature(e.g.,
TLSinallcasesandSASLinthecasewhenasecuritylayermightbeestablished).
Ifthisistrueofagivenstreamfeature,thedefinitionofthatfeatureneedsto
specifythatastreamrestartisexpectedafternegotiationofthefeature.
A<features/>elementthatcontainsatleastonemandatorytonegotiatefeature
indicatesthatthestreamnegotiationisnotcompleteandthattheinitiatingentity
MUSTnegotiatefurtherfeatures.
R:<stream:features>
<starttlsxmlns='urn:ietf:params:xml:ns:xmpptls'>
<required/>
</starttls>
</stream:features>
A<features/>elementMAYcontainmorethanonemandatorytonegotiatefeature.
Thismeansthattheinitiatingentitycanchooseamongthemandatorytonegotiate
featuresatthisstageofthestreamnegotiationprocess.Asanexample,perhapsa
futuretechnologywillperformroughlythesamefunctionasTLS,sothereceiving
entitymightadvertisesupportforbothTLSandthefuturetechnologyatthesame
stageofthestreamnegotiationprocess.However,thisappliesonlyatagivenstage
ofthestreamnegotiationprocessanddoesnotapplytofeaturesthatare
mandatorytonegotiateatdifferentstages(e.g.,thereceivingentitywouldnot
advertisebothSTARTTLSandSASLasmandatorytonegotiate,orbothSASLand
resourcebindingasmandatorytonegotiate,becauseTLSwouldneedtobe
negotiatedbeforeSASLandbecauseSASLwouldneedtobenegotiatedbefore
19/164
5/17/2016
resourcebinding).
A<features/>elementthatcontainsbothmandatorytonegotiateandvoluntaryto
negotiatefeaturesindicatesthatthenegotiationisnotcompletebutthatthe
initiatingentityMAYcompletethevoluntarytonegotiatefeature(s)beforeit
attemptstonegotiatethemandatorytonegotiatefeature(s).
R:<stream:features>
<bindxmlns='urn:ietf:params:xml:ns:xmppbind'/>
<compressionxmlns='http://jabber.org/features/compress'>
<method>zlib</method>
<method>lzw</method>
</compression>
</stream:features>
A<features/>elementthatcontainsonlyvoluntarytonegotiatefeaturesindicates
thatthestreamnegotiationiscompleteandthattheinitiatingentityisclearedto
sendXMLstanzas,butthattheinitiatingentityMAYnegotiatefurtherfeaturesif
desired.
R:<stream:features>
<compressionxmlns='http://jabber.org/features/compress'>
<method>zlib</method>
<method>lzw</method>
</compression>
</stream:features>
Anempty<features/>elementindicatesthatthestreamnegotiationiscomplete
andthattheinitiatingentityisclearedtosendXMLstanzas.
R:<stream:features/>
4.3.3.Restarts
TOC
Onsuccessfulnegotiationofafeaturethatnecessitatesastreamrestart,both
partiesMUSTconsiderthepreviousstreamtobereplacedbutMUSTNOTsenda
closing</stream>tagandMUSTNOTterminatetheunderlyingTCPconnection
instead,thepartiesMUSTreusetheexistingconnection,whichmightbeinanew
state(e.g.,encryptedasaresultofTLSnegotiation).Theinitiatingentitythen
MUSTsendanewinitialstreamheader,whichSHOULDbeprecededbyanXML
declarationasdescribedunder Section11.5.Whenthereceivingentityreceives
thenewinitialstreamheader,itMUSTgenerateanewstreamID(insteadof
reusingtheoldstreamID)beforesendinganewresponsestreamheader(which
SHOULDbeprecededbyanXMLdeclarationasdescribedunder Section11.5).
4.3.4.ResendingFeatures
TOC
ThereceivingentityMUSTsendanupdatedlistofstreamfeaturestotheinitiating
entityafterastreamrestart.ThelistofupdatedfeaturesMAYbeemptyifthereare
nofurtherfeaturestobeadvertisedorMAYincludeanycombinationoffeatures.
20/164
5/17/2016
4.3.5.CompletionofStreamNegotiation
TOC
Thereceivingentityindicatescompletionofthestreamnegotiationprocessby
sendingtotheinitiatingentityeitheranempty<features/>elementora
<features/>elementthatcontainsonlyvoluntarytonegotiatefeatures.Afterdoing
so,thereceivingentityMAYsendanempty<features/>element(e.g.,after
negotiationofsuchvoluntarytonegotiatefeatures)butMUSTNOTsendadditional
streamfeaturestotheinitiatingentity(ifthereceivingentityhasnewfeaturesto
offer,preferablylimitedtomandatorytonegotiateorsecuritycriticalfeatures,it
cansimplyclosethestreamwitha<reset/>streamerror(Section4.9.3.16)and
thenadvertisethenewfeatureswhentheinitiatingentityreconnects,preferably
closingexistingstreamsinastaggeredwaysothatnotalloftheinitiatingentities
reconnectatonce).Oncestreamnegotiationiscomplete,theinitiatingentityis
clearedtosendXMLstanzasoverthestreamforaslongasthestreamis
maintainedbybothparties.
InformationalNote:Resourcebindingasspecifiedunder Section7isan
historicalexceptiontotheforegoingrule,sinceitismandatoryto
negotiateforclientsbutusesXMLstanzasfornegotiationpurposes.
TheinitiatingentityMUSTNOTattempttosend XMLstanzastoentitiesotherthan
itself(i.e.,theclient'sconnectedresourceoranyotherauthenticatedresourceof
theclient'saccount)ortheservertowhichitisconnecteduntilstreamnegotiation
hasbeencompleted.Eveniftheinitiatingentitydoesattempttodoso,the
receivingentityMUSTNOTacceptsuchstanzasandMUSTclosethestreamwitha
<notauthorized/>streamerror(Section4.9.3.12).ThisruleappliestoXML
stanzasonly(i.e.,<message/>,<presence/>,and<iq/>elementsqualifiedbythe
contentnamespace)andnottoXMLelementsusedforstreamnegotiation(e.g.,
elementsusedtocomplete TLSnegotiationor SASLnegotiation).
4.3.6.DeterminationofAddresses
TOC
AfterthepartiestoanXMLstreamhavecompletedtheappropriateaspectsof
streamnegotiation,thereceivingentityforastreamMUSTdeterminetheinitiating
entity'sJID.
Forclienttoservercommunication,both SASLnegotiationand resourcebinding
MUSTbecompletedbeforetheservercandeterminetheclient'saddress.The
client'sbareJID(<localpart@domainpart>)MUSTbetheauthorizationidentity(as
definedby [SASL]),either(1)asdirectlycommunicatedbytheclientduring SASL
negotiationor(2)asderivedbytheserverfromtheauthenticationidentityifno
authorizationidentitywasspecifiedduringSASLnegotiation.Theresourcepartof
thefullJID(<localpart@domainpart/resourcepart>)MUSTbetheresource
negotiatedbytheclientandserverduring resourcebinding.AclientMUSTNOT
attempttoguessatitsJIDbutinsteadMUSTconsideritsJIDtobewhateverthe
serverreturnstoitduringresourcebinding.TheserverMUSTensurethatthe
resultingJID(includinglocalpart,domainpart,resourcepart,andseparator
characters)conformstothecanonicalformatforXMPPaddressesdefinedin
[XMPPADDR]tomeetthisrestriction,theserverMAYreplacetheJIDsentbythe
clientwiththecanonicalizedJIDasdeterminedbytheserverandcommunicatethat
JIDtotheclientduringresourcebinding.
Forservertoservercommunication,theinitiatingserver'sbareJID
(<domainpart>)MUSTbetheauthorizationidentity(asdefinedby [SASL]),either
(1)asdirectlycommunicatedbytheinitiatingserverduring SASLnegotiationor
(2)asderivedbythereceivingserverfromtheauthenticationidentityifno
authorizationidentitywasspecifiedduringSASLnegotiation.IntheabsenceofSASL
negotiation,thereceivingserverMAYconsidertheauthorizationidentitytobean
21/164
5/17/2016
identitynegotiatedwithintherelevantverificationprotocol(e.g.,the'from'attribute
ofthe<result/>elementinServerDialback [XEP0220]).
SecurityWarning:Becauseitispossibleforathirdpartytotamperwith
informationthatissentoverthestreambeforeasecuritylayersuchas
TLSissuccessfullynegotiated,itisadvisableforthereceivingserverto
treatanysuchunprotectedinformationwithcautionthisapplies
especiallytothe'from'and'to'addressesonthefirstinitialstream
headersentbytheinitiatingentity.
4.3.7.FlowChart
TOC
Wesummarizetheforegoingrulesinthefollowingnonnormativeflowchartforthe
streamnegotiationprocess,presentedfromtheperspectiveoftheinitiatingentity.
++
|openTCPconnection|
++
|
v
++
|sendinitial|<+
|streamheader|^
++|
||
v|
++|
|receiveresponse||
|streamheader||
++|
||
v|
++|
|receivestream||
+>|features||
^{OPTIONAL}++|
|||
|v|
|+<+|
|||
|{empty?}>{allvoluntary?}>{somemandatory?}|
||no|no||
||yes|yes|yes|
||vv|
||++++|
|||MAYnegotiate||MUSTnegotiate||
|||anyornone||onefeature||
||++++|
|v|||
|++v||
||DONE|<{negotiate?}||
|++no|||
|yes|||
|vv|
|+>+<+|
|||
22/164
5/17/2016
|v|
+<{restartmandatory?}>+
noyes
Figure3:StreamNegotiationFlowChart
4.4.ClosingaStream
TOC
AnXMLstreamfromoneentitytoanothercanbeclosedatanytime,either
becauseaspecificstreamerror(Section4.9)hasoccurredorintheabsenceofan
error(e.g.,whenaclientsimplyendsitssession).
Astreamisclosedbysendingaclosing</stream>tag.
E:</stream:stream>
IfthepartiesareusingeithertwostreamsoverasingleTCPconnectionortwo
streamsovertwoTCPconnections,theentitythatsendstheclosingstreamtag
MUSTbehaveasfollows:
1.Waitfortheotherpartytoalsocloseitsoutboundstreambefore
terminatingtheunderlyingTCPconnection(s)thisgivestheotherparty
anopportunitytofinishtransmittinganyoutbounddatatotheclosing
entitybeforetheterminationoftheTCPconnection(s).
2.Refrainfromsendinganyfurtherdataoveritsoutboundstreamtothe
otherentity,butcontinuetoprocessdatareceivedfromtheotherentity
(and,ifnecessary,processsuchdata).
3.Considerbothstreamstobevoidiftheotherpartydoesnotsendits
closingstreamtagwithinareasonableamountoftime(wherethe
definitionof"reasonable"isamatterofimplementationordeployment).
4.Afterreceivingareciprocalclosingstreamtagfromtheotherpartyor
waitingareasonableamountoftimewithnoresponse,terminatethe
underlyingTCPconnection(s).
SecurityWarning:InaccordancewithSection7.2.1of [TLS],tohelp
preventatruncationattackthepartythatisclosingthestreamMUST
sendaTLSclose_notifyalertandMUSTreceivearesponding
close_notifyalertfromtheotherpartybeforeterminatingthe
underlyingTCPconnection(s).
IfthepartiesareusingmultiplestreamsovermultipleTCPconnections,thereisno
definedpairingofstreamsandthereforethebehaviorisamatterfor
implementation.
4.5.Directionality
TOC
AnXMLstreamisalwaysunidirectional,bywhichismeantthatXMLstanzascanbe
sentinonlyonedirectionoverthestream(eitherfromtheinitiatingentitytothe
receivingentityorfromthereceivingentitytotheinitiatingentity).
Dependingonthetypeofsessionthathasbeennegotiatedandthenatureofthe
entitiesinvolved,theentitiesmightuse:
TwostreamsoverasingleTCPconnection,wherethesecuritycontext
23/164
5/17/2016
negotiatedforthefirststreamisappliedtothesecondstream.Thisis
typicalforclienttoserversessions,andaserverMUSTallowaclientto
usethesameTCPconnectionforbothstreams.
TwostreamsovertwoTCPconnections,whereeachstreamis
separatelysecured.Inthisapproach,oneTCPconnectionisusedforthe
streaminwhichstanzasaresentfromtheinitiatingentitytothe
receivingentity,andtheotherTCPconnectionisusedforthestreamin
whichstanzasaresentfromthereceivingentitytotheinitiatingentity.
Thisistypicalforservertoserversessions.
MultiplestreamsovertwoormoreTCPconnections,whereeachstream
isseparatelysecured.Thisapproachissometimesusedforserverto
servercommunicationbetweentwolargeXMPPserviceproviders
however,thiscanmakeitdifficulttomaintaincoherenceofdata
receivedovermultiplestreamsinsituationsdescribedunder
Section10.1,whichiswhyaserverMAYclosethestreamwitha
<conflict/>streamerror(Section4.9.3.3)ifaremoteserverattempts
tonegotiatemorethanonestream(asdescribedunder
Section4.9.3.3).
Thisconceptofdirectionalityappliesonlytostanzasandexplicitlydoesnotapplyto
firstlevelchildrenofthestreamrootthatareusedtobootstrapormanagethe
stream(e.g.,firstlevelelementsusedforTLSnegotiation,SASLnegotiation,
ServerDialback [XEP0220],andStreamManagement [XEP0198]).
Theforegoingconsiderationsimplythatwhilecompleting STARTTLSnegotiation
and SASLnegotiationtwoserverswoulduseoneTCPconnection,butafterthe
streamnegotiationprocessisdonethatoriginalTCPconnectionwouldbeusedonly
fortheinitiatingservertosendXMLstanzastothereceivingserver.Inorderforthe
receivingservertosendXMLstanzastotheinitiatingserver,thereceivingserver
wouldneedtoreversetherolesandnegotiateanXMLstreamfromthereceiving
servertotheinitiatingserveroveraseparateTCPconnection.ThisseparateTCP
connectionisthensecuredusinganewroundofTLSand/orSASLnegotiation.
ImplementationNote:Forhistoricalreasons,aservertoserversession
alwaysusestwoTCPconnections.Whilethatapproachremainsthe
standardbehaviordescribedinthisdocument,extensionssuchas
[XEP0288]enableserverstonegotiatetheuseofasingleTCP
connectionforbidirectionalstanzaexchange.
InformationalNote:AlthoughXMPPdeveloperssometimesapplythe
terms"unidirectional"and"bidirectional"totheunderlyingTCP
connection(e.g.,callingtheTCPconnectionforaclienttoserver
session"bidirectional"andtheTCPconnectionforaservertoserver
session"unidirectional"),strictlyspeakingastreamisalways
unidirectional(becausetheinitiatingentityandreceivingentityalways
haveaminimumoftwostreams,oneineachdirection)andaTCP
connectionisalwaysbidirectional(becauseTCPtrafficcanbesentin
bothdirections).Directionalityappliestotheapplicationlayertraffic
sentovertheTCPconnection,nottothetransportlayertrafficsentover
theTCPconnectionitself.
4.6.HandlingofSilentPeers
TOC
WhenanentitythatisapartytoastreamhasnotreceivedanyXMPPtrafficfrom
itsstreampeerforsomeperiodoftime,thepeermightappeartobesilent.There
areseveralreasonswhythismighthappen:
1.TheunderlyingTCPconnectionisdead.
2.TheXMLstreamisbrokendespitethefactthattheunderlyingTCP
24/164
5/17/2016
connectionisalive.
3.ThepeerisidleandsimplyhasnotsentanyXMPPtrafficoveritsXML
streamtotheentity.
Thesethreeconditionsarebesthandledseparately,asdescribedinthefollowing
sections.
ImplementationNote:Forthepurposeofhandlingsilentpeers,wetreat
atwounidirectionalTCPconnectionsasconceptuallyequivalenttoa
singlebidirectionalTCPconnection(see Section4.5)however,
implementersneedtobeawarethat,inthecaseoftwounidirectional
TCPconnections,responsestotrafficattheXMPPapplicationlayerwill
comebackfromthepeeronthesecondTCPconnection.Inaddition,the
useofmultiplestreamsineachdirection(whichisasomewhatfrequent
deploymentchoiceforservertoserverconnectivityamonglargeXMPP
serviceproviders)furthercomplicatesapplicationlevelcheckingof
XMPPstreamsandtheirunderlyingTCPconnections,becausethereisno
necessarycorrelationbetweenanygiveninitialstreamandanygiven
responsestream.
4.6.1.DeadConnection
TOC
IftheunderlyingTCPconnectionisdead,streamlevelchecks(e.g., [XEP0199]
and [XEP0198])areineffective.Therefore,itisunnecessarytoclosethestream
withorwithoutanerror,anditisappropriateinsteadtosimplyterminatetheTCP
connection.
OnecommonmethodforcheckingtheTCPconnectionistosendaspacecharacter
(U+0020)betweenXMLstanzas,whichisallowedforXMLstreamsasdescribed
under Section11.7thesendingofsuchaspacecharacterisproperlycalleda
"whitespacekeepalive"(theterm"whitespaceping"isoftenused,despitethefact
thatitisnotapingsinceno"pong"ispossible).However,thisisnotallowedduring
TLSnegotiationorSASLnegotiation,asdescribedunder Section5.3.3and
Section6.3.5.
4.6.2.BrokenStream
TOC
EveniftheunderlyingTCPconnectionisalive,thepeermightneverrespondto
XMPPtrafficthattheentitysends,whethernormalstanzasorspecializedstream
checkingtrafficsuchastheapplicationlevelpingsdefinedin [XEP0199]orthe
morecomprehensiveStreamManagementprotocoldefinedin [XEP0198].Inthis
case,itisappropriatefortheentitytocloseabrokenstreamwitha<connection
timeout/>streamerror(Section4.9.3.4).
4.6.3.IdlePeer
TOC
EveniftheunderlyingTCPconnectionisaliveandthestreamisnotbroken,the
peermighthavesentnostanzasforacertainperiodoftime.Inthiscase,thepeer
itselfMAYclosethestream(asdescribedunder Section4.4)ratherthanleavingan
unusedstreamopen.Iftheidlepeerdoesnotclosethestream,theotherpartyMAY
eitherclosethestreamusingthehandshakedescribedunder Section4.4orclose
thestreamwithastreamerror(e.g.,<resourceconstraint/>(Section4.9.3.17)if
theentityhasreachedalimitonthenumberofopenTCPconnectionsor<policy
25/164
5/17/2016
violation/>(Section4.9.3.14)iftheconnectionhasexceededalocaltimeout
policy).However,consistentwiththeorderoflayers(specifiedunder
Section13.3),theotherpartyisadvisedtoverifythattheunderlyingTCP
connectionisaliveandthestreamisunbroken(asdescribedabove)before
concludingthatthepeerisidle.Furthermore,itispreferabletobeliberalin
acceptingidlepeers,sinceexperiencehasshownthatdoingsoimprovesthe
reliabilityofcommunicationoverXMPPnetworksandthatitistypicallymore
efficienttomaintainastreambetweentwoserversthantoaggressivelytimeout
suchastream.
4.6.4.UseofCheckingMethods
TOC
Implementersareadvisedtosupportwhicheverstreamcheckingandconnection
checkingmethodstheydeemappropriate,buttocarefullyweighthenetworkimpact
ofsuchmethodsagainstthebenefitsofdiscoveringbrokenstreamsanddeadTCP
connectionsinatimelymanner.Thelengthoftimebetweentheuseofany
particularcheckisverymuchamatteroflocalservicepolicyanddependsstrongly
onthenetworkenvironmentandusagescenariosofagivendeploymentand
connectiontype.Atthetimeofwriting,itisRECOMMENDEDthatanysuchcheckbe
performednotmorethanonceevery5minutesandthat,ideally,suchcheckswill
beinitiatedbyclientsratherthanservers.ThosewhoimplementXMPPsoftwareand
deployXMPPservicesareencouragedtoseekadditionaladviceregarding
appropriatetimingofstreamcheckingandconnectioncheckingmethods,
particularlywhenpowerconstraineddevicesarebeingused(e.g.,inmobile
environments).
4.7.StreamAttributes
TOC
Theattributesoftheroot<stream/>elementaredefinedinthefollowingsections.
SecurityWarning:Untilandunlesstheconfidentialityandintegrityof
thestreamareprotectedviaTLSasdescribedunder Section5oran
equivalentsecuritylayer(suchastheSASLGSSAPImechanism),the
attributesprovidedinastreamheadercouldbetamperedwithbyan
attacker.
ImplementationNote:Theattributesoftheroot<stream/>elementare
notprependedbyanamespaceprefixbecause,asexplainedin
[XMLNAMES],"[d]efaultnamespacedeclarationsdonotapplydirectly
toattributenamestheinterpretationofunprefixedattributesis
determinedbytheelementonwhichtheyappear."
4.7.1.from
TOC
The'from'attributespecifiesanXMPPidentityoftheentitysendingthestream
element.
Forinitialstreamheadersinclienttoservercommunication,the'from'attributeis
theXMPPidentityoftheprincipalcontrollingtheclient,i.e.,aJIDoftheform
<localpart@domainpart>.TheclientmightnotknowtheXMPPidentity,e.g.,
becausetheXMPPidentityisassignedatalevelotherthantheXMPPapplication
layer(asintheGenericSecurityServiceApplicationProgramInterface [GSSAPI])
orisderivedbytheserverfrominformationprovidedbytheclient(asinsome
deploymentsofendusercertificateswiththeSASLEXTERNALmechanism).
26/164
5/17/2016
Furthermore,iftheclientconsiderstheXMPPidentitytobeprivateinformationthen
itisadvisednottoincludea'from'attributebeforetheconfidentialityandintegrity
ofthestreamareprotectedviaTLSoranequivalentsecuritylayer.However,ifthe
clientknowstheXMPPidentitythenitSHOULDincludethe'from'attributeafterthe
confidentialityandintegrityofthestreamareprotectedviaTLSoranequivalent
securitylayer.
<stream:stream
to='im.example.com'
version='1.0'
xml:lang='en'
Forinitialstreamheadersinservertoservercommunication,the'from'attributeis
oneoftheconfiguredFQDNsoftheserver,i.e.,aJIDoftheform<domainpart>.
TheinitiatingservermighthavemorethanoneXMPPidentity,e.g.,inthecaseofa
serverthatprovidesvirtualhosting,soitwillneedtochooseanidentitythatis
associatedwiththisoutputstream(e.g.,basedonthe'to'attributeofthestanza
thattriggeredthestreamnegotiationattempt).Becauseaserverisa"publicentity"
ontheXMPPnetwork,itMUSTincludethe'from'attributeaftertheconfidentiality
andintegrityofthestreamareprotectedviaTLSoranequivalentsecuritylayer.
<stream:stream
from='example.net'
to='im.example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:server'
Forresponsestreamheadersinbothclienttoserverandservertoserver
communication,thereceivingentityMUSTincludethe'from'attributeandMUSTset
itsvaluetooneofthereceivingentity'sFQDNs(whichMAYbeanFQDNotherthan
thatspecifiedinthe'to'attributeoftheinitialstreamheader,asdescribedunder
Section4.9.1.3and Section4.9.3.6).
<stream:stream
version='1.0'
xml:lang='en'
Whetherornotthe'from'attributeisincluded,eachentityMUSTverifytheidentity
oftheotherentitybeforeexchangingXMLstanzaswithit,asdescribedunder
Section13.5.
InteroperabilityNote:Itispossiblethatimplementationsbasedon
[RFC3920]willnotincludethe'from'addressonanystreamheaders
27/164
5/17/2016
(evenoneswhoseconfidentialityandintegrityareprotected)anentity
SHOULDbeliberalinacceptingsuchstreamheaders.
4.7.2.to
TOC
Forinitialstreamheadersinbothclienttoserverandservertoserver
communication,theinitiatingentityMUSTincludethe'to'attributeandMUSTsetits
valuetoadomainpartthattheinitiatingentityknowsorexpectsthereceivingentity
toservice.(Thesameinformationcanbeprovidedinotherways,suchasaServer
NameIndicationduringTLSnegotiationasdescribedin [TLSEXT].)
<stream:stream
to='im.example.com'
version='1.0'
xml:lang='en'
Forresponsestreamheadersinclienttoservercommunication,iftheclient
includeda'from'attributeintheinitialstreamheaderthentheserverMUSTinclude
a'to'attributeintheresponsestreamheaderandMUSTsetitsvaluetothebareJID
specifiedinthe'from'attributeoftheinitialstreamheader.Iftheclientdidnot
includea'from'attributeintheinitialstreamheaderthentheserverMUSTNOT
includea'to'attributeintheresponsestreamheader.
<stream:stream
version='1.0'
xml:lang='en'
Forresponsestreamheadersinservertoservercommunication,thereceiving
entityMUSTincludea'to'attributeintheresponsestreamheaderandMUSTsetits
valuetothedomainpartspecifiedinthe'from'attributeoftheinitialstreamheader.
<stream:stream
id='g4qSvGvBxJ+xeAd7QKezOQJFFlw='
to='example.net'
version='1.0'
xml:lang='en'
Whetherornotthe'to'attributeisincluded,eachentityMUSTverifytheidentityof
theotherentitybeforeexchangingXMLstanzaswithit,asdescribedunder
28/164
5/17/2016
Section13.5.
InteroperabilityNote:Itispossiblethatimplementationsbasedon
[RFC3920]willnotincludethe'to'addressonstreamheadersan
entitySHOULDbeliberalinacceptingsuchstreamheaders.
TOC
4.7.3.id
The'id'attributespecifiesauniqueidentifierforthestream,calleda"streamID".
ThestreamIDMUSTbegeneratedbythereceivingentitywhenitsendsaresponse
streamheaderandMUSTBEuniquewithinthereceivingapplication(normallya
server).
SecurityWarning:ThestreamIDMUSTbebothunpredictableandnon
repeatingbecauseitcanbesecuritycriticalwhenreusedbyan
authenticationmechanisms,asisthecaseforServerDialback
[XEP0220]andthe"XMPP0.9"authenticationmechanismusedbefore
RFC3920definedtheuseofSASLinXMPPforrecommendations
regardingrandomnessforsecuritypurposes,see [RANDOM].
Forinitialstreamheaders,theinitiatingentityMUSTNOTincludethe'id'attribute
however,ifthe'id'attributeisincluded,thereceivingentityMUSTignoreit.
Forresponsestreamheaders,thereceivingentityMUSTincludethe'id'attribute.
<stream:stream
version='1.0'
xml:lang='en'
InteroperabilityNote:InRFC3920,thetextregardinginclusionofthe
'id'attributewasambiguous,leadingsomeimplementationstoleavethe
attributeofftheresponsestreamheader.
4.7.4.xml:lang
TOC
The'xml:lang'attributespecifiesanentity'spreferredordefaultlanguageforany
humanreadableXMLcharacterdatatobesentoverthestream(anXMLstanzacan
alsopossessan'xml:lang'attribute,asdiscussedunder Section8.1.5).Thesyntax
ofthisattributeisdefinedinSection2.12of [XML]inparticular,thevalueofthe
'xml:lang'attributeMUSTconformtotheNMTOKENdatatype(asdefinedinSection
2.3of [XML])andMUSTconformtothelanguageidentifierformatdefinedin
[LANGTAGS].
Forinitialstreamheaders,theinitiatingentitySHOULDincludethe'xml:lang'
attribute.
<stream:stream
29/164
5/17/2016
to='im.example.com'
version='1.0'
xml:lang='en'
Forresponsestreamheaders,thereceivingentityMUSTincludethe'xml:lang'
attribute.Thefollowingrulesapply:
Iftheinitiatingentityincludedan'xml:lang'attributeinitsinitialstream
headerandthereceivingentitysupportsthatlanguageinthehuman
readableXMLcharacterdatathatitgeneratesandsendstotheinitiating
entity(e.g.,inthe<text/>elementforstreamandstanzaerrors),the
valueofthe'xml:lang'attributeMUSTbetheidentifierfortheinitiating
entity'spreferredlanguage(e.g.,"deCH").
Ifthereceivingentitysupportsalanguagethatmatchestheinitiating
entity'spreferredlanguageaccordingtothe"lookupscheme"specified
inSection3.4of [LANGMATCH](e.g.,"de"insteadof"deCH"),then
thevalueofthe'xml:lang'attributeSHOULDbetheidentifierforthe
matchinglanguage.
Ifthereceivingentitydoesnotsupporttheinitiatingentity'spreferred
languageoramatchinglanguageaccordingtothelookupscheme(orif
theinitiatingentitydidnotincludethe'xml:lang'attributeinitsinitial
streamheader),thenthevalueofthe'xml:lang'attributeMUSTbethe
identifierforthedefaultlanguageofthereceivingentity(e.g.,"en").
<stream:stream
version='1.0'
xml:lang='en'
Iftheinitiatingentityincludedthe'xml:lang'attributeinitsinitialstreamheader,
thereceivingentitySHOULDrememberthatvalueasthedefaultxml:langforall
stanzassentbytheinitiatingentityoverthecurrentstream.Asdescribedunder
Section8.1.5,theinitiatingentityMAYincludethe'xml:lang'attributeinanyXML
stanzasitsendsoverthestream.Iftheinitiatingentitydoesnotincludethe
'xml:lang'attributeinanysuchstanza,thereceivingentitySHOULDaddthe
'xml:lang'attributetothestanzawhenroutingittoaremoteserverordeliveringit
toaconnectedclient,wherethevalueoftheattributeMUSTbetheidentifierforthe
languagepreferredbytheinitiatingentity(evenifthereceivingentitydoesnot
supportthatlanguageforhumanreadableXMLcharacterdataitgeneratesand
sendstotheinitiatingentity,suchasinstreamorstanzaerrors).Iftheinitiating
entityincludesthe'xml:lang'attributeinanysuchstanza,thereceivingentityMUST
NOTmodifyordeleteitwhenroutingittoaremoteserverordeliveringittoa
connectedclient.
4.7.5.version
TOC
Theinclusionoftheversionattributesettoavalueofatleast"1.0"signalssupport
forthestreamrelatedprotocolsdefinedinthisspecification,including TLS
30/164
5/17/2016
negotiation, SASLnegotiation, streamfeatures,and streamerrors.

TheversionofXMPPspecifiedinthisspecificationis"1.0"inparticular,XMPP1.0
encapsulatesthestreamrelatedprotocolsaswellasthebasicsemanticsofthe
threedefinedXMLstanzatypes(<message/>,<presence/>,and<iq/>as
describedunderSections 8.2.1, 8.2.2,and 8.2.3,respectively).
ThenumberingschemeforXMPPversionsis"<major>.<minor>".Themajorand
minornumbersMUSTbetreatedasseparateintegersandeachnumberMAYbe
incrementedhigherthanasingledigit.Thus,"XMPP2.4"wouldbealowerversion
than"XMPP2.13",whichinturnwouldbelowerthan"XMPP12.3".Leadingzeros
(e.g.,"XMPP6.01")MUSTbeignoredbyrecipientsandMUSTNOTbesent.
Themajorversionnumberwillbeincrementedonlyifthestreamandstanza
formatsorobligatoryactionshavechangedsodramaticallythatanolderversion
entitywouldnotbeabletointeroperatewithanewerversionentityifitsimply
ignoredtheelementsandattributesitdidnotunderstandandtooktheactions
definedintheolderspecification.
Theminorversionnumberwillbeincrementedonlyifsignificantnewcapabilities
havebeenaddedtothecoreprotocol(e.g.,anewlydefinedvalueofthe'type'
attributeformessage,presence,orIQstanzas).TheminorversionnumberMUST
beignoredbyanentitywithasmallerminorversionnumber,butMAYbeusedfor
informationalpurposesbytheentitywiththelargerminorversionnumber(e.g.,the
entitywiththelargerminorversionnumberwouldsimplynotethatits
correspondentwouldnotbeabletounderstandthatvalueofthe'type'attributeand
thereforewouldnotsendit).
Thefollowingrulesapplytothegenerationandhandlingofthe'version'attribute
withinstreamheaders:
1.TheinitiatingentityMUSTsetthevalueofthe'version'attributeinthe
initialstreamheadertothehighestversionnumberitsupports(e.g.,if
thehighestversionnumberitsupportsisthatdefinedinthis
specification,itMUSTsetthevalueto"1.0").
2.ThereceivingentityMUSTsetthevalueofthe'version'attributeinthe
responsestreamheadertoeitherthevaluesuppliedbytheinitiating
entityorthehighestversionnumbersupportedbythereceivingentity,
whicheverislower.ThereceivingentityMUSTperformanumeric
comparisononthemajorandminorversionnumbers,notastring
matchon"<major>.<minor>".
3.Iftheversionnumberincludedintheresponsestreamheaderisatleast
onemajorversionlowerthantheversionnumberincludedintheinitial
streamheaderandnewerversionentitiescannotinteroperatewitholder
versionentitiesasdescribed,theinitiatingentitySHOULDclosethe
streamwithan<unsupportedversion/>streamerror
(Section4.9.3.25).
4.Ifeitherentityreceivesastreamheaderwithno'version'attribute,the
entityMUSTconsidertheversionsupportedbytheotherentitytobe
"0.9"andSHOULDNOTincludea'version'attributeintheresponse
streamheader.
4.7.6.SummaryofStreamAttributes
TOC
Thefollowingtablesummarizestheattributesoftheroot<stream/>element.
++++
31/164
5/17/2016
||initiatingtoreceiving|receivingtoinitiating|
++++
|to|JIDofreceiver|JIDofinitiator|
|from|JIDofinitiator|JIDofreceiver|
|id|ignored|streamidentifier|
|xml:lang|defaultlanguage|defaultlanguage|
|version|XMPP1.0+supported|XMPP1.0+supported|
++++
Figure4:StreamAttributes
4.8.XMLNamespaces
TOC
ReadersarereferredtothespecificationofXMLnamespaces [XMLNAMES]fora
fullunderstandingoftheconceptsusedinthissection,especiallytheconceptofa
"defaultnamespace"asprovidedinSection3andSection6.2ofthatspecification.
4.8.1.StreamNamespace
TOC
Theroot<stream/>element("streamheader")MUSTbequalifiedbythe
namespace'http://etherx.jabber.org/streams'(the"streamnamespace").Ifthisrule
isviolated,theentitythatreceivestheoffendingstreamheaderMUSTclosethe
streamwithastreamerror,whichSHOULDbe<invalidnamespace/>
(Section4.9.3.10),althoughsomeexistingimplementationssend<badformat/>
(Section4.9.3.1)instead.
4.8.2.ContentNamespace
TOC
AnentityMAYdeclarea"contentnamespace"asthedefaultnamespacefordata
sentoverthestream(i.e.,dataotherthanelementsqualifiedbythestream
namespace).Ifso,(1)thecontentnamespaceMUSTbeotherthanthestream
namespace,and(2)thecontentnamespaceMUSTbethesamefortheinitialstream
andtheresponsestreamsothatbothstreamsarequalifiedconsistently.The
contentnamespaceappliestoallfirstlevelchildelementssentoverthestream
unlessexplicitlyqualifiedbyanothernamespace(i.e.,thecontentnamespaceisthe
defaultnamespace).
Alternatively(i.e.,insteadofdeclaringthecontentnamespaceasthedefault
namespace),anentityMAYexplicitlyqualifythenamespaceforeachfirstlevelchild
elementofthestream,usingsocalled"prefixfreecanonicalization".Thesetwo
stylesareshowninthefollowingexamples.
Whenacontentnamespaceisdeclaredasthedefaultnamespace,inroughoutlinea
streamwilllooksomethinglikethefollowing.
<stream:stream
to='im.example.com'
version='1.0'
xml:lang='en'
<message>
32/164
5/17/2016
<body>foo</body>
</message>
</stream:stream>
Whenacontentnamespaceisnotdeclaredasthedefaultnamespaceandsocalled
"prefixfreecanonicalization"isusedinstead,inroughoutlineastreamwilllook
somethinglikethefollowing.
<stream
to='im.example.com'
version='1.0'
xml:lang='en'
xmlns='http://etherx.jabber.org/streams'>
<messagexmlns='jabber:client'>
<body>foo</body>
</message>
</stream>
Traditionally,mostXMPPimplementationshaveusedthecontentnamespaceas
defaultnamespacestyleratherthantheprefixfreecanonicalizationstylefor
streamheadershowever,bothstylesareacceptablesincetheyaresemantically
equivalent.
4.8.3.XMPPContentNamespaces
TOC
XMPPasdefinedinthisspecificationusestwocontentnamespaces:'jabber:client'
and'jabber:server'.Thesenamespacesarenearlyidenticalbutareusedindifferent
contexts(clienttoservercommunicationfor'jabber:client'andservertoserver
communicationfor'jabber:server').Theonlydifferencebetweenthetwoisthatthe
'to'and'from'attributesareOPTIONALonstanzassentoverXMLstreamsqualified
bythe'jabber:client'namespace,whereastheyareREQUIREDonstanzassentover
XMLstreamsqualifiedbythe'jabber:server'namespace.Supportforthesecontent
namespacesimpliessupportforthe commonattributesand basicsemanticsof
allthreecorestanzatypes(message,presence,andIQ).
AnimplementationMAYsupportcontentnamespacesotherthan'jabber:client'or
'jabber:server'.However,becausesuchnamespaceswoulddefineapplicationsother
thanXMPP,theyaretobedefinedinseparatespecifications.
AnimplementationMAYrefusetosupportanyothercontentnamespacesasdefault
namespaces.Ifanentityreceivesafirstlevelchildelementqualifiedbyacontent
namespaceitdoesnotsupport,itMUSTclosethestreamwithan<invalid
namespace/>streamerror(Section4.9.3.10).
ClientimplementationsMUSTsupportthe'jabber:client'contentnamespaceasa
defaultnamespace.The'jabber:server'contentnamespaceisoutofscopeforan
XMPPclient,andaclientMUSTNOTsendstanzasqualifiedbythe'jabber:server'
namespace.
ServerimplementationsMUSTsupportasdefaultcontentnamespacesboththe
'jabber:client'namespace(whenthestreamisusedforcommunicationbetweena
clientandaserver)andthe'jabber:server'namespace(whenthestreamisusedfor
communicationbetweentwoservers).Whencommunicatingwithaconnectedclient,
aserverMUSTNOTsendstanzasqualifiedbythe'jabber:server'namespacewhen
communicatingwithapeerserver,aserverMUSTNOTsendstanzasqualifiedby
the'jabber:client'namespace.
33/164
5/17/2016
ImplementationNote:Becauseaclientsendsstanzasoverastream
whosecontentnamespaceis'jabber:client',ifaserverroutestoapeer
serverastanzaithasreceivedfromaconnectedclientthenitneedsto
"rescope"thestanzasothatitscontentnamespaceis'jabber:server'.
Similarly,ifaserverdeliverstoaconnectedclientastanzaithas
receivedfromapeerserverthenitneedsto"rescope"thestanzaso
thatitscontentnamespaceis'jabber:client'.ThisruleappliestoXML
stanzasasdefinedunder Section4.1(i.e.,afirstlevel<message/>,
<presence/>,or<iq/>elementqualifiedbythe'jabber:client'or
'jabber:server'namespace),andbynamespaceinheritancetoallchild
elementsofastanza.However,theruledoesnotapplytoelements
qualifiedbynamespacesotherthan'jabber:client'and'jabber:server'
nortoanychildrenofsuchelements(e.g.,a<message/>element
containedwithinanextensionelement(Section8.4)forreporting
purposes).Althoughitisnotforbiddenforanentitytogeneratestanzas
inwhichanextensionelementcontainsachildelementqualifiedbythe
'jabber:client'or'jabber:server'namespace,existingimplementations
handlesuchstanzasinconsistentlytherefore,implementersareadvised
toweighthelikelylackofinteroperabilityagainstthepossibleutilityof
suchstanzas.Finally,serversareadvisedtoapplystanzarescopingto
otherstreamconnectionmethodsandalternativeXMPPconnection
methods,suchasthosespecifiedin [XEP0124], [XEP0206],
[XEP0114],and [XEP0225].
4.8.4.OtherNamespaces
TOC
EitherpartytoastreamMAYsenddataqualifiedbynamespacesotherthanthe
contentnamespaceandthestreamnamespace.Forexample,thisishowdata
relatedtoTLSnegotiationandSASLnegotiationareexchanged,aswellasXMPP
extensionssuchasStreamManagement [XEP0198]andServerDialback
[XEP0220].
InteroperabilityNote:Forhistoricalreasons,someserver
implementationsexpectadeclarationofthe'jabber:server:dialback'
namespaceonservertoserverstreams,asexplainedin [XEP0220].
However,anXMPPserverMUSTNOTrouteordeliverdatareceivedoveraninput
streamifthatdatais(a)qualifiedbyanothernamespaceand(b)addressedtoan
entityotherthantheserver,unlesstheotherpartytotheoutputstreamoverwhich
theserverwouldsendthedatahasexplicitlynegotiatedoradvertisedsupportfor
receivingarbitrarydatafromtheserver.ThisruleisincludedbecauseXMPPis
designedfortheexchangeofXMLstanzas(notarbitraryXMLdata),andbecause
allowinganentitytosendarbitrarydatatootherentitiescouldsignificantlyincrease
thepotentialforexchangingmaliciousinformation.Asanexampleofthisrule,the
serverhostingtheexample.netdomainwouldnotroutethefollowingfirstlevelXML
elementfrom<romeo@example.net>to<juliet@example.com>:
<ns1:fooxmlns:ns1='http://example.org/ns1'
from='romeo@example.net/resource1'
to='juliet@example.com'>
<ns1:bar/>
</ns1:foo>
Thisrulealsoappliestofirstlevelelementsthatlooklikestanzasbutthatare
improperlynamespacedandthereforereallyarenotstanzasatall(seealso
Section4.8.5),forexample:
34/164
5/17/2016
<ns2:messagexmlns:ns2='http://example.org/ns2'
from='romeo@example.net/resource1'
to='juliet@example.com'>
<body>hi</body>
</ns2:message>
UponreceivingarbitraryfirstlevelXMLelementsoveraninputstream,aserver
MUSTeitherignorethedataorclosethestreamwithastreamerror,which
SHOULDbe<unsupportedstanzatype/>(Section4.9.3.24).
4.8.5.NamespaceDeclarationsandPrefixes
TOC
Becausethecontentnamespaceisotherthanthestreamnamespace,ifacontent
namespaceisdeclaredasthedefaultnamespacethenthefollowingstatementsare
true:
1.Thestreamheaderneedstocontainanamespacedeclarationforboth
thecontentnamespaceandthestreamnamespace.
2.Thestreamnamespacedeclarationneedstoincludeanamespaceprefix
forthestreamnamespace.
InteroperabilityNote:Forhistoricalreasons,animplementationMAY
acceptonlytheprefix'stream'forthestreamnamespace(resultingin
prefixednamessuchas<stream:stream>and<stream:features>)
thisspecificationretainsthatallowancefrom [RFC3920]forthe
purposeofbackwardcompatibility.Implementationsareadvisedthat
usingaprefixotherthan'stream'forthestreamnamespacemight
resultininteroperabilityproblems.Ifanentityreceivesastream
headerwithastreamnamespaceprefixitdoesnotaccept,itMUST
closethestreamwithastreamerror,whichSHOULDbe<bad
namespaceprefix/>(Section4.9.3.2),althoughsomeexisting
implementationssend<badformat/>(Section4.9.3.1)instead.
AnimplementationMUSTNOTgeneratenamespaceprefixesforelementsqualified
bythecontentnamespace(i.e.,thedefaultnamespacefordatasentoverthe
stream)ifthecontentnamespaceis'jabber:client'or'jabber:server'.Forexample,
thefollowingisillegal:
<stream:stream
to='im.example.com'
version='1.0'
xml:lang='en'
<foo:messagexmlns:foo='jabber:client'>
<foo:body>foo</foo:body>
</foo:message>
AnXMPPentitySHOULDNOTacceptdatathatviolatesthisrule(inparticular,an
XMPPserverMUSTNOTrouteordeliversuchdatatoanotherentitywithoutfirst
correctingtheerror)insteaditSHOULDeitherignorethedataorclosethestream
withastreamerror,whichSHOULDbe<badnamespaceprefix/>
(Section4.9.3.2).
35/164
5/17/2016
NamespacesdeclaredinastreamheaderMUSTapplyonlytothatstream(e.g.,the
'jabber:server:dialback'namespaceusedinServerDialback [XEP0220]).In
particular,becauseXMLstanzasintendedforroutingordeliveryoverstreamswith
otherentitieswilllosethenamespacecontextdeclaredintheheaderofthestream
inwhichthosestanzasoriginated,namespacesforextendedcontentwithinsuch
stanzasMUSTNOTbedeclaredinthatstreamheader(seealso Section8.4).If
eitherpartytoastreamdeclaressuchnamespaces,theotherpartytothestream
SHOULDclosethestreamwithan<invalidnamespace/>streamerror
(Section4.9.3.10).Inanycase,anentityMUSTensurethatsuchnamespacesare
properlydeclared(accordingtothissection)whenroutingordeliveringstanzas
fromaninputstreamtoanoutputstream.
4.9.StreamErrors
TOC
TherootstreamelementMAYcontainan<error/>childelementthatisqualifiedby
thestreamnamespace.TheerrorchildSHALLbesentbyacompliantentityifit
perceivesthatastreamlevelerrorhasoccurred.
4.9.1.Rules
TOC
Thefollowingrulesapplytostreamlevelerrors.
4.9.1.1.StreamErrorsAreUnrecoverable
TOC
Streamlevelerrorsareunrecoverable.Therefore,ifanerroroccursatthelevelof
thestream,theentitythatdetectstheerrorMUSTsendan<error/>elementwith
anappropriatechildelementspecifyingtheerrorconditionandthenimmediately
closethestreamasdescribedunder Section4.4.
C:<message><body>Noclosingtag!</message>
S:<stream:error>
<notwellformed
xmlns='urn:ietf:params:xml:ns:xmppstreams'/>
</stream:error>
</stream:stream>
TheentitythatreceivesthestreamerrorthenSHALLclosethestreamasexplained
under Section4.4.
C:</stream:stream>
4.9.1.2.StreamErrorsCanOccurDuringSetup
TOC
Iftheerroristriggeredbytheinitialstreamheader,thereceivingentityMUSTstill
sendtheopening<stream>tag,includethe<error/>elementasachildofthe
streamelement,andsendtheclosing</stream>tag(preferablyinthesameTCP
packet).
36/164
5/17/2016
C:<?xmlversion='1.0'?>
<stream:stream
to='im.example.com'
version='1.0'
xml:lang='en'
xmlns:stream='http://wrong.namespace.example.org/'>
S:<?xmlversion='1.0'?>
<stream:stream
version='1.0'
xml:lang='en'
<stream:error>
<invalidnamespace
</stream:error>
</stream:stream>
4.9.1.3.StreamErrorsWhentheHostIsUnspecifiedorUnknown
TOC
Iftheinitiatingentityprovidesno'to'attributeorprovidesanunknownhostinthe
'to'attributeandtheerroroccursduringstreamsetup,thevalueofthe'from'
attributereturnedbythereceivingentityinthestreamheadersentbeforeclosing
thestreamMUSTbeeitheranauthoritativeFQDNforthereceivingentityorthe
emptystring.
<stream:stream
to='unknown.host.example.com'
version='1.0'
xml:lang='en'
<stream:stream
version='1.0'
xml:lang='en'
<stream:error>
<hostunknown
</stream:error>
</stream:stream>
37/164
5/17/2016
4.9.1.4.WhereStreamErrorsAreSent
TOC
WhentwoTCPconnectionsareusedbetweentheinitiatingentityandthereceiving
entity(oneineachdirection)ratherthanusingasinglebidirectionalconnection,the
followingrulesapply:
Streamlevelerrorsrelatedtotheinitialstreamarereturnedbythe
receivingentityontheresponsestreamviathesameTCPconnection.
Stanzaerrorstriggeredbyoutboundstanzassentfromtheinitiating
entityovertheinitialstreamviathesameTCPconnectionarereturned
bythereceivingentityontheresponsestreamviatheother("return")
TCPconnection,sincetheyareinboundstanzasfromtheperspectiveof
theinitiatingentity.
TOC
4.9.2.Syntax
Thesyntaxforstreamerrorsisasfollows,whereXMLdatashownwithinthesquare
brackets'['and']'isOPTIONAL.
<stream:error>
<definedconditionxmlns='urn:ietf:params:xml:ns:xmppstreams'/>
[<textxmlns='urn:ietf:params:xml:ns:xmppstreams'
xml:lang='langcode'>
OPTIONALdescriptivetext
</text>]
[OPTIONALapplicationspecificconditionelement]
</stream:error>
The"definedcondition"MUSTcorrespondtooneofthestreamerrorconditions
definedunder Section4.9.3.However,becauseadditionalerrorconditionsmightbe
definedinthefuture,ifanentityreceivesastreamerrorconditionthatitdoesnot
understandthenitMUSTtreattheunknownconditionasequivalentto<undefined
condition/>(Section4.9.3.21).IfthedesignersofanXMPPprotocolextensionor
thedevelopersofanXMPPimplementationneedtocommunicateastreamerror
conditionthatisnotdefinedinthisspecification,theycandosobydefiningan
applicationspecificerrorconditionelementqualifiedbyanapplicationspecific
namespace.
The<error/>element:
MUSTcontainachildelementcorrespondingtooneofthe defined
streamerrorconditionsthiselementMUSTbequalifiedbythe
'urn:ietf:params:xml:ns:xmppstreams'namespace.
MAYcontaina<text/>childelementcontainingXMLcharacterdatathat
describestheerrorinmoredetailthiselementMUSTbequalifiedby
the'urn:ietf:params:xml:ns:xmppstreams'namespaceandSHOULD
possessan'xml:lang'attributespecifyingthenaturallanguageofthe
XMLcharacterdata.
MAYcontainachildelementforanapplicationspecificerrorcondition
thiselementMUSTbequalifiedbyanapplicationdefinednamespace,
anditsstructureisdefinedbythatnamespace(see Section4.9.4).
The<text/>elementisOPTIONAL.Ifincluded,itMUSTbeusedonlytoprovide
descriptiveordiagnosticinformationthatsupplementsthemeaningofadefined
conditionorapplicationspecificcondition.ItMUSTNOTbeinterpreted
38/164
5/17/2016
programmaticallybyanapplication.ItMUSTNOTbeusedastheerrormessage
presentedtoahumanuser,butMAYbeshowninadditiontotheerrormessage
associatedwiththedefinedconditionelement(and,optionally,theapplication
specificconditionelement).
4.9.3.DefinedStreamErrorConditions
TOC
Thefollowingstreamlevelerrorconditionsaredefined.
4.9.3.1.badformat
TOC
TheentityhassentXMLthatcannotbeprocessed.
(Inthefollowingexample,theclientsendsanXMPPmessagethatisnotwell
formedXML,whichalternativelymighttriggera<notwellformed/>streamerror
(Section4.9.3.13).)
C:<message>
<body>Noclosingtag!
</message>
S:<stream:error>
<badformat
</stream:error>
</stream:stream>
ThiserrorcanbeusedinsteadofthemorespecificXMLrelatederrors,suchas
<badnamespaceprefix/>,<invalidxml/>,<notwellformed/>,<restricted
xml/>,and<unsupportedencoding/>.However,themorespecificerrorsare
RECOMMENDED.
4.9.3.2.badnamespaceprefix
TOC
Theentityhassentanamespaceprefixthatisunsupported,orhassentno
namespaceprefixonanelementthatneedssuchaprefix(see Section11.2).
(Inthefollowingexample,theclientspecifiesanamespaceprefixof"foobar"for
theXMLstreamnamespace.)
<foobar:stream
to='im.example.com'
version='1.0'
xmlns:foobar='http://etherx.jabber.org/streams'>
<stream:stream
39/164
5/17/2016
version='1.0'
xml:lang='en'
<stream:error>
<badnamespaceprefix
</stream:error>
</stream:stream>
4.9.3.3.conflict
TOC
Theservereither(1)isclosingtheexistingstreamforthisentitybecauseanew
streamhasbeeninitiatedthatconflictswiththeexistingstream,or(2)isrefusinga
newstreamforthisentitybecauseallowingthenewstreamwouldconflictwithan
existingstream(e.g.,becausetheserverallowsonlyacertainnumberof
connectionsfromthesameIPaddressorallowsonlyoneservertoserverstream
foragivendomainpairasawayofhelpingtoensureinorderprocessingas
describedunder Section10.1).
<stream:stream
to='im.example.com'
version='1.0'
<stream:stream
version='1.0'
xml:lang='en'
<stream:error>
<conflict
</stream:error>
</stream:stream>
Ifaclientreceivesa<conflict/>streamerror(Section4.9.3.3),duringthe
resourcebindingaspectofitsreconnectionattemptitMUSTNOTblindlyrequestthe
resourcepartitusedduringtheformersessionbutinsteadMUSTchooseadifferent
resourcepartdetailsareprovidedunder Section7.
4.9.3.4.connectiontimeout
TOC
Onepartyisclosingthestreambecauseithasreasontobelievethattheother
partyhaspermanentlylosttheabilitytocommunicateoverthestream.Thelackof
40/164
5/17/2016
abilitytocommunicatecanbediscoveredusingvariousmethods,suchas
whitespacekeepalivesasspecifiedunder Section4.4,XMPPlevelpingsasdefined
in [XEP0199],andXMPPStreamManagementasdefinedin [XEP0198].
P:<stream:error>
<connectiontimeout
</stream:error>
</stream:stream>
InteroperabilityNote:RFC3920specifiedthatthe<connection
timeout/>streamerror(Section4.9.3.4)istobeusedifthepeerhas
notgeneratedanytrafficoverthestreamforsomeperiodoftime.That
behaviorisnolongerrecommendedinstead,theerrorSHOULDbeused
onlyiftheconnectedclientorpeerserverhasnotrespondedtodata
sentoverthestream.
4.9.3.5.hostgone
TOC
Thevalueofthe'to'attributeprovidedintheinitialstreamheadercorrespondsto
anFQDNthatisnolongerservicedbythereceivingentity.
(Inthefollowingexample,thepeerspecifiesa'to'addressof"foo.im.example.com"
whenconnectingtothe"im.example.com"server,buttheservernolongerhostsa
serviceatthataddress.)
P:<?xmlversion='1.0'?>
<stream:stream
from='example.net'
to='foo.im.example.com'
version='1.0'
<stream:stream
to='example.net'
version='1.0'
xml:lang='en'
<stream:error>
<hostgone
</stream:error>
</stream:stream>
4.9.3.6.hostunknown
TOC
Thevalueofthe'to'attributeprovidedintheinitialstreamheaderdoesnot
correspondtoanFQDNthatisservicedbythereceivingentity.
41/164
5/17/2016
(Inthefollowingexample,thepeerspecifiesa'to'addressof"example.org"when
connectingtothe"im.example.com"server,buttheserverknowsnothingofthat
address.)
P:<?xmlversion='1.0'?>
<stream:stream
from='example.net'
to='example.org'
version='1.0'
<stream:stream
to='example.net'
version='1.0'
xml:lang='en'
<stream:error>
<hostunknown
</stream:error>
</stream:stream>
4.9.3.7.improperaddressing
TOC
Astanzasentbetweentwoserverslacksa'to'or'from'attribute,the'from'or'to'
attributehasnovalue,orthevalueviolatestherulesforXMPPaddresses
[XMPPADDR].
(Inthefollowingexample,thepeersendsastanzawithouta'to'addressovera
servertoserverstream.)
P:<messagefrom='juliet@im.example.com'>
<body>Whereforeartthou?</body>
</message>
S:<stream:error>
<improperaddressing
</stream:error>
</stream:stream>
TOC
Theserverhasexperiencedamisconfigurationorotherinternalerrorthatprevents
itfromservicingthestream.
S:<stream:error>
<internalservererror
42/164
5/17/2016
</stream:error>
</stream:stream>
4.9.3.9.invalidfrom
TOC
Thedataprovidedina'from'attributedoesnotmatchanauthorizedJIDor
validateddomainasnegotiated(1)betweentwoserversusingSASLorServer
Dialback,or(2)betweenaclientandaserverviaSASLauthenticationandresource
binding.
(Inthefollowingexample,apeerthathasauthenticatedonlyas"example.net"
attemptstosendastanzafromanaddressat"example.org".)
P:<messagefrom='romeo@example.org'to='juliet@im.example.com'>
<body>Neither,fairsaint,ifeithertheedislike.</body>
</message>
S:<stream:error>
<invalidfrom
</stream:error>
</stream:stream>
4.9.3.10.invalidnamespace
TOC
Thestreamnamespacenameissomethingotherthan
"http://etherx.jabber.org/streams"(see Section11.2)orthecontentnamespace
declaredasthedefaultnamespaceisnotsupported(e.g.,somethingotherthan
"jabber:client"or"jabber:server").
(Inthefollowingexample,theclientspecifiesanamespaceof
'http://wrong.namespace.example.org/'forthestream.)
<stream:stream
to='im.example.com'
version='1.0'
xmlns:stream='http://wrong.namespace.example.org/'>
<stream:stream
version='1.0'
xml:lang='en'
<stream:error>
<invalidnamespace
43/164
5/17/2016
</stream:error>
</stream:stream>
4.9.3.11.invalidxml
TOC
TheentityhassentinvalidXMLoverthestreamtoaserverthatperformsvalidation
(see Section11.4).
(Inthefollowingexample,thepeerattemptstosendanIQstanzaoftype
"subscribe",buttheXMLschemadefinesnosuchvalueforthe'type'attribute.)
P:<iqfrom='example.net'
id='l3b1vs75'
to='im.example.com'
type='subscribe'>
<pingxmlns='urn:xmpp:ping'/>
</iq>
S:<stream:error>
<invalidxml
</stream:error>
</stream:stream>
TOC
TheentityhasattemptedtosendXMLstanzasorotheroutbounddatabeforethe
streamhasbeenauthenticated,orotherwiseisnotauthorizedtoperformanaction
relatedtostreamnegotiationthereceivingentityMUSTNOTprocesstheoffending
databeforesendingthestreamerror.
(Inthefollowingexample,theclientattemptstosendXMLstanzasbefore
authenticatingwiththeserver.)
<stream:stream
to='im.example.com'
version='1.0'
<stream:stream
version='1.0'
xml:lang='en'
C:<messageto='romeo@example.net'>
<body>Whereforeartthou?</body>
44/164
5/17/2016
</message>
S:<stream:error>
<notauthorized
</stream:error>
</stream:stream>
4.9.3.13.notwellformed
TOC
TheinitiatingentityhassentXMLthatviolatesthewellformednessrulesof [XML]
or [XMLNAMES].
(Inthefollowingexample,theclientsendsanXMPPmessagethatisnot
namespacewellformed.)
C:<message>
<foo:body>Whatisthisfoo?</foo:body>
</message>
S:<stream:error>
<notwellformed
</stream:error>
</stream:stream>
InteroperabilityNote:InRFC3920,thenameofthiserrorconditionwas
"xmlnotwellformed"insteadof"notwellformed".Thenamewas
changedbecausetheelementname<xmlnotwellformed/>violates
theconstraintfromSection3of [XML]that"namesbeginningwitha
matchto(('X'|'x')('M'|'m')('L'|'l'))arereservedforstandardizationinthis
orfutureversionsofthisspecification".
TOC
Theentityhasviolatedsomelocalservicepolicy(e.g.,astanzaexceedsa
configuredsizelimit)theserverMAYchoosetospecifythepolicyinthe<text/>
elementorinanapplicationspecificconditionelement.
(Inthefollowingexample,theclientsendsanXMPPmessagethatistoolarge
accordingtotheserver'slocalservicepolicy.)
C:<messageto='juliet@im.example.com'id='foo'>
<body>[...theemacsmanual...]</body>
</message>
S:<stream:error>
<policyviolation
<stanzatoobigxmlns='urn:xmpp:errors'/>
</stream:error>
S:</stream:stream>
45/164
5/17/2016
4.9.3.15.remoteconnectionfailed
TOC
Theserverisunabletoproperlyconnecttoaremoteentitythatisneededfor
authenticationorauthorization(e.g.,incertainscenariosrelatedtoServerDialback
[XEP0220])thisconditionisnottobeusedwhenthecauseoftheerroriswithin
theadministrativedomainoftheXMPPserviceprovider,inwhichcasethe
<internalservererror/>conditionismoreappropriate.
<stream:stream
to='im.example.com'
version='1.0'
<stream:stream
version='1.0'
xml:lang='en'
<stream:error>
<remoteconnectionfailed
</stream:error>
</stream:stream>
4.9.3.16.reset
TOC
Theserverisclosingthestreambecauseithasnew(typicallysecuritycritical)
featurestooffer,becausethekeysorcertificatesusedtoestablishasecurecontext
forthestreamhaveexpiredorhavebeenrevokedduringthelifeofthestream
(Section13.7.2.3),becausetheTLSsequencenumberhaswrapped
(Section5.3.5),etc.Theresetappliestothestreamandtoanysecuritycontext
establishedforthatstream(e.g.,viaTLSandSASL),whichmeansthatencryption
andauthenticationneedtobenegotiatedagainforthenewstream(e.g.,TLS
sessionresumptioncannotbeused).
S:<stream:error>
<reset
</stream:error>
</stream:stream>
TOC
Theserverlacksthesystemresourcesnecessarytoservicethestream.
46/164
5/17/2016
<stream:stream
to='im.example.com'
version='1.0'
<stream:stream
version='1.0'
xml:lang='en'
<stream:error>
<resourceconstraint
</stream:error>
</stream:stream>
4.9.3.18.restrictedxml
TOC
TheentityhasattemptedtosendrestrictedXMLfeaturessuchasacomment,
processinginstruction,DTDsubset,orXMLentityreference(see Section11.1).
(Inthefollowingexample,theclientsendsanXMPPmessagecontaininganXML
comment.)
C:<messageto='juliet@im.example.com'>
<!<subject/>>
<body>Thismessagehasnosubject.</body>
</message>
S:<stream:error>
<restrictedxml
</stream:error>
</stream:stream>
4.9.3.19.seeotherhost
TOC
Theserverwillnotprovideservicetotheinitiatingentitybutisredirectingtrafficto
anotherhostundertheadministrativecontrolofthesameserviceprovider.TheXML
characterdataofthe<seeotherhost/>elementreturnedbytheserverMUST
specifythealternateFQDNorIPaddressatwhichtoconnect,whichMUSTbea
validdomainpartoradomainpartplusportnumber(separatedbythe':'character
intheform"domainpart:port").Ifthedomainpartisthesameasthesource
domain,deriveddomain,orresolvedIPv4orIPv6addresstowhichtheinitiating
entityoriginallyconnected(differingonlybytheportnumber),thentheinitiating
entitySHOULDsimplyattempttoreconnectatthataddress.(TheformatofanIPv6
addressMUSTfollow [IPv6ADDR],whichincludestheenclosingtheIPv6address
47/164
5/17/2016
insquarebrackets'['and']'asoriginallydefinedby [URI].)Otherwise,the
initiatingentityMUSTresolvetheFQDNspecifiedinthe<seeotherhost/>element
asdescribedunder Section3.2.
<stream:stream
to='im.example.com'
version='1.0'
<stream:stream
version='1.0'
xml:lang='en'
<stream:error>
<seeotherhost
xmlns='urn:ietf:params:xml:ns:xmppstreams'>
[2001:41D0:1:A49b::1]:9222
</seeotherhost>
</stream:error>
</stream:stream>
Whennegotiatingastreamwiththehosttowhichithasbeenredirected,the
initiatingentityMUSTapplythesamepoliciesitwouldhaveappliedtotheoriginal
connectionattempt(e.g.,apolicyrequiringTLS),MUSTspecifythesame'to'
addressontheinitialstreamheader,andMUSTverifytheidentityofthenewhost
usingthesamereferenceidentifier(s)itwouldhaveusedfortheoriginalconnection
attempt(inaccordancewith [TLSCERTS]).Evenifthereceivingentityreturnsa
<seeotherhost/>errorbeforetheconfidentialityandintegrityofthestreamhave
beenestablished(thusintroducingthepossibilityofadenialofserviceattack),the
factthattheinitiatingentityneedstoverifytheidentityoftheXMPPservicebased
onthesamereferenceidentifiersimpliesthattheinitiatingentitywillnotconnectto
amaliciousentity.Toreducethepossibilityofadenialofserviceattack,(a)the
receivingentitySHOULDNOTclosethestreamwitha<seeotherhost/>stream
erroruntilaftertheconfidentialityandintegrityofthestreamhavebeenprotected
viaTLSoranequivalentsecuritylayer(suchastheSASLGSSAPImechanism),and
(b)thereceivingentityMAYhaveapolicyoffollowingredirectsonlyifithas
authenticatedthereceivingentity.Inaddition,theinitiatingentitySHOULDabortthe
connectionattemptafteracertainnumberofsuccessiveredirects(e.g.,atleast2
butnomorethan5).
4.9.3.20.systemshutdown
TOC
Theserverisbeingshutdownandallactivestreamsarebeingclosed.
S:<stream:error>
<systemshutdown
</stream:error>
48/164
5/17/2016
</stream:stream>
TOC
Theerrorconditionisnotoneofthosedefinedbytheotherconditionsinthislist
thiserrorconditionSHOULDNOTbeusedexceptinconjunctionwithanapplication
specificcondition.
S:<stream:error>
<undefinedcondition
<apperrorxmlns='http://example.org/ns'/>
</stream:error>
</stream:stream>
4.9.3.22.unsupportedencoding
TOC
Theinitiatingentityhasencodedthestreaminanencodingthatisnotsupportedby
theserver(see Section11.6)orhasotherwiseimproperlyencodedthestream
(e.g.,byviolatingtherulesofthe [UTF8]encoding).
(Inthefollowingexample,theclientattemptstoencodedatausingUTF16instead
ofUTF8.)
C:<?xmlversion='1.0'encoding='UTF16'?>
<stream:stream
to='im.example.com'
version='1.0'
<stream:stream
version='1.0'
xml:lang='en'
<stream:error>
<unsupportedencoding
</stream:error>
</stream:stream>
4.9.3.23.unsupportedfeature
TOC
Thereceivingentityhasadvertisedamandatorytonegotiatestreamfeaturethat
theinitiatingentitydoesnotsupport,andhasofferednoothermandatoryto
49/164
5/17/2016
negotiatefeaturealongsidetheunsupportedfeature.
(Inthefollowingexample,thereceivingentityrequiresnegotiationofanexample
feature,buttheinitiatingentitydoesnotsupportthefeature.)
R:<stream:features>
<examplexmlns='urn:xmpp:example'>
<required/>
</example>
</stream:features>
I:<stream:error>
<unsupportedfeature
</stream:error>
</stream:stream>
4.9.3.24.unsupportedstanzatype
TOC
Theinitiatingentityhassentafirstlevelchildofthestreamthatisnotsupported
bytheserver,eitherbecausethereceivingentitydoesnotunderstandthe
namespaceorbecausethereceivingentitydoesnotunderstandtheelementname
fortheapplicablenamespace(whichmightbethecontentnamespacedeclaredas
thedefaultnamespace).
(Inthefollowingexample,theclientattemptstosendafirstlevelchildelementof
<pubsub/>qualifiedbythe'jabber:client'namespace,buttheschemaforthat
namespacedefinesnosuchelement.)
C:<pubsubxmlns='jabber:client'>
<publishnode='princely_musings'>
<itemid='ae890ac52d0df67ed7cfdf51b644e901'>
<entryxmlns='http://www.w3.org/2005/Atom'>
<title>Soliloquy</title>
<summary>
Tobe,ornottobe:thatisthequestion:
Whether'tisnoblerinthemindtosuffer
Theslingsandarrowsofoutrageousfortune,
Ortotakearmsagainstaseaoftroubles,
Andbyopposingendthem?
</summary>
<linkrel='alternate'type='text/html'
href='http://denmark.example/2003/12/13/atom03'/>
<id>tag:denmark.example,2003:entry32397</id>
<published>20031213T18:30:02Z</published>
<updated>20031213T18:30:02Z</updated>
</entry>
</item>
</publish>
</pubsub>
S:<stream:error>
<unsupportedstanzatype
</stream:error>
</stream:stream>
50/164
5/17/2016
4.9.3.25.unsupportedversion
TOC
The'version'attributeprovidedbytheinitiatingentityinthestreamheader
specifiesaversionofXMPPthatisnotsupportedbytheserver.
<stream:stream
to='im.example.com'
version='11.0'
<stream:stream
version='1.0'
xml:lang='en'
<stream:error>
<unsupportedversion
</stream:error>
</stream:stream>
TOC
Asnoted,anapplicationMAYprovideapplicationspecificstreamerrorinformation
byincludingaproperlynamespacedchildintheerrorelement.Theapplication
specificelementSHOULDsupplementorfurtherqualifyadefinedelement.Thus,
the<error/>elementwillcontaintwoorthreechildelements.
C:<message>
<body>
Mykeyboardlayoutis:
QWERTYUIOP{}|
ASDFGHJKL:"
ZXCVBNM<>?
</body>
</message>
S:<stream:error>
<notwellformed
<textxml:lang='en'xmlns='urn:ietf:params:xml:ns:xmppstreams'>
Somespecialapplicationdiagnosticinformation!
</text>
<escapeyourdataxmlns='http://example.org/ns'/>
</stream:error>
</stream:stream>
51/164
5/17/2016
4.10.SimplifiedStreamExamples
TOC
Thissectioncontainstwohighlysimplifiedexamplesofastreambasedconnection
betweenaclientandaservertheseexamplesareincludedforthepurposeof
illustratingtheconceptsintroducedthusfar,butthereaderneedstobeawarethat
theseexampleselidemanydetails(see Section9formorecompleteexamples).
Abasicconnection:
<stream:stream
to='im.example.com'
version='1.0'
xml:lang='en'
<stream:stream
version='1.0'
xml:lang='en'
[...streamnegotiation...]
C:<messagefrom='juliet@im.example.com/balcony'
to='romeo@example.net'
xml:lang='en'>
<body>ArtthounotRomeo,andaMontague?</body>
</message>
S:<messagefrom='romeo@example.net/orchard'
to='juliet@im.example.com/balcony'
xml:lang='en'>
</message>
C:</stream:stream>
S:</stream:stream>
Aconnectiongonebad:
<stream:stream
to='im.example.com'
version='1.0'
xml:lang='en'
52/164
5/17/2016
<stream:stream
version='1.0'
xml:lang='en'
[...streamnegotiation...]
xml:lang='en'>
<body>Noclosingtag!
</message>
S:<stream:error>
<notwellformed
</stream:error>
</stream:stream>
Moredetailedexamplesareprovidedunder Section9.
5.STARTTLSNegotiation
TOC
5.1.Fundamentals
TOC
XMPPincludesamethodforsecuringthestreamfromtamperingand
eavesdropping.ThischannelencryptionmethodmakesuseoftheTransportLayer
Security [TLS]protocol,specificallya"STARTTLS"extensionthatismodeledafter
similarextensionsforthe [IMAP], [POP3],and [ACAP]protocolsasdescribedin
[USINGTLS].TheXMLnamespacenamefortheSTARTTLSextensionis
'urn:ietf:params:xml:ns:xmpptls'.
5.2.Support
TOC
SupportforSTARTTLSisREQUIREDinXMPPclientandserverimplementations.An
administratorofagivendeploymentMAYspecifythatTLSismandatorytonegotiate
forclienttoservercommunication,servertoservercommunication,orboth.An
initiatingentitySHOULDuseTLStosecureitsstreamwiththereceivingentity
beforeproceedingwithSASLauthentication.
TOC
53/164
5/17/2016
TOC
IfthereceivingentityadvertisesonlytheSTARTTLSfeatureorifthereceiving
entityincludesthe<required/>childelementasexplainedunder Section5.4.1,
thepartiesMUSTconsiderTLSasmandatorytonegotiate.IfTLSismandatoryto
negotiate,thereceivingentitySHOULDNOTadvertisesupportforanystream
featureexceptSTARTTLSduringtheinitialstageofthestreamnegotiationprocess,
becausefurtherstreamfeaturesmightdependonpriornegotiationofTLSgiventhe
orderoflayersinXMPP(e.g.,theparticularSASLmechanismsofferedbythe
receivingentitywilllikelydependonwhetherTLShasbeennegotiated).
5.3.2.Restart
TOC
AfterTLSnegotiation,thepartiesMUSTrestartthestream.
TOC
DuringSTARTTLSnegotiation,theentitiesMUSTNOTsendanywhitespaceas
separatorsbetweenXMLelements(i.e.,fromthelastcharacterofthefirstlevel
<starttls/>elementqualifiedbythe'urn:ietf:params:xml:ns:xmpptls'namespace
assentbytheinitiatingentity,untilthelastcharacterofthefirstlevel<proceed/>
elementqualifiedbythe'urn:ietf:params:xml:ns:xmpptls'namespaceassentby
thereceivingentity).Thisprohibitionhelpstoensurepropersecuritylayerbyte
precision.AnysuchwhitespaceshownintheSTARTTLSexamplesprovidedinthis
documentisincludedonlyforthesakeofreadability.
5.3.4.OrderofTLSandSASLNegotiations
TOC
IftheinitiatingentitychoosestouseTLS,STARTTLSnegotiationMUSTbecompleted
beforeproceedingto SASLnegotiationthisorderofnegotiationisnecessaryto
helpsafeguardauthenticationinformationsentduringSASLnegotiation,aswellas
tomakeitpossibletobasetheuseoftheSASLEXTERNALmechanismona
certificate(orothercredentials)providedduringpriorTLSnegotiation.
5.3.5.TLSRenegotiation
TOC
TheTLSprotocolallowseitherpartyinaTLSprotectedchanneltoinitiateanew
handshakethatestablishesnewcryptographicparameters(see [TLSNEG]).The
casesmostcommonlymentionedare:
1.Refreshingencryptionkeys.
2.WrappingtheTLSsequencenumberasexplainedinSection6.1of
[TLS].
3.Protectingclientcredentialsbycompletingserverauthenticationfirst
andthencompletingclientauthenticationovertheprotectedchannel.
BecauseitisrelativelyinexpensivetoestablishstreamsinXMPP,forthefirsttwo
casesitispreferabletouseanXMPPstreamreset(asdescribedunder
Section4.9.3.16)insteadofperformingTLSrenegotiation.
54/164
5/17/2016
ThethirdcasehasimprovedsecuritycharacteristicswhentheTLSclient(which
mightbeanXMPPserver)presentscredentialstotheTLSserver.Ifcommunicating
suchcredentialstoanunauthenticatedTLSservermightleakprivateinformation,it
canbeappropriatetocompleteTLSnegotiationforthepurposeofauthenticatingthe
TLSservertotheTLSclientandthenattemptTLSrenegotiationforthepurposeof
authenticatingtheTLSclienttotheTLSserver.However,thiscaseisextremelyrare
becausethecredentialspresentedbyanXMPPserverorXMPPclientactingasaTLS
clientarealmostalwayspublic(i.e.,aPKIXcertificate),andthereforeproviding
thosecredentialsbeforeauthenticatingtheXMPPserveractingasaTLSserver
wouldnotingeneralleakprivateinformation.
Asaresult,implementersareencouragedtocarefullyweighthecostsandbenefits
ofTLSrenegotiationbeforesupportingitintheirsoftware,andXMPPentitiesthat
actasTLSclientsarediscouragedfromattemptingTLSrenegotiationunlessthe
certificate(orothercredentialinformation)sentduringTLSnegotiationisknownto
beprivate.
SupportforTLSrenegotiationisstrictlyOPTIONAL.However,implementationsthat
supportTLSrenegotiationMUSTimplementandusetheTLSRenegotiationExtension
[TLSNEG].
IfanentitythatdoesnotsupportTLSrenegotiationdetectsarenegotiationattempt,
thenitMUSTimmediatelyclosetheunderlyingTCPconnectionwithoutreturninga
streamerror(sincetheviolationhasoccurredattheTLSlayer,nottheXMPPlayer,
asdescribedunder Section13.3).
IfanentitythatsupportsTLSrenegotiationdetectsaTLSrenegotiationattemptthat
doesnotusetheTLSRenegotiationExtension [TLSNEG],thenitMUSTimmediately
closetheunderlyingTCPconnectionwithoutreturningastreamerror(sincethe
violationhasoccurredattheTLSlayer,nottheXMPPlayerasdescribedunder
Section13.3).
5.3.6.TLSExtensions
TOC
EitherpartytoastreamMAYincludeanyTLSextensionduringtheTLSnegotiation
itself.ThisisamatterfortheTLSlayer,nottheXMPPlayer.
5.4.Process
TOC
TOC
TheinitiatingentityresolvestheFQDNofthereceivingentityasspecifiedunder
Section3,opensaTCPconnectiontotheadvertisedportattheresolvedIP
address,andsendsaninitialstreamheadertothereceivingentity.
I:<stream:stream
to='im.example.com'
version='1.0'
xml:lang='en'
55/164
5/17/2016
ThereceivingentityMUSTsendaresponsestreamheadertotheinitiatingentity
overtheTCPconnectionopenedbytheinitiatingentity.
R:<stream:stream
id='t7AMCin9zjMNwQKDnplntZPIDEI='
version='1.0'
xml:lang='en'
ThereceivingentitythenMUSTsendstreamfeaturestotheinitiatingentity.Ifthe
receivingentitysupportsTLS,thestreamfeaturesMUSTincludeanadvertisement
forsupportofSTARTTLSnegotiation,i.e.,a<starttls/>elementqualifiedbythe
'urn:ietf:params:xml:ns:xmpptls'namespace.
IfthereceivingentityconsidersSTARTTLSnegotiationtobemandatoryto
negotiate,the<starttls/>elementMUSTcontainanempty<required/>child
element.
R:<stream:features>
<required/>
</starttls>
</stream:features>
5.4.2.InitiationofSTARTTLSNegotiation
5.4.2.1.STARTTLSCommand
TOC
TOC
InordertobegintheSTARTTLSnegotiation,theinitiatingentityissuestheSTARTTLS
command(i.e.,a<starttls/>elementqualifiedbythe
'urn:ietf:params:xml:ns:xmpptls'namespace)toinstructthereceivingentitythatit
wishestobeginaSTARTTLSnegotiationtosecurethestream.
I:<starttlsxmlns='urn:ietf:params:xml:ns:xmpptls'/>
ThereceivingentityMUSTreplywitheithera<proceed/>element(proceedcase)
ora<failure/>element(failurecase)qualifiedbythe
'urn:ietf:params:xml:ns:xmpptls'namespace.
5.4.2.2.FailureCase
TOC
Ifthefailurecaseoccurs,thereceivingentityMUSTreturna<failure/>element
qualifiedbythe'urn:ietf:params:xml:ns:xmpptls'namespace,closetheXML
stream,andterminatetheunderlyingTCPconnection.
56/164
5/17/2016
R:<failurexmlns='urn:ietf:params:xml:ns:xmpptls'/>
R:</stream:stream>
Causesforthefailurecaseincludebutarenotlimitedto:
1.TheinitiatingentityhassentamalformedSTARTTLScommand.
2.ThereceivingentitydidnotoffertheSTARTTLSfeatureinitsstream
features.
3.ThereceivingentitycannotcompleteSTARTTLSnegotiationbecauseof
aninternalerror.
InformationalNote:STARTTLSfailureisnottriggeredbyTLSerrors
suchasbad_certificateorhandshake_failure,whicharegeneratedand
handledduringtheTLSnegotiationitselfasdescribedin [TLS].
Ifthefailurecaseoccurs,theinitiatingentityMAYattempttoreconnectas
explainedunder Section3.3.
5.4.2.3.ProceedCase
TOC
Iftheproceedcaseoccurs,thereceivingentityMUSTreturna<proceed/>element
qualifiedbythe'urn:ietf:params:xml:ns:xmpptls'namespace.
R:<proceedxmlns='urn:ietf:params:xml:ns:xmpptls'/>
ThereceivingentityMUSTconsidertheTLSnegotiationtohavebegunimmediately
aftersendingtheclosing'>'characterofthe<proceed/>elementtotheinitiating
entity.TheinitiatingentityMUSTconsidertheTLSnegotiationtohavebegun
immediatelyafterreceivingtheclosing'>'characterofthe<proceed/>element
fromthereceivingentity.
TheentitiesnowproceedtoTLSnegotiationasexplainedinthenextsection.
5.4.3.TLSNegotiation
TOC
5.4.3.1.Rules
TOC
InordertocompleteTLSnegotiationovertheTCPconnection,theentitiesMUST
followtheprocessdefinedin [TLS].
Thefollowingrulesapply:
1.TheentitiesMUSTNOTsendanyfurtherXMLdatauntiltheTLS
negotiationiscomplete.
2.Whenusinganyofthemandatorytoimplement(MTI)ciphersuites
specifiedunder Section13.8,thereceivingentityMUSTpresenta
certificate.
3.Sothatmutualcertificateauthenticationwillbepossible,thereceiving
entitySHOULDsendacertificaterequesttotheinitiatingentity,andthe
initiatingentitySHOULDsendacertificatetothereceivingentity(but
forprivacyreasonsmightoptnottosendacertificateuntilafterthe
57/164
5/17/2016
receivingentityhasauthenticatedtotheinitiatingentity).
4.ThereceivingentitySHOULDchoosewhichcertificatetopresentbased
onthedomainpartcontainedinthe'to'attributeoftheinitialstream
header(inessence,thisdomainpartisfunctionallyequivalenttothe
ServerNameIndicationdefinedforTLSin [TLSEXT]).
5.TodetermineiftheTLSnegotiationwillsucceed,theinitiatingentity
MUSTattempttovalidatethereceivingentity'scertificateinaccordance
withthecertificatevalidationproceduresspecifiedunder
Section13.7.2.
6.Iftheinitiatingentitypresentsacertificate,thereceivingentitytoo
MUSTattempttovalidatetheinitiatingentity'scertificateinaccordance
withthecertificatevalidationproceduresspecifiedunder
Section13.7.2.
7.FollowingsuccessfulTLSnegotiation,allfurtherdatatransmittedby
eitherpartyMUSTbeprotectedwiththenegotiatedalgorithms,keys,
andsecrets(i.e.,encrypted,integrityprotected,orbothdependingon
theciphersuiteused).
SecurityWarning:See Section13.8regardingciphersuitesthatMUST
besupportedforTLSnaturally,otherciphersuitesMAYbesupportedas
well.
TOC
5.4.3.2.TLSFailure
IftheTLSnegotiationresultsinfailure,thereceivingentityMUSTterminatetheTCP
connection.
ThereceivingentityMUSTNOTsendaclosing</stream>tagbeforeterminating
theTCPconnection(sincethefailurehasoccurredattheTLSlayer,nottheXMPP
layerasdescribedunder Section13.3).
TheinitiatingentityMAYattempttoreconnectasexplainedunder Section3.3,with
orwithoutattemptingTLSnegotiation(inaccordancewithlocalservicepolicy,user
configuredpreferences,etc.).
TOC
5.4.3.3.TLSSuccess
IftheTLSnegotiationissuccessful,thentheentitiesMUSTproceedasfollows.
1.TheinitiatingentityMUSTdiscardanyinformationtransmittedinlayers
aboveTCPthatitobtainedfromthereceivingentityinaninsecure
mannerbeforeTLStookeffect(e.g.,thereceivingentity's'from'
addressorthestreamIDandstreamfeaturesreceivedfromthe
receivingentity).
2.ThereceivingentityMUSTdiscardanyinformationtransmittedinlayers
aboveTCPthatitobtainedfromtheinitiatingentityinaninsecure
mannerbeforeTLStookeffect(e.g.,theinitiatingentity's'from'
address).
3.TheinitiatingentityMUSTsendanewinitialstreamheadertothe
receivingentityovertheencryptedconnection(asspecifiedunder
Section4.3.3,theinitiatingentityMUSTNOTsendaclosing</stream>
tagbeforesendingthenewinitialstreamheader,sincethereceiving
entityandinitiatingentityMUSTconsidertheoriginalstreamtobe
replaceduponsuccessoftheTLSnegotiation).
I:<stream:stream
58/164
5/17/2016
to='im.example.com'
version='1.0'
xml:lang='en'
4.ThereceivingentityMUSTrespondwithanewresponsestreamheader
overtheencryptedconnection(forwhichitMUSTgenerateanew
streamIDinsteadofreusingtheoldstreamID).
R:<stream:stream
id='vgKi/bkYME8OAj4rlXMkpucAqe4='
version='1.0'
xml:lang='en'
5.ThereceivingentityalsoMUSTsendstreamfeaturestotheinitiating
entity,whichMUSTNOTincludetheSTARTTLSfeaturebutwhich
SHOULDincludetheSASLstreamfeatureasdescribedunder Section6
(seeespecially Section6.4.1regardingthefewreasonswhytheSASL
streamfeaturewouldnotbeofferedhere).
R:<stream:features>
<mechanismsxmlns='urn:ietf:params:xml:ns:xmppsasl'>
<mechanism>EXTERNAL</mechanism>
<mechanism>SCRAMSHA1PLUS</mechanism>
<mechanism>SCRAMSHA1</mechanism>
<mechanism>PLAIN</mechanism>
</mechanisms>
</stream:features>
6.SASLNegotiation
6.1.Fundamentals
TOC
TOC
XMPPincludesamethodforauthenticatingastreambymeansofanXMPPspecific
profileoftheSimpleAuthenticationandSecurityLayerprotocol(see [SASL]).SASL
providesageneralizedmethodforaddingauthenticationsupporttoconnection
basedprotocols,andXMPPusesanXMLnamespaceprofileofSASLthatconformsto
theprofilingrequirementsof [SASL].TheXMLnamespacenamefortheSASL
extensionis'urn:ietf:params:xml:ns:xmppsasl'.
6.2.Support
TOC
SupportforSASLnegotiationisREQUIREDinXMPPclientandserver
implementations.
59/164
5/17/2016
TOC
TOC
ThepartiestoastreamMUSTconsiderSASLasmandatorytonegotiate.
6.3.2.Restart
TOC
AfterSASLnegotiation,thepartiesMUSTrestartthestream.
6.3.3.MechanismPreferences
TOC
AnyentitythatwillactasaSASLclientoraSASLserverMUSTmaintainanordered
listofitspreferredSASLmechanismsaccordingtotheclientorserver,wherethe
listisorderedaccordingtolocalpolicyoruserconfiguration(whichSHOULDbein
orderofperceivedstrengthtoenablethestrongestauthenticationpossible).The
initiatingentityMUSTmaintainitsownpreferenceorderindependentofthe
preferenceorderofthereceivingentity.AclientMUSTtrySASLmechanismsinits
preferenceorder.Forexample,iftheserverofferstheorderedlist"PLAINSCRAM
SHA1GSSAPI"or"SCRAMSHA1GSSAPIPLAIN"buttheclient'sorderedlistis
"GSSAPISCRAMSHA1",theclientMUSTtryGSSAPIfirstandthenSCRAMSHA1
butMUSTNOTtryPLAIN(sincePLAINisnotonitslist).
6.3.4.MechanismOffers
TOC
Ifthereceivingentityconsiders TLSnegotiationtobemandatorytonegotiate
beforeitwillacceptauthenticationwithaparticularSASLmechanism,itMUSTNOT
advertisethatmechanisminitslistofavailableSASLmechanismsbeforeTLS
negotiationhasbeencompleted.
ThereceivingentitySHOULDoffertheSASLEXTERNALmechanismifbothofthe
followingconditionshold:
1.DuringTLSnegotiationtheinitiatingentitypresentedacertificatethatis
acceptabletothereceivingentityforpurposesofstrongidentity
verificationinaccordancewithlocalservicepolicies(e.g.,becausesaid
certificateisunexpired,isunrevoked,andisanchoredtoaroottrusted
bythereceivingentity).
2.Thereceivingentityexpectsthattheinitiatingentitywillbeableto
authenticateandauthorizeastheidentityprovidedinthecertificatein
thecaseofaservertoserverstream,thereceivingentitymighthave
suchanexpectationbecauseaDNSdomainnamepresentedinthe
initiatingentity'scertificatematchesthedomainreferencedinthe'from'
attributeoftheinitialstreamheader,wherethematchingrulesof
[TLSCERTS]applyinthecaseofaclienttoserverstream,the
receivingentitymighthavesuchanexpectationbecausethebareJID
presentedintheinitiatingentity'scertificatematchesauseraccount
thatisregisteredwiththeserverorbecauseotherinformation
containedintheinitiatingentity'scertificatematchesthatofanentity
thathaspermissiontousetheserverforaccesstoanXMPPnetwork.
60/164
5/17/2016
However,thereceivingentityMAYoffertheSASLEXTERNALmechanismunderother
circumstances,aswell.
WhenthereceivingentityofferstheSASLEXTERNALmechanism,thereceiving
entitySHOULDlisttheEXTERNALmechanismfirstamongitsofferedSASL
mechanismsandtheinitiatingentitySHOULDattemptSASLnegotiationusingthe
EXTERNALmechanismfirst(thispreferencewilltendtoincreasethelikelihoodthat
thepartiescannegotiatemutualcertificateauthentication).
Section13.8specifiesSASLmechanismsthatMUSTbesupportednaturally,other
SASLmechanismsMAYbesupportedaswell.
InformationalNote:BestpracticesfortheuseofSASLinthecontextof
XMPParedescribedin [XEP0175]fortheANONYMOUSmechanismand
in [XEP0178]fortheEXTERNALmechanism.
TOC
ThefollowingdataformattingrulesapplytotheSASLnegotiation:
1.DuringSASLnegotiation,theentitiesMUSTNOTsendanywhitespaceas
separatorsbetweenXMLelements(i.e.,fromthelastcharacterofthe
firstlevel<auth/>elementqualifiedbythe
'urn:ietf:params:xml:ns:xmppsasl'namespaceassentbytheinitiating
entity,untilthelastcharacterofthefirstlevel<success/>element
qualifiedbythe'urn:ietf:params:xml:ns:xmppsasl'namespaceassent
bythereceivingentity).Thisprohibitionhelpstoensurepropersecurity
layerbyteprecision.AnysuchwhitespaceshownintheSASLexamples
providedinthisdocumentisincludedonlyforthesakeofreadability.
2.AnyXMLcharacterdatacontainedwithintheXMLelementsMUSTbe
encodedusingbase64,wheretheencodingadherestothedefinitionin
Section4of [BASE64]andwherethepaddingbitsaresettozero.
3.AsformallyspecifiedintheXMLschemaforthe
'urn:ietf:params:xml:ns:xmppsasl'namespaceunder AppendixA.4,
thereceivingentityMAYincludeoneormoreapplicationspecificchild
elementsinsidethe<mechanisms/>elementtoprovideinformation
thatmightbeneededbytheinitiatingentityinordertocomplete
successfulSASLnegotiationusingoneormoreoftheoffered
mechanismshowever,thesyntaxandsemanticsofallsuchelements
areoutofscopeforthisspecification(see [XEP0233]forone
example).
6.3.6.SecurityLayers
TOC
UponsuccessfulSASLnegotiationthatinvolvesnegotiationofasecuritylayer,both
theinitiatingentityandthereceivingentityMUSTdiscardanyapplicationlayer
state(i.e,statefromtheXMPPlayer,excludingstatefromtheTLSnegotiationor
SASLnegotiation).
6.3.7.SimpleUserName
TOC
SomeSASLmechanisms(e.g.,CRAMMD5,DIGESTMD5,andSCRAM)specifythat
theauthenticationidentityusedinthecontextofsuchmechanismsisa"simpleuser
name"(seeSection2of [SASL]aswellas [SASLPREP]).Theexactformofthe
61/164
5/17/2016
simpleusernameinanyparticularmechanismordeploymentthereofisalocal
matter,andasimpleusernamedoesnotnecessarilymaptoanapplication
identifiersuchasaJIDorJIDcomponent(e.g.,alocalpart).However,inthe
absenceoflocalinformationprovidedbytheserver,anXMPPclientSHOULD
assumethattheauthenticationidentityforsuchaSASLmechanismisasimpleuser
nameequaltothelocalpartoftheuser'sJID.
6.3.8.AuthorizationIdentity
TOC
AnauthorizationidentityisanOPTIONALidentityincludedbytheinitiatingentityto
specifyanidentitytoactas(seeSection2of [SASL]).Inclienttoserverstreams,
itwouldmostlikelybeusedbyanadministratortoperformsomemanagementtask
onbehalfofanotheruser,whereasinservertoserverstreamsitwouldmostlikely
beusedtospecifyaparticularaddonserviceatanXMPPservice(e.g.,amulti
userchatserveratconference.example.comthatishostedbytheexample.com
XMPPservice).Iftheinitiatingentitywishestoactonbehalfofanotherentityand
theselectedSASLmechanismsupportstransmissionofanauthorizationidentity,the
initiatingentityMUSTprovideanauthorizationidentityduringSASLnegotiation.If
theinitiatingentitydoesnotwishtoactonbehalfofanotherentity,itMUSTNOT
provideanauthorizationidentity.
Inthecaseofclienttoservercommunication,thevalueofanauthorizationidentity
MUSTbeabareJID(<localpart@domainpart>)ratherthanafullJID
(<localpart@domainpart/resourcepart>).
Inthecaseofservertoservercommunication,thevalueofanauthorization
identityMUSTbeadomainpartonly(<domainpart>).
IftheinitiatingentityprovidesanauthorizationidentityduringSASLnegotiation,the
receivingentityisresponsibleforverifyingthattheinitiatingentityisinfact
allowedtoassumethespecifiedauthorizationidentityifnot,thereceivingentity
MUSTreturnan<invalidauthzid/>SASLerrorasdescribedunder Section6.5.6.
6.3.9.Realms
TOC
ThereceivingentityMAYincludearealmwhennegotiatingcertainSASL
mechanisms(e.g.,boththeGSSAPIandDIGESTMD5mechanismsallowthe
authenticationexchangetoincludearealm,thoughindifferentways,whereasthe
EXTERNAL,SCRAM,andPLAINmechanismsdonot).Ifthereceivingentitydoesnot
communicatearealm,theinitiatingentityMUSTNOTassumethatanyrealmexists.
TherealmMUSTbeusedonlyforthepurposeofauthenticationinparticular,an
initiatingentityMUSTNOTattempttoderiveanXMPPdomainpartfromtherealm
informationprovidedbythereceivingentity.
6.3.10.RoundTrips
TOC
[SASL]specifiesthatausingprotocolsuchasXMPPcandefinetwomethodsby
whichtheprotocolcansaveroundtripswhereallowedfortheSASLmechanism:
1.WhentheSASLclient(theXMPP"initiatingentity")requestsan
authenticationexchange,itcaninclude"initialresponse"datawithits
requestifappropriatefortheSASLmechanisminuse.InXMPP,thisis
donebyincludingtheinitialresponseastheXMLcharacterdataofthe
<auth/>element.
62/164
5/17/2016
2.Attheendoftheauthenticationexchange,theSASLserver(theXMPP
"receivingentity")caninclude"additionaldatawithsuccess"if
appropriatefortheSASLmechanisminuse.InXMPP,thisisdoneby
includingtheadditionaldataastheXMLcharacterdataofthe
<success/>element.
Forthesakeofprotocolefficiency,itisREQUIREDforclientsandserverstosupport
thesemethodsandRECOMMENDEDtousethemhowever,clientsandserversMUST
supportthelessefficientmodesaswell.
TOC
6.4.Process
TheprocessforSASLnegotiationisasfollows.
TOC
IfSASLnegotiationfollowssuccessful STARTTLSnegotiation,thentheSASL
negotiationoccursovertheprotectedstreamthathasalreadybeennegotiated.If
not,theinitiatingentityresolvestheFQDNofthereceivingentityasspecifiedunder
Section3,opensaTCPconnectiontotheadvertisedportattheresolvedIP
address,andsendsaninitialstreamheadertothereceivingentity.Ineithercase,
thereceivingentitywillreceiveaninitialstreamfromtheinitiatingentity.
I:<stream:stream
to='im.example.com'
version='1.0'
xml:lang='en'
Whenthereceivingentityprocessesaninitialstreamheaderfromtheinitiating
entity,itMUSTsendaresponsestreamheadertotheinitiatingentity(forwhichit
MUSTgenerateauniquestreamID.IfTLSnegotiationhasalreadysucceeded,then
thisstreamIDMUSTbedifferentfromthestreamIDsentbeforeTLSnegotiation
succeeded).
R:<stream:stream
version='1.0'
xml:lang='en'
ThereceivingentityalsoMUSTsendstreamfeaturestotheinitiatingentity.The
streamfeaturesSHOULDincludeanadvertisementforsupportofSASLnegotiation,
i.e.,a<mechanisms/>elementqualifiedbythe'urn:ietf:params:xml:ns:xmppsasl'
namespace.TypicallythereareonlythreecasesinwhichsupportforSASL
negotiationwouldnotbeadvertisedhere:
TLSnegotiationneedstohappenbeforeSASLcanbeoffered(i.e.,TLSis
63/164
5/17/2016
requiredandthereceivingentityisrespondingtotheveryfirstinitial
streamheaderithasreceivedforthisconnectionattempt).
SASLnegotiationisimpossibleforaservertoserverconnection(i.e.,
theinitiatingserverhasnotprovidedacertificatethatwouldenable
strongauthenticationandthereforethereceivingserverisfallingback
toweakidentityverificationusingtheServerDialbackprotocol
[XEP0220]).
SASLhasalreadybeennegotiated(i.e.,thereceivingentityis
respondingtoaninitialstreamheadersentasastreamrestartafter
successfulSASLnegotiation).
The<mechanisms/>elementMUSTcontainone<mechanism/>childelementfor
eachauthenticationmechanismthereceivingentityofferstotheinitiatingentity.As
noted,theorderof<mechanism/>elementsintheXMLindicatesthepreference
orderoftheSASLmechanismsaccordingtothereceivingentity(whichisnot
necessarilythepreferenceorderaccordingtotheinitiatingentity).
R:<stream:features>
</mechanisms>
</stream:features>
6.4.2.Initiation
TOC
InordertobegintheSASLnegotiation,theinitiatingentitysendsan<auth/>
elementqualifiedbythe'urn:ietf:params:xml:ns:xmppsasl'namespaceand
includesanappropriatevalueforthe'mechanism'attribute,thusstartingthe
handshakeforthatparticularauthenticationmechanism.ThiselementMAYcontain
XMLcharacterdata(inSASLterminology,the"initialresponse")ifthemechanism
supportsorrequiresit.Iftheinitiatingentityneedstosendazerolengthinitial
response,itMUSTtransmittheresponseasasingleequalssigncharacter("="),
whichindicatesthattheresponseispresentbutcontainsnodata.
I:<authxmlns='urn:ietf:params:xml:ns:xmppsasl'
mechanism='PLAIN'>AGp1bGlldAByMG0zMG15cjBtMzA=</auth>
Iftheinitiatingentitysubsequentlysendsanother<auth/>elementandtheongoing
authenticationhandshakehasnotyetcompleted,thereceivingentityMUSTdiscard
theongoinghandshakeandMUSTprocessanewhandshakeforthesubsequently
requestedSASLmechanism.
6.4.3.ChallengeResponseSequence
TOC
Ifnecessary,thereceivingentitychallengestheinitiatingentitybysendinga
<challenge/>elementqualifiedbythe'urn:ietf:params:xml:ns:xmppsasl'
namespacethiselementMAYcontainXMLcharacterdata(whichMUSTbe
generatedinaccordancewiththedefinitionoftheSASLmechanismchosenbythe
initiatingentity).
64/164
5/17/2016
Theinitiatingentityrespondstothechallengebysendinga<response/>element
qualifiedbythe'urn:ietf:params:xml:ns:xmppsasl'namespacethiselementMAY
containXMLcharacterdata(whichMUSTbegeneratedinaccordancewiththe
definitionoftheSASLmechanismchosenbytheinitiatingentity).
Ifnecessary,thereceivingentitysendsmorechallengesandtheinitiatingentity
sendsmoreresponses.
Thisseriesofchallenge/responsepairscontinuesuntiloneofthreethingshappens:
Theinitiatingentityabortsthehandshakeforthisauthentication
mechanism.
Thereceivingentityreportsfailureofthehandshake.
Thereceivingentityreportssuccessofthehandshake.
Thesescenariosaredescribedinthefollowingsections.
6.4.4.Abort
TOC
Theinitiatingentityabortsthehandshakeforthisauthenticationmechanismby
sendingan<abort/>elementqualifiedbythe'urn:ietf:params:xml:ns:xmppsasl'
namespace.
I:<abortxmlns='urn:ietf:params:xml:ns:xmppsasl'/>
Uponreceivingan<abort/>element,thereceivingentityMUSTreturna<failure/>
elementqualifiedbythe'urn:ietf:params:xml:ns:xmppsasl'namespaceand
containingan<aborted/>childelement.
R:<failurexmlns='urn:ietf:params:xml:ns:xmppsasl'>
<aborted/>
</failure>
6.4.5.SASLFailure
TOC
Thereceivingentityreportsfailureofthehandshakeforthisauthentication
mechanismbysendinga<failure/>elementqualifiedbythe
'urn:ietf:params:xml:ns:xmppsasl'namespace(theparticularcauseoffailure
MUSTbecommunicatedinanappropriatechildelementofthe<failure/>element
asdefinedunder Section6.5).
<notauthorized/>
</failure>
WhereappropriateforthechosenSASLmechanism,thereceivingentitySHOULD
allowaconfigurablebutreasonablenumberofretries(atleast2andnomorethan
5)thisenablestheinitiatingentity(e.g.,anenduserclient)totolerateincorrectly
providedcredentials(e.g.,amistypedpassword)withoutbeingforcedtoreconnect
(whichitwouldifthereceivingentityimmediatelyreturnedaSASLfailureand
closedthestream).
65/164
5/17/2016
IftheinitiatingentityattemptsareasonablenumberofretrieswiththesameSASL
mechanismandallattemptsfail,itMAYfallbacktothenextmechanisminits
orderedlistbysendinganew<auth/>requesttothereceivingentity,thusstarting
anewhandshakeforthatauthenticationmechanism.Ifallhandshakesfailand
therearenoremainingmechanismsintheinitiatingentity'slistofsupportedand
acceptablemechanisms,theinitiatingentitySHOULDsimplyclosethestreamas
describedunder Section4.4(insteadofwaitingforthestreamtotimeout).
Iftheinitiatingentityexceedsthenumberofretries,thereceivingentityMUST
closethestreamwithastreamerror,whichSHOULDbe<policyviolation/>
(Section4.9.3.14),althoughsomeexistingimplementationssend<not
authorized/>(Section4.9.3.12)instead.
ImplementationNote:Forservertoserverstreams,ifthereceiving
entitycannotoffertheSASLEXTERNALmechanismoranyotherSASL
mechanismbasedonthesecuritycontextestablishedduringTLS
negotiation,thereceivingentityMAYattempttocompleteweakidentity
verificationusingtheServerDialbackprotocol [XEP0220]however,if
accordingtolocalservicepoliciesweakidentityverificationis
insufficientthenthereceivingentitySHOULDinsteadclosethestream
witha<policyviolation/>streamerror(Section4.9.3.14)insteadof
waitingforthestreamtotimeout.
6.4.6.SASLSuccess
TOC
BeforeconsideringtheSASLhandshaketobeasuccess,iftheinitiatingentity
provideda'from'attributeonaninitialstreamheaderwhoseconfidentialityand
integritywereprotectedviaTLSoranequivalentsecuritylayer(suchastheSASL
GSSAPImechanism)thenthereceivingentitySHOULDcorrelatetheauthentication
identityresultingfromtheSASLnegotiationwiththat'from'addressifthetwo
identitiesdonotmatchthenthereceivingentitySHOULDterminatetheconnection
attempt(however,thereceivingentitymighthavelegitimatereasonsnotto
terminatetheconnectionattempt,forexample,becauseithasoverriddena
connectingclient'saddresstocorrecttheJIDformatorassignaJIDbasedon
informationpresentedinanendusercertificate).
Thereceivingentityreportssuccessofthehandshakebysendinga<success/>
elementqualifiedbythe'urn:ietf:params:xml:ns:xmppsasl'namespacethis
elementMAYcontainXMLcharacterdata(inSASLterminology,"additionaldatawith
success")ifthechosenSASLmechanismsupportsorrequiresit.Ifthereceiving
entityneedstosendadditionaldataofzerolength,itMUSTtransmitthedataasa
singleequalssigncharacter("=").
R:<successxmlns='urn:ietf:params:xml:ns:xmppsasl'/>
InformationalNote:Forclienttoserverstreams,theauthorization
identitycommunicatedduringSASLnegotiationisusedtodeterminethe
canonicaladdressfortheinitiatingclientaccordingtothereceiving
server,asdescribedunder Section4.3.6.
Uponreceivingthe<success/>element,theinitiatingentityMUSTinitiateanew
streamovertheexistingTCPconnectionbysendinganewinitialstreamheaderto
thereceivingentity(asspecifiedunder Section4.3.3,theinitiatingentityMUST
NOTsendaclosing</stream>tagbeforesendingthenewinitialstreamheader,
sincethereceivingentityandinitiatingentityMUSTconsidertheoriginalstreamto
bereplaceduponsuccessoftheSASLnegotiation).
66/164
5/17/2016
I:<stream:stream
to='im.example.com'
version='1.0'
xml:lang='en'
Uponreceivingthenewinitialstreamheaderfromtheinitiatingentity,thereceiving
entityMUSTrespondbysendinganewresponsestreamheadertotheinitiating
entity(forwhichitMUSTgenerateanewstreamIDinsteadofreusingtheold
streamID).
R:<stream:stream
id='gPybzaOzBmaADgxKXu9UClbprp0='
version='1.0'
xml:lang='en'
ThereceivingentityMUSTalsosendstreamfeatures,containinganyfurther
availablefeaturesorcontainingnofeatures(viaanempty<features/>element).
R:<stream:features>
</stream:features>
6.5.SASLErrors
TOC
ThesyntaxofSASLerrorsisasfollows,wheretheXMLdatashownwithinthe
squarebrackets'['and']'isOPTIONAL.
<failurexmlns='urn:ietf:params:xml:ns:xmppsasl'>
<definedcondition/>
[<textxml:lang='langcode'>
</text>]
</failure>
The"definedcondition"MUSTbeoneoftheSASLrelatederrorconditionsdefinedin
thefollowingsections.However,becauseadditionalerrorconditionsmightbe
definedinthefuture,ifanentityreceivesaSASLerrorconditionthatitdoesnot
understandthenitMUSTtreattheunknownconditionasagenericauthentication
failure,i.e.,asequivalentto<notauthorized/>(Section6.5.10).
Inclusionofthe<text/>elementisOPTIONAL,andcanbeusedtoprovide
applicationspecificinformationabouttheerrorcondition,whichinformationMAYbe
displayedtoahumanbutonlyasasupplementtothedefinedcondition.
BecauseXMPPitselfdefinesanapplicationprofileofSASLandthereisno
expectationthatmorespecializedXMPPapplicationswillbebuiltontopofSASL,the
67/164
5/17/2016
SASLerrorformatdoesnotprovideextensibilityforapplicationspecificerror
conditionsasisdoneforXMLstreams(Section4.9.4)andXMLstanzas
(Section8.3.4).
6.5.1.aborted
TOC
Thereceivingentityacknowledgesthattheauthenticationhandshakehasbeen
abortedbytheinitiatingentitysentinreplytothe<abort/>element.
I:<abortxmlns='urn:ietf:params:xml:ns:xmppsasl'/>
<aborted/>
</failure>
6.5.2.accountdisabled
TOC
Theaccountoftheinitiatingentityhasbeentemporarilydisabledsentinreplyto
an<auth/>element(withorwithoutinitialresponsedata)ora<response/>
element.
<accountdisabled/>
<textxml:lang='en'>Call2125551212forassistance.</text>
</failure>
6.5.3.credentialsexpired
TOC
Theauthenticationfailedbecausetheinitiatingentityprovidedcredentialsthathave
expiredsentinreplytoa<response/>elementoran<auth/>elementwithinitial
responsedata.
I:<responsexmlns='urn:ietf:params:xml:ns:xmppsasl'>
[...]
</response>
<credentialsexpired/>
</failure>
6.5.4.encryptionrequired
TOC
Themechanismrequestedbytheinitiatingentitycannotbeusedunlessthe
confidentialityandintegrityoftheunderlyingstreamareprotected(typicallyvia
TLS)sentinreplytoan<auth/>element(withorwithoutinitialresponsedata).
68/164
5/17/2016
<encryptionrequired/>
</failure>
6.5.5.incorrectencoding
TOC
Thedataprovidedbytheinitiatingentitycouldnotbeprocessedbecausethebase
64encodingisincorrect(e.g.,becausetheencodingdoesnotadheretothe
definitioninSection4of [BASE64])sentinreplytoa<response/>elementoran
<auth/>elementwithinitialresponsedata.
mechanism='DIGESTMD5'>[...]</auth>
<incorrectencoding/>
</failure>
6.5.6.invalidauthzid
TOC
Theauthzidprovidedbytheinitiatingentityisinvalid,eitherbecauseitis
incorrectlyformattedorbecausetheinitiatingentitydoesnothavepermissionsto
authorizethatIDsentinreplytoa<response/>elementoran<auth/>element
withinitialresponsedata.
[...]
</response>
<invalidauthzid/>
</failure>
6.5.7.invalidmechanism
TOC
Theinitiatingentitydidnotspecifyamechanism,orrequestedamechanismthatis
notsupportedbythereceivingentitysentinreplytoan<auth/>element.
mechanism='CRAMMD5'/>
<invalidmechanism/>
</failure>
69/164
5/17/2016
6.5.8.malformedrequest
TOC
Therequestismalformed(e.g.,the<auth/>elementincludesinitialresponsedata
butthemechanismdoesnotallowthat,orthedatasentviolatesthesyntaxforthe
specifiedSASLmechanism)sentinreplytoan<abort/>,<auth/>,<challenge/>,
or<response/>element.
(Inthefollowingexample,theXMLcharacterdataofthe<auth/>elementcontains
morethan255UTF8encodedUnicodecharactersandthereforeviolatesthe"token"
productionfortheSASLANONYMOUSmechanismasspecifiedin [ANONYMOUS].)
mechanism='ANONYMOUS'>[...somelongtoken...]</auth>
<malformedrequest/>
</failure>
6.5.9.mechanismtooweak
TOC
Themechanismrequestedbytheinitiatingentityisweakerthanserverpolicy
permitsforthatinitiatingentitysentinreplytoan<auth/>element(withor
withoutinitialresponsedata).
<mechanismtooweak/>
</failure>
6.5.10.notauthorized
TOC
Theauthenticationfailedbecausetheinitiatingentitydidnotprovideproper
credentials,orbecausesomegenericauthenticationfailurehasoccurredbutthe
receivingentitydoesnotwishtodisclosespecificinformationaboutthecauseofthe
failuresentinreplytoa<response/>elementoran<auth/>elementwithinitial
responsedata.
[...]
</response>
<notauthorized/>
</failure>
SecurityWarning:Thiserrorconditionincludesbutisnotlimitedtothe
caseofincorrectcredentialsoranonexistentusername.Inorderto
discouragedirectoryharvestattacks,nodifferentiationismadebetween
incorrectcredentialsandanonexistentusername.
70/164
5/17/2016
6.5.11.temporaryauthfailure
TOC
Theauthenticationfailedbecauseofatemporaryerrorconditionwithinthe
receivingentity,anditisadvisablefortheinitiatingentitytotryagainlatersentin
replytoan<auth/>elementora<response/>element.
[...]
</response>
<temporaryauthfailure/>
</failure>
6.6.SASLDefinition
TOC
Theprofilingrequirementsof [SASL]requirethatthefollowinginformationbe
suppliedbythedefinitionofausingprotocol.
servicename:
"xmpp"
initiationsequence:
AftertheinitiatingentityprovidesanopeningXMLstreamheaderandthe
receivingentityrepliesinkind,thereceivingentityprovidesalistof
acceptableauthenticationmethods.Theinitiatingentitychoosesone
methodfromthelistandsendsittothereceivingentityasthevalueof
the'mechanism'attributepossessedbyan<auth/>element,optionally
includinganinitialresponsetoavoidaroundtrip.
exchangesequence:
Challengesandresponsesarecarriedthroughtheexchangeof
<challenge/>elementsfromreceivingentitytoinitiatingentityand
<response/>elementsfrominitiatingentitytoreceivingentity.The
receivingentityreportsfailurebysendinga<failure/>elementand
successbysendinga<success/>elementtheinitiatingentityabortsthe
exchangebysendingan<abort/>element.Uponsuccessfulnegotiation,
bothsidesconsidertheoriginalXMLstreamtobeclosedandnewstream
headersaresentbybothentities.
securitylayernegotiation:
Thesecuritylayertakeseffectimmediatelyaftersendingtheclosing'>'
characterofthe<success/>elementforthereceivingentity,and
immediatelyafterreceivingtheclosing'>'characterofthe<success/>
elementfortheinitiatingentity.Theorderoflayersisfirst [TCP],then
[TLS],then [SASL],thenXMPP.
useoftheauthorizationidentity:
TheauthorizationidentitycanbeusedinXMPPtodenotethenondefault
<localpart@domainpart>ofaclientanemptystringisequivalenttoan
absentauthorizationidentity.
7.ResourceBinding
TOC
TOC
71/164
5/17/2016
7.1.Fundamentals
Afteraclientauthenticateswithaserver,itMUSTbindaspecificresourcetothe
streamsothattheservercanproperlyaddresstheclient.Thatis,thereMUSTbe
anXMPPresourceassociatedwiththebareJID(<localpart@domainpart>)ofthe
client,sothattheaddressforuseoverthatstreamisafullJIDoftheform
<localpart@domainpart/resource>(includingtheresourcepart).Thisensuresthat
theservercandeliverXMLstanzastoandreceiveXMLstanzasfromtheclientin
relationtoentitiesotherthantheserveritselfortheclient'saccount,asexplained
under Section10.
InformationalNote:Theclientcouldexchangestanzaswiththeserver
itselfortheclient'saccountbeforebindingaresourcesincethefullJID
isneededonlyforaddressingoutsidethecontextofthestream
negotiatedbetweentheclientandtheserver,butthisisnotcommonly
done.
Afteraclienthasboundaresourcetothestream,itisreferredtoasa"connected
resource".AserverSHOULDallowanentitytomaintainmultipleconnected
resourcessimultaneously,whereeachconnectedresourceisassociatedwitha
distinctXMLstreamandisdifferentiatedfromtheotherconnectedresourcesbya
distinctresourcepart.
SecurityWarning:AserverSHOULDenabletheadministratorofan
XMPPservicetolimitthenumberofconnectedresourcesinorderto
preventcertaindenialofserviceattacksasdescribedunder
Section13.12.
If,beforecompletingtheresourcebindingstep,theclientattemptstosendanXML
stanzatoanentityotherthantheserveritselfortheclient'saccount,theserver
MUSTNOTprocessthestanzaandMUSTclosethestreamwitha<notauthorized/>
streamerror(Section4.9.3.12).
TheXMLnamespacenamefortheresourcebindingextensionis
'urn:ietf:params:xml:ns:xmppbind'.
7.2.Support
TOC
SupportforresourcebindingisREQUIREDinXMPPclientandserver
implementations.
TOC
TOC
ThepartiestoastreamMUSTconsiderresourcebindingasmandatorytonegotiate.
7.3.2.Restart
TOC
Afterresourcebinding,thepartiesMUSTNOTrestartthestream.
72/164
5/17/2016
7.4.AdvertisingSupport
TOC
UponsendinganewresponsestreamheadertotheclientaftersuccessfulSASL
negotiation,theserverMUSTincludea<bind/>elementqualifiedbythe
'urn:ietf:params:xml:ns:xmppbind'namespaceinthestreamfeaturesitpresents
totheclient.
TheserverMUSTNOTincludetheresourcebindingstreamfeatureuntilafterthe
clienthasauthenticated,typicallybymeansofsuccessfulSASLnegotiation.
S:<stream:stream
version='1.0'
xml:lang='en'
S:<stream:features>
</stream:features>
Uponbeinginformedthatresourcebindingismandatorytonegotiate,theclient
MUSTbindaresourcetothestreamasdescribedinthefollowingsections.
7.5.GenerationofResourceIdentifiers
TOC
AresourcepartMUSTataminimumbeuniqueamongtheconnectedresourcesfor
that<localpart@domainpart>.Enforcementofthispolicyistheresponsibilityofthe
server.
SecurityWarning:Aresourcepartcanbesecuritycritical.Forexample,
ifamaliciousentitycanguessaclient'sresourcepartthenitmightbe
abletodetermineiftheclient(andthereforethecontrollingprincipal)is
onlineoroffline,thusresultinginapresenceleakasdescribedunder
Section13.10.2.Topreventthatpossibility,aclientcaneither(1)
generatearandomresourcepartonitsownor(2)asktheserverto
generatearesourcepartonitsbehalf.Onemethodforensuringthatthe
resourcepartisrandomistogenerateaUniversallyUniqueIdentifier
(UUID)asspecifiedin [UUID].
7.6.ServerGeneratedResourceIdentifier
TOC
AserverMUSTbeabletogenerateanXMPPresourcepartonbehalfofaclient.The
resourcepartgeneratedbytheserverMUSTberandom(see [RANDOM]).
7.6.1.SuccessCase
TOC
AclientrequestsaservergeneratedresourcepartbysendinganIQstanzaoftype
"set"(see Section8.2.3)containinganempty<bind/>elementqualifiedbythe
'urn:ietf:params:xml:ns:xmppbind'namespace.
73/164
5/17/2016
C:<iqid='tn281v37'type='set'>
</iq>
OncetheserverhasgeneratedanXMPPresourcepartfortheclient,itMUSTreturn
anIQstanzaoftype"result"totheclient,whichMUSTincludea<jid/>child
elementthatspecifiesthefullJIDfortheconnectedresourceasdeterminedbythe
server.
S:<iqid='tn281v37'type='result'>
<bindxmlns='urn:ietf:params:xml:ns:xmppbind'>
<jid>
juliet@im.example.com/4db06f061ea411dcaca3000bcd821bfb
</jid>
</bind>
</iq>
7.6.2.ErrorCases
TOC
Whenaclientaskstheservertogeneratearesourcepartduringresourcebinding,
thefollowingstanzaerrorconditionsaredefined:
Theaccounthasreachedalimitonthenumberofsimultaneous
connectedresourcesallowed.
Theclientisotherwisenotallowedtobindaresourcetothestream.
Naturally,itispossiblethaterrorconditionsnotspecifiedheremightoccur,as
describedunder Section8.3.
7.6.2.1.ResourceConstraint
TOC
Iftheaccounthasreachedalimitonthenumberofsimultaneousconnected
resourcesallowed,theserverMUSTreturna<resourceconstraint/>stanzaerror
(Section8.3.3.18).
S:<iqid='tn281v37'type='error'>
<errortype='wait'>
<resourceconstraint
xmlns='urn:ietf:params:xml:ns:xmppstanzas'/>
</error>
</iq>
7.6.2.2.NotAllowed
TOC
Iftheclientisotherwisenotallowedtobindaresourcetothestream,theserver
MUSTreturna<notallowed/>stanzaerror(Section8.3.3.10).
S:<iqid='tn281v37'type='error'>
<errortype='cancel'>
74/164
5/17/2016
<notallowed
</error>
</iq>
7.7.ClientSubmittedResourceIdentifier
TOC
Insteadofaskingtheservertogeneratearesourcepartonitsbehalf,aclientMAY
attempttosubmitaresourcepartthatithasgeneratedorthatthecontrollinguser
hasprovided.
7.7.1.SuccessCase
TOC
AclientasksitsservertoacceptaclientsubmittedresourcepartbysendinganIQ
stanzaoftype"set"containinga<bind/>elementwithachild<resource/>
elementcontainingnonzerolengthXMLcharacterdata.
C:<iqid='wy2xa82b4'type='set'>
<resource>balcony</resource>
</bind>
</iq>
TheserverSHOULDaccepttheclientsubmittedresourcepart.Itdoessoby
returninganIQstanzaoftype"result"totheclient,includinga<jid/>childelement
thatspecifiesthefullJIDfortheconnectedresourceandcontainswithout
modificationtheclientsubmittedtext.
S:<iqid='wy2xa82b4'type='result'>
<jid>juliet@im.example.com/balcony</jid>
</bind>
</iq>
Alternatively,inaccordancewithlocalservicepoliciestheserverMAYrefusethe
clientsubmittedresourcepartandoverrideitwitharesourcepartthattheserver
generates.
<jid>
juliet@im.example.com/balcony4db06f061ea411dcaca3000bcd821bfb
</jid>
</bind>
</iq>
7.7.2.ErrorCases
TOC
WhenaclientattemptstosubmititsownXMPPresourcepartduringresource
75/164
5/17/2016
binding,thefollowingstanzaerrorconditionsaredefinedinadditiontothose
describedunder Section7.6.2:
Theprovidedresourcepartcannotbeprocessedbytheserver.
Theprovidedresourcepartisalreadyinuse.
Naturally,itispossiblethaterrorconditionsnotspecifiedheremightoccur,as
7.7.2.1.BadRequest
TOC
Iftheprovidedresourcepartcannotbeprocessedbytheserver(e.g.,becauseitis
ofzerolengthorbecauseitotherwiseviolatestherulesforresourcepartsspecified
in [XMPPADDR]),theservercanreturna<badrequest/>stanzaerror
(Section8.3.3.1)butSHOULDinsteadprocesstheresourcepartsothatitisin
conformance.
S:<iqid='wy2xa82b4'type='error'>
<errortype='modify'>
<badrequestxmlns='urn:ietf:params:xml:ns:xmppstanzas'/>
</error>
</iq>
7.7.2.2.Conflict
TOC
Ifthereisacurrentlyconnectedclientwhosesessionhastheresourcepartbeing
requestedbythenewlyconnectingclient,theserverMUSTdooneofthefollowing
(whichofthesetheserverdoesisamatterforimplementationorlocalservice
policy,althoughsuggestionsareprovidedbelow).
1.Overridetheresourcepartprovidedbythenewlyconnectingclientwith
aservergeneratedresourcepart.Thisbehaviorisencouraged,because
itsimplifiestheresourcebindingprocessforclientimplementations.
2.Disallowtheresourcebindingattemptofthenewlyconnectingclientand
maintainthesessionofthecurrentlyconnectedclient.Thisbehavioris
neitherencouragednordiscouraged,despitethefactthatitwas
implicitlyencouragedinRFC3920however,notethathandlingofthe
<conflict/>errorisunevenlysupportedamongexistingclient
implementations,whichoftentreatitasanauthenticationerrorand
havebeenobservedtodiscardcachedcredentialswhenreceivingit.
3.Terminatethesessionofthecurrentlyconnectedclientandallowthe
resourcebindingattemptofthenewlyconnectingclient.Althoughthis
wasthetraditionalbehaviorofearlyXMPPserverimplementations,itis
nowdiscouragedbecauseitcanleadtoaneverendingcycleoftwo
clientseffectivelydisconnectingeachotherhowever,notethatthis
behaviorcanbeappropriateinsomedeploymentscenariosorifthe
serverknowsthatthecurrentlyconnectedclienthasadeadconnection
orbrokenstreamasdescribedunder Section4.6.
Iftheserverfollowsbehavior#1,itreturnsan<iq/>stanzaoftype"result"tothe
newlyconnectingclient,wherethe<jid/>childofthe<bind/>elementcontains
XMLcharacterdatathatindicatesthefullJIDoftheclient,includingthe
resourcepartthatwasgeneratedbytheserver.
76/164
5/17/2016
<jid>
juliet@im.example.com/balcony4db06f061ea411dcaca3000bcd821bfb
</jid>
</bind>
</iq>
Iftheserverfollowsbehavior#2,itsendsa<conflict/>stanzaerror
(Section8.3.3.2)inresponsetotheresourcebindingattemptofthenewly
connectingclientbutmaintainstheXMLstreamsothatthenewlyconnectingclient
hasanopportunitytonegotiateanonconflictingresourcepart(i.e.,thenewly
connectingclientneedstochooseadifferentresourcepartbeforemakinganother
attempttobindaresource).
<conflictxmlns='urn:ietf:params:xml:ns:xmppstanzas'/>
</error>
</iq>
Iftheserverfollowsbehavior#3,itreturnsa<conflict/>streamerror
(Section4.9.3.3)tothecurrentlyconnectedclient(asdescribedunder
Section4.9.3.3)andreturnsanIQstanzaoftype"result"(indicatingsuccess)in
responsetotheresourcebindingattemptofthenewlyconnectingclient.
<jid>
juliet@im.example.com/balcony
</jid>
</bind>
</iq>
7.7.3.Retries
TOC
Ifanerroroccurswhenaclientsubmitsaresourcepart,theserverSHOULDallowa
configurablebutreasonablenumberofretries(atleast5andnomorethan10)this
enablestheclienttotolerateincorrectlyprovidedresourceparts(e.g.,baddata
formatsorduplicatetextstrings)withoutbeingforcedtoreconnect.
Aftertheclienthasreachedtheretrylimit,theserverMUSTclosethestreamwith
a<policyviolation/>streamerror(Section4.9.3.14).
8.XMLStanzas
TOC
Afteraclientandaserver(ortwoservers)havecompletedstreamnegotiation,
eitherpartycansendXMLstanzas.ThreekindsofXMLstanzaaredefinedforthe
'jabber:client'and'jabber:server'namespaces:<message/>,<presence/>,and
<iq/>.Inaddition,therearefivecommonattributesforthesestanzatypes.These
commonattributes,aswellasthebasicsemanticsofthethreestanzatypes,are
definedinthisspecificationmoredetailedinformationregardingthesyntaxofXML
stanzasforinstantmessagingandpresenceapplicationsisprovidedin [XMPPIM],
77/164
5/17/2016
andforotherapplicationsintherelevantXMPPextensionspecifications.
SupportfortheXMLstanzasyntaxandsemanticsdefinedinthisspecificationis
REQUIREDinXMPPclientandserverimplementations.
SecurityWarning:AserverMUSTNOTprocessapartialstanzaand
MUSTNOTattachmeaningtothetransmissiontimingofanypartofa
stanza(beforereceiptoftheclosingtag).
8.1.CommonAttributes
TOC
Thefollowingfiveattributesarecommontomessage,presence,andIQstanzas.
TOC
8.1.1.to
The'to'attributespecifiestheJIDoftheintendedrecipientforthestanza.
<messageto='romeo@example.net'>
</message>
ForinformationaboutserverprocessingofinboundandoutboundXMLstanzas
basedonthe'to'address,referto Section10.
TOC
Thefollowingrulesapplytoinclusionofthe'to'attributeinstanzassentfroma
connectedclienttoitsserveroveranXMLstreamqualifiedbythe'jabber:client'
namespace.
1.Astanzawithaspecificintendedrecipient(e.g.,aconversationpartner,
aremoteservice,theserveritself,evenanotherresourceassociated
withtheuser'sbareJID)MUSTpossessa'to'attributewhosevalueisan
XMPPaddress.
2.Astanzasentfromaclienttoaserverfordirectprocessingbythe
server(e.g.,rosterprocessingasdescribedin [XMPPIM]orpresence
senttotheserverforbroadcastingtootherentities)MUSTNOTpossess
a'to'attribute.
Thefollowingrulesapplytoinclusionofthe'to'attributeinstanzassentfroma
servertoaconnectedclientoveranXMLstreamqualifiedbythe'jabber:client'
namespace.
1.Iftheserverhasreceivedthestanzafromanotherconnectedclientor
fromapeerserver,theserverMUSTNOTmodifythe'to'addressbefore
deliveringthestanzatotheclient.
2.Iftheserverhasitselfgeneratedthestanza(e.g.,aresponsetoanIQ
stanzaoftype"get"or"set",evenifthestanzadidnotincludea'to'
address),thestanzaMAYincludea'to'address,whichMUSTbethefull
JIDoftheclienthowever,ifthestanzadoesnotincludea'to'address
thentheclientMUSTtreatitasifthe'to'addresswereincludedwitha
valueoftheclient'sfullJID.
78/164
5/17/2016
ImplementationNote:Itistheserver'sresponsibilitytodeliveronly
stanzasthatareaddressedtotheclient'sfullJIDortheuser'sbareJID
thus,thereisnoneedfortheclienttocheckthe'to'addressofincoming
stanzas.However,iftheclientdoescheckthe'to'addressthenitis
suggestedtocheckatmostthebareJIDportion(notthefullJID),since
the'to'addressmightbetheuser'sbareJID,theclient'scurrentfullJID,
orevenafullJIDwithadifferentresourcepart(e.g.,inthecaseofso
called"offlinemessages"asdescribedin [XEP0160]).
TOC
Thefollowingrulesapplytoinclusionofthe'to'attributeinthecontextofXML
streamsqualifiedbythe'jabber:server'namespace(i.e.,servertoserverstreams).
1.AstanzaMUSTpossessa'to'attributewhosevalueisanXMPPaddress
ifaserverreceivesastanzathatdoesnotmeetthisrestriction,itMUST
closethestreamwithan<improperaddressing/>streamerror
(Section4.9.3.7).
2.ThedomainpartoftheJIDcontainedinthestanza's'to'attributeMUST
matchtheFQDNofthereceivingserver(oranyvalidateddomain
thereof)ascommunicatedviaSASLnegotiation(see Section6),Server
Dialback(see [XEP0220]),orsimilarmeansifaserverreceivesa
stanzathatdoesnotmeetthisrestriction,itMUSTclosethestreamwith
a<hostunknown/>streamerror(Section4.9.3.6)ora<hostgone/>
TOC
8.1.2.from
The'from'attributespecifiestheJIDofthesender.
<messagefrom='juliet@im.example.com/balcony'
to='romeo@example.net'>
</message>
TOC
Thefollowingrulesapplytothe'from'attributeinthecontextofXMLstreams
qualifiedbythe'jabber:client'namespace(i.e.,clienttoserverstreams).
1.WhenaserverreceivesanXMLstanzafromaconnectedclient,the
serverMUSTadda'from'attributetothestanzaoroverridethe'from'
attributespecifiedbytheclient,wherethevalueofthe'from'attribute
MUSTbethefullJID(<localpart@domainpart/resource>)determinedby
theserverfortheconnectedresourcethatgeneratedthestanza(see
Section4.3.6),orthebareJID(<localpart@domainpart>)inthecase
ofsubscriptionrelatedpresencestanzas(see [XMPPIM]).
2.Whentheservergeneratesastanzaonitsownbehalffordeliverytothe
clientfromtheserveritself,thestanzaMUSTincludea'from'attribute
whosevalueisthebareJID(i.e.,<domainpart>)oftheserveras
agreeduponduringstreamnegotiation(e.g.,basedonthe'to'attribute
oftheinitialstreamheader).
79/164
5/17/2016
3.Whentheservergeneratesastanzafromtheserverfordeliverytothe
clientonbehalfoftheaccountoftheconnectedclient(e.g.,inthe
contextofdatastorageservicesprovidedbytheserveronbehalfofthe
client),thestanzaMUSTeither(a)notincludea'from'attributeor(b)
includea'from'attributewhosevalueistheaccount'sbareJID
(<localpart@domainpart>).
4.AserverMUSTNOTsendtotheclientastanzawithouta'from'attribute
ifthestanzawasnotgeneratedbytheserveronitsownbehalf(e.g.,if
itwasgeneratedbyanotherclientorapeerserverandtheserveris
merelydeliveringittotheclientonbehalfofsomeotherentity)
therefore,whenaclientreceivesastanzathatdoesnotincludea'from'
attribute,itMUSTassumethatthestanzaisfromtheuser'saccounton
theserver.
TOC
Thefollowingrulesapplytothe'from'attributeinthecontextofXMLstreams
qualifiedbythe'jabber:server'namespace(i.e.,servertoserverstreams).
1.AstanzaMUSTpossessa'from'attributewhosevalueisanXMPP
addressifaserverreceivesastanzathatdoesnotmeetthis
restriction,itMUSTclosethestreamwithan<improperaddressing/>
2.ThedomainpartoftheJIDcontainedinthestanza's'from'attribute
MUSTmatchtheFQDNofthesendingserver(oranyvalidateddomain
thereof)ascommunicatedviaSASLnegotiation(see Section6),Server
Dialback(see [XEP0220]),orsimilarmeansifaserverreceivesa
stanzathatdoesnotmeetthisrestriction,itMUSTclosethestreamwith
an<invalidfrom/>streamerror(Section4.9.3.9).
Enforcementoftheseruleshelpstopreventcertaindenialofserviceattacksas
8.1.3.id
TOC
The'id'attributeisusedbytheoriginatingentitytotrackanyresponseorerror
stanzathatitmightreceiveinrelationtothegeneratedstanzafromanotherentity
(suchasanintermediateserverortheintendedrecipient).
Itisuptotheoriginatingentitywhetherthevalueofthe'id'attributeisuniqueonly
withinitscurrentstreamoruniqueglobally.
For<message/>and<presence/>stanzas,itisRECOMMENDEDfortheoriginating
entitytoincludean'id'attributefor<iq/>stanzas,itisREQUIRED.
Ifthegeneratedstanzaincludesan'id'attributethenitisREQUIREDforthe
responseorerrorstanzatoalsoincludean'id'attribute,wherethevalueofthe'id'
attributeMUSTmatchthatofthegeneratedstanza.
ThesemanticsofIQstanzasimposeadditionalrestrictionsasdescribedunder
Section8.2.3.
8.1.4.type
TOC
The'type'attributespecifiesthepurposeorcontextofthemessage,presence,orIQ
80/164
5/17/2016
stanza.Theparticularallowablevaluesforthe'type'attributevarydependingon
whetherthestanzaisamessage,presence,orIQstanza.Thedefinedvaluesfor
messageandpresencestanzasarespecifictoinstantmessagingandpresence
applicationsandthereforearedefinedin [XMPPIM],whereasthevaluesforIQ
stanzasspecifythepartofthesemanticsforallstructuredrequestresponse
exchanges(nomatterwhatthepayload)andthereforearespecifiedunder
Section8.2.3.Theonly'type'valuecommontoallthreekindsofstanzasis"error"
asdescribedunder Section8.3.
8.1.5.xml:lang
TOC
AstanzaSHOULDpossessan'xml:lang'attribute(asdefinedinSection2.12of
[XML])ifthestanzacontainsXMLcharacterdatathatisintendedtobepresentedto
ahumanuser(asexplainedin [CHARSETS],"internationalizationisforhumans").
Thevalueofthe'xml:lang'attributespecifiesthedefaultlanguageofanysuch
humanreadableXMLcharacterdata.
<presencefrom='romeo@example.net/orchard'xml:lang='en'>
<show>dnd</show>
<status>WooingJuliet</status>
</presence>
Thevalueofthe'xml:lang'attributeMAYbeoverriddenbythe'xml:lang'attributeof
aspecificchildelement.
<presencefrom='romeo@example.net/orchard'xml:lang='en'>
<show>dnd</show>
<statusxml:lang='cs'>Dvo&#x0159&#x00EDmseJulii</status>
</presence>
Ifanoutboundstanzageneratedbyaclientdoesnotpossessan'xml:lang'attribute,
theclient'sserverSHOULDaddan'xml:lang'attributewhosevalueisthatspecified
fortheclient'soutputstreamasdefinedunder Section4.7.4.
C:<presencefrom='romeo@example.net/orchard'>
<show>dnd</show>
</presence>
S:<presencefrom='romeo@example.net/orchard'
xml:lang='en'>
<show>dnd</show>
</presence>
Ifaninboundstanzareceivedbyaclientorserverdoesnotpossessan'xml:lang'
attribute,animplementationMUSTassumethatthedefaultlanguageisthat
specifiedfortheentity'sinputstreamasdefinedunder Section4.7.4.
Thevalueofthe'xml:lang'attributeMUSTconformtotheNMTOKENdatatype(as
definedinSection2.3of [XML])andMUSTconformtotheformatdefinedin
81/164
5/17/2016
[LANGTAGS].
AserverMUSTNOTmodifyordelete'xml:lang'attributesonstanzasitreceives
fromotherentities.
8.2.BasicSemantics
8.2.1.MessageSemantics
TOC
TOC
The<message/>stanzaisa"push"mechanismwherebyoneentitypushes
informationtoanotherentity,similartothecommunicationsthatoccurinasystem
suchasemail.Allmessagestanzaswillpossessa'to'attributethatspecifiesthe
intendedrecipientofthemessage(see Section8.1.1and Section10.3),unless
themessageisbeingsenttothebareJIDofaconnectedclient'saccount.Upon
receivingamessagestanzawitha'to'address,aserverSHOULDattempttoroute
ordeliverittotheintendedrecipient(see Section10forgeneralroutingand
deliveryrulesrelatedtoXMLstanzas).
8.2.2.PresenceSemantics
TOC
The<presence/>stanzaisaspecialized"broadcast"or"publishsubscribe"
mechanism,wherebymultipleentitiesreceiveinformation(inthiscase,network
availabilityinformation)aboutanentitytowhichtheyhavesubscribed.Ingeneral,
apublishingclientSHOULDsendapresencestanzawithno'to'attribute,inwhich
casetheservertowhichtheclientisconnectedwillbroadcastthatstanzatoall
subscribedentities.However,apublishingclientMAYalsosendapresencestanza
witha'to'attribute,inwhichcasetheserverwillrouteordeliverthatstanzatothe
intendedrecipient.Althoughthe<presence/>stanzaismostoftenusedbyXMPP
clients,itcanalsobeusedbyservers,addonservices,andanyotherkindofXMPP
entity.See Section10forgeneralroutinganddeliveryrulesrelatedtoXML
stanzas,and [XMPPIM]forrulesspecifictopresenceapplications.
8.2.3.IQSemantics
TOC
Info/Query,orIQ,isa"requestresponse"mechanism,similarinsomewaystothe
HypertextTransferProtocol [HTTP].ThesemanticsofIQenableanentitytomake
arequestof,andreceivearesponsefrom,anotherentity.Thedatacontentofthe
requestandresponseisdefinedbytheschemaorotherstructuraldefinition
associatedwiththeXMLnamespacethatqualifiesthedirectchildelementoftheIQ
element(see Section8.4),andtheinteractionistrackedbytherequestingentity
throughuseofthe'id'attribute.Thus,IQinteractionsfollowacommonpatternof
structureddataexchangesuchasget/resultorset/result(althoughanerrorcanbe
returnedinreplytoarequestifappropriate):
RequestingResponding
EntityEntity
||
82/164
5/17/2016
|<iqid='1'type='get'>|
|[...payload...]|
|</iq>|
|>|
||
|<iqid='1'type='result'>|
|[...payload...]|
|</iq>|
|<|
||
|<iqid='2'type='set'>|
|[...payload...]|
|</iq>|
|>|
||
|<iqid='2'type='error'>|
|[...condition...]|
|</iq>|
|<|
||
Figure5:SemanticsofIQStanzas
Toenforcethesesemantics,thefollowingrulesapply:
1.The'id'attributeisREQUIREDforIQstanzas.
2.The'type'attributeisREQUIREDforIQstanzas.ThevalueMUSTbeone
ofthefollowingifnot,therecipientoranintermediaterouterMUST
returna<badrequest/>stanzaerror(Section8.3.3.1).
getThestanzarequestsinformation,inquires
aboutwhatdataisneededinordertocomplete
furtheroperations,etc.
setThestanzaprovidesdatathatisneededforan
operationtobecompleted,setsnewvalues,replaces
existingvalues,etc.
resultThestanzaisaresponsetoasuccessfulget
orsetrequest.
errorThestanzareportsanerrorthathas
occurredregardingprocessingordeliveryofagetor
setrequest(see Section8.3).
3.AnentitythatreceivesanIQrequestoftype"get"or"set"MUSTreply
withanIQresponseoftype"result"or"error".TheresponseMUST
preservethe'id'attributeoftherequest(orbeemptyifthegenerated
stanzadidnotincludean'id'attribute).
4.Anentitythatreceivesastanzaoftype"result"or"error"MUSTNOT
respondtothestanzabysendingafurtherIQresponseoftype"result"
or"error"however,therequestingentityMAYsendanotherrequest
(e.g.,anIQoftype"set"toprovideobligatoryinformationdiscovered
throughaget/resultpair).
5.AnIQstanzaoftype"get"or"set"MUSTcontainexactlyonechild
element,whichspecifiesthesemanticsoftheparticularrequest.
6.AnIQstanzaoftype"result"MUSTincludezerooronechildelements.
7.AnIQstanzaoftype"error"MAYincludethechildelementcontainedin
theassociated"get"or"set"andMUSTincludean<error/>childfor
details,see Section8.3.
8.3.StanzaErrors
TOC
83/164
5/17/2016
Stanzarelatederrorsarehandledinamannersimilarto streamerrors.Unlike
streamerrors,stanzaerrorsarerecoverabletherefore,theydonotresultin
terminationoftheXMLstreamandunderlyingTCPconnection.Instead,theentity
thatdiscoverstheerrorconditionreturnsanerrorstanza,whichisastanzathat:
isofthesamekind(message,presence,orIQ)asthegeneratedstanza
thattriggeredtheerror
hasa'type'attributesettoavalueof"error"
typicallyswapsthe'from'and'to'addressesofthegeneratedstanza
mirrorsthe'id'attribute(ifany)ofthegeneratedstanzathattriggered
theerror
containsan<error/>childelementthatspecifiestheerrorcondition
andthereforeprovidesahintregardingactionsthatthesendermightbe
abletotakeinanefforttoremedytheerror(however,itisnotalways
possibletoremedytheerror)
TOC
8.3.1.Rules
Thefollowingrulesapplytostanzaerrors:
1.Thereceivingorprocessingentitythatdetectsanerrorconditionin
relationtoastanzaSHOULDreturnanerrorstanza(andMUSTdosofor
IQstanzas).
2.TheerrorstanzaSHOULDsimplyswapthe'from'and'to'addresses
fromthegeneratedstanza,unlessdoingsowould(1)resultinan
informationleak(seeunder Section13.10)orotherbreachofsecurity,
or(2)forcethesenderoftheerrorstanzatoincludeamalformedJIDin
the'from'or'to'addressoftheerrorstanza.
3.Ifthegeneratedstanzawas<message/>or<presence/>andincluded
an'id'attributethenitisREQUIREDfortheerrorstanzatoalsoinclude
an'id'attribute.Ifthegeneratedstanzawas<iq/>thentheerrorstanza
MUSTincludean'id'attribute.Inallcases,thevalueofthe'id'attribute
MUSTmatchthatofthegeneratedstanza(orbeemptyifthegenerated
stanzadidnotincludean'id'attribute).
4.AnerrorstanzaMUSTcontainan<error/>childelement.
5.TheentitythatreturnsanerrorstanzaMAYpassalongitsJIDtothe
senderofthegeneratedstanza(e.g.,fordiagnosticortracking
purposes)throughtheadditionofa'by'attributetothe<error/>child
element.
6.TheentitythatreturnsanerrorstanzaMAYincludetheoriginalXMLsent
sothatthesendercaninspectand,ifnecessary,correcttheXMLbefore
attemptingtoresend(however,thisisacourtesyonlyandthe
originatingentityMUSTNOTdependonreceivingtheoriginalpayload).
Naturally,theentityMUSTNOTincludetheoriginaldataifitnotwell
formedXML,violatestheXMLrestrictionsofXMPP(seeunder
Section11.1),orisotherwiseharmful(e.g.,exceedsasizelimit).
7.An<error/>childMUSTNOTbeincludedifthe'type'attributehasa
valueotherthan"error"(orifthereisno'type'attribute).
8.AnentitythatreceivesanerrorstanzaMUSTNOTrespondtothestanza
withafurthererrorstanzathishelpstopreventlooping.
8.3.2.Syntax
TOC
Thesyntaxforstanzarelatederrorsisasfollows,whereXMLdatashownwithinthe
squarebrackets'['and']'isOPTIONAL,'intendedrecipient'istheJIDoftheentityto
whichtheoriginalstanzawasaddressed,'sender'istheJIDoftheoriginatingentity,
84/164
5/17/2016
and'errorgenerator'istheentitythatdetectsthefactthatanerrorhasoccurred
andthusreturnsanerrorstanza.
<stanzakindfrom='intendedrecipient'to='sender'type='error'>
[OPTIONALtoincludesenderXMLhere]
<error[by='errorgenerator']
type='errortype'>
<definedconditionxmlns='urn:ietf:params:xml:ns:xmppstanzas'/>
[<textxmlns='urn:ietf:params:xml:ns:xmppstanzas'
xml:lang='langcode'>
</text>]
[OPTIONALapplicationspecificconditionelement]
</error>
</stanzakind>
The"stanzakind"MUSTbeoneofmessage,presence,oriq.
The"errortype"MUSTbeoneofthefollowing:
authretryafterprovidingcredentials
canceldonotretry(theerrorcannotberemedied)
continueproceed(theconditionwasonlyawarning)
modifyretryafterchangingthedatasent
waitretryafterwaiting(theerroristemporary)
The"definedcondition"MUSTcorrespondtooneofthestanzaerrorconditions
definedunder Section8.3.3.However,becauseadditionalerrorconditionsmightbe
definedinthefuture,ifanentityreceivesastanzaerrorconditionthatitdoesnot
understandthenitMUSTtreattheunknownconditionasequivalentto<undefined
condition/>(Section8.3.3.21).IfthedesignersofanXMPPprotocolextensionor
thedevelopersofanXMPPimplementationneedtocommunicateastanzaerror
conditionthatisnotdefinedinthisspecification,theycandosobydefiningan
applicationspecificerrorconditionelementqualifiedbyanapplicationspecific
namespace.
The<error/>element:
MUSTcontainadefinedconditionelement.
MAYcontaina<text/>childelementcontainingXMLcharacterdatathat
describestheerrorinmoredetailthiselementMUSTbequalifiedby
the'urn:ietf:params:xml:ns:xmppstanzas'namespaceandSHOULD
possessan'xml:lang'attributespecifyingthenaturallanguageofthe
XMLcharacterdata.
MAYcontainachildelementforanapplicationspecificerrorcondition
thiselementMUSTbequalifiedbyanapplicationspecificnamespace
thatdefinesthesyntaxandsemanticsoftheelement.
The<text/>elementisOPTIONAL.Ifincluded,itistobeusedonlytoprovide
descriptiveordiagnosticinformationthatsupplementsthemeaningofadefined
conditionorapplicationspecificcondition.ItMUSTNOTbeinterpreted
programmaticallybyanapplication.ItSHOULDNOTbeusedastheerrormessage
presentedtoahumanuser,butMAYbeshowninadditiontotheerrormessage
associatedwiththedefinedconditionelement(and,optionally,theapplication
specificconditionelement).
InteroperabilityNote:Thesyntaxdefinedin [RFC3920]includeda
legacy'code'attribute,whosesemanticshavebeenreplacedbythe
definedconditionelementsinformationaboutmappingdefined
conditionelementstovaluesofthelegacy'code'attributecanbefound
85/164
5/17/2016
in [XEP0086].
8.3.3.DefinedConditions
TOC
Thefollowingconditionsaredefinedforuseinstanzaerrors.
TheerrortypevaluethatisRECOMMENDEDforeachdefinedconditionistheusual
expectedtypehowever,insomecircumstancesadifferenttypemightbemore
appropriate.
8.3.3.1.badrequest
TOC
ThesenderhassentastanzacontainingXMLthatdoesnotconformtothe
appropriateschemaorthatcannotbeprocessed(e.g.,anIQstanzathatincludesan
unrecognizedvalueofthe'type'attribute,oranelementthatisqualifiedbya
recognizednamespacebutthatviolatesthedefinedsyntaxfortheelement)the
associatederrortypeSHOULDbe"modify".
C:<iqfrom='juliet@im.example.com/balcony'
id='zj3v142b'
to='im.example.com'
type='subscribe'>
<pingxmlns='urn:xmpp:ping'/>
</iq>
S:<iqfrom='im.example.com'
id='zj3v142b'
type='error'>
</error>
</iq>
8.3.3.2.conflict
TOC
Accesscannotbegrantedbecauseanexistingresourceexistswiththesamename
oraddresstheassociatederrortypeSHOULDbe"cancel".
C:<iqid='wy2xa82b4'type='set'>
</bind>
</iq>
</error>
</iq>
86/164
5/17/2016
8.3.3.3.featurenotimplemented
TOC
ThefeaturerepresentedintheXMLstanzaisnotimplementedbytheintended
recipientoranintermediateserverandthereforethestanzacannotbeprocessed
(e.g.,theentityunderstandsthenamespacebutdoesnotrecognizetheelement
name)theassociatederrortypeSHOULDbe"cancel"or"modify".
C:<iqfrom='juliet@im.example.com/balcony'
id='9u2bax16'
to='pubsub.example.com'
type='get'>
<pubsubxmlns='http://jabber.org/protocol/pubsub'>
<subscriptions/>
</pubsub>
</iq>
E:<iqfrom='pubsub.example.com'
id='9u2bax16'
type='error'>
<featurenotimplemented
<unsupported
xmlns='http://jabber.org/protocol/pubsub#errors'
feature='retrievesubscriptions'/>
</error>
</iq>
8.3.3.4.forbidden
TOC
Therequestingentitydoesnotpossessthenecessarypermissionstoperforman
actionthatonlycertainauthorizedrolesorindividualsareallowedtocomplete(i.e.,
ittypicallyrelatestoauthorizationratherthanauthentication)theassociatederror
typeSHOULDbe"auth".
C:<presence
from='juliet@im.example.com/balcony'
id='y2bs71v4'
to='characters@muc.example.com/JulieC'>
<xxmlns='http://jabber.org/protocol/muc'/>
</presence>
E:<presence
from='characters@muc.example.com/JulieC'
id='y2bs71v4'
type='error'>
<errortype='auth'>
<forbiddenxmlns='urn:ietf:params:xml:ns:xmppstanzas'/>
</error>
</presence>
87/164
5/17/2016
8.3.3.5.gone
TOC
Therecipientorservercannolongerbecontactedatthisaddress,typicallyona
permanentbasis(asopposedtothe<redirect/>errorcondition,whichisusedfor
temporaryaddressingfailures)theassociatederrortypeSHOULDbe"cancel"and
theerrorstanzaSHOULDincludeanewaddress(ifavailable)astheXMLcharacter
dataofthe<gone/>element(whichMUSTbeaUniformResourceIdentifier [URI]
orInternationalizedResourceIdentifier [IRI]atwhichtheentitycanbecontacted,
typicallyanXMPPIRIasspecifiedin [XMPPURI]).
C:<message
from='juliet@im.example.com/churchyard'
id='sj2b371v'
type='chat'>
<body>Thylipsarewarm.</body>
</message>
S:<message
from='romeo@example.net'
id='sj2b371v'
to='juliet@im.example.com/churchyard'
type='error'>
<errorby='example.net'
type='cancel'>
<gonexmlns='urn:ietf:params:xml:ns:xmppstanzas'>
xmpp:romeo@afterlife.example.net
</gone>
</error>
</message>
TOC
Theserverhasexperiencedamisconfigurationorotherinternalerrorthatprevents
itfromprocessingthestanzatheassociatederrortypeSHOULDbe"cancel".
C:<presence
id='y2bs71v4'
</presence>
E:<presence
id='y2bs71v4'
type='error'>
<internalservererror
</error>
</presence>
88/164
5/17/2016
8.3.3.7.itemnotfound
TOC
TheaddressedJIDoritemrequestedcannotbefoundtheassociatederrortype
SHOULDbe"cancel".
C:<presencefrom='userfoo@example.com/bar'
id='pwb2n78i'
to='nosuchroom@conference.example.org/foo'/>
S:<presencefrom='nosuchroom@conference.example.org/foo'
id='pwb2n78i'
to='userfoo@example.com/bar'
type='error'>
<itemnotfoundxmlns='urn:ietf:params:xml:ns:xmppstanzas'/>
</error>
</presence>
SecurityWarning:AnapplicationMUSTNOTreturnthiserrorifdoingso
wouldprovideinformationabouttheintendedrecipient'snetwork
availabilitytoanentitythatisnotauthorizedtoknowsuchinformation
(foramoredetaileddiscussionofpresenceauthorization,refertothe
discussionofpresencesubscriptionsin [XMPPIM])insteaditMUST
returna<serviceunavailable/>stanzaerror(Section8.3.3.19).
8.3.3.8.jidmalformed
TOC
Thesendingentityhasprovided(e.g.,duringresourcebinding)orcommunicated
(e.g.,inthe'to'addressofastanza)anXMPPaddressoraspectthereofthat
violatestherulesdefinedin [XMPPADDR]theassociatederrortypeSHOULDbe
"modify".
C:<presence
id='y2bs71v4'
to='ch@r@cters@muc.example.com/JulieC'>
</presence>
E:<presence
from='ch@r@cters@muc.example.com/JulieC'
id='y2bs71v4'
type='error'>
<errorby='muc.example.com'
type='modify'>
<jidmalformed
</error>
</presence>
ImplementationNote:EnforcementoftheformatforXMPPlocalpartsis
primarilytheresponsibilityoftheserviceatwhichtheassociated
accountorentityislocated(e.g.,theexample.comserviceis
89/164
5/17/2016
responsibleforreturning<jidmalformed/>errorsrelatedtoallJIDsof
theform<localpart@example.com>),whereasenforcementofthe
formatforXMPPdomainpartsisprimarilytheresponsibilityofthe
servicethatseekstorouteastanzatotheserviceidentifiedbythat
domainpart(e.g.,theexample.orgserviceisresponsibleforreturning
<jidmalformed/>errorsrelatedtostanzasthatusersofthatservice
havetotriedsendtoJIDsoftheform<localpart@example.com>).
However,anyentitythatdetectsamalformedJIDMAYreturnthiserror.
8.3.3.9.notacceptable
TOC
Therecipientorserverunderstandstherequestbutcannotprocessitbecausethe
requestdoesnotmeetcriteriadefinedbytherecipientorserver(e.g.,arequestto
subscribetoinformationthatdoesnotsimultaneouslyincludeconfiguration
parametersneededbytherecipient)theassociatederrortypeSHOULDbe
"modify".
C:<messageto='juliet@im.example.com'id='yt2vs71m'>
<body>[...theemacsmanual...]</body>
</message>
S:<messagefrom='juliet@im.example.com'id='yt2vs71m'>
<notacceptable
</error>
</message>
8.3.3.10.notallowed
TOC
Therecipientorserverdoesnotallowanyentitytoperformtheaction(e.g.,
sendingtoentitiesatablacklisteddomain)theassociatederrortypeSHOULDbe
"cancel".
C:<presence
id='y2bs71v4'
</presence>
E:<presence
id='y2bs71v4'
type='error'>
<notallowedxmlns='urn:ietf:params:xml:ns:xmppstanzas'/>
</error>
</presence>
TOC
90/164
5/17/2016
Thesenderneedstoprovidecredentialsbeforebeingallowedtoperformtheaction,
orhasprovidedimpropercredentials(thename"notauthorized",whichwas
borrowedfromthe"401Unauthorized"errorof [HTTP],mightleadthereaderto
thinkthatthisconditionrelatestoauthorization,butinsteaditistypicallyusedin
relationtoauthentication)theassociatederrortypeSHOULDbe"auth".
C:<presence
id='y2bs71v4'
</presence>
E:<presence
id='y2bs71v4'
to='juliet@im.example.com/balcony'>
<errortype='auth'>
<notauthorizedxmlns='urn:ietf:params:xml:ns:xmppstanzas'/>
</error>
</presence>
TOC
Theentityhasviolatedsomelocalservicepolicy(e.g.,amessagecontainswords
thatareprohibitedbytheservice)andtheserverMAYchoosetospecifythepolicy
inthe<text/>elementorinanapplicationspecificconditionelementthe
associatederrortypeSHOULDbe"modify"or"wait"dependingonthepolicybeing
violated.
(Inthefollowingexample,theclientsendsanXMPPmessagecontainingwordsthat
areforbiddenaccordingtotheserver'slocalservicepolicy.)
C:<messagefrom='romeo@example.net/foo'
to='bill@im.example.com'
id='vq71f4nb'>
<body>%#&@^!!!</body>
</message>
S:<messagefrom='bill@im.example.com'
id='vq71f4nb'
to='romeo@example.net/foo'>
<errorby='example.net'type='modify'>
<policyviolation
</error>
</message>
8.3.3.13.recipientunavailable
TOC
Theintendedrecipientistemporarilyunavailable,undergoingmaintenance,etc.
theassociatederrortypeSHOULDbe"wait".
91/164
5/17/2016
C:<presence
id='y2bs71v4'
</presence>
E:<presence
id='y2bs71v4'
<errortype='wait'>
<recipientunavailable
</error>
</presence>
SecurityWarning:AnapplicationMUSTNOTreturnthiserrorifdoingso
wouldprovideinformationabouttheintendedrecipient'snetwork
availabilitytoanentitythatisnotauthorizedtoknowsuchinformation
(foramoredetaileddiscussionofpresenceauthorization,refertothe
discussionofpresencesubscriptionsin [XMPPIM])insteaditMUST
returna<serviceunavailable/>stanzaerror(Section8.3.3.19).
8.3.3.14.redirect
TOC
Therecipientorserverisredirectingrequestsforthisinformationtoanotherentity,
typicallyinatemporaryfashion(asopposedtothe<gone/>errorcondition,which
isusedforpermanentaddressingfailures)theassociatederrortypeSHOULDbe
"modify"andtheerrorstanzaSHOULDcontainthealternateaddressintheXML
characterdataofthe<redirect/>element(whichMUSTbeaURIorIRIwithwhich
thesendercancommunicate,typicallyanXMPPIRIasspecifiedin [XMPPURI]).
C:<presence
id='y2bs71v4'
</presence>
E:<presence
id='y2bs71v4'
type='error'>
<redirectxmlns='urn:ietf:params:xml:ns:xmppstanzas'>
xmpp:characters@conference.example.org
</redirect>
</error>
</presence>
SecurityWarning:Anapplicationreceivingastanzalevelredirect
SHOULDwarnahumanuseroftheredirectionattemptandrequest
92/164
5/17/2016
approvalbeforeproceedingtocommunicatewiththeentitywhose
addressiscontainedintheXMLcharacterdataofthe<redirect/>
element,becausethatentitymighthaveadifferentidentityormight
enforcedifferentsecuritypolicies.Theendtoendauthenticationor
signingofXMPPstanzascouldhelptomitigatethisrisk,sinceitwould
enablethesendertodetermineiftheentitytowhichithasbeen
redirectedhasthesameidentityastheentityitoriginallyattemptedto
contact.AnapplicationMAYhaveapolicyoffollowingredirectsonlyifit
hasauthenticatedthereceivingentity.Inaddition,anapplication
SHOULDabortthecommunicationattemptafteracertainnumberof
successiveredirects(e.g.,atleast2butnomorethan5).
8.3.3.15.registrationrequired
TOC
Therequestingentityisnotauthorizedtoaccesstherequestedservicebecause
priorregistrationisnecessary(examplesofpriorregistrationincludemembersonly
roomsinXMPPmultiuserchat [XEP0045]andgatewaystononXMPPinstant
messagingservices,whichtraditionallyrequiredregistrationinordertousethe
gateway [XEP0100])theassociatederrortypeSHOULDbe"auth".
C:<presence
id='y2bs71v4'
</presence>
E:<presence
id='y2bs71v4'
<errortype='auth'>
<registrationrequired
</error>
</presence>
8.3.3.16.remoteservernotfound
TOC
AremoteserverorservicespecifiedaspartoralloftheJIDoftheintended
recipientdoesnotexistorcannotberesolved(e.g.,thereisno_xmppserver._tcp
DNSSRVrecord,theAorAAAAfallbackresolutionfails,orA/AAAAlookupssucceed
butthereisnoresponseontheIANAregisteredport5269)theassociatederror
typeSHOULDbe"cancel".
C:<message
from='romeo@example.net/home'
id='ud7n1f4h'
to='bar@example.org'
type='chat'>
<body>yt?</body>
</message>
E:<message
93/164
5/17/2016
from='bar@example.org'
id='ud7n1f4h'
to='romeo@example.net/home'
type='error'>
<remoteservernotfound
</error>
</message>
8.3.3.17.remoteservertimeout
TOC
AremoteserverorservicespecifiedaspartoralloftheJIDoftheintended
recipient(orneededtofulfillarequest)wasresolvedbutcommunicationscouldnot
beestablishedwithinareasonableamountoftime(e.g.,anXMLstreamcannotbe
establishedattheresolvedIPaddressandport,oranXMLstreamcanbe
establishedbutstreamnegotiationfailsbecauseofproblemswithTLS,SASL,
ServerDialback,etc.)theassociatederrortypeSHOULDbe"wait"(unlessthe
errorisofamorepermanentnature,e.g.,theremoteserverisfoundbutitcannot
beauthenticatedoritviolatessecuritypolicies).
C:<message
from='romeo@example.net/home'
id='ud7n1f4h'
to='bar@example.org'
type='chat'>
<body>yt?</body>
</message>
E:<message
from='bar@example.org'
id='ud7n1f4h'
to='romeo@example.net/home'
type='error'>
<errortype='wait'>
<remoteservertimeout
</error>
</message>
TOC
Theserverorrecipientisbusyorlacksthesystemresourcesnecessarytoservice
therequesttheassociatederrortypeSHOULDbe"wait".
C:<iqfrom='romeo@example.net/foo'
id='kj4vz31m'
type='get'>
<itemsnode='my_musings'/>
</pubsub>
</iq>
94/164
5/17/2016
id='kj4vz31m'
to='romeo@example.net/foo'
type='error'>
<errortype='wait'>
<resourceconstraint
</error>
</iq>
8.3.3.19.serviceunavailable
TOC
Theserverorrecipientdoesnotcurrentlyprovidetherequestedservicethe
associatederrortypeSHOULDbe"cancel".
C:<messagefrom='romeo@example.net/foo'
to='juliet@im.example.com'>
<body>Hello?</body>
</message>
S:<messagefrom='juliet@im.example.com/foo'
to='romeo@example.net'>
<serviceunavailable
</error>
</message>
SecurityWarning:AnapplicationMUSTreturna<serviceunavailable/>
stanzaerror(Section8.3.3.19)insteadof<itemnotfound/>
(Section8.3.3.7)or<recipientunavailable/>(Section8.3.3.13)if
sendingoneofthelattererrorswouldprovideinformationaboutthe
intendedrecipient'snetworkavailabilitytoanentitythatisnot
authorizedtoknowsuchinformation(foramoredetaileddiscussionof
presenceauthorization,referto [XMPPIM]).
8.3.3.20.subscriptionrequired
TOC
Therequestingentityisnotauthorizedtoaccesstherequestedservicebecausea
priorsubscriptionisnecessary(examplesofpriorsubscriptionincludeauthorization
toreceivepresenceinformationasdefinedin [XMPPIM]andoptindatafeedsfor
XMPPpublishsubscribeasdefinedin [XEP0060])theassociatederrortype
SHOULDbe"auth".
C:<message
from='romeo@example.net/orchard'
id='pa73b4n7'
to='playwright@shakespeare.example.com'
type='chat'>
<subject>ACTII,SCENEII</subject>
<body>help,Iforgotmylines!</body>
</message>
95/164
5/17/2016
E:<message
from='playwright@shakespeare.example.com'
id='pa73b4n7'
to='romeo@example.net/orchard'
type='error'>
<errortype='auth'>
<subscriptionrequired
</error>
</message>
TOC
Theerrorconditionisnotoneofthosedefinedbytheotherconditionsinthislist
anyerrortypecanbeassociatedwiththiscondition,anditSHOULDNOTbeused
exceptinconjunctionwithanapplicationspecificcondition.
C:<message
from='northumberland@shakespeare.example'
id='richard24.1.247'
to='kingrichard@royalty.england.example'>
<body>Mylord,dispatchreado'erthesearticles.</body>
<ampxmlns='http://jabber.org/protocol/amp'>
<ruleaction='notify'
condition='deliver'
value='stored'/>
</amp>
</message>
S:<messagefrom='example.org'
id='amp1'
to='northumberland@example.net/field'
type='error'>
<ampxmlns='http://jabber.org/protocol/amp'
from='kingrichard@example.org'
status='error'
to='northumberland@example.net/field'>
<ruleaction='error'
condition='deliver'
value='stored'/>
</amp>
<undefinedcondition
<failedrulesxmlns='http://jabber.org/protocol/amp#errors'>
<ruleaction='error'
condition='deliver'
value='stored'/>
</failedrules>
</error>
</message>
8.3.3.22.unexpectedrequest
TOC
96/164
5/17/2016
Therecipientorserverunderstoodtherequestbutwasnotexpectingitatthistime
(e.g.,therequestwasoutoforder)theassociatederrortypeSHOULDbe"wait"or
"modify".
C:<iqfrom='romeo@example.net/foo'
id='o6hsv25z'
type='set'>
<unsubscribe
node='my_musings'
jid='romeo@example.net'/>
</pubsub>
</iq>
id='o6hsv25z'
to='romeo@example.net/foo'
type='error'>
<unexpectedrequest
<notsubscribed
xmlns='http://jabber.org/protocol/pubsub#errors'/>
</error>
</iq>
TOC
Asnoted,anapplicationMAYprovideapplicationspecificstanzaerrorinformation
byincludingaproperlynamespacedchildwithintheerrorelement.Typically,the
applicationspecificelementsupplementsorfurtherqualifiesadefinedelement.
Thus,the<error/>elementwillcontaintwoorthreechildelements.
<iqid='ixc3v1b9'type='error'>
<toomanyparametersxmlns='http://example.org/ns'/>
</error>
</iq>
<messagetype='error'id='7h3baci9'>
<undefinedcondition
<textxml:lang='en'
xmlns='urn:ietf:params:xml:ns:xmppstanzas'>
[...applicationspecificinformation...]
</text>
<toomanyparametersxmlns='http://example.org/ns'/>
</error>
</message>
Anentitythatreceivesanapplicationspecificerrorconditionitdoesnotunderstand
97/164
5/17/2016
MUSTignorethatconditionbutappropriatelyprocesstherestoftheerrorstanza.
8.4.ExtendedContent
TOC
Althoughthemessage,presence,andIQstanzasprovidebasicsemanticsfor
messaging,availability,andrequestresponseinteractions,XMPPusesXML
namespaces(see [XMLNAMES])toextendthebasicstanzasyntaxforthepurpose
ofprovidingadditionalfunctionality.
AmessageorpresencestanzaMAYcontainoneormoreoptionalchildelements
specifyingcontentthatextendsthemeaningofthemessage(e.g.,anXHTML
formattedversionofthemessagebodyasdescribedin [XEP0071]),andanIQ
stanzaoftype"get"or"set"MUSTcontainonesuchchildelement.Suchachild
elementMAYhaveanynameandMUSTpossessanamespacedeclaration(other
than"jabber:client","jabber:server",or"http://etherx.jabber.org/streams")that
definesthedatacontainedwithinthechildelement.Suchachildelementiscalled
an"extensionelement".Anextensionelementcanbeincludedeitheratthedirect
childlevelofthestanzaorinanymixoflevels.
Similarly,"extensionattributes"areallowed.Thatis:astanzaitself(i.e.,an<iq/>,
<message/>,or<presence/>elementqualifiedbythe"jabber:client"or
"jabber:server"contentnamespace)oranychildelementofsuchastanza(whether
anextensionelementorachildelementqualifiedbythecontentnamespace)MAY
alsoincludeoneormoreattributesqualifiedbyXMLnamespacesotherthanthe
contentnamespaceorthereserved"http://www.w3.org/XML/1998/namespace"
namespace(includingthesocalled"emptynamespace"iftheattributeisnot
prefixedasdescribedunder [XMLNAMES]).
InteroperabilityNote:Forthesakeofbackwardcompatibilityand
maximuminteroperability,anentitythatgeneratesastanzaSHOULD
NOTincludesuchattributesinthestanzaitselforinchildelementsof
thestanzathatarequalifiedbythecontentnamespaces"jabber:client"
or"jabber:server"(e.g.,the<body/>childofthe<message/>stanza).
Anextensionelementorextensionattributeissaidtobe"extendedcontent"andthe
qualifyingnamespaceforsuchanelementorattributeissaidtobean"extended
namespace".
InformationalNote:AlthoughextendednamespacesforXMPPare
commonlydefinedbytheXMPPStandardsFoundation(XSF)andbythe
IETF,nospecificationorIETFstandardsactionisnecessarytodefine
extendednamespaces,andanyindividualororganizationisfreeto
defineXMPPextensions.
Toillustratetheseconcepts,severalexamplesfollow.
Thefollowingstanzacontainsonedirectchildelementwhoseextendednamespace
is'jabber:iq:roster':
<iqfrom='juliet@capulet.com/balcony'
id='h83vxa4c'
type='get'>
<queryxmlns='jabber:iq:roster'/>
</iq>
Thefollowingstanzacontainstwodirectchildelementswithtwodifferentextended
namespaces.
98/164
5/17/2016
<presencefrom='juliet@capulet.com/balcony'>
<cxmlns='http://jabber.org/protocol/caps'
hash='sha1'
node='http://code.google.com/p/exodus'
ver='QgayPKawpkPSDYmwT/WM94uAlu0='/>
<xxmlns='vcardtemp:x:update'>
<photo>sha1hashofimage</photo>
</x>
</presence>
Thefollowingstanzacontainstwochildelements,oneofwhichisqualifiedbythe
"jabber:client"or"jabber:server"contentnamespaceandoneofwhichisqualified
byanextendednamespacetheextensionelementinturncontainsachildelement
thatisqualifiedbyadifferentextendednamespace.
<messageto='juliet@capulet.com'>
<body>Hello?</body>
<htmlxmlns='http://jabber.org/protocol/xhtmlim'>
<bodyxmlns='http://www.w3.org/1999/xhtml'>
<pstyle='fontweight:bold'>Hello?</p>
</body>
</html>
</message>
ItisconventionalintheXMPPcommunityforimplementationstonotgenerate
namespaceprefixesforelementsthatarequalifiedbyextendednamespaces(inthe
XMLcommunity,thisconventionissometimescalled"prefixfreecanonicalization").
However,ifanimplementationgeneratessuchnamespaceprefixesthenitMUST
includethenamespacedeclarationinthestanzaitselforachildelementofthe
stanza,notinthestreamheader(see Section4.8.4).
Routingentities(typicallyservers)SHOULDtrytomaintainprefixeswhen
serializingXMLstanzasforprocessing,butreceivingentitiesMUSTNOTdependon
theprefixstringstohaveanyparticularvalue(theallowanceforthe'stream'prefix,
describedunder Section4.8.5,isanexceptiontothisrule,albeitforstreams
ratherthanstanzas).
SupportforanygivenextendednamespaceisOPTIONALonthepartofany
implementation.Ifanentitydoesnotunderstandsuchanamespace,theentity's
expectedbehaviordependsonwhethertheentityis(1)therecipientor(2)aserver
thatisroutingordeliveringthestanzatotherecipient.
Ifarecipientreceivesastanzathatcontainsanelementorattributeitdoesnot
understand,itMUSTNOTattempttoprocessthatXMLdataandinsteadMUST
proceedasfollows.
Ifanintendedrecipientreceivesamessagestanzawhoseonlychild
elementisqualifiedbyanamespaceitdoesnotunderstand,then
dependingontheXMPPapplicationitMUSTeitherignoretheentire
stanzaorreturnastanzaerror,whichSHOULDbe<service
unavailable/>(Section8.3.3.19).
Ifanintendedrecipientreceivesapresencestanzawhoseonlychild
elementisqualifiedbyanamespaceitdoesnotunderstand,thenit
MUSTignorethechildelementbytreatingthepresencestanzaasifit
containednochildelement.
Ifanintendedrecipientreceivesamessageorpresencestanzathat
containsXMLdataqualifiedbyanamespaceitdoesnotunderstand,
thenitMUSTignoretheportionofthestanzaqualifiedbytheunknown
99/164
5/17/2016
namespace.
IfanintendedrecipientreceivesanIQstanzaoftype"get"or"set"
containingachildelementqualifiedbyanamespaceitdoesnot
understand,thentheentityMUSTreturnanIQstanzaoftype"error"
withanerrorconditionof<serviceunavailable/>.
Ifaserverhandlesastanzathatisintendedfordeliverytoanotherentityandthat
containsachildelementitdoesnotunderstand,itMUSTroutethestanza
unmodifiedtoaremoteserverordeliverthestanzaunmodifiedtoaconnected
clientassociatedwithalocalaccount.
9.DetailedExamples
TOC
Thedetailedexamplesinthissectionfurtherillustratetheprotocolsdefinedinthis
specification.
9.1.ClienttoServerExamples
TOC
ThefollowingexamplesshowtheXMPPdataflowforaclientnegotiatinganXML
streamwithaserver,exchangingXMLstanzas,andclosingthenegotiatedstream.
Theserveris"im.example.com",theserverrequiresuseofTLS,theclient
authenticatesviatheSASLSCRAMSHA1mechanismas<juliet@im.example.com>
withapasswordof"r0m30myr0m30",andtheclientbindsaclientsubmitted
resourcetothestream.Itisassumedthatbeforesendingtheinitialstreamheader,
theclienthasalreadyresolvedanSRVrecordof_xmppclient._tcp.im.example.com
andhasopenedaTCPconnectiontotheadvertisedportattheresolvedIPaddress.
9.1.1.TLS
TOC
Step1:Clientinitiatesstreamtoserver:
C:<stream:stream
to='im.example.com'
version='1.0'
xml:lang='en'
Step2:Serverrespondsbysendingaresponsestreamheadertoclient:
S:<stream:stream
id='t7AMCin9zjMNwQKDnplntZPIDEI='
version='1.0'
xml:lang='en'
100/164
5/17/2016
Step3:Serversendsstreamfeaturestoclient(onlytheSTARTTLSextensionatthis
point,whichismandatorytonegotiate):
S:<stream:features>
<required/>
</starttls>
</stream:features>
Step4:ClientsendsSTARTTLScommandtoserver:
C:<starttlsxmlns='urn:ietf:params:xml:ns:xmpptls'/>
Step5:Serverinformsclientthatitisallowedtoproceed:
S:<proceedxmlns='urn:ietf:params:xml:ns:xmpptls'/>
Step5(alt):ServerinformsclientthatSTARTTLSnegotiationhasfailed,closesthe
XMLstream,andterminatestheTCPconnection(thus,thestreamnegotiation
processendsunsuccessfullyandthepartiesdonotmoveontothenextstep):
S:<failurexmlns='urn:ietf:params:xml:ns:xmpptls'/>
</stream:stream>
Step6:ClientandserverattempttocompleteTLSnegotiationovertheexistingTCP
connection(see [TLS]fordetails).
Step7:IfTLSnegotiationissuccessful,clientinitiatesanewstreamtoserverover
theTLSprotectedTCPconnection:
C:<stream:stream
to='im.example.com'
version='1.0'
xml:lang='en'
Step7(alt):IfTLSnegotiationisunsuccessful,serverclosesTCPconnection(thus,
thestreamnegotiationprocessendsunsuccessfullyandthepartiesdonotmoveon
tothenextstep):
9.1.2.SASL
TOC
Step8:Serverrespondsbysendingastreamheadertoclientalongwithany
availablestreamfeatures:
S:<stream:stream
101/164
5/17/2016
version='1.0'
xml:lang='en'
S:<stream:features>
</mechanisms>
</stream:features>
Step9:Clientselectsanauthenticationmechanism(inthiscase,SCRAMSHA1),
includinginitialresponsedata:
C:<authxmlns="urn:ietf:params:xml:ns:xmppsasl"
mechanism="SCRAMSHA1">
biwsbj1qdWxpZXQscj1vTXNUQUF3QUFBQU1BQUFBTlAwVEFBQUFBQUJQVTBBQQ==
</auth>
Thedecodedbase64datais
"n,,n=juliet,r=oMsTAAwAAAAMAAAANP0TAAAAAABPU0AA".
Step10:Serversendsachallenge:
S:<challengexmlns="urn:ietf:params:xml:ns:xmppsasl">
cj1vTXNUQUF3QUFBQU1BQUFBTlAwVEFBQUFBQUJQVTBBQWUxMjQ2OTViLTY5Y
TktNGRlNi05YzMwLWI1MWIzODA4YzU5ZSxzPU5qaGtZVE0wTURndE5HWTBaaT
AwTmpkbUxUa3hNbVV0TkRsbU5UTm1ORE5rTURNeixpPTQwOTY=
</challenge>
Thedecodedbase64datais
"r=oMsTAAwAAAAMAAAANP0TAAAAAABPU0AAe124695b69a94de69c30
b51b3808c59e,s=NjhkYTM0MDgtNGY0Zi00NjdmLTkxMmUtNDlmNTNmNDNkMDMz,i=4096"
(linebreaksnotincludedinactualdata).
Step11:Clientsendsaresponse:
C:<responsexmlns="urn:ietf:params:xml:ns:xmppsasl">
Yz1iaXdzLHI9b01zVEFBd0FBQUFNQUFBQU5QMFRBQUFBQUFCUFUwQUFlMTI0N
jk1Yi02OWE5LTRkZTYtOWMzMC1iNTFiMzgwOGM1OWUscD1VQTU3dE0vU3ZwQV
RCa0gyRlhzMFdEWHZKWXc9
</response>
Thedecodedbase64datais"c=biws,r=oMsTAAwAAAAMAAAANP0TAAAAAABPU0
AAe124695b69a94de69c30b51b3808c59e,p=UA57tM/
SvpATBkH2FXs0WDXvJYw="(linebreaksnotincludedinactualdata).
Step12:Serverinformsclientofsuccess,includingadditionaldatawithsuccess:
S:<successxmlns='urn:ietf:params:xml:ns:xmppsasl'>
102/164
5/17/2016
dj1wTk5ERlZFUXh1WHhDb1NFaVc4R0VaKzFSU289
</success>
Thedecodedbase64datais"v=pNNDFVEQxuXxCoSEiW8GEZ+1RSo=".
Step12(alt):ServerreturnsaSASLerrortoclient(thus,thestreamnegotiation
S:<failurexmlns='urn:ietf:params:xml:ns:xmppsasl'>
<notauthorized/>
</failure>
</stream>
Step13:Clientinitiatesanewstreamtoserver:
C:<stream:stream
to='im.example.com'
version='1.0'
xml:lang='en'
9.1.3.ResourceBinding
TOC
Step14:Serverrespondsbysendingastreamheadertoclientalongwithsupported
features(inthiscase,resourcebinding):
S:<stream:stream
version='1.0'
xml:lang='en'
S:<stream:features>
</stream:features>
Uponbeinginformedthatresourcebindingismandatorytonegotiate,theclient
needstobindaresourcetothestreamhereweassumethattheclientsubmitsa
humanreadabletextstring.
Step15:Clientbindsaresource:
C:<iqid='yhc13a95'type='set'>
</bind>
</iq>
103/164
5/17/2016
Step16:Serveracceptssubmittedresourcepartandinformsclientofsuccessful
resourcebinding:
S:<iqid='yhc13a95'type='result'>
<jid>
juliet@im.example.com/balcony
</jid>
</bind>
</iq>
Step16(alt):Serverreturnserrortoclient(thus,thestreamnegotiationprocess
endsunsuccessfullyandthepartiesdonotmoveontothenextstep):
S:<iqid='yhc13a95'type='error'>
</error>
</iq>
TOC
NowtheclientisallowedtosendXMLstanzasoverthenegotiatedstream.
id='ju2ba41c'
type='chat'
xml:lang='en'>
</message>
Ifnecessary,sender'sservernegotiatesXMLstreamswithintendedrecipient's
server(see Section9.2).
Theintendedrecipientreplies,andthemessageisdeliveredtotheclient.
E:<messagefrom='romeo@example.net/orchard'
id='ju2ba41c'
type='chat'
xml:lang='en'>
</message>
Theclientcansubsequentlysendandreceiveanunboundednumberofsubsequent
XMLstanzasoverthestream.
9.1.5.Close
TOC
104/164
5/17/2016
Desiringtosendnofurthermessages,theclientclosesitsstreamtotheserverbut
waitsforincomingdatafromtheserver.
C:</stream:stream>
Consistentwith Section4.4,theservermightsendadditionaldatatotheclientand
thenclosesitsstreamtotheclient.
S:</stream:stream>
TheclientnowsendsaTLSclose_notifyalert,receivesarespondingclose_notify
alertfromtheserver,andthenterminatestheunderlyingTCPconnection.
9.2.ServertoServerExamples
TOC
ThefollowingexamplesshowthedataflowforaservernegotiatinganXMLstream
withapeerserver,exchangingXMLstanzas,andclosingthenegotiatedstream.The
initiatingserver("Server1")isim.example.comthereceivingserver("Server2")is
example.netanditrequiresuseofTLSim.example.compresentsacertificateand
authenticatesviatheSASLEXTERNALmechanism.Itisassumedthatbeforesending
theinitialstreamheader,Server1hasalreadyresolvedanSRVrecordof_xmpp
server._tcp.example.netandhasopenedaTCPconnectiontotheadvertisedportat
theresolvedIPaddress.NotehowServer1declaresthecontentnamespace
"jabber:server"asthedefaultnamespaceandusesprefixesforstreamrelated
elements,whereasServer2usesprefixfreecanonicalization.
9.2.1.TLS
TOC
Step1:Server1initiatesstreamtoServer2:
S1:<stream:stream
to='example.net'
version='1.0'
Step2:Server2respondsbysendingaresponsestreamheadertoServer1:
S2:<stream
from='example.net'
id='hTiXkW+ih9k2SqdGkk/AZi0OJ/Q='
to='im.example.com'
version='1.0'
Step3:Server2sendsstreamfeaturestoServer1(onlytheSTARTTLSextensionat
thispoint,whichismandatorytonegotiate):
105/164
5/17/2016
S2:<featuresxmlns='http://etherx.jabber.org/streams'>
<required/>
</starttls>
</features>
Step4:Server1sendstheSTARTTLScommandtoServer2:
S1:<starttlsxmlns='urn:ietf:params:xml:ns:xmpptls'/>
Step5:Server2informsServer1thatitisallowedtoproceed:
S2:<proceedxmlns='urn:ietf:params:xml:ns:xmpptls'/>
Step5(alt):Server2informsServer1thatSTARTTLSnegotiationhasfailed,closes
thestream,andterminatestheTCPconnection(thus,thestreamnegotiation
S2:<failurexmlns='urn:ietf:params:xml:ns:xmpptls'/>
</stream>
Step6:Server1andServer2attempttocompleteTLSnegotiationviaTCP(see
[TLS]fordetails).
Step7:IfTLSnegotiationissuccessful,Server1initiatesanewstreamtoServer2
overtheTLSprotectedTCPconnection:
S1:<stream:stream
to='example.net'
version='1.0'
Step7(alt):IfTLSnegotiationisunsuccessful,Server2closestheTCPconnection
(thus,thestreamnegotiationprocessendsunsuccessfullyandthepartiesdonot
moveontothenextstep).
9.2.2.SASL
TOC
Step8:Server2sendsaresponsestreamheadertoServer1alongwithavailable
streamfeatures(includingapreferencefortheSASLEXTERNALmechanism):
S2:<stream
from='example.net'
id='RChdjlgj/TIBcbT9Keu31zDihH4='
to='im.example.com'
version='1.0'
106/164
5/17/2016
S2:<featuresxmlns='http://etherx.jabber.org/streams'>
</mechanisms>
</features>
Step9:Server1selectstheEXTERNALmechanism(includinganemptyresponseof
"="):
S1:<authxmlns='urn:ietf:params:xml:ns:xmppsasl'
mechanism='EXTERNAL'>=</auth>
Step10:Server2returnssuccess:
S2:<successxmlns='urn:ietf:params:xml:ns:xmppsasl'/>
Step10(alt):Server2informsServer1offailedauthentication(thus,thestream
negotiationprocessendsunsuccessfullyandthepartiesdonotmoveontothenext
step):
S2:<failurexmlns='urn:ietf:params:xml:ns:xmppsasl'>
<notauthorized/>
</failure>
</stream>
Step11:Server1initiatesanewstreamtoServer2:
S1:<stream:stream
to='example.net'
version='1.0'
Step12:Server2respondsbysendingastreamheadertoServer1alongwithany
additionalfeatures(or,inthiscase,anemptyfeatureselement):
S2:<stream
from='example.net'
id='MbbV2FeojySpUIP6J91qaa+TWHM='
to='im.example.com'
version='1.0'
S2:<featuresxmlns='http://etherx.jabber.org/streams'/>
TOC
NowServer1isallowedtosendXMLstanzastoServer2overthenegotiatedstream
107/164
5/17/2016
fromim.example.comtoexample.nethereweassumethatthetransferredstanzas
arethoseshownearlierforclienttoservercommunication,albeitoveraserverto
serverstreamqualifiedbythe'jabber:server'namespace.
Server1sendsXMLstanzatoServer2:
S1:<messagefrom='juliet@im.example.com/balcony'
id='ju2ba41c'
type='chat'
xml:lang='en'>
</message>
9.2.4.Close
TOC
Desiringtosendnofurthermessages,Server1closesitsstreamtoServer2but
waitsforincomingdatafromServer2.(Inpractice,thestreamwouldmostlikely
remainopenforsometime,sinceServer1andServer2donotimmediatelyknowif
thestreamwillbeneededforfurthercommunication.)
S1:</stream:stream>
Consistentwiththerecommendedstreamclosinghandshake,Server2closesthe
streamaswell:
S2:</stream>
Server1nowsendsaTLSclose_notifyalert,receivesarespondingclose_notifyalert
fromServer2,andthenterminatestheunderlyingTCPconnection.
10.ServerRulesforProcessingXMLStanzas
TOC
Eachserverimplementationwillcontainitsownlogicforprocessingstanzasit
receives.Suchlogicdetermineswhethertheserverneedstorouteagivenstanzato
anotherdomain,deliverittoalocalentity(typicallyaconnectedclientassociated
withalocalaccount),orhandleitdirectlywithintheserveritself.Thissection
providesgeneralrulesforprocessingXMLstanzas.However,particularXMPP
applicationsMAYspecifydeliveryrulesthatmodifyorsupplementthefollowing
rules(e.g.,asetofdeliveryrulesforinstantmessagingandpresenceapplications
isdefinedin [XMPPIM]).
10.1.InOrderProcessing
TOC
AnXMPPserverMUSTensureinorderprocessingofthestanzasandotherXML
elementsitreceivesoveragiveninputstreamfromaconnectedclientorremote
server.
Inorderprocessingapplies(a)toanyXMLelementsusedtonegotiateandmanage
108/164
5/17/2016
XMLstreams,and(b)toallusesofXMLstanzas,includingbutnotlimitedtothe
following:
1.StanzassentbyaclienttoitsserverortoitsownbareJIDfordirect
processingbytheserver(e.g.,inorderprocessingofarostergetand
initialpresenceasdescribedin [XMPPIM]).
2.Stanzassentbyaconnectedclientandintendedfordeliverytoanother
entityassociatedwiththeserver(e.g.,stanzasaddressedfrom
<juliet@im.example.com>to<nurse@im.example.com>).Theserver
MUSTensurethatitdeliversstanzasaddressedtotheintendedrecipient
intheorderitreceivesthemovertheinputstreamfromthesending
client,treatingstanzasaddressedtothebareJIDandthefullJIDofthe
intendedrecipientasequivalentfordeliverypurposes.
3.Stanzassentbyaconnectedclientandintendedfordeliverytoanentity
locatedataremotedomain(e.g.,stanzasaddressedfrom
<juliet@im.example.com>to<romeo@example.net>).Therouting
serverMUSTensurethatitroutesstanzasaddressedtotheintended
recipientintheorderitreceivesthemovertheinputstreamfromthe
sendingclient,treatingstanzasaddressedtothebareJIDandthefull
JIDoftheintendedrecipientasequivalentforroutingpurposes.Tohelp
ensureinorderprocessing,theroutingserverMUSTroutesuchstanzas
overasingleoutputstreamtotheremotedomain,ratherthansending
somestanzasoveroneservertoserverstreamandotherstanzasover
anotherservertoserverstream.
4.Stanzasroutedfromoneservertoanotherserverfordeliverytoan
entityassociatedwiththeremotedomain(e.g.,stanzasaddressedfrom
<juliet@im.example.com>to<romeo@example.net>androutedby
<im.example.com>overaservertoserverstreamto<example.net>).
ThedeliveringserverMUSTensurethatitdeliversstanzastothe
intendedrecipientintheorderitreceivesthemovertheinputstream
fromtheroutingserver,treatingstanzasaddressedtothebareJIDand
thefullJIDoftheintendedrecipientasequivalentfordeliverypurposes.
5.Stanzassentbyoneservertoanotherserverfordirectprocessingby
theserverthatishostingtheremotedomain(e.g.,stanzasaddressed
from<im.example.com>to<example.net>).
Iftheserver'sprocessingofaparticularrequestcouldhaveaneffectonits
processingofsubsequentdataitmightreceiveoverthatinputstream(e.g.,
enforcementofcommunicationpolicies),itMUSTsuspendprocessingofsubsequent
datauntilithasprocessedtherequest.
Inorderprocessingappliesonlytoasingleinputstream.Therefore,aserverisnot
responsibleforensuringthecoherenceofdataitreceivesacrossmultipleinput
streamsassociatedwiththesamelocalaccount(e.g.,stanzasreceivedovertwo
differentinputstreamsfrom<juliet@im.example.com/balcony>and
<juliet@im.example.com/chamber>)orthesameremotedomain(e.g.,two
differentinputstreamsnegotiatedbyaremotedomainhowever,aserverMAY
closethestreamwitha<conflict/>streamerror(Section4.9.3.3)ifaremote
serverattemptstonegotiatemorethanonestream,asdescribedunder
Section4.9.3.3).
10.2.GeneralConsiderations
TOC
Athighlevel,therearethreeprimaryconsiderationsatplayinserverprocessingof
XMLstanzas,whichsometimesareatoddsbutneedtobemanagedinaconsistent
way:
1.Itisgoodtodeliverastanzatotheintendedrecipientifpossible.
2.Ifastanzacannotbedelivered,itishelpfultoinformthesender.
109/164
5/17/2016
3.Itisbadtofacilitatedirectoryharvestingattacks(Section13.11)and
presenceleaks(Section13.10.2).
Withregardtopossibledeliveryrelatedattacks,thefollowingpointsneedtobe
keptinmind:
1.Fromtheperspectiveofanattacker,thereislittleifanyeffective
differencebetweentheserver's(i)deliveringthestanzaorstoringit
offlineforlaterdelivery(see [XMPPIM])and(ii)silentlyignoringit
(becauseanerrorisnotreturnedimmediatelyinanyofthosecases)
therefore,inscenarioswhereaserverdeliversastanzaorplacesthe
stanzaintoofflinestorageforlaterdelivery,itneedstosilentlyignore
thestanzaifthataccountdoesnotexist.
2.HowaserverprocessesstanzassenttothebareJID
<localpart@domainpart>hasimplicationsfordirectoryharvesting,
becauseanattackercoulddeterminewhetheranaccountexistsifthe
serverrespondsdifferentlydependingonwhetherthereisanaccount
foragivenbareJID.
3.HowaserverprocessesstanzassenttoafullJIDhasimplicationsfor
presenceleaks,becauseanattackercouldsendrequeststomultiplefull
JIDsandreceivedifferentrepliesdependingonwhethertheuserhasa
devicecurrentlyonlineatthatfullJID.Theuseofrandomized
resourceparts(whethergeneratedbytheclientortheserveras
describedunder Section7)significantlyhelpstomitigatethisattack,so
itisofsomewhatlesserconcernthanthedirectoryharvestingattack.
Naturally,presenceisnotleakediftheentitytowhichauser'sserverreturnsan
erroralreadyknowstheuser'spresenceorisauthorizedtodoso(e.g.,bymeans
ofapresencesubscriptionordirectedpresence),andaserverdoesnotenablea
directoryharvestingattackifitreturnsanerrortoanentitythatalreadyknowsifa
userexists(e.g.,becausetheentityisintheuser'scontactlist)thesemattersare
discussedmorefullyin [XMPPIM].
10.3.No'to'Address
TOC
Ifthestanzapossessesno'to'attribute,theserverMUSThandleitdirectlyon
behalfoftheentitythatsentit,wherethemeaningof"handleitdirectly"depends
onwhetherthestanzaismessage,presence,orIQ.Becauseallstanzasreceived
fromotherserversMUSTpossessa'to'attribute,thisruleappliesonlytostanzas
receivedfromalocalentity(typicallyaclient)thatisconnectedtotheserver.
10.3.1.Message
TOC
Iftheserverreceivesamessagestanzawithno'to'attribute,itMUSTtreatthe
messageasifthe'to'addresswerethebareJID<localpart@domainpart>ofthe
sendingentity.
10.3.2.Presence
TOC
Iftheserverreceivesapresencestanzawithno'to'attribute,itMUSTbroadcastit
totheentitiesthataresubscribedtothesendingentity'spresence,ifapplicable
([XMPPIM]definesthesemanticsofsuchbroadcastingforpresenceapplications).
110/164
5/17/2016
TOC
10.3.3.IQ
IftheserverreceivesanIQstanzawithno'to'attribute,itMUSTprocessthestanza
onbehalfoftheaccountfromwhichreceivedthestanza,asfollows:
1.IftheIQstanzaisoftype"get"or"set"andtheserverunderstandsthe
namespacethatqualifiesthepayload,theserverMUSThandlethe
stanzaonbehalfofthesendingentityorreturnanappropriateerrorto
thesendingentity.Althoughthemeaningof"handle"isdeterminedby
thesemanticsofthequalifyingnamespace,ingeneraltheserverwill
respondtotheIQstanzaoftype"get"or"set"byreturningan
appropriateIQstanzaoftype"result"or"error",respondingasifthe
serverwerethebareJIDofthesendingentity.Asanexample,ifthe
sendingentitysendsanIQstanzaoftype"get"wherethepayloadis
qualifiedbythe'jabber:iq:roster'namespace(asdescribedin
[XMPPIM]),thentheserverwillreturntherosterassociatedwiththe
sendingentity'sbareJIDtotheparticularresourceofthesendingentity
thatrequestedtheroster.
2.IftheIQstanzaisoftype"get"or"set"andtheserverdoesnot
understandthenamespacethatqualifiesthepayload,theserverMUST
returnanerrortothesendingentity,whichMUSTbe<service
unavailable/>.
3.IftheIQstanzaisoftype"error"or"result",theserverMUSThandle
theerrororresultinaccordancewiththepayloadoftheassociatedIQ
stanzaortype"get"or"set"(ifthereisnosuchassociatedstanza,the
serverMUSTignoretheerrororresultstanza).
10.4.RemoteDomain
TOC
IfthedomainpartoftheJIDcontainedinthe'to'attributedoesnotmatchoneofthe
configuredFQDNsoftheserver,theserverSHOULDattempttoroutethestanzato
theremotedomain(subjecttolocalserviceprovisioningandsecuritypolicies
regardinginterdomaincommunication,sincesuchcommunicationisOPTIONALfor
anygivendeployment).Asdescribedinthefollowingsections,therearetwo
possiblecases.
SecurityWarning:Theserulesapplyonlyclienttoserverstreams.As
describedunder Section8.1.1.2,aserverMUSTNOTacceptastanza
overaservertoserverstreamifthedomainpartoftheJIDinthe'to'
attributedoesnotmatchanFQDNservicedbythereceivingserver.
10.4.1.ExistingStream
TOC
Ifaservertoserverstreamalreadyexistsbetweenthetwodomains,thesender's
serverSHOULDattempttoroutethestanzatotheauthoritativeserverforthe
remotedomainovertheexistingstream.
10.4.2.NoExistingStream
TOC
Ifthereexistsnoservertoserverstreambetweenthetwodomains,thesender's
serverwillproceedasfollows:
1.ResolvetheFQDNoftheremotedomain(asdescribedunder
111/164
5/17/2016
Section13.9.2).
2.Negotiateaservertoserverstreambetweenthetwodomains(as
definedunder Section5and Section6).
3.Routethestanzatotheauthoritativeserverfortheremotedomainover
thenewlyestablishedstream.
10.4.3.ErrorHandling
TOC
Ifroutingofastanzatotheintendedrecipient'sserverisunsuccessful,thesender's
serverMUSTreturnanerrortothesender.Ifresolutionoftheremotedomainis
unsuccessful,thestanzaerrorMUSTbe<remoteservernotfound/>
(Section8.3.3.16).Ifresolutionsucceedsbutstreamscannotbenegotiated,the
stanzaerrorMUSTbe<remoteservertimeout/>(Section8.3.3.17).
Ifstreamnegotiationwiththeintendedrecipient'sserverissuccessfulbutthe
remoteservercannotdeliverthestanzatotherecipient,theremoteserverMUST
returnanappropriateerrortothesenderbywayofthesender'sserver.
10.5.LocalDomain
TOC
IfthedomainpartoftheJIDcontainedinthe'to'attributematchesoneofthe
configuredFQDNsoftheserver,theserverMUSTfirstdetermineiftheFQDNis
servicedbytheserveritselforbyaspecializedlocalservice.Ifthelatter,the
serverMUSTroutethestanzatothatservice.Iftheformer,theserverMUST
proceedasfollows.However,theserverMUSTNOTrouteor"forward"thestanzato
anotherdomain,becauseitistheserver'sresponsibilitytoprocessallstanzasfor
whichthedomainpartofthe'to'addressmatchesoneoftheconfiguredFQDNsof
theserver(amongotherthings,thishelpstopreventlooping).
10.5.1.domainpart
TOC
IftheJIDcontainedinthe'to'attributeisoftheform<domainpart>,thenthe
serverMUSTeither(a)handlethestanzaasappropriateforthestanzakindor(b)
returnanerrorstanzatothesender.
10.5.2.domainpart/resourcepart
TOC
IftheJIDcontainedinthe'to'attributeisoftheform<domainpart/resourcepart>,
thentheserverMUSTeither(a)handlethestanzaasappropriateforthestanza
kindor(b)returnanerrorstanzatothesender.
10.5.3.localpart@domainpart
TOC
Anaddressofthistypeisnormallyassociatedwithanaccountontheserver.The
followingrulesprovidesomegeneralguidelinesmoredetailedrulesinthecontext
ofinstantmessagingandpresenceapplicationsareprovidedin [XMPPIM].
112/164
5/17/2016
10.5.3.1.NoSuchUser
TOC
Ifthereisnolocalaccountassociatedwiththe<localpart@domainpart>,howthe
stanzaisprocesseddependsonthestanzatype.
Foramessagestanza,theserverMUSTeither(a)silentlyignorethe
stanzaor(b)returna<serviceunavailable/>stanzaerror
(Section8.3.3.19)tothesender.
Forapresencestanza,theserverSHOULDignorethestanza(orbehave
asdescribedin [XMPPIM]).
ForanIQstanza,theserverMUSTreturna<serviceunavailable/>
stanzaerror(Section8.3.3.19)tothesender.
10.5.3.2.UserExists
TOC
IftheJIDcontainedinthe'to'attributeisoftheform<localpart@domainpart>,how
thestanzaisprocesseddependsonthestanzatype.
Foramessagestanza,ifthereexistsatleastoneconnectedresource
fortheaccountthentheserverSHOULDdeliverittoatleastoneofthe
connectedresources.Ifthereexistsnoconnectedresourcethenthe
serverMUSTeither(a)storethemessageofflinefordeliverywhenthe
accountnexthasaconnectedresourceor(b)returna<service
unavailable/>stanzaerror(Section8.3.3.19).
Forapresencestanza,ifthereexistsatleastoneconnectedresource
thathassentinitialpresence(i.e.,hasa"presencesession"asdefined
in [XMPPIM])thentheserverSHOULDdeliverittosuchresources.If
thereexistsnoconnectedresourcethentheserverSHOULDignorethe
stanza(orbehaveasdescribedin [XMPPIM]).
ForanIQstanza,theserverMUSThandleitdirectlyonbehalfofthe
intendedrecipient.
10.5.4.localpart@domainpart/resourcepart
TOC
IftheJIDcontainedinthe'to'attributeisoftheform
<localpart@domainpart/resourcepart>andtheuserexistsbutthereisnoconnected
resourcethatexactlymatchesthefullJID,thestanzaSHOULDbeprocessedasif
theJIDwereoftheform<localpart@domainpart>asdescribedunder
Section10.5.3.2.
IftheJIDcontainedinthe'to'attributeisoftheform
<localpart@domainpart/resourcepart>,theuserexists,andthereisaconnected
resourcethatexactlymatchesthefullJID,theserverMUSTdeliverthestanzato
thatconnectedresource.
11.XMLUsage
11.1.XMLRestrictions
TOC
TOC
XMPPdefinesaclassofdataobjectscalledXMLstreamsaswellasthebehaviorof
computerprogramsthatprocessXMLstreams.XMPPisanapplicationprofileor
113/164
5/17/2016
restrictedformoftheExtensibleMarkupLanguage [XML],andacompleteXML
stream(includingstartandendstreamtags)isaconformingXMLdocument.
However,XMPPdoesnotdealwithXMLdocumentsbutwithXMLstreams.Because
XMPPdoesnotrequiretheparsingofarbitraryandcompleteXMLdocuments,there
isnorequirementthatXMPPneedstosupportthefullfeaturesetof [XML].
Furthermore,XMPPusesXMLtodefineprotocoldatastructuresandextensionsfor
thepurposeofstructuredinteractionsbetweennetworkentitiesandtherefore
adherestotherecommendationsprovidedin [XMLGUIDE]regardingrestrictions
ontheuseofXMLinIETFprotocols.Asaresult,thefollowingfeaturesofXMLare
prohibitedinXMPP:
comments(asdefinedinSection2.5of [XML])
processinginstructions(Section2.6therein)
internalorexternalDTDsubsets(Section2.8therein)
internalorexternalentityreferences(Section4.2therein)withthe
exceptionofthepredefinedentities(Section4.6therein)
AnXMPPimplementationMUSTbehaveasfollowswithregardtothesefeatures:
1.AnXMPPimplementationMUSTNOTinjectcharactersmatchingsuch
featuresintoanXMLstream.
2.IfanXMPPimplementationreceivescharactersmatchingsuchfeatures
overanXMLstream,itMUSTclosethestreamwithastreamerror,
whichSHOULDbe<restrictedxml/>( Section4.9.3.18),although
someexistingimplementationssend<badformat/>(Section4.9.3.1)
instead.
11.2.XMLNamespaceNamesandPrefixes
TOC
XMLnamespaces(see [XMLNAMES])areusedwithinXMPPstreamstocreate
strictboundariesofdataownership.Thebasicfunctionofnamespacesisto
separatedifferentvocabulariesofXMLelementsthatarestructurallymixed
together.EnsuringthatXMPPstreamsarenamespaceawareenablesanyallowable
XMLtobestructurallymixedwithanydataelementwithinXMPP.XMPPspecific
rulesforXMLnamespacenamesandprefixesaredefinedunder Section4.8for
XMLstreamsand Section8.4forXMLstanzas.
11.3.WellFormedness
TOC
InXML,therearetwovarietiesofwellformedness:
"XMLwellformedness"inaccordancewiththedefinitionof"well
formed"fromSection2.1of [XML].
"Namespacewellformedness"inaccordancewiththedefinitionof
"namespacewellformed"fromSection7of [XMLNAMES].
Thefollowingrulesapply:
1.AnXMPPentityMUSTNOTgeneratedatathatisnotXMLwellformed.
2.AnXMPPentityMUSTNOTacceptdatathatisnotXMLwellformed
insteaditMUSTclosethestreamoverwhichthedatawasreceivedwith
a<notwellformed/>streamerror(Section4.9.3.13).
3.AnXMPPentityMUSTNOTgeneratedatathatisnotnamespacewell
formed.
4.AnXMPPentityMUSTNOTacceptdatathatisnotnamespacewell
formed(inparticular,anXMPPserverMUSTNOTrouteordeliverdata
114/164
5/17/2016
thatisnotnamespacewellformed)insteaditMUSTreturneithera
<notacceptable/>stanzaerror(Section8.3.3.9)orclosethestream
witha<notwellformed/>streamerror(Section4.9.3.13),whereitis
preferabletoclosethestreamwithastreamerrorbecauseaccepting
suchdatacanopenanentitytocertaindenialofserviceattacks.
InteroperabilityNote:Becausetheserestrictionswereunderspecifiedin
[RFC3920],itispossiblethatimplementationsbasedonthat
specificationwillsenddatathatdoesnotcomplywiththeserestrictions.
11.4.Validation
TOC
AserverisnotresponsibleforensuringthatXMLdatadeliveredtoaconnected
clientorroutedtoapeerserverisvalid,inaccordancewiththedefinitionof"valid"
providedinSection2.8of [XML].AnimplementationMAYchoosetoacceptorsend
onlydatathathasbeenexplicitlyvalidatedagainsttheschemasprovidedinthis
document,butsuchbehaviorisOPTIONAL.Clientsareadvisednottorelyonthe
abilitytosenddatathatdoesnotconformtotheschemas,andSHOULDignoreany
nonconformantelementsorattributesontheincomingXMLstream.
InformationalNote:Theterms"valid"and"wellformed"aredistinctin
XML.
11.5.InclusionofXMLDeclaration
TOC
Beforesendingastreamheader,animplementationSHOULDsendanXML
declaration(matchingthe"XMLDecl"productionfrom [XML]).ApplicationsMUST
followtherulesprovidedin [XML]regardingtheformatoftheXMLdeclarationand
thecircumstancesunderwhichtheXMLdeclarationisincluded.
BecauseexternalmarkupdeclarationsareprohibitedinXMPP(asdescribedunder
Section11.1),thestandalonedocumentdeclaration(matchingthe"SDDecl"
productionfrom [XML])wouldhavenomeaningandthereforeMUSTNOTbe
includedinanXMLdeclarationsentoveranXMLstream.IfanXMPPentityreceives
anXMLdeclarationcontainingastandalonedocumentdeclarationsettoavalueof
"no",theentityMUSTeitherignorethestandalonedocumentdeclarationorclose
thestreamwithastreamerror,whichSHOULDbe<restrictedxml/>
(Section4.9.3.18).
11.6.CharacterEncoding
TOC
ImplementationsMUSTsupporttheUTF8transformationofUniversalCharacterSet
[UCS2]characters,asneededforconformancewith [CHARSETS]andasdefinedin
[UTF8].ImplementationsMUSTNOTattempttouseanyotherencoding.Ifone
partytoanXMLstreamdetectsthattheotherpartyhasattemptedtosendXMLdata
withanencodingotherthanUTF8,itMUSTclosethestreamwithastreamerror,
whichSHOULDbe<unsupportedencoding/>(Section4.9.3.22),althoughsome
existingimplementationssend<badformat/>(Section4.9.3.1)instead.
BecauseitismandatoryforanXMPPimplementationtosupportallandonlythe
UTF8encodingandbecauseUTF8alwayshasthesamebyteorder,an
implementationMUSTNOTsendabyteordermark("BOM")atthebeginningofthe
datastream.Ifanentityreceivesthe [UNICODE]characterU+FEFFanywherein
anXMLstream(includingasthefirstcharacterofthestream),itMUSTinterpret
115/164
5/17/2016
thatcharacterasazerowidthnobreakspace,notasabyteordermark.
11.7.Whitespace
TOC
Exceptwhereexplicitlydisallowed(e.g.,during TLSnegotiationand SASL

negotiation),eitherentityMAYsendwhitespaceasseparatorsbetweenXML
stanzasorbetweenanyotherfirstlevelelementssentoverthestream.One
commonuseforsendingsuchwhitespaceisexplainedunder Section4.4.
11.8.XMLVersions
TOC
XMPPisanapplicationprofileofXML1.0.AfutureversionofXMPPmightbedefined
intermsofhigherversionsofXML,butthisspecificationdefinesXMPPonlyinterms
ofXML1.0.
12.InternationalizationConsiderations
TOC
Asspecifiedunder Section11.6,XMLstreamsMUSTbeencodedinUTF8.
Asspecifiedunder Section4.7,anXMLstreamSHOULDincludean'xml:lang'
attributespecifyingthedefaultlanguageforanyXMLcharacterdatathatisintended
tobepresentedtoahumanuser.Asspecifiedunder Section8.1.5,anXMLstanza
SHOULDincludean'xml:lang'attributeifthestanzacontainsXMLcharacterdata
thatisintendedtobepresentedtoahumanuser.AserverSHOULDapplythe
default'xml:lang'attributetostanzasitroutesordeliversonbehalfofconnected
entities,andMUSTNOTmodifyordelete'xml:lang'attributesonstanzasitreceives
fromotherentities.
InternationalizationofXMPPaddressesisspecifiedin [XMPPADDR].
13.SecurityConsiderations
TOC
13.1.Fundamentals
TOC
XMPPtechnologiesaretypicallydeployedusingadecentralizedclientserver
architecture.Asaresult,severalpathsarepossiblewhentwoXMPPentitiesneedto
communicate:
1.Bothentitiesareservers.Inthiscase,theentitiescanestablishadirect
servertoserverstreambetweenthemselves.
2.Oneentityisaserverandtheotherentityisaclientwhoseaccountis
hostedonthatserver.Inthiscase,theentitiescanestablishadirect
clienttoserverstreambetweenthemselves.
3.Bothentitiesareclientswhoseaccountsarehostedonthesameserver.
Inthiscase,theentitiescannotestablishadirectstreambetween
themselves,butthereisonlyoneintermediateentitybetweenthem,
whosepoliciestheymightunderstandandinwhichtheymighthave
someleveloftrust(e.g.,theservermightrequiretheuseofTransport
LayerSecurityforallclientconnections).
116/164
5/17/2016
4.Bothentitiesareclientsbuttheiraccountsarehostedondifferent
servers.Inthiscase,theentitiescannotestablishadirectstream
betweenthemselvesandtherearetwointermediateentitiesbetween
themeachclientmighthavesometrustintheserverthathostsits
accountbutmightknownothingaboutthepoliciesoftheservertowhich
theotherclientconnects.
ThisspecificationcoversonlythesecurityofadirectXMLstreambetweentwo
serversorbetweenaclientandaserver(cases#1and#2),whereeachstream
canbeconsideredasingle"hop"alongacommunicationpath.Thegoalofsecurity
foramultihoppath(cases#3and#4),althoughverydesirable,isoutofscopefor
thisspecification.
Inaccordancewith [SECGUIDE],thisspecificationcoverscommunicationsecurity
(confidentiality,dataintegrity,andpeerentityauthentication),nonrepudiation,and
systemssecurity(unauthorizedusage,inappropriateusage,anddenialofservice).
Wealsodiscusscommonsecurityissuessuchasinformationleaks,firewalls,and
directoryharvesting,aswellasbestpracticesrelatedtothereuseoftechnologies
suchasbase64,DNS,cryptographichashfunctions,SASL,TLS,UTF8,andXML.
13.2.ThreatModel
TOC
ThethreatmodelforXMPPisinessencethestandard"InternetThreatModel"
describedin [SECGUIDE].Attackersareassumedtobeinterestedinandcapable
oflaunchingthefollowingattacksagainstunprotectedXMPPsystems:
Eavesdropping
Sniffingpasswords
Breakingpasswordsthroughdictionaryattacks
Discoveringusernamesthroughdirectoryharvestingattacks
Replaying,inserting,deleting,ormodifyingstanzas
Spoofingusers
Gainingunauthorizedentrytoaserveroraccount
Usingaserveroraccountinappropriately
Denyingservicetootherentities
Subvertingcommunicationstreamsthroughmaninthemiddleattacks
Gainingcontroloveronpathservers
Whereappropriate,thefollowingsectionsdescribemethodsforprotectingagainst
thesethreats.
13.3.OrderofLayers
TOC
TheorderoflayersinwhichprotocolsMUSTbestackedisasfollows:
1.TCP
2.TLS
3.SASL
4.XMPP
Thisorderhasimportantsecurityimplications,asdescribedthroughoutthese
securityconsiderations.
WithinXMPP,XMLstanzasarefurtherorderedontopofXMLstreams,asdescribed
under Section4.
117/164
5/17/2016
13.4.ConfidentialityandIntegrity
TOC
TheuseofTransportLayerSecurity(TLS)withappropriateciphersuitesprovidesa
reliablemechanismtoensuretheconfidentialityandintegrityofdataexchanged
betweenaclientandaserverorbetweentwoservers.Therefore,TLScanhelpto
protectagainsteavesdropping,passwordsniffing,maninthemiddleattacks,and
stanzareplays,insertion,deletion,andmodificationoveranXMLstream.XMPP
clientsandserversMUSTsupportTLSasdefinedunder Section5.
InformationalNote:Theconfidentialityandintegrityofastreamcanbe
protectedbymethodsotherthanTLS,e.g.,bymeansofaSASL
mechanismthatinvolvesnegotiationofasecuritylayer.
SecurityWarning:TheuseofTLSinXMPPappliestoasinglestream.
BecauseXMPPistypicallydeployedusingadistributedclientserver
architecture(asexplainedunder Section2.5),astanzamighttraverse
multiplestreams,andnotallofthosestreamsmightbeTLSprotected.
Forexample,astanzasentfromaclientwithasessionatoneserver
(e.g.,<romeo@example.net/orchard>)andintendedfordeliverytoa
clientwithasessionatanotherserver(e.g.,
<juliet@example.com/balcony>)willtraversethreestreams:(1)the
streamfromthesender'sclienttoitsserver,(2)thestreamfromthe
sender'sservertotherecipient'sserver,and(3)thestreamfromthe
recipient'sservertotherecipient'sclient.Furthermore,thestanzawill
beprocessedascleartextwithinthesender'sserverandtherecipient's
server.Therefore,evenifthestreamfromthesender'sclienttoits
serverisprotected,theconfidentialityandintegrityofastanzasent
overthatprotectedstreamcannotbeguaranteedwhenthestanzais
processedbythesender'sserver,sentfromthesender'sservertothe
recipient'sserver,processedbytherecipient'sserver,orsentfromthe
recipient'sservertotherecipient'sclient.Onlyarobusttechnologyfor
endtoendencryptioncouldensuretheconfidentialityandintegrityofa
stanzaasittraversesallofthe"hops"alongacommunicationpath
(e.g.,atechnologythatmeetstherequirementsdefinedin
[E2EREQS]).Unfortunately,theXMPPcommunityhassofarfailedto
produceanendtoendencryptiontechnologythatmightbesuitablefor
widespreadimplementationanddeployment,anddefinitionofsucha
technologyisoutofscopeforthisdocument.
13.5.PeerEntityAuthentication
TOC
TheuseoftheSimpleAuthenticationandSecurityLayer(SASL)forauthentication
providesareliablemechanismforpeerentityauthentication.Therefore,SASLhelps
toprotectagainstuserspoofing,unauthorizedusage,andmaninthemiddle
attacks.XMPPclientsandserversMUSTsupportSASLasdefinedunder Section6.
13.6.StrongSecurity
TOC
[STRONGSEC]defines"strongsecurity"anditsimportancetocommunicationover
theInternet.ForthepurposeofXMPPcommunicationoverclienttoserverand
servertoserverstreams,theterm"strongsecurity"referstotheuseofsecurity
technologiesthatprovidebothmutualauthenticationandintegritychecking(e.g.,a
combinationofTLSencryptionandSASLauthenticationusingappropriateSASL
mechanisms).
118/164
5/17/2016
ImplementationsMUSTsupportstrongsecurity.ServiceprovisioningSHOULDuse
strongsecurity.
AnimplementationSHOULDmakeitpossibleforanenduserorservice
administratortoprovisionadeploymentwithspecifictrustanchorsforthe
certificatepresentedbyaconnectingentity(eitherclientorserver)whenan
applicationisthusprovisioned,itMUSTNOTuseagenericPKItruststoreto
authenticatetheconnectingentity.Moredetailedrulesandguidelinesregarding
certificatevalidationareprovidedinthenextsection.
TheinitialstreamandtheresponsestreamMUSTbesecuredseparately,although
securityinbothdirectionsMAYbeestablishedviamechanismsthatprovidemutual
authentication.
13.7.Certificates
TOC
ChannelencryptionofanXMLstreamusingTransportLayerSecurityasdescribed
under Section5,andinsomecasesalsoauthenticationasdescribedunder
Section6,iscommonlybasedonaPKIXcertificatepresentedbythereceiving
entity(or,inthecaseofmutualcertificateauthentication,boththereceivingentity
andtheinitiatingentity).Thissectiondescribesbestpracticesregardingthe
generationofPKIXcertificatestobepresentedbyXMPPentitiesandtheverification
ofPKIXcertificatespresentedbyXMPPentities.
Ingeneral,thefollowingsectionsrelyonandextendtherulesandguidelines
providedinthe [PKIX]profileof [X509],andin [TLSCERTS].Thereaderis
referredtothosespecificationsforadetailedunderstandingofPKIXcertificatesand
theiruseinTLS.
13.7.1.CertificateGeneration
13.7.1.1.GeneralConsiderations
TOC
TOC
Thefollowingrulesapplytoendentitypublickeycertificatesthatareissuedto
XMPPserversorclients:
1.ThecertificateMUSTconformto [PKIX].
2.ThecertificateMUSTNOTcontainabasicConstraintsextensionwiththe
cAbooleansettoTRUE.
3.ThesubjectfieldMUSTNOTbenull.
4.ThesignatureAlgorithmSHOULDbethePKCS#1version1.5signature
algorithmwithSHA256asdefinedby [PKIXALGO],orastronger
algorithmifavailable.
5.ThecertificateSHOULDincludeanAuthorityInformationAccess(AIA)
extensionthatspecifiestheaddressofanOnlineCertificateStatus
Protocol [OCSP]responder(ifnot,arelyingpartywouldneedtofall
backontheuseofCertificateRevocationLists(CRLs)asdescribedin
[PKIX]).
Thefollowingrulesapplytocertificationauthority(CA)certificatesthatareusedby
issuersofXMPPendentitycertificates:
1.ThecertificateMUSTconformto [PKIX].
2.ThecertificateMUSTcontainakeyUsageextensionwiththe
119/164
5/17/2016
digitalSignaturebitset.
3.ThesubjectfieldMUSTNOTbenull.
4.ThesignatureAlgorithmSHOULDbethePKCS#1version1.5signature
algorithmwithSHA256asdefinedby [PKIXALGO],orastronger
algorithmifavailable.
5.Forissuersofpublickeycertificates,theissuer'scertificateMUST
containabasicConstraintsextensionwiththecAbooleansettoTRUE.
13.7.1.2.1.Rules
TOC
TOC
InaPKIXcertificatetobepresentedbyanXMPPserver(i.e.,a"servercertificate"),
thecertificateSHOULDincludeoneormoreXMPPaddresses(i.e.,domainparts)
associatedwithXMPPserviceshostedattheserver.Therulesandguidelines
definedin [TLSCERTS]applytoXMPPservercertificates,withthefollowingXMPP
specificconsiderations:
SupportfortheDNSIDidentifiertype [PKIX]isREQUIREDinXMPP
clientandserversoftwareimplementations.Certificationauthoritiesthat
issueXMPPspecificcertificatesMUSTsupporttheDNSIDidentifier
type.XMPPserviceprovidersSHOULDincludetheDNSIDidentifiertype
incertificaterequests.
SupportfortheSRVIDidentifiertype [PKIXSRV]isREQUIREDfor
XMPPclientandserversoftwareimplementations(forverification
purposesXMPPclientimplementationsneedtosupportonlythe"_xmpp
client"servicetype,whereasXMPPserverimplementationsneedto
supportboththe"_xmppclient"and"_xmppserver"servicetypes).
CertificationauthoritiesthatissueXMPPspecificcertificatesSHOULD
supporttheSRVIDidentifiertype.XMPPserviceprovidersSHOULD
includetheSRVIDidentifiertypeincertificaterequests.
SupportfortheXmppAddridentifiertype(specifiedunder
Section13.7.1.4)isencouragedinXMPPclientandserversoftware
implementationsforthesakeofbackwardcompatibility,butisnolonger
encouragedincertificatesissuedbycertificationauthoritiesor
requestedbyXMPPserviceproviders.
DNSdomainnamesinservercertificatesMAYcontainthewildcard
character'*'asthecompleteleftmostlabelwithintheidentifier.
13.7.1.2.2.Examples
TOC
Forourfirst(relativelysimple)example,consideracompanycalled"Example
Products,Inc."IthostsanXMPPserviceat"im.example.com"(i.e.,useraddresses
attheserviceareoftheform"user@im.example.com"),andSRVlookupsforthe
xmppclientandxmppserverservicesat"im.example.com"yieldonemachine,
called"x.example.com",asfollows:
_xmppclient._tcp.im.example.com.400INSRV2005222x.example.com
_xmppserver._tcp.im.example.com.400INSRV2005269x.example.com
Thecertificatepresentedbyx.example.comcontainsthefollowingrepresentations:
120/164
5/17/2016
AnotherNametypeofSRVName(idondnsSRV)containinganIA5String
(ASCII)stringof"_xmppclient.im.example.com"
(ASCII)stringof"_xmppserver.im.example.com"
AdNSNamecontaininganASCIIstringof"im.example.com"
AnotherNametypeofXmppAddr(idonxmppAddr)containingaUTF8
stringof"im.example.com"
ACNcontaininganASCIIstringof"ExampleProducts,Inc."
Foroursecond(morecomplex)example,consideranISPcalled"ExampleInternet
Services".IthostsanXMPPserviceat"example.net"(i.e.,useraddressesatthe
serviceareoftheform"user@example.net"),butSRVlookupsforthexmppclient
andxmppserverservicesat"example.net"yieldtwomachines("x1.example.net"
and"x2.example.net"),asfollows:
_xmppclient._tcp.example.net.68400INSRV2005222x1.example.net.
_xmppclient._tcp.example.net.68400INSRV2005222x2.example.net.
_xmppserver._tcp.example.net.68400INSRV2005269x1.example.net.
_xmppserver._tcp.example.net.68400INSRV2005269x2.example.net.
ExampleInternetServicesalsohostschatroomsatchat.example.net,andprovides
anxmppserverSRVrecordforthatserviceaswell(thusenablingentitiesfrom
remotedomainstoaccessthatservice).Italsomightprovideothersuchservicesin
thefuture,soitwishestorepresentawildcardinitscertificatetohandlesuch
growth.
Thecertificatepresentedbyeitherx1.example.netorx2.example.netcontainsthe
followingrepresentations:
(ASCII)stringof"_xmppclient.example.net"
(ASCII)stringof"_xmppserver.example.net"
(ASCII)stringof"_xmppserver.chat.example.net"
AdNSNamecontaininganASCIIstringof"example.net"
AdNSNamecontaininganASCIIstringof"*.example.net"
stringof"example.net"
stringof"chat.example.net"
ACNcontaininganASCIIstringof"ExampleInternetServices"
TOC
InaPKIXcertificatetobepresentedbyanXMPPclientcontrolledbyahumanuser
(i.e.,a"clientcertificate"),itisRECOMMENDEDforthecertificatetoincludeoneor
moreJIDsassociatedwithanXMPPuser.Ifincluded,aJIDMUSTberepresentedas
anXmppAddrasspecifiedunder Section13.7.1.4.
13.7.1.4.XmppAddrIdentifierType
TOC
TheXmppAddridentifiertypeisaUTF8StringwithinanotherNameentityinsidethe
subjectAltName,usingthe [ASN.1]ObjectIdentifier"idonxmppAddr"specified
below.
121/164
5/17/2016
idpkixOBJECTIDENTIFIER::={iso(1)identifiedorganization(3)
dod(6)internet(1)security(5)mechanisms(5)pkix(7)}
idonOBJECTIDENTIFIER::={idpkix8}othernameforms
idonxmppAddrOBJECTIDENTIFIER::={idon5}
XmppAddr::=UTF8String
Asanalternativetothe"idonxmppAddr"notation,thisObjectIdentifierMAYbe
representedindotteddisplayformat(i.e.,"1.3.6.1.5.5.7.8.5")orintheUniform
ResourceNamenotationspecifiedin [URNOID](i.e.,"urn:oid:1.3.6.1.5.5.7.8.5").
ThusforexampletheJID<juliet@im.example.com>asincludedinacertificate
couldbeformattedinanyofthefollowingthreeways:
idonxmppAddr:
subjectAltName=otherName:idon
xmppAddrUTF8:juliet@im.example.com
dotteddisplayformat:
subjectAltName=otherName:1.3.6.1.5.5.7.8.5UTF8:juliet@im.example.com
URNnotation:
subjectAltName=otherName:urn:oid:1.3.6.1.5.5.7.8.5UTF8:juliet@im.example.com
Useofthe"idonxmppAddr"formatisRECOMMENDEDinthegenerationof
certificates,butallthreeformatsMUSTbesupportedforthepurposeofcertificate
validation.
The"idonxmppAddr"objectidentifierMAYbeusedinconjunctionwiththe
extendedkeyusageextensionspecifiedinSection4.2.1.12of [PKIX]inorderto
explicitlydefineandlimittheintendeduseofacertificatetotheXMPPnetwork.
13.7.2.CertificateValidation
TOC
WhenanXMPPentityispresentedwithaservercertificateorclientcertificatebya
peerforthepurposeofencryptionorauthenticationofXMLstreamsasdescribed
under Section5and Section6,theentityMUSTattempttovalidatethecertificate
todetermineifthecertificatewillbeconsidereda"trustedcertificate",i.e.,a
certificatethatisacceptableforencryptionand/orauthenticationinaccordancewith
theXMPPentity'slocalservicepoliciesorconfiguredsettings.
Forbothservercertificatesandclientcertificates,thevalidatingentityMUSTdothe
following:
1.Attempttoverifytheintegrityofthecertificate.
2.Attempttoverifythatthecertificatehasbeenproperlysignedbythe
issuingCertificateAuthority.
3.Attempttovalidatethefullcertificationpath.
4.Checktherulesforendentitypublickeycertificatesandcertification
authoritycertificatesspecifiedunder Section13.7.1.1forthegeneral
caseandundereither Section13.7.1.2or Section13.7.1.3forXMPP
serverorclientcertificates,respectively.
5.CheckcertificaterevocationmessagesviaCertificateRevocationLists
(CRLs),theOnlineCertificateStatusProtocol [OCSP],orboth.
Ifanyofthosevalidationattemptsfail,thevalidatingentityMUSTunilaterally
terminatethesession.
122/164
5/17/2016
Thefollowingsectionsdescribetheadditionalidentityverificationrulesthatapplyto
servertoserverandclienttoserverstreams.
Oncetheidentityofthestreampeerhasbeenvalidated,thevalidatingentity
SHOULDalsocorrelatethevalidatedidentitywiththe'from'address(ifany)ofthe
streamheaderitreceivedfromthepeer.Ifthetwoidentitiesdonotmatch,the
validatingentitySHOULDterminatetheconnectionattempt(however,theremight
begoodreasonswhytheidentitiesdonotmatch,asdescribedunder
Section4.7.1).
TOC
Forservercertificates,therulesandguidelinesdefinedin [TLSCERTS]apply,with
theprovisothattheXmppAddridentifierspecifiedunder Section13.7.1.4is
allowedasareferenceidentifier.
Theidentitiestobecheckedaresetasfollows:
Theinitiatingentitysetsthesourcedomainofitsreferenceidentifiersto
the'to'addressitcommunicatesintheinitialstreamheaderi.e.,thisis
theidentityitexpectsthereceivingentitytoprovideinaPKIX
certificate.
Thereceivingentitysetsthesourcedomainofitsreferenceidentifiers
tothe'from'addresscommunicatedbytheinitiatingentityintheinitial
streamheaderi.e.,thisistheidentitythattheinitiatingentityistrying
toassert.
Inthecaseofservertoservercommunication,thematchingproceduredescribedin
[TLSCERTS]canbeperformedbyanapplicationserver(receivingentity)when
verifyinganincomingservertoserverconnectionfromapeerserver(initiating
entity).Inthiscase,thereceivingentityverifiestheidentityoftheinitiatingentity
andusesasthesourcedomainofitsreferenceidentifierstheDNSdomainname
assertedbytheinitiatingentityinthe'from'attributeoftheinitialstreamheader.
However,thematchingproceduredescribedin [TLSCERTS]remainsunchanged
andisappliedinthesameway.
TOC
WhenanXMPPservervalidatesacertificatepresentedbyaclient,therearethree
possiblecases,asdiscussedinthefollowingsections.
Theidentitiestobecheckedaresetasfollows:
Theclientsetsthesourcedomainofitsreferenceidentifierstothe'to'
addressitcommunicatesintheinitialstreamheaderi.e.,thisisthe
identityitexpectstheservertoprovideinaPKIXcertificate.
TheserversetsthebareJIDofitsreferenceidentifierstothe'from'
addresscommunicatedbytheinitiatingentityintheinitialstream
headeri.e.,thisistheidentitythattheclientistryingtoassert.
13.7.2.2.1.Case#1
TOC
Iftheclientcertificateappearstobecertifiedbyacertificationpathterminatingin
atrustanchor(asdescribedinSection6.1of [PKIX]),theserverMUSTcheckthe
123/164
5/17/2016
certificateforanyinstancesoftheXmppAddrasdescribedunder Section13.7.1.4.
Therearethreepossiblesubcases:
SubCase#1:
TheserverfindsoneXmppAddrforwhichthedomainpartofthe
representedJIDmatchesoneoftheconfiguredFQDNsoftheserverthe
serverSHOULDusethisrepresentedJIDasthevalidatedidentityofthe
client.
SubCase#2:
TheserverfindsmorethanoneXmppAddrforwhichthedomainpartof
therepresentedJIDmatchesoneoftheconfiguredFQDNsoftheserver
theserverSHOULDuseoneoftheserepresentedJIDsasthevalidated
identityoftheclient,choosingamongthembasedonthebareJID
containedinthe'from'addressoftheinitialstreamheader(ifany),based
onthedomainpartcontainedinthe'to'addressoftheinitialstream
header,orinaccordancewithlocalservicepolicies(suchasalookupina
userdatabasebasedonotherinformationcontainedintheclient
certificate).
SubCase#3:
TheserverfindsnoXmppAddrs,orfindsatleastoneXmppAddrbutthe
domainpartoftherepresentedJIDdoesnotmatchoneoftheconfigured
FQDNsoftheservertheserverMUSTNOTusetherepresentedJID(if
any)asthevalidatedidentityoftheclientbutinsteadMUSTvalidatethe
identityoftheclientusingothermeansinaccordancewithlocalservice
policies(suchasalookupinauserdatabasebasedonotherinformation
containedintheclientcertificate).Iftheidentitycannotbesovalidated,
theserverMAYabortthevalidationprocessandterminatetheTLS
negotiation.
13.7.2.2.2.Case#2
TOC
IftheclientcertificateiscertifiedbyaCertificateAuthoritynotknowntotheserver,
theserverMUSTproceedasunderCase#1,SubCase#3.
13.7.2.2.3.Case#3
TOC
Iftheclientcertificateisselfsigned,theserverMUSTproceedasunderCase#1,
SubCase#3.
13.7.2.3.CheckingofCertificatesinLongLivedStreams
TOC
BecauseXMPPuseslonglivedXMLstreams,itispossiblethatacertificate
presentedduringstreamnegotiationmightexpireorberevokedwhilethestreamis
stilllive(thisisespeciallyrelevantinthecontextofservertoserverstreams).
Therefore,eachpartytoalonglivedstreamSHOULD:
1.Cachetheexpirationdateofthecertificatepresentedbytheotherparty
andanycertificatesonwhichthatcertificatedepends(suchasarootor
intermediatecertificateforacertificationauthority),andclosethe
streamwhenanysuchcertificateexpires,withastreamerrorof
<reset/>(Section4.9.3.16).
2.PeriodicallyquerytheOnlineCertificateStatusProtocol [OCSP]
responderlistedintheAuthorityInformationAccess(AIA)extensionof
thecertificatepresentedbytheotherpartyandanycertificateson
124/164
5/17/2016
whichthatcertificatedepends(suchasarootorintermediatecertificate
foracertificationauthority),andclosethestreamifanysuchcertificate
hasbeenrevoked,withastreamerrorof<reset/>(Section4.9.3.16).
ItisRECOMMENDEDtoquerytheOSCPresponderatornearthetime
communicatedviathenextUpdatefieldreceivedintheOCSPresponse
or,ifthenextUpdatefieldisnotset,toqueryevery24hours.
Afterthestreamisclosed,theinitiatingentityfromtheclosedstreamwillneedto
reconnectandthereceivingentitywillneedtoauthenticatetheinitiatingentity
basedonwhatevercertificateitpresentsduringnegotiationofthenewstream.
13.7.2.4.UseofCertificatesinXMPPExtensions
TOC
CertificatesMAYbeusedinextensionstoXMPPforthepurposeofapplicationlayer
encryptionorauthenticationabovethelevelofXMLstreams(e.g.,forendtoend
encryption).Suchextensionswilldefinetheirowncertificatehandlingrules.Ata
minimum,suchextensionsareencouragedtoremainconsistentwiththerules
definedinthisspecification,specifyingadditionalrulesonlywhennecessary.
13.8.MandatorytoImplementTLSandSASLTechnologies
TOC
ThefollowingTLSciphersuitesandSASLmechanismsaremandatorytoimplement
(naturally,implementationsMAYsupportotherciphersuitesandmechanismsas
well).ForsecurityconsiderationsrelatedtoTLSciphersuites,see Section13.9.4
and [TLS].ForsecurityconsiderationsrelatedtoSASLmechanisms,see
Section13.9.4, [SASL],andspecificationsforparticularSASLmechanismssuchas
[SCRAM], [DIGESTMD5],and [PLAIN].
13.8.1.ForAuthenticationOnly
TOC
Forauthenticationonly,serversandclientsMUSTsupporttheSASLSaltedChallenge
ResponseAuthenticationMechanism [SCRAM]inparticular,theSCRAMSHA1
andSCRAMSHA1PLUSvariants.
SecurityWarning:Eventhoughitispossibletocompleteauthentication
onlywithoutconfidentiality,itisRECOMMENDEDforserversandclients
toprotectthestreamwithTLSbeforeattemptingauthenticationwith
SASL,bothtohelpprotecttheinformationexchangedduringSASL
negotiationandtohelppreventcertaindowngradeattacksasdescribed
under Section13.9.4and Section13.9.5.EvenifTLSisused,
implementationsSHOULDalsoenforcechannelbindingasdescribed
under Section13.9.4.
InteroperabilityNote:TheSCRAMSHA1orSASLSCRAMSHA1PLUS
variantsoftheSCRAMmechanismreplacetheSASLDIGESTMD5
mechanismasXMPP'smandatorytoimplementpasswordbasedmethod
forauthenticationonly.Forbackwardcompatibilitywithexisting
deployedinfrastructure,implementationsareencouragedtocontinue
supportingtheDIGESTMD5mechanismasspecifiedin [DIGESTMD5]
however,thereareknowninteroperabilityissueswithDIGESTMD5that
makeitimpracticalinthelongterm.
125/164
5/17/2016
13.8.2.ForConfidentialityOnly
TOC
Forconfidentialityonly,serversMUSTsupportTLSwiththe
TLS_RSA_WITH_AES_128_CBC_SHAciphersuite.
SecurityWarning:Becauseaconnectionwithconfidentialityonlyhas
weakersecuritypropertiesthanaconnectionwithbothconfidentiality
andauthentication,itisRECOMMENDEDforserversandclientstoprefer
connectionswithbothqualities(e.g.,byprotectingthestreamwithTLS
beforeattemptingauthenticationwithSASL).Inpractice,confidentiality
onlyisemployedmerelyforservertoserverconnectionswhenthe
peerserverdoesnotpresentatrustedcertificateandtheserversuse
ServerDialback [XEP0220]forweakidentityverification,butTLSwith
confidentialityonlyisstilldesirabletoprotecttheconnectionagainst
casualeavesdropping.
13.8.3.ForConfidentialityandAuthenticationwithPasswords
TOC
Forbothconfidentialityandauthenticationwithpasswords,serversandclients
MUSTimplementTLSwiththeTLS_RSA_WITH_AES_128_CBC_SHAciphersuiteplus
SASLSCRAM,inparticulartheSCRAMSHA1andSCRAMSHA1PLUSvariants(with
SCRAMSHA1PLUSbeingpreferred,asdescribedunder Section13.9.4).
AsfurtherexplainedinthefollowingSecurityWarning,incertaincircumstancesa
serverMAYofferTLSwiththeTLS_RSA_WITH_AES_128_CBC_SHAciphersuiteplus
SASLPLAINwhenitisnotpossibletooffermoresecurealternativesinaddition,
clientsSHOULDimplementPLAINoverTLSinordertomaximizeinteroperability
withserversthatarenotabletodeploymoresecurealternatives.
SecurityWarning:Inpractice,manyserversoffer,andmanyclients
use,TLSplusSASLPLAIN.TheSCRAMSHA1andespeciallySCRAM
SHA1PLUSvariantsoftheSCRAMmechanismarestronglypreferred
overthePLAINmechanismbecauseoftheirsuperiorsecurityproperties
(includingforSCRAMSHA1PLUStheabilitytoenforcechannelbinding
asdescribedunder Section13.9.4).AclientSHOULDtreatTLSplus
SASLPLAINasatechnologyoflastresorttobeusedonlywhen
interactingwithaserverthatdoesnotofferSCRAM(orother
alternativesthataremoresecurethanTLSplusSASLPLAIN),MUST
prefermoresecuremechanisms(e.g.,EXTERNAL,SCRAMSHA1PLUS,
SCRAMSHA1,ortheolderDIGESTMD5mechanism)tothePLAIN
mechanism,andMUSTNOTusethePLAINmechanismifthestream
doesnotataminimumhaveconfidentialityandintegrityprotectionvia
TLSwithfullcertificatevalidationasdescribedunder Section13.7.2.1.
AserverMUSTNOTofferSASLPLAINiftheconfidentialityandintegrity
ofthestreamarenotprotectedviaTLSoranequivalentsecuritylayer.
AserverSHOULDNOTofferTLSplusSASLPLAINunlessitisunableto
offersomevariantofSASLSCRAM(orotheralternativesthataremore
securethanTLSplusSASLPLAIN),e.g.,becausetheXMPPservice
dependsforauthenticationpurposesonadatabaseordirectorythatis
notunderthecontroloftheXMPPadministrators,suchasPluggable
AuthenticationModules(PAM),anLightweightDirectoryAccessProtocol
(LDAP)directory [LDAP],oranAuthentication,Authorization,and
Accounting(AAA)keymanagementprotocol(forguidance,referto
[AAA]).However,offeringTLSplusSASLPLAINevenwhentheserver
supportsmoresecurealternativesmightbeappropriateiftheserver
needstoenableinteroperabilitywithaninstalledbaseofclientsthatdo
notyetsupportSCRAMorotheralternativesthataremoresecurethan
TLSplusSASLPLAIN.
126/164
5/17/2016
13.8.4.ForConfidentialityandAuthenticationwithoutPasswords
TOC
Forbothconfidentialityandauthenticationwithoutpasswords,serversMUSTand
clientsSHOULDimplementTLSwiththeTLS_RSA_WITH_AES_128_CBC_SHA
ciphersuiteplustheSASLEXTERNALmechanism(seeAppendixAof [SASL])with
PKIXcertificates.
13.9.TechnologyReuse
13.9.1.UseofBase64inSASL
TOC
TOC
BoththeclientandtheserverMUSTverifyanybase64datareceivedduring SASL
negotiation.AnimplementationMUSTreject(notignore)anycharactersthatare
notexplicitlyallowedbythebase64alphabetthishelpstoguardagainstcreation
ofacovertchannelthatcouldbeusedto"leak"information.
AnimplementationMUSTNOTbreakoninvalidinputandMUSTrejectanysequence
ofbase64characterscontainingthepad('=')characterifthatcharacterisincluded
assomethingotherthanthelastcharacterofthedata(e.g.,"=AAA"or
"BBBB=CCC")thishelpstoguardagainstbufferoverflowattacksandotherattacks
ontheimplementation.
Whilebase64encodingvisuallyhidesotherwiseeasilyrecognizedinformation(such
aspasswords),itdoesnotprovideanycomputationalconfidentiality.
Allusesofbase64encodingMUSTfollowthedefinitioninSection4of [BASE64]
andpaddingbitsMUSTbesettozero.
13.9.2.UseofDNS
TOC
XMPPtypicallyreliesontheDomainNameSystem(specifically [DNSSRV]
records)toresolveafullyqualifieddomainnametoanIPaddressbeforeaclient
connectstoaserverorbeforeapeerserverconnectstoanotherserver.Before
attemptingtonegotiateanXMLstream,theinitiatingentityMUSTNOTproceeduntil
ithasresolvedtheDNSdomainnameofthereceivingentityasspecifiedunder
Section3(althoughitisnotnecessarytoresolvetheDNSdomainnamebefore
eachconnectionattempt,becauseDNSresolutionresultscanbetemporarilycached
inaccordancewithtimetolivevalues).However,intheabsenceofasecureDNS
option(e.g.,asprovidedby [DNSSEC]),amaliciousattackerwithaccesstothe
DNSserverdata,orabletocausespoofedanswerstobecachedinarecursive
resolver,canpotentiallycausetheinitiatingentitytoconnecttoanyXMPPserver
chosenbytheattacker.Deploymentandvalidationofservercertificateshelpto
preventsuchattacks.
13.9.3.UseofHashFunctions
TOC
XMPPitselfdoesnotdirectlymandatetheuseofanyparticularcryptographichash
function.However,technologiesonwhichXMPPdepends(e.g.,TLSandparticular
SASLmechanisms),aswellasvariousXMPPextensions,mightmakeuseof
127/164
5/17/2016
cryptographichashfunctions.ThosewhoimplementXMPPtechnologiesorwho
developXMPPextensionsareadvisedtocloselymonitorthestateoftheart
regardingattacksagainstcryptographichashfunctionsinInternetprotocolsasthey
relatetoXMPP.Forhelpfulguidance,referto [HASHES].
13.9.4.UseofSASL
TOC
BecausetheinitiatingentitychoosesanacceptableSASLmechanismfromthelist
presentedbythereceivingentity,theinitiatingentitydependsonthereceiving
entity'slistforauthentication.Thisdependencyintroducesthepossibilityofa
downgradeattackifanattackercangaincontrolofthechannelandtherefore
presentaweaklistofmechanisms.Tomitigatethisattack,thepartiesSHOULD
protectthechannelusingTLSbeforeattemptingSASLnegotiationandeither
performfullcertificatevalidationasdescribedunder Section13.7.2.1orusea
SASLmechanismthatprovideschannelbindings,suchasSCRAMSHA1PLUS.
(ProtectingthechannelviaTLSwithfullcertificatevalidationcanhelptoensurethe
confidentialityandintegrityoftheinformationexchangedduringSASLnegotiation.)
TheSASLframeworkitselfdoesnotprovideamethodforbindingSASL
authenticationtoasecuritylayerprovidingconfidentialityandintegrityprotection
thatwasnegotiatedatalowerlayer(e.g.,TLS).Suchabindingisknownasa
"channelbinding"(see [CHANNEL]).SomeSASLmechanismsprovidechannel
bindings,whichinthecaseofXMPPwouldtypicallybeabindingtoTLS(see
[CHANNELTLS]).IfaSASLmechanismprovidesachannelbinding(e.g.,thisis
trueof [SCRAM]),thenXMPPentitiesusingthatmechanismSHOULDpreferthe
channelbindingvariant(e.g.,preferring"SCRAMSHA1PLUS"over"SCRAMSHA
1").IfaSASLmechanismdoesnotprovideachannelbinding,thenthemechanism
cannotprovideawaytoverifythatthesourceanddestinationendpointstowhich
thelowerlayer'ssecurityisboundareequivalenttotheendpointsthatSASLis
authenticatingfurthermore,iftheendpointsarenotidentical,thenthelower
layer'ssecuritycannotbetrustedtoprotectdatatransmittedbetweentheSASL
authenticatedentities.Insuchasituation,aSASLsecuritylayerSHOULDbe
negotiatedthateffectivelyignoresthepresenceofthelowerlayersecurity.
ManydeployedXMPPservicesauthenticateclientconnectionsbymeansof
passwords.Itiswellknownthatmosthumanuserschooserelativelyweak
passwords.Althoughserviceprovisioningisoutofscopeforthisdocument,XMPP
serversthatallowpasswordbasedauthenticationSHOULDenforceminimalcriteria
forpasswordstrengthtohelppreventdictionaryattacks.Becauseallpassword
basedauthenticationmechanismsaresusceptibletopasswordguessingattacks,
XMPPserversMUSTlimitthenumberofretriesallowedduringSASLauthentication,
asdescribedunder Section6.4.5.
SomeSASLmechanisms(e.g., [ANONYMOUS])donotprovidestrongpeerentity
authenticationoftheclienttotheserver.Serviceadministratorsareadvisedto
enablesuchmechanismswithcaution.BestpracticesfortheuseoftheSASL
ANONYMOUSmechanisminXMPParedescribedin [XEP0175].
13.9.5.UseofTLS
TOC
ImplementationsofTLStypicallysupportmultipleversionsoftheTransportLayer
SecurityprotocolaswellastheolderSecureSocketsLayer(SSL)protocol.Because
ofknownsecurityvulnerabilities,XMPPserversandclientsMUSTNOTrequest,
offer,oruseSSL2.0.Forfurtherdetails,seeAppendixE.2of [TLS]alongwith
[TLSSSL2].
128/164
5/17/2016
Topreventmaninthemiddleattacks,theTLSclient(whichmightbeanXMPP
clientoranXMPPserver)MUSTverifythecertificateoftheTLSserverandMUST
checkitsunderstandingoftheserverFQDNagainsttheserver'sidentityas
presentedintheTLSCertificatemessageasdescribedunder Section13.7.2.1(for
furtherdetails,see [TLSCERTS].
SupportforTLSrenegotiationisstrictlyOPTIONAL.However,implementationsthat
supportTLSrenegotiationMUSTimplementandusetheTLSRenegotiationExtension
[TLSNEG].Furtherdetailsareprovidedunder Section5.3.5.
13.9.6.UseofUTF8
TOC
TheuseofUTF8makesitpossibletotransportnonASCIIcharacters,andthus
enablescharacter"spoofing"scenarios,inwhichadisplayedvalueappearstobe
somethingotherthanitis.Furthermore,thereareknownattackscenariosrelated
tothedecodingofUTF8data.Onbothofthesepoints,referto [UTF8]formore
information.
13.9.7.UseofXML
TOC
BecauseXMPPisanapplicationprofileoftheExtensibleMarkupLanguage [XML],
manyofthesecurityconsiderationsdescribedin [XMLMEDIA]and [XMLGUIDE]
alsoapplytoXMPP.SeveralaspectsofXMPPmitigatetherisksdescribedthere,
suchastheprohibitionsspecifiedunder Section11.1andthelackofexternal
referencestostylesheetsortransformations,butthesemitigatingfactorsarebyno
meanscomprehensive.
13.10.InformationLeaks
13.10.1.IPAddresses
TOC
TOC
Aclient'sIPaddressandmethodofaccessMUSTNOTbemadepublicbyaserver
(e.g.,astypicallyoccursin [IRC]).
13.10.2.PresenceInformation
TOC
OneofthecoreaspectsofXMPPispresence:informationaboutthenetwork
availabilityofanXMPPentity(i.e.,whethertheentityiscurrentlyonlineoroffline).
A"presenceleak"occurswhenanentity'snetworkavailabilityisinadvertentlyand
involuntarilyrevealedtoasecondentitythatisnotauthorizedtoknowthefirst
entity'snetworkavailability.
Althoughpresenceisdiscussedmorefullyin [XMPPIM],itisimportanttonote
thatanXMPPserverMUSTNOTleakpresence.InparticularatthecoreXMPPlevel,
realtimeaddressingandnetworkavailabilityisassociatedwithaspecificconnected
resourcetherefore,anydisclosureofaconnectedresource'sfullJIDcomprisesa
presenceleak.Tohelppreventsuchapresenceleak,aserverMUSTNOTreturn
differentstanzaerrorsdependingonwhetherapotentialattackersendsXML
129/164
5/17/2016
stanzastotheentity'sbareJID(<localpart@domainpart>)orfullJID
(<localpart@domainpart/resourcepart>).
13.11.DirectoryHarvesting
TOC
Ifaservergeneratesanerrorstanzainresponsetoreceivingastanzaforauser
accountthatdoesnotexist,usingthe<serviceunavailable/>stanzaerrorcondition
(Section8.3.3.19)canhelpprotectagainstdirectoryharvestingattacks,sincethis
isthesameerrorconditionthatisreturnedif,forinstance,thenamespaceofanIQ
childelementisnotunderstood,orif"offlinemessagestorage"([XEP0160])or
messageforwardingisnotenabledforadomain.However,subtledifferencesinthe
exactXMLoferrorstanzas,aswellasinthetimingwithwhichsucherrorsare
returned,canenableanattackertodeterminethenetworkpresenceofauserwhen
moreadvancedblockingtechnologiesarenotused(seeforinstance [XEP0016]
and [XEP0191]).Therefore,aserverthatexercisesahigherlevelofcautionmight
notreturnanyerroratallinresponsetocertainkindsofreceivedstanzas,sothata
nonexistentuserappearstobehavelikeauserthathasnointerestinconversing
withthesender.
13.12.DenialofService
TOC
[DOS]definesdenialofserviceasfollows:
Adenialofservice(DoS)attackisanattackinwhichoneormore
machinestargetavictimandattempttopreventthevictimfromdoing
usefulwork.Thevictimcanbeanetworkserver,clientorrouter,a
networklinkoranentirenetwork,anindividualInternetuserora
companydoingbusinessusingtheInternet,anInternetServiceProvider
(ISP),country,oranycombinationoforvariantonthese.
Someconsiderationsdiscussedinthisdocumenthelptopreventdenialofservice
attacks(e.g.,themandatethataserverMUSTNOTprocessXMLstanzasfrom
clientsthathavenotyetprovidedappropriateauthenticationcredentialsandMUST
NOTprocessXMLstanzasfrompeerserverswhoseidentityithasnoteither
authenticatedviaSASLorweaklyverifiedviaServerDialback).
Inaddition, [XEP0205]providesadetaileddiscussionofpotentialdenialofservice
attacksagainstXMPPsystemsalongwithbestpracticesforpreventingsuchattacks.
Therecommendationsinclude:
1.AserverimplementationSHOULDenableaserveradministratortolimit
thenumberofTCPconnectionsthatitwillacceptfromagivenIP
addressatanyonetime.Ifanentityattemptstoconnectbutthe
maximumnumberofTCPconnectionshasbeenreached,thereceiving
serverMUSTNOTallowthenewconnectiontoproceed.
thenumberofTCPconnectionattemptsthatitwillacceptfromagiven
IPaddressinagiventimeperiod.Ifanentityattemptstoconnectbut
themaximumnumberofconnectionattemptshasbeenreached,the
receivingserverMUSTNOTallowthenewconnectiontoproceed.
thenumberofconnectedresourcesitwillallowanaccounttobindat
anyonetime.Ifaclientattemptstobindaresourcebutithasalready
reachedtheconfigurednumberofallowableresources,thereceiving
serverMUSTreturna<resourceconstraint/>stanzaerror
(Section8.3.3.18).
130/164
5/17/2016
thesizeofstanzasitwillacceptfromaconnectedclientorpeerserver
(where"size"isinclusiveofallXMLmarkupasdefinedinSection2.4of
[XML],fromtheopening"<"characterofthestanzatotheclosing">"
character).Adeployedserver'smaximumstanzasizeMUSTNOTbe
smallerthan10000bytes,whichreflectsareasonablecompromise
betweenthebenefitsofexpressivenessfororiginatingentitiesandthe
costsofstanzaprocessingforservers.Aserverimplementation
SHOULDNOTblindlyset10000bytesasthevalueforalldeployments
butinsteadSHOULDenableserveradministratorstosettheirown
limits.Ifaconnectedresourceorpeerserversendsastanzathat
violatestheupperlimit,thereceivingserverMUSTeitherreturna
<policyviolation/>stanzaerror(Section8.3.3.12),thusallowingthe
sendertorecover,orclosethestreamwitha<policyviolation/>
thenumberofXMLstanzasthataconnectedclientisallowedtosendto
distinctrecipientswithinagiventimeperiod.Ifaconnectedclientsends
toomanystanzastodistinctrecipientsinagiventimeperiod,the
receivingserverSHOULDNOTprocessthestanzaandinsteadSHOULD
returna<policyviolation/>stanzaerror(Section8.3.3.12).
theamountofbandwidthitwillallowaconnectedclientorpeerserver
touseinagiventimeperiod.
7.AserverimplementationMAYenableaserveradministratortolimitthe
typesofstanzas(basedontheextendedcontent"payload")thatitwill
allowaconnectedresourceorpeerserversendoveranactive
connection.Suchlimitsandrestrictionsareamatterofdeployment
policy.
8.AserverimplementationMAYrefusetorouteordeliveranystanzathat
itconsiderstobeabusive,withorwithoutreturninganerrortothe
sender.
FormoredetailedrecommendationsregardingdenialofserviceattacksinXMPP
systems,referto [XEP0205].
13.13.Firewalls
TOC
AlthoughDNSSRVrecordscaninstructconnectingentitiestouseTCPportsother
than5222(clienttoserver)and5269(servertoserver),communicationusing
XMPPtypicallyoccursoverthoseports,whichareregisteredwiththeIANA(see
Section14).Useofthesewellknownportsallowsadministratorstoeasilyenable
ordisableXMPPactivitythroughexistingandcommonlydeployedfirewalls.
13.14.InterdomainFederation
TOC
Theterm"federation"iscommonlyusedtodescribecommunicationbetweentwo
servers.
Becauseserviceprovisioningisamatterofpolicy,itisOPTIONALforanygiven
servertosupportfederation.Ifaparticularserverenablesfederation,itSHOULD
enablestrongsecurityaspreviouslydescribedtoensurebothauthenticationand
confidentialitycompliantimplementationsSHOULDsupportTLSandSASLforthis
purpose.
BeforeRFC3920definedTLSplusSASLEXTERNALwithcertificatesforencryption
131/164
5/17/2016
andauthenticationofservertoserverstreams,theonlymethodforweakidentity
verificationofapeerserverwasServerDialbackasdefinedin [XEP0220].Even
when [DNSSEC]isused,ServerDialbackprovidesonlyweakidentityverification
andprovidesnoconfidentialityorintegrity.Atthetimeofwriting,ServerDialback
isstillthemostwidelyusedtechniqueforsomelevelofassuranceoverserverto
serverstreams.Thisrealityintroducesthepossibilityofadowngradeattackfrom
TLS+SASLEXTERNALtoServerDialbackifanattackercangaincontrolofthe
channelandthereforeconvincetheinitiatingserverthatthereceivingserverdoes
notsupportTLSordoesnothaveanappropriatecertificate.Tohelppreventthis
attack,thepartiesSHOULDprotectthechannelusingTLSbeforeproceeding,evenif
thepresentedcertificatesareselfsignedorotherwiseuntrusted.
13.15.NonRepudiation
TOC
Systemsthatprovidebothpeerentityauthenticationanddataintegrityhavethe
potentialtoenableanentitytoprovetoathirdpartythatanotherentityintendedto
sendparticulardata.AlthoughXMPPsystemscanprovidebothpeerentity
authenticationanddataintegrity,XMPPwasneverdesignedtoprovidenon
repudiation.
14.IANAConsiderations
TOC
Thefollowingsubsectionsupdatetheregistrationsprovidedin [RFC3920].This
sectionistobeinterpretedaccordingto [IANAGUIDE].
14.1.XMLNamespaceNameforTLSData
TOC
AURNsubnamespaceforSTARTTLSnegotiationdataintheExtensibleMessaging
andPresenceProtocol(XMPP)isdefinedasfollows.(Thisnamespacenameadheres
totheformatdefinedin [XMLREG].)
URI:
urn:ietf:params:xml:ns:xmpptls
Specification:
RFC6120
Description:
ThisistheXMLnamespacenameforSTARTTLSnegotiationdatainthe
ExtensibleMessagingandPresenceProtocol(XMPP)asdefinedbyRFC
6120.
RegistrantContact:
IESG<iesg@ietf.org>
14.2.XMLNamespaceNameforSASLData
TOC
AURNsubnamespaceforSASLnegotiationdataintheExtensibleMessagingand
PresenceProtocol(XMPP)isdefinedasfollows.(Thisnamespacenameadheresto
theformatdefinedin [XMLREG].)
URI:
urn:ietf:params:xml:ns:xmppsasl
Specification:
132/164
5/17/2016
RFC6120
Description:
ThisistheXMLnamespacenameforSASLnegotiationdatainthe
ExtensibleMessagingandPresenceProtocol(XMPP)asdefinedbyRFC
6120.
RegistrantContact:
IESG<iesg@ietf.org>
14.3.XMLNamespaceNameforStreamErrors
TOC
AURNsubnamespaceforstreamerrordataintheExtensibleMessagingand
URI:
urn:ietf:params:xml:ns:xmppstreams
Specification:
RFC6120
Description:
ThisistheXMLnamespacenameforstreamerrordataintheExtensible
MessagingandPresenceProtocol(XMPP)asdefinedbyRFC6120.
RegistrantContact:
IESG<iesg@ietf.org>
14.4.XMLNamespaceNameforResourceBinding
TOC
AURNsubnamespaceforresourcebindingintheExtensibleMessagingand
URI:
urn:ietf:params:xml:ns:xmppbind
Specification:
RFC6120
Description:
ThisistheXMLnamespacenameforresourcebindingintheExtensible
RegistrantContact:
IESG<iesg@ietf.org>
14.5.XMLNamespaceNameforStanzaErrors
TOC
AURNsubnamespaceforstanzaerrordataintheExtensibleMessagingand
URI:
urn:ietf:params:xml:ns:xmppstanzas
Specification:
RFC6120
Description:
ThisistheXMLnamespacenameforstanzaerrordataintheExtensible
133/164
5/17/2016
RegistrantContact:
IESG<iesg@ietf.org>
14.6.GSSAPIServiceName
TOC
TheIANAhasregistered"xmpp"asa [GSSAPI]servicename,asdefinedunder
Section6.6.
14.7.PortNumbersandServiceNames
TOC
TheIANAhasregistered"xmppclient"and"xmppserver"askeywordsfor [TCP]
ports5222and5269,respectively.Inaccordancewith [IANAPORTS],this
documentupdatestheexistingregistration,asfollows.
ServiceName:
xmppclient
TransportProtocol:
TCP
Description:
AserviceofferingsupportforconnectionsbyXMPPclientapplications
Registrant:
IETFXMPPWorkingGroup
Contact:
IESG<iesg@ietf.org>
Reference:
RFC6120
PortNumber:
5222
ServiceName:
xmppserver
TransportProtocol:
TCP
Description:
AserviceofferingsupportforconnectionsbyXMPPserverapplications
Registrant:
IETFXMPPWorkingGroup
Contact:
IESG<iesg@ietf.org>
Reference:
RFC6120
PortNumber:
5269
15.ConformanceRequirements
TOC
Thissectiondescribesaprotocolfeaturesetthatsummarizestheconformance
requirementsofthisspecification.Thisfeaturesetisappropriateforuseinsoftware
certification,interoperabilitytesting,andimplementationreports.Foreachfeature,
thissectionprovidesthefollowinginformation:
Ahumanreadablename
Aninformationaldescription
Areferencetotheparticularsectionofthisdocumentthatnormatively
134/164
5/17/2016
definesthefeature
WhetherthefeatureappliestotheClientrole,theServerrole,orboth
(where"N/A"signifiesthatthefeatureisnotapplicabletothespecified
role)
WhetherthefeatureMUSTorSHOULDbeimplemented,wherethe
capitalizedtermsaretobeunderstoodasdescribedin [KEYWORDS]
Thefeaturesetspecifiedhereattemptstoadheretotheconceptsandformats
proposedbyLarryMasinterwithintheIETF'sNEWTRKWorkingGroupin2005,as
capturedin [INTEROP].Althoughthisfeaturesetismoredetailedthancalledfor
by [REPORTS],itprovidesasuitablebasisforthegenerationofimplementation
reportstobesubmittedinsupportofadvancingthisspecificationfromProposed
StandardtoDraftStandardinaccordancewith [PROCESS].
Feature:
bindgen
Description:
Generatearandomresourceondemand.
Section:
Section7.6
Roles:
ClientN/A,ServerMUST.
Feature:
bindmtn
Description:
Considerresourcebindingasmandatorytonegotiate.
Section:
Section7.3.1
Roles:
ClientMUST,ServerMUST.
Feature:
bindrestart
Description:
Donotrestartthestreamafternegotiationofresourcebinding.
Section:
Section7.3.2
Roles:
Feature:
bindsupport
Description:
Supportbindingofclientresourcestoanauthenticatedstream.
Section:
Section7
Roles:
Feature:
saslcorrelate
Description:
WhenauthenticatingastreampeerusingSASL,correlatethe
authenticationidentifierresultingfromSASLnegotiationwiththe'from'
address(ifany)ofthestreamheaderitreceivedfromthepeer.
Section:
Section6.4.6
Roles:
ClientSHOULD,ServerSHOULD.
Feature:
135/164
5/17/2016
saslerrors
Description:
SupportSASLerrorsduringthenegotiationprocess.
Section:
Section6.5
Roles:
Feature:
saslmtn
Description:
ConsiderSASLasmandatorytonegotiate.
Section:
Section6.3.1
Roles:
Feature:
saslrestart
Description:
InitiateorhandleastreamrestartafterSASLnegotiation.
Section:
Section6.3.2
Roles:
Feature:
saslsupport
Description:
SupporttheSimpleAuthenticationandSecurityLayerforstream
authentication.
Section:
Section6
Roles:
Feature:
securitymtiauthscram
Description:
SupporttheSASLSCRAMmechanismforauthenticationonly(thisimplies
supportforboththeSCRAMSHA1andSCRAMSHA1PLUSvariants).
Section:
Section13.8
Roles:
Feature:
securitymtibothexternal
Description:
SupportTLSwithSASLEXTERNALforconfidentialityandauthentication.
Section:
Section13.8
Roles:
ClientSHOULD,ServerMUST.
Feature:
securitymtibothplain
Description:
SupportTLSusingtheTLS_RSA_WITH_AES_128_CBC_SHAciphersuite
plustheSASLPLAINmechanismforconfidentialityandauthentication.
Section:
Section13.8
136/164
5/17/2016
Roles:
ClientSHOULD,ServerMAY.
Feature:
securitymtibothscram
Description:
SupportTLSusingtheTLS_RSA_WITH_AES_128_CBC_SHAciphersuite
plustheSCRAMSHA1andSCRAMSHA1PLUSvariantsoftheSASL
SCRAMmechanismforconfidentialityandauthentication.
Section:
Section13.8
Roles:
Feature:
securitymticonfidentiality
Description:
SupportTLSusingtheTLS_RSA_WITH_AES_128_CBC_SHAciphersuitefor
confidentialityonly.
Section:
Section13.8
Roles:
ClientN/A,ServerSHOULD.
Feature:
stanzaattributefrom
Description:
Supportthecommon'from'attributeforallstanzakinds.
Section:
Section8.1.2
Roles:
Feature:
stanzaattributefromstamp
Description:
Stamporrewritethe'from'addressofallstanzasreceivedfrom
connectedclients.
Section:
Section8.1.2.1
Roles:
Feature:
stanzaattributefromvalidate
Description:
Validatethe'from'addressofallstanzasreceivedfrompeerservers.
Section:
Section8.1.2.2
Roles:
Feature:
stanzaattributeid
Description:
Supportthecommon'id'attributeforallstanzakinds.
Section:
Section8.1.3
Roles:
Feature:
137/164
5/17/2016
stanzaattributeto
Description:
Supportthecommon'to'attributeforallstanzakinds.
Section:
Section8.1.1
Roles:
Feature:
stanzaattributetovalidate
Description:
Ensurethatallstanzasreceivedfrompeerserversincludea'to'address.
Section:
Section8.1.1
Roles:
Feature:
stanzaattributetype
Description:
Supportthecommon'type'attributeforallstanzakinds.
Section:
Section8.1.4
Roles:
Feature:
stanzaattributexmllang
Description:
Supportthecommon'xml:lang'attributeforallstanzakinds.
Section:
Section8.1.5
Roles:
Feature:
stanzaerror
Description:
Generateandhandlestanzasoftype"error"forallstanzakinds.
Section:
Section8.3
Roles:
Feature:
stanzaerrorchild
Description:
Ensurethatstanzasoftype"error"includean<error/>childelement.
Section:
Section8.3
Roles:
Feature:
stanzaerrorid
Description:
Ensurethatstanzasoftype"error"preservethe'id'providedinthe
triggeringstanza.
Section:
Section8.3
Roles:
138/164
5/17/2016
Feature:
stanzaerrorreply
Description:
Donotreplytoastanzaoftype"error"withanotherstanzaoftype
"error".
Section:
Section8.3
Roles:
Feature:
stanzaextension
Description:
CorrectlyprocessXMLdataqualifiedbyanunsupportedXMLnamespace,
where"correctlyprocess"meanstoignorethatportionofthestanzain
thecaseofamessageorpresencestanzaandreturnanerrorinthecase
ofanIQstanza(fortheintendedrecipient),andtorouteordeliverthe
stanza(foraroutingentitysuchasaserver).
Section:
Section8.4
Roles:
Feature:
stanzaiqchild
Description:
Includeexactlyonechildelementinan<iq/>stanzaoftype"get"or
"set",zerooronechildelementsinan<iq/>stanzaoftype"result",and
oneortwochildelementsinan<iq/>stanzaoftype"error".
Section:
Section8.2.3
Roles:
Feature:
stanzaiqid
Description:
Ensurethatall<iq/>stanzasincludean'id'attribute.
Section:
Section8.2.3
Roles:
Feature:
stanzaiqreply
Description:
Replytoan<iq/>stanzaoftype"get"or"set"withan<iq/>stanzaof
type"result"or"error".
Section:
Section8.2.3
Roles:
Feature:
stanzaiqtype
Description:
Ensurethatall<iq/>stanzasincludea'type'attributewhosevalueis
"get","set","result",or"error".
Section:
Section8.2.3
Roles:
139/164
5/17/2016
Feature:
stanzakindiq
Description:
Supportthe<iq/>stanza.
Section:
Section8.2.3
Roles:
Feature:
stanzakindmessage
Description:
Supportthe<message/>stanza.
Section:
Section8.2.1
Roles:
Feature:
stanzakindpresence
Description:
Supportthe<presence/>stanza.
Section:
Section8.2.2
Roles:
Feature:
streamattributeinitialfrom
Description:
Includea'from'attributeintheinitialstreamheader.
Section:
Section4.7.1
Roles:
ClientSHOULD,ServerMUST.
Feature:
streamattributeinitiallang
Description:
Includean'xml:lang'attributeintheinitialstreamheader.
Section:
Section4.7.4
Roles:
Feature:
streamattributeinitialto
Description:
Includea'to'attributeintheinitialstreamheader.
Section:
Section4.7.2
Roles:
Feature:
streamattributeresponsefrom
Description:
Includea'from'attributeintheresponsestreamheader.
Section:
Section4.7.1
Roles:
140/164
5/17/2016
Feature:
streamattributeresponseid
Description:
Includean'id'attributeintheresponsestreamheader.
Section:
Section4.7.3
Roles:
Feature:
streamattributeresponseidunique
Description:
Ensurethatthe'id'attributeintheresponsestreamheaderisunique
withinthecontextofthereceivingentity.
Section:
Section4.7.3
Roles:
Feature:
streamattributeresponseto
Description:
Includea'to'attributeintheresponsestreamheader.
Section:
Section4.7.2
Roles:
ClientN/A,ServerSHOULD.
Feature:
streamerrorgenerate
Description:
Generateastreamerror(followedbyaclosingstreamtagand
terminationoftheTCPconnection)upondetectingastreamrelatederror
condition.
Section:
Section4.9
Roles:
Feature:
streamfqdnresolution
Description:
ResolveFQDNsbeforeopeningaTCPconnectiontothereceivingentity.
Section:
Section3.2
Roles:
Feature:
streamnegotiationcomplete
Description:
Donotconsiderthestreamnegotiationprocesstobecompleteuntilthe
receivingentitysendsastreamfeaturesadvertisementthatisemptyor
thatcontainsonlyvoluntarytonegotiatefeatures.
Section:
Section4.3.5
Roles:
Feature:
streamnegotiationfeatures
Description:
141/164
5/17/2016
Sendstreamfeaturesaftersendingaresponsestreamheader.
Section:
Section4.3.2
Roles:
Feature:
streamnegotiationrestart
Description:
Considerthepreviousstreamtobereplaceduponnegotiationofastream
featurethatnecessitatesastreamrestart,andsendorreceiveanew
initialstreamheaderafternegotiationofsuchastreamfeature.
Section:
Section4.3.3
Roles:
Feature:
streamreconnect
Description:
ReconnectwithexponentialbackoffifaTCPconnectionisterminated
unexpectedly.
Section:
Section3.3
Roles:
Feature:
streamtcpbinding
Description:
BindanXMLstreamtoaTCPconnection.
Section:
Section3
Roles:
Feature:
tlscerts
Description:
ChecktheidentityspecifiedinacertificatethatispresentedduringTLS
negotiation.
Section:
Section13.7.2
Roles:
Feature:
tlsmtn
Description:
ConsiderTLSasmandatorytonegotiateifSTARTTLSistheonlyfeature
advertisedoriftheSTARTTLSfeatureadvertisementincludesanempty
<required/>element.
Section:
Section5.3.1
Roles:
Feature:
tlsrestart
Description:
InitiateorhandleastreamrestartafterTLSnegotiation.
Section:
142/164
5/17/2016
Section5.3.2
Roles:
Feature:
tlssupport
Description:
SupportTransportLayerSecurityforstreamencryption.
Section:
Section5
Roles:
Feature:
tlscorrelate
Description:
WhenvalidatingacertificatepresentedbyastreampeerduringTLS
negotiation,correlatethevalidatedidentitywiththe'from'address(if
any)ofthestreamheaderitreceivedfromthepeer.
Section:
Section13.7.2
Roles:
Feature:
xmlnamespacecontentclient
Description:
Support'jabber:client'asacontentnamespace.
Section:
Section4.8.2
Roles:
Feature:
xmlnamespacecontentserver
Description:
Support'jabber:server'asacontentnamespace.
Section:
Section4.8.2
Roles:
Feature:
xmlnamespacestreamsdeclaration
Description:
Ensurethatthereisanamespacedeclarationforthe
'http://etherx.jabber.org/streams'namespace.
Section:
Section4.8.1
Roles:
Feature:
xmlnamespacestreamsprefix
Description:
Ensurethatallelementsqualifiedbythe
'http://etherx.jabber.org/streams'namespaceareprefixedbytheprefix
(ifany)definedinthenamespacedeclaration.
Section:
Section4.8.1
Roles:
143/164
5/17/2016
Feature:
xmlrestrictioncomment
Description:
DonotgenerateoracceptXMLcomments.
Section:
Section11.1
Roles:
Feature:
xmlrestrictiondtd
Description:
DonotgenerateoracceptinternalorexternalDTDsubsets.
Section:
Section11.1
Roles:
Feature:
xmlrestrictionpi
Description:
DonotgenerateoracceptXMLprocessinginstructions.
Section:
Section11.1
Roles:
Feature:
xmlrestrictionref
Description:
Donotgenerateoracceptinternalorexternalentityreferenceswiththe
exceptionofthepredefinedentities.
Section:
Section11.1
Roles:
Feature:
xmlwellformedxml
Description:
DonotgenerateoracceptdatathatisnotXMLwellformed.
Section:
Section11.3
Roles:
Feature:
xmlwellformedns
Description:
Donotgenerateoracceptdatathatisnotnamespacewellformed.
Section:
Section11.3
Roles:
16.References
TOC
TOC
144/164
5/17/2016
16.1.NormativeReferences
[BASE64]
Josefsson,S.,TheBase16,Base32,andBase64DataEncodings,RFC4648,October2006
(TXT).
[CHANNEL]
Williams,N.,OntheUseofChannelBindingstoSecureChannels,RFC5056,November2007
(TXT).
[CHANNEL
TLS]
Altman,J.,Williams,N.,andL.Zhu,ChannelBindingsforTLS,RFC5929,July2010(TXT).
[CHARSETS]
Alvestrand,H.,IETFPolicyonCharacterSetsandLanguages,BCP18,RFC2277,
January1998(TXT,HTML,XML).
[DNS
CONCEPTS]
Mockapetris,P.,Domainnamesconceptsandfacilities,STD13,RFC1034,November1987
(TXT).
[DNSSRV]
Gulbrandsen,A.,Vixie,P.,andL.Esibov,ADNSRRforspecifyingthelocationofservices
(DNSSRV),RFC2782,February2000(TXT).
[IPv6ADDR]
Kawamura,S.andM.Kawashima,ARecommendationforIPv6AddressTextRepresentation,
RFC5952,August2010(TXT).
[KEYWORDS] Bradner,S.,KeywordsforuseinRFCstoIndicateRequirementLevels,BCP14,RFC2119,
March1997(TXT,HTML,XML).
[LANGMATCH] Phillips,A.andM.Davis,MatchingofLanguageTags,BCP47,RFC4647,September2006(TXT).
[LANGTAGS]
Phillips,A.andM.Davis,TagsforIdentifyingLanguages,BCP47,RFC5646,September2009
(TXT).
[OCSP]
Myers,M.,Ankney,R.,Malpani,A.,Galperin,S.,andC.Adams,X.509InternetPublicKey
InfrastructureOnlineCertificateStatusProtocolOCSP,RFC2560,June1999(TXT).
[PKIX]
Cooper,D.,Santesson,S.,Farrell,S.,Boeyen,S.,Housley,R.,andW.Polk,InternetX.509Public
KeyInfrastructureCertificateandCertificateRevocationList(CRL)Profile,RFC5280,
May2008(TXT).
[PKIXALGO] Jonsson,J.andB.Kaliski,PublicKeyCryptographyStandards(PKCS)#1:RSACryptography
SpecificationsVersion2.1,RFC3447,February2003(TXT).
[PKIXSRV]
Santesson,S.,InternetX.509PublicKeyInfrastructureSubjectAlternativeNamefor
ExpressionofServiceName,RFC4985,August2007(TXT).
[PLAIN]
Zeilenga,K.,ThePLAINSimpleAuthenticationandSecurityLayer(SASL)Mechanism,
RFC4616,August2006(TXT).
[RANDOM]
Eastlake,D.,Schiller,J.,andS.Crocker,RandomnessRequirementsforSecurity,BCP106,
RFC4086,June2005(TXT).
[SASL]
Melnikov,A.andK.Zeilenga,SimpleAuthenticationandSecurityLayer(SASL),RFC4422,
June2006(TXT).
[SCRAM]
Newman,C.,MenonSen,A.,Melnikov,A.,andN.Williams,SaltedChallengeResponse
AuthenticationMechanism(SCRAM)SASLandGSSAPIMechanisms,RFC5802,July2010
(TXT).
[STRONGSEC] Schiller,J.,StrongSecurityRequirementsforInternetEngineeringTaskForceStandard
Protocols,BCP61,RFC3365,August2002(TXT).
[TCP]
Postel,J.,TransmissionControlProtocol,STD7,RFC793,September1981(TXT).
[TLS]
Dierks,T.andE.Rescorla,TheTransportLayerSecurity(TLS)ProtocolVersion1.2,RFC5246,
August2008(TXT).
[TLSCERTS]
SaintAndre,P.andJ.Hodges,RepresentationandVerificationofDomainBasedApplication
ServiceIdentitywithinInternetPublicKeyInfrastructureUsingX.509(PKIX)Certificatesin
theContextofTransportLayerSecurity(TLS),RFC6125,March2011.
[TLSNEG]
Rescorla,E.,Ray,M.,Dispensa,S.,andN.Oskov,TransportLayerSecurity(TLS)Renegotiation
IndicationExtension,RFC5746,February2010(TXT).
[TLSSSL2]
Turner,S.andT.Polk,ProhibitingSecureSocketsLayer(SSL)Version2.0,RFC6176,
March2011.
[UCS2]
InternationalOrganizationforStandardization,InformationTechnologyUniversalMultipleoctet
codedCharacterSet(UCS)Amendment2:UCSTransformationFormat8(UTF8),ISOStandard
106461Addendum2,October1996.
[UNICODE]
TheUnicodeConsortium,TheUnicodeStandard,Version6.0,2010.
[UTF8]
Yergeau,F.,UTF8,atransformationformatofISO10646,STD63,RFC3629,November2003
(TXT).
[URI]
BernersLee,T.,Fielding,R.,andL.Masinter,UniformResourceIdentifier(URI):Generic
Syntax,STD66,RFC3986,January2005(TXT,HTML,XML).
[X509]
InternationalTelecommunicationsUnion,InformationtechnologyOpenSystemsInterconnection
TheDirectory:Publickeyandattributecertificateframeworks,ITUTRecommendationX.509,
ISOStandard95948,March2000.
[XML]
Maler,E.,Yergeau,F.,SperbergMcQueen,C.,Paoli,J.,andT.Bray,ExtensibleMarkupLanguage
(XML)1.0(FifthEdition),WorldWideWebConsortiumRecommendationRECxml20081126,
November2008(HTML).
[XMLGUIDE] Hollenbeck,S.,Rose,M.,andL.Masinter,GuidelinesfortheUseofExtensibleMarkup
Language(XML)withinIETFProtocols,BCP70,RFC3470,January2003(TXT,HTML,XML).
[XMLMEDIA] Murata,M.,St.Laurent,S.,andD.Kohn,XMLMediaTypes,RFC3023,January2001(TXT).
[XMLNAMES] Thompson,H.,Hollander,D.,Layman,A.,Bray,T.,andR.Tobin,NamespacesinXML1.0(Third
145/164
5/17/2016
Edition),WorldWideWebConsortiumRecommendationRECxmlnames20091208,December2009
(HTML).
[XMPPADDR] SaintAndre,P.,ExtensibleMessagingandPresenceProtocol(XMPP):AddressFormat,
RFC6122,March2011.
[XMPPIM]
SaintAndre,P.,ExtensibleMessagingandPresenceProtocol(XMPP):InstantMessagingand
Presence,RFC6121,March2011.
16.2.InformativeReferences
TOC
[AAA]
Housley,R.andB.Aboba,GuidanceforAuthentication,Authorization,andAccounting(AAA)
KeyManagement,BCP132,RFC4962,July2007(TXT).
[ABNF]
Crocker,D.andP.Overell,AugmentedBNFforSyntaxSpecifications:ABNF,STD68,
RFC5234,January2008(TXT).
[ACAP]
Newman,C.andJ.Myers,ACAPApplicationConfigurationAccessProtocol,RFC2244,
November1997(TXT).
[ANONYMOUS] Zeilenga,K.,AnonymousSimpleAuthenticationandSecurityLayer(SASL)Mechanism,
RFC4505,June2006(TXT).
[ASN.1]
CCITT,RecommendationX.208:SpecificationofAbstractSyntaxNotationOne(ASN.1),1988.
[DIGESTMD5] Leach,P.andC.Newman,UsingDigestAuthenticationasaSASLMechanism,RFC2831,
May2000(TXT).
[DNSSEC]
Arends,R.,Austein,R.,Larson,M.,Massey,D.,andS.Rose,DNSSecurityIntroductionand
Requirements,RFC4033,March2005(TXT).
[DNSTXT]
Rosenbaum,R.,UsingtheDomainNameSystemToStoreArbitraryStringAttributes,
RFC1464,May1993(TXT).
[DOS]
Handley,M.,Rescorla,E.,andIAB,InternetDenialofServiceConsiderations,RFC4732,
December2006(TXT).
[E2EREQS]
SaintAndre,P.,RequirementsforEndtoEndEncryptionintheExtensibleMessagingandPresence
Protocol(XMPP),WorkinProgress,March2010.
[EMAILARCH] Crocker,D.,InternetMailArchitecture,RFC5598,July2009(TXT).
[ETHERNET]
InformationtechnologyTelecommunicationsandinformationexchangebetweensystemsLocal
andmetropolitanareanetworksSpecificrequirementsPart3:Carriersensemultipleaccesswith
collisiondetection(CSMA/CD)accessmethodandphysicallayerspecifications,IEEEStandard802.3,
September1998.
[GSSAPI]
Linn,J.,GenericSecurityServiceApplicationProgramInterfaceVersion2,Update1,
[HASHES]
Hoffman,P.andB.Schneier,AttacksonCryptographicHashesinInternetProtocols,
RFC4270,November2005(TXT).
[HTTP]
Fielding,R.,Gettys,J.,Mogul,J.,Frystyk,H.,Masinter,L.,Leach,P.,andT.BernersLee,
HypertextTransferProtocolHTTP/1.1,RFC2616,June1999(TXT,PS,PDF,HTML,XML).
[IANAGUIDE] Narten,T.andH.Alvestrand,GuidelinesforWritinganIANAConsiderationsSectioninRFCs,
BCP26,RFC5226,May2008(TXT).
[IANAPORTS] Cotton,M.,Eggert,L.,Touch,J.,Westerlund,M.,andS.Cheshire,InternetAssignedNumbers
Authority(IANA)ProceduresfortheManagementoftheTransportProtocolPortNumberandService
NameRegistry,WorkinProgress,February2011.
[IMAP]
Crispin,M.,INTERNETMESSAGEACCESSPROTOCOLVERSION4rev1,RFC3501,March2003
(TXT).
[IMPREQS]
Day,M.,Aggarwal,S.,andJ.Vincent,InstantMessaging/PresenceProtocol
Requirements,RFC2779,February2000(TXT).
[INTEROP]
Masinter,L.,FormalizingIETFInteroperabilityReporting,WorkinProgress,October2005.
[IRC]
Kalt,C.,InternetRelayChat:Architecture,RFC2810,April2000(TXT).
[IRI]
Duerst,M.andM.Suignard,InternationalizedResourceIdentifiers(IRIs),RFC3987,
January2005(TXT).
[LDAP]
Zeilenga,K.,LightweightDirectoryAccessProtocol(LDAP):TechnicalSpecificationRoad
Map,RFC4510,June2006(TXT).
[LINKLOCAL]
Cheshire,S.,Aboba,B.,andE.Guttman,DynamicConfigurationofIPv4LinkLocalAddresses,
RFC3927,May2005(TXT).
[MAILBOXES] Crocker,D.,MAILBOXNAMESFORCOMMONSERVICES,ROLESANDFUNCTIONS,RFC2142,
May1997(TXT,HTML,XML).
[POP3]
Myers,J.andM.Rose,PostOfficeProtocolVersion3,STD53,RFC1939,May1996(TXT).
[PROCESS]
Bradner,S.,TheInternetStandardsProcessRevision3,BCP9,RFC2026,October1996
(TXT).
[REPORTS]
Dusseault,L.andR.Sparks,GuidanceonInteroperationandImplementationReportsfor
AdvancementtoDraftStandard,BCP9,RFC5657,September2009(TXT).
[REST]
Fielding,R.,ArchitecturalStylesandtheDesignofNetworkbasedSoftwareArchitectures,
2000.
[RFC3920]
SaintAndre,P.,Ed.,ExtensibleMessagingandPresenceProtocol(XMPP):Core,RFC3920,
October2004(TXT,HTML,XML).
146/164
5/17/2016
[RFC3921]
SaintAndre,P.,Ed.,ExtensibleMessagingandPresenceProtocol(XMPP):Instant
MessagingandPresence,RFC3921,October2004(TXT,HTML,XML).
[SASLPREP]
Zeilenga,K.,SASLprep:StringprepProfileforUserNamesandPasswords,RFC4013,
February2005(TXT).
[SECTERMS]
Shirey,R.,InternetSecurityGlossary,Version2,RFC4949,August2007(TXT).
[SMTP]
Klensin,J.,SimpleMailTransferProtocol,RFC5321,October2008(TXT).
[SECGUIDE]
Rescorla,E.andB.Korver,GuidelinesforWritingRFCTextonSecurityConsiderations,
BCP72,RFC3552,July2003(TXT).
[TLSEXT]
Eastlake3rd,D.,TransportLayerSecurity(TLS)Extensions:ExtensionDefinitions,
[TLSRESUME] Salowey,J.,Zhou,H.,Eronen,P.,andH.Tschofenig,TransportLayerSecurity(TLS)Session
ResumptionwithoutServerSideState,RFC5077,January2008(TXT).
[URNOID]
Mealling,M.,AURNNamespaceofObjectIdentifiers,RFC3061,February2001(TXT).
[USINGTLS]
Newman,C.,UsingTLSwithIMAP,POP3andACAP,RFC2595,June1999(TXT).
[UUID]
Leach,P.,Mealling,M.,andR.Salz,AUniversallyUniqueIDentifier(UUID)URN
Namespace,RFC4122,July2005(TXT,HTML,XML).
[XEP0001]
SaintAndre,P.,XMPPExtensionProtocols,XSFXEP0001,March2010.
[XEP0016]
Millard,P.andP.SaintAndre,PrivacyLists,XSFXEP0016,February2007.
[XEP0045]
SaintAndre,P.,MultiUserChat,XSFXEP0045,July2007.
[XEP0060]
Millard,P.,SaintAndre,P.,andR.Meijer,PublishSubscribe,XSFXEP0060,July2010.
[XEP0071]
SaintAndre,P.,XHTMLIM,XSFXEP0071,September2008.
[XEP0077]
SaintAndre,P.,InBandRegistration,XSFXEP0077,September2009.
[XEP0086]
Norris,R.andP.SaintAndre,ErrorConditionMappings,XSFXEP0086,February2004.
[XEP0100]
SaintAndre,P.andD.Smith,GatewayInteraction,XSFXEP0100,October2005.
[XEP0114]
SaintAndre,P.,JabberComponentProtocol,XSFXEP0114,March2005.
[XEP0124]
Paterson,I.,Smith,D.,andP.SaintAndre,BidirectionalstreamsOverSynchronousHTTP
(BOSH),XSFXEP0124,July2010.
[XEP0138]
Hildebrand,J.andP.SaintAndre,StreamCompression,XSFXEP0138,May2009.
[XEP0156]
Hildebrand,J.andP.SaintAndre,DiscoveringAlternativeXMPPConnectionMethods,XSF
XEP0156,June2007.
[XEP0160]
SaintAndre,P.,BestPracticesforHandlingOfflineMessages,XSFXEP0160,January2006.
[XEP0174]
SaintAndre,P.,LinkLocalMessaging,XSFXEP0174,November2008.
[XEP0175]
SaintAndre,P.,BestPracticesforUseofSASLANONYMOUS,XSFXEP0175,
September2009.
[XEP0178]
SaintAndre,P.andP.Millard,BestPracticesforUseofSASLEXTERNALwithCertificates,
XSFXEP0178,February2007.
[XEP0191]
SaintAndre,P.,SimpleCommunicationsBlocking,XSFXEP0191,February2007.
[XEP0198]
Karneges,J.,Hildebrand,J.,SaintAndre,P.,Forno,F.,Cridland,D.,andM.Wild,Stream
Management,XSFXEP0198,February2011.
[XEP0199]
SaintAndre,P.,XMPPPing,XSFXEP0199,June2009.
[XEP0205]
SaintAndre,P.,BestPracticestoDiscourageDenialofServiceAttacks,XSFXEP0205,
January2009.
[XEP0206]
Paterson,I.andP.SaintAndre,XMPPOverBOSH,XSFXEP0206,July2010.
[XEP0220]
Miller,J.,SaintAndre,P.,andP.Hancke,ServerDialback,XSFXEP0220,March2010.
[XEP0225]
SaintAndre,P.,ComponentConnections,XSFXEP0225,October2008.
[XEP0233]
Miller,M.,SaintAndre,P.,andJ.Hildebrand,DomainBasedServiceNamesinXMPPSASL
Negotiation,XSFXEP0233,June2010.
[XEP0288]
Hancke,P.andD.Cridland,BidirectionalServertoServerConnections,XSFXEP0288,
October2010.
[XMLFRAG]
Grosso,P.andD.Veillard,XMLFragmentInterchange,WorldWideWebConsortiumCRCRxml
fragment20010212,February2001(HTML).
[XMLREG]
Mealling,M.,TheIETFXMLRegistry,BCP81,RFC3688,January2004(TXT).
[XML
SCHEMA]
Thompson,H.,Maloney,M.,Mendelsohn,N.,andD.Beech,XMLSchemaPart1:Structures
SecondEdition,WorldWideWebConsortiumRecommendationRECxmlschema120041028,
October2004(HTML).
[XMPPURI]
SaintAndre,P.,InternationalizedResourceIdentifiers(IRIs)andUniformResource
Identifiers(URIs)fortheExtensibleMessagingandPresenceProtocol(XMPP),RFC5122,
February2008(TXT).
AppendixA.XMLSchemas
TOC
Thefollowingschemasformallydefinevariousnamespacesusedinthisdocument,
inconformancewith [XMLSCHEMA].BecausevalidationofXMLstreamsand
147/164
5/17/2016
stanzasisoptional,theseschemasarenotnormativeandareprovidedfor
descriptivepurposesonly.
A.1.StreamNamespace
TOC
<?xmlversion='1.0'encoding='UTF8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='http://etherx.jabber.org/streams'
xmlns='http://etherx.jabber.org/streams'
elementFormDefault='unqualified'>
<xs:importnamespace='jabber:client'/>
<xs:importnamespace='jabber:server'/>
<xs:importnamespace='urn:ietf:params:xml:ns:xmppsasl'/>
<xs:importnamespace='urn:ietf:params:xml:ns:xmppstreams'/>
<xs:importnamespace='urn:ietf:params:xml:ns:xmpptls'/>
<xs:elementname='stream'>
<xs:complexType>
<xs:sequencexmlns:client='jabber:client'
xmlns:server='jabber:server'>
<xs:elementref='features'
minOccurs='0'
maxOccurs='1'/>
<xs:anynamespace='urn:ietf:params:xml:ns:xmpptls'
minOccurs='0'
maxOccurs='1'/>
<xs:anynamespace='urn:ietf:params:xml:ns:xmppsasl'
minOccurs='0'
maxOccurs='1'/>
<xs:anynamespace='##other'
minOccurs='0'
maxOccurs='unbounded'
processContents='lax'/>
<xs:choiceminOccurs='0'maxOccurs='1'>
<xs:choiceminOccurs='0'maxOccurs='unbounded'>
<xs:elementref='client:message'/>
<xs:elementref='client:presence'/>
<xs:elementref='client:iq'/>
</xs:choice>
<xs:elementref='server:message'/>
<xs:elementref='server:presence'/>
<xs:elementref='server:iq'/>
</xs:choice>
</xs:choice>
<xs:elementref='error'minOccurs='0'maxOccurs='1'/>
</xs:sequence>
<xs:attributename='from'type='xs:string'use='optional'/>
<xs:attributename='id'type='xs:string'use='optional'/>
<xs:attributename='to'type='xs:string'use='optional'/>
<xs:attributename='version'type='xs:decimal'use='optional'/>
<xs:attributeref='xml:lang'use='optional'/>
<xs:anyAttributenamespace='##other'processContents='lax'/>
</xs:complexType>
148/164
5/17/2016
</xs:element>
<xs:elementname='features'>
<xs:complexType>
<xs:sequence>
minOccurs='0'
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:elementname='error'>
<xs:complexType>
<xs:sequencexmlns:err='urn:ietf:params:xml:ns:xmppstreams'>
<xs:groupref='err:streamErrorGroup'/>
<xs:elementref='err:text'
minOccurs='0'
maxOccurs='1'/>
minOccurs='0'
maxOccurs='1'
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
A.2.StreamErrorNamespace
TOC
<xs:schema
targetNamespace='urn:ietf:params:xml:ns:xmppstreams'
xmlns='urn:ietf:params:xml:ns:xmppstreams'
elementFormDefault='qualified'>
<xs:elementname='badformat'type='empty'/>
<xs:elementname='badnamespaceprefix'type='empty'/>
<xs:elementname='conflict'type='empty'/>
<xs:elementname='connectiontimeout'type='empty'/>
<xs:elementname='hostgone'type='empty'/>
<xs:elementname='hostunknown'type='empty'/>
<xs:elementname='improperaddressing'type='empty'/>
<xs:elementname='internalservererror'type='empty'/>
<xs:elementname='invalidfrom'type='empty'/>
<xs:elementname='invalidid'type='empty'/>
<xs:elementname='invalidnamespace'type='empty'/>
<xs:elementname='invalidxml'type='empty'/>
<xs:elementname='notauthorized'type='empty'/>
<xs:elementname='notwellformed'type='empty'/>
<xs:elementname='policyviolation'type='empty'/>
<xs:elementname='remoteconnectionfailed'type='empty'/>
<xs:elementname='reset'type='empty'/>
149/164
5/17/2016
<xs:elementname='resourceconstraint'type='empty'/>
<xs:elementname='restrictedxml'type='empty'/>
<xs:elementname='seeotherhost'type='xs:string'/>
<xs:elementname='systemshutdown'type='empty'/>
<xs:elementname='undefinedcondition'type='empty'/>
<xs:elementname='unsupportedencoding'type='empty'/>
<xs:elementname='unsupportedstanzatype'type='empty'/>
<xs:elementname='unsupportedversion'type='empty'/>
<xs:groupname='streamErrorGroup'>
<xs:choice>
<xs:elementref='badformat'/>
<xs:elementref='badnamespaceprefix'/>
<xs:elementref='conflict'/>
<xs:elementref='connectiontimeout'/>
<xs:elementref='hostgone'/>
<xs:elementref='hostunknown'/>
<xs:elementref='improperaddressing'/>
<xs:elementref='internalservererror'/>
<xs:elementref='invalidfrom'/>
<xs:elementref='invalidid'/>
<xs:elementref='invalidnamespace'/>
<xs:elementref='invalidxml'/>
<xs:elementref='notauthorized'/>
<xs:elementref='notwellformed'/>
<xs:elementref='policyviolation'/>
<xs:elementref='remoteconnectionfailed'/>
<xs:elementref='reset'/>
<xs:elementref='resourceconstraint'/>
<xs:elementref='restrictedxml'/>
<xs:elementref='seeotherhost'/>
<xs:elementref='systemshutdown'/>
<xs:elementref='undefinedcondition'/>
<xs:elementref='unsupportedencoding'/>
<xs:elementref='unsupportedstanzatype'/>
<xs:elementref='unsupportedversion'/>
</xs:choice>
</xs:group>
<xs:elementname='text'>
<xs:complexType>
<xs:simpleContent>
<xs:extensionbase='xs:string'>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:simpleTypename='empty'>
<xs:restrictionbase='xs:string'>
<xs:enumerationvalue=''/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
A.3.STARTTLSNamespace
TOC
150/164
5/17/2016
<xs:schema
targetNamespace='urn:ietf:params:xml:ns:xmpptls'
xmlns='urn:ietf:params:xml:ns:xmpptls'
<xs:elementname='starttls'>
<xs:complexType>
<xs:choiceminOccurs='0'maxOccurs='1'>
<xs:elementname='required'type='empty'/>
</xs:choice>
</xs:complexType>
</xs:element>
<xs:elementname='proceed'type='empty'/>
<xs:elementname='failure'type='empty'/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
A.4.SASLNamespace
TOC
<xs:schema
targetNamespace='urn:ietf:params:xml:ns:xmppsasl'
xmlns='urn:ietf:params:xml:ns:xmppsasl'
<xs:elementname='mechanisms'>
<xs:complexType>
<xs:sequence>
<xs:elementname='mechanism'
minOccurs='1'
type='xs:NMTOKEN'/>
minOccurs='0'
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:elementname='abort'type='empty'/>
<xs:elementname='auth'>
151/164
5/17/2016
<xs:complexType>
<xs:simpleContent>
<xs:attributename='mechanism'
type='xs:NMTOKEN'
use='required'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:elementname='challenge'type='xs:string'/>
<xs:elementname='response'type='xs:string'/>
<xs:elementname='success'type='xs:string'/>
<xs:elementname='failure'>
<xs:complexType>
<xs:sequence>
<xs:choiceminOccurs='0'>
<xs:elementname='aborted'type='empty'/>
<xs:elementname='accountdisabled'type='empty'/>
<xs:elementname='credentialsexpired'type='empty'/>
<xs:elementname='encryptionrequired'type='empty'/>
<xs:elementname='incorrectencoding'type='empty'/>
<xs:elementname='invalidauthzid'type='empty'/>
<xs:elementname='invalidmechanism'type='empty'/>
<xs:elementname='malformedrequest'type='empty'/>
<xs:elementname='mechanismtooweak'type='empty'/>
<xs:elementname='temporaryauthfailure'type='empty'/>
</xs:choice>
<xs:elementref='text'minOccurs='0'maxOccurs='1'/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:complexType>
<xs:simpleContent>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:restriction>
</xs:simpleType>
</xs:schema>
A.5.ClientNamespace
TOC
152/164
5/17/2016
<xs:schema
targetNamespace='jabber:client'
<xs:import
namespace='urn:ietf:params:xml:ns:xmppstanzas'/>
<xs:elementname='message'>
<xs:complexType>
<xs:sequence>
<xs:elementref='subject'/>
<xs:elementref='body'/>
<xs:elementref='thread'/>
</xs:choice>
minOccurs='0'
<xs:elementref='error'
minOccurs='0'/>
</xs:sequence>
<xs:attributename='from'
type='xs:string'
use='optional'/>
<xs:attributename='id'
type='xs:NMTOKEN'
use='optional'/>
<xs:attributename='to'
type='xs:string'
use='optional'/>
<xs:attributename='type'
use='optional'
default='normal'>
<xs:simpleType>
<xs:restrictionbase='xs:NMTOKEN'>
<xs:enumerationvalue='chat'/>
<xs:enumerationvalue='error'/>
<xs:enumerationvalue='groupchat'/>
<xs:enumerationvalue='headline'/>
<xs:enumerationvalue='normal'/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:elementname='body'>
<xs:complexType>
<xs:simpleContent>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
153/164
5/17/2016
<xs:elementname='subject'>
<xs:complexType>
<xs:simpleContent>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:elementname='thread'>
<xs:complexType>
<xs:simpleContent>
<xs:extensionbase='xs:NMTOKEN'>
<xs:attributename='parent'
type='xs:NMTOKEN'
use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:elementname='presence'>
<xs:complexType>
<xs:sequence>
<xs:elementref='show'/>
<xs:elementref='status'/>
<xs:elementref='priority'/>
</xs:choice>
minOccurs='0'
minOccurs='0'/>
</xs:sequence>
type='xs:string'
use='optional'/>
type='xs:NMTOKEN'
use='optional'/>
type='xs:string'
use='optional'/>
<xs:attributename='type'use='optional'>
<xs:simpleType>
<xs:enumerationvalue='probe'/>
<xs:enumerationvalue='subscribe'/>
<xs:enumerationvalue='subscribed'/>
<xs:enumerationvalue='unavailable'/>
<xs:enumerationvalue='unsubscribe'/>
<xs:enumerationvalue='unsubscribed'/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
154/164
5/17/2016
</xs:complexType>
</xs:element>
<xs:elementname='show'>
<xs:simpleType>
<xs:enumerationvalue='away'/>
<xs:enumerationvalue='dnd'/>
<xs:enumerationvalue='xa'/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:elementname='status'>
<xs:complexType>
<xs:simpleContent>
<xs:extensionbase='string1024'>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:simpleTypename='string1024'>
<xs:minLengthvalue='1'/>
<xs:maxLengthvalue='1024'/>
</xs:restriction>
</xs:simpleType>
<xs:elementname='priority'type='xs:byte'/>
<xs:elementname='iq'>
<xs:complexType>
<xs:sequence>
minOccurs='0'
maxOccurs='1'
minOccurs='0'/>
</xs:sequence>
type='xs:string'
use='optional'/>
type='xs:NMTOKEN'
use='required'/>
type='xs:string'
use='optional'/>
<xs:attributename='type'use='required'>
<xs:simpleType>
<xs:enumerationvalue='get'/>
<xs:enumerationvalue='result'/>
<xs:enumerationvalue='set'/>
</xs:restriction>
</xs:simpleType>
155/164
5/17/2016
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:complexType>
<xs:sequencexmlns:err='urn:ietf:params:xml:ns:xmppstanzas'>
<xs:groupref='err:stanzaErrorGroup'/>
minOccurs='0'/>
</xs:sequence>
<xs:attributename='by'
type='xs:string'
use='optional'/>
<xs:simpleType>
<xs:enumerationvalue='auth'/>
<xs:enumerationvalue='cancel'/>
<xs:enumerationvalue='continue'/>
<xs:enumerationvalue='modify'/>
<xs:enumerationvalue='wait'/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
</xs:schema>
A.6.ServerNamespace
TOC
<xs:schema
targetNamespace='jabber:server'
<xs:import
namespace='urn:ietf:params:xml:ns:xmppstanzas'/>
<xs:elementname='message'>
<xs:complexType>
<xs:sequence>
<xs:elementref='subject'/>
<xs:elementref='body'/>
<xs:elementref='thread'/>
</xs:choice>
minOccurs='0'
156/164
5/17/2016
minOccurs='0'/>
</xs:sequence>
type='xs:string'
use='required'/>
type='xs:NMTOKEN'
use='optional'/>
type='xs:string'
use='required'/>
<xs:attributename='type'
use='optional'
default='normal'>
<xs:simpleType>
<xs:enumerationvalue='groupchat'/>
<xs:enumerationvalue='headline'/>
<xs:enumerationvalue='normal'/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:elementname='body'>
<xs:complexType>
<xs:simpleContent>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:complexType>
<xs:simpleContent>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:elementname='thread'>
<xs:complexType>
<xs:simpleContent>
type='xs:NMTOKEN'
use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
157/164
5/17/2016
<xs:complexType>
<xs:simpleContent>
type='xs:NMTOKEN'
use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:elementname='presence'>
<xs:complexType>
<xs:sequence>
<xs:elementref='show'/>
<xs:elementref='status'/>
<xs:elementref='priority'/>
</xs:choice>
minOccurs='0'
minOccurs='0'/>
</xs:sequence>
type='xs:string'
use='required'/>
type='xs:NMTOKEN'
use='optional'/>
type='xs:string'
use='required'/>
<xs:attributename='type'use='optional'>
<xs:simpleType>
<xs:enumerationvalue='probe'/>
<xs:enumerationvalue='subscribe'/>
<xs:enumerationvalue='subscribed'/>
<xs:enumerationvalue='unavailable'/>
<xs:enumerationvalue='unsubscribe'/>
<xs:enumerationvalue='unsubscribed'/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:elementname='show'>
<xs:simpleType>
<xs:enumerationvalue='away'/>
<xs:enumerationvalue='dnd'/>
<xs:enumerationvalue='xa'/>
</xs:restriction>
</xs:simpleType>
158/164
5/17/2016
</xs:element>
<xs:elementname='status'>
<xs:complexType>
<xs:simpleContent>
<xs:extensionbase='string1024'>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:simpleTypename='string1024'>
</xs:restriction>
</xs:simpleType>
<xs:elementname='priority'type='xs:byte'default='0'/>
<xs:elementname='iq'>
<xs:complexType>
<xs:sequence>
minOccurs='0'
maxOccurs='1'
minOccurs='0'/>
</xs:sequence>
type='xs:string'
use='required'/>
type='xs:NMTOKEN'
use='required'/>
type='xs:string'
use='required'/>
<xs:simpleType>
<xs:enumerationvalue='get'/>
<xs:enumerationvalue='result'/>
<xs:enumerationvalue='set'/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:complexType>
<xs:sequencexmlns:err='urn:ietf:params:xml:ns:xmppstanzas'>
<xs:groupref='err:stanzaErrorGroup'/>
minOccurs='0'/>
</xs:sequence>
159/164
5/17/2016
<xs:attributename='by'
type='xs:string'
use='optional'/>
<xs:simpleType>
<xs:enumerationvalue='auth'/>
<xs:enumerationvalue='cancel'/>
<xs:enumerationvalue='continue'/>
<xs:enumerationvalue='modify'/>
<xs:enumerationvalue='wait'/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
</xs:schema>
A.7.ResourceBindingNamespace
TOC
<xs:schema
targetNamespace='urn:ietf:params:xml:ns:xmppbind'
xmlns='urn:ietf:params:xml:ns:xmppbind'
<xs:elementname='bind'>
<xs:complexType>
<xs:choice>
<xs:elementname='resource'type='resourceType'/>
<xs:elementname='jid'type='fullJIDType'/>
</xs:choice>
</xs:complexType>
</xs:element>
<xs:simpleTypename='fullJIDType'>
</xs:restriction>
</xs:simpleType>
<xs:simpleTypename='resourceType'>
</xs:restriction>
</xs:simpleType>
</xs:schema>
TOC
160/164
5/17/2016
A.8.StanzaErrorNamespace
<xs:schema
targetNamespace='urn:ietf:params:xml:ns:xmppstanzas'
xmlns='urn:ietf:params:xml:ns:xmppstanzas'
<xs:elementname='badrequest'type='empty'/>
<xs:elementname='conflict'type='empty'/>
<xs:elementname='featurenotimplemented'type='empty'/>
<xs:elementname='forbidden'type='empty'/>
<xs:elementname='gone'type='xs:string'/>
<xs:elementname='internalservererror'type='empty'/>
<xs:elementname='itemnotfound'type='empty'/>
<xs:elementname='jidmalformed'type='empty'/>
<xs:elementname='notacceptable'type='empty'/>
<xs:elementname='notallowed'type='empty'/>
<xs:elementname='policyviolation'type='empty'/>
<xs:elementname='recipientunavailable'type='empty'/>
<xs:elementname='redirect'type='xs:string'/>
<xs:elementname='registrationrequired'type='empty'/>
<xs:elementname='remoteservernotfound'type='empty'/>
<xs:elementname='remoteservertimeout'type='empty'/>
<xs:elementname='resourceconstraint'type='empty'/>
<xs:elementname='serviceunavailable'type='empty'/>
<xs:elementname='subscriptionrequired'type='empty'/>
<xs:elementname='undefinedcondition'type='empty'/>
<xs:elementname='unexpectedrequest'type='empty'/>
<xs:groupname='stanzaErrorGroup'>
<xs:choice>
<xs:elementref='badrequest'/>
<xs:elementref='conflict'/>
<xs:elementref='featurenotimplemented'/>
<xs:elementref='forbidden'/>
<xs:elementref='gone'/>
<xs:elementref='internalservererror'/>
<xs:elementref='itemnotfound'/>
<xs:elementref='jidmalformed'/>
<xs:elementref='notacceptable'/>
<xs:elementref='notauthorized'/>
<xs:elementref='notallowed'/>
<xs:elementref='policyviolation'/>
<xs:elementref='recipientunavailable'/>
<xs:elementref='redirect'/>
<xs:elementref='registrationrequired'/>
<xs:elementref='remoteservernotfound'/>
<xs:elementref='remoteservertimeout'/>
<xs:elementref='resourceconstraint'/>
<xs:elementref='serviceunavailable'/>
<xs:elementref='subscriptionrequired'/>
<xs:elementref='undefinedcondition'/>
<xs:elementref='unexpectedrequest'/>
</xs:choice>
</xs:group>
161/164
5/17/2016
<xs:complexType>
<xs:simpleContent>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:restriction>
</xs:simpleType>
</xs:schema>
AppendixB.ContactAddresses
TOC
Consistentwith [MAILBOXES],organizationthatofferXMPPservicesare
encouragedtoprovideanInternetmailboxof"XMPP"forinquiriesrelatedtothat
service,wherethehostportionoftheresultingmailtoURIistheorganization's
domain,notthedomainoftheXMPPserviceitself(e.g.,theXMPPservicemightbe
offeredatim.example.combuttheInternetmailboxwouldbe
<xmpp@example.com>).
AppendixC.AccountProvisioning
TOC
Accountprovisioningisoutofscopeforthisspecification.Possiblemethodsfor
accountprovisioningincludeaccountcreationbyaserveradministratorandinband
accountregistrationusingthe'jabber:iq:register'namespaceasdocumentedin
[XEP0077].AnXMPPserverimplementationoradministrativefunctionMUST
ensurethatanyJIDassignedduringaccountprovisioning(includinglocalpart,
domainpart,resourcepart,andseparatorcharacters)conformstothecanonical
formatforXMPPaddressesdefinedin [XMPPADDR].
AppendixD.DifferencesfromRFC3920
TOC
Basedonconsensusderivedfromimplementationanddeploymentexperienceas
wellasformalinteroperabilitytesting,thefollowingsubstantivemodificationswere
madefromRFC3920(inadditiontonumerouschangesofaneditorialnature).
MovedspecificationoftheXMPPaddressformattoaseparate
document.
Recommendedormandateduseofthe'from'and'to'attributeson
streamheaders.
Morefullyspecifiedthestreamclosinghandshake.
Specifiedtherecommendedstreamreconnectionalgorithm.
Changedthenameofthe<xmlnotwellformed/>streamerror
conditionto<notwellformed/>forcompliancewiththeXML
specification.
Removedtheunnecessaryandunused<invalidid/>streamerror(see
162/164
5/17/2016
RFC3920forhistoricaldocumentation).
Specifiedreturnofthe<restrictedxml/>streamerrorinresponseto
receiptofprohibitedXMLfeatures.
Morecompletelyspecifiedtheformatandhandlingofthe<seeother
host/>streamerror,includingconsistencywithRFC3986andRFC5952
withregardtoIPv6addresses(e.g.,enclosingtheIPv6addressin
squarebrackets'['and']').
SpecifiedthattheSASLSCRAMmechanismisamandatoryto
implementtechnologyforclienttoserverstreams.
SpecifiedthatTLSplustheSASLPLAINmechanismisamandatoryto
implementtechnologyforclienttoserverstreams.
SpecifiedthatsupportfortheSASLEXTERNALmechanismisrequired
forserversbutonlyrecommendedforclients(sinceenduserX.509
certificatesaredifficulttoobtainandnotyetwidelydeployed).
Removedthehardtwoconnectionruleforservertoserverstreams.
Moreclearlyspecifiedthecertificateprofileforbothpublickey
certificatesandissuercertificates.
Addedthe<reset/>streamerror(Section4.9.3.16)conditionto
handleexpired/revokedcertificatesortheadditionofsecuritycritical
featurestoanexistingstream.
Addedthe<accountdisabled/>,<credentialsexpired/>,<encryption
required/>,and<malformedrequest/>SASLerrorconditionstohandle
errorflowsmistakenlyleftoutofRFC3920ordiscussedinRFC4422but
notinRFC2222.
Removedtheunused<paymentrequired/>stanzaerror.
Removedtheunnecessaryrequirementforescapingofcharactersthat
maptocertainpredefinedentities,sincetheydonotneedtobeescaped
inXML.
ClarifiedtheprocessofDNSSRVlookupsandfallbacks.
ClarifiedthehandlingofSASLsecuritylayers.
ClarifiedthataSASLsimpleusernameisthelocalpart,notthebare
JID.
Clarifiedthestreamnegotiationprocessandassociatedflowchart.
Clarifiedthehandlingofstreamfeatures.
Addeda'by'attributetothe<error/>elementforstanzaerrorssothat
theentitythathasdetectedtheerrorcanincludeitsJIDfordiagnostic
ortrackingpurposes.
Clarifiedthehandlingofdatathatviolatesthewellformedness
definitionsforXML1.0andXMLnamespaces.
Specifiedthesecurityconsiderationsinmoredetail,especiallywith
regardtopresenceleaksanddenialofserviceattacks.
MoveddocumentationoftheServerDialbackprotocolfromthis
specificationtoaseparatespecificationmaintainedbytheXMPP
StandardsFoundation.
AppendixE.Acknowledgements
TOC
Thisdocumentisanupdateto,andderivedfrom,RFC3920.Thisdocumentwould
havebeenimpossiblewithouttheworkofthecontributorsandcommenters
acknowledgedthere.
Hundredsofpeoplehaveprovidedimplementationfeedback,bugreports,requests
forclarification,andsuggestionsforimprovementsincepublicationofRFC3920.
Althoughthedocumenteditorhasendeavoredtoaddressallsuchfeedback,heis
solelyresponsibleforanyremainingerrorsandambiguities.
SpecialthanksareduetoKevinSmith,MatthewWild,DaveCridland,Philipp
Hancke,WaqasHussain,FlorianZeitz,BenCampbell,JehanPages,PaulAurich,
JustinKarneges,KurtZeilenga,SimonJosefsson,RalphMeijer,CurtisKing,and
163/164
5/17/2016
othersfortheircommentsduringWorkingGroupLastCall.
ThanksalsotoYaronShefferandElwynDaviesfortheirreviewsonbehalfofthe
SecurityDirectorateandtheGeneralAreaReviewTeam,respectively.
TheWorkingGroupchairswereBenCampbellandJoeHildebrand.Theresponsible
AreaDirectorwasGonzaloCamarillo.
Author'sAddress
TOC
PeterSaintAndre
Cisco
1899WyknoopStreet,Suite600
Denver,CO80202
USA
Phone:+13033083282
EMail:psaintan@cisco.com
164/164

Extensible Messaging and Presence Protocol (XMPP) - Core PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Extensible Messaging and Presence Protocol (XMPP) - Core PDF

Uploaded by

Copyright:

Available Formats

5/17/2016

InformationalNote:Architecturesthatemploy XMLstreamsand XML

connecttoeachotherbymeansof [HTTP]asspecifiedin [XEP0124]

negotiation, SASLnegotiation, streamfeatures,and streamerrors.

Exceptwhereexplicitlydisallowed(e.g.,during TLSnegotiationand SASL

You might also like