Subject: [Uri-review] XMPP jabber: URI scheme not registered?

From: Graham Klyne <[email-masked]>
Date: Sun, 25 Nov 2012 12:04:44 +0000

I've just been digging around the XMPP specs, and I notive they make reference 
to required namespaces of the form "jabber:client" and "jabber:server" (cf. 
http://tools.ietf.org/html/rfc3920#section-11.2, esp sect 11.2.2).

Examples in sections 8 and 9 of that spec reinforce the indication that jabber: 
is being used as a URI scheme (rather than a namespace prefix).

But looking at http://www.iana.org/assignments/uri-schemes.html I'm not seeing 
any mention of jabber:.

Assuming I'm reading this right... it's probably unfortunate that that this use 
of jabber: has come about (like dav: before it?) but I guess it's now entrenched 
and should at least be registered?

#g
--

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 26 Nov 2012 08:28:42 -0700

On 11/25/12 5:04 AM, Graham Klyne wrote:
> I've just been digging around the XMPP specs, and I notive they
> make reference to required namespaces of the form "jabber:client"
> and "jabber:server" (cf.
> Examples in sections 8 and 9 of that spec reinforce the indication
> that jabber: is being used as a URI scheme (rather than a namespace
> prefix).

The 'jabber:' string was used in the earliest days of the jabberd
server project when the core developers didn't really understand XML
namespaces (which were quite new at the time). It is not a URI scheme,
just a mistake. :)

> But looking at http://www.iana.org/assignments/uri-schemes.html I'm
> not seeing any mention of jabber:.
> 
> Assuming I'm reading this right... it's probably unfortunate that
> that this use of jabber: has come about (like dav: before it?) but
> I guess it's now entrenched and should at least be registered?

I have never registered it and I hesitate to do so now because I think
it would cause more confusion than it's worth. We do have the 'xmpp:'
URI scheme for pointing to JabberIDs.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Julian Reschke <[email-masked]>
Date: Mon, 26 Nov 2012 17:37:52 +0100

On 2012-11-26 16:28, Peter Saint-Andre wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> ...

I think it would still be good to have it in the registry, and have the 
documentation explain what's going on.

I believe the "DAV:" scheme was created for the same purpose, and we 
have documented that in 
<http://greenbytes.de/tech/webdav/rfc4918.html#rfc.section.21.1>.

Best regards, Julian

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 26 Nov 2012 09:39:22 -0700

On 11/26/12 8:28 AM, Peter Saint-Andre wrote:
>> make reference to required namespaces of the form
>> "jabber:client" and "jabber:server" (cf. 
>> Examples in sections 8 and 9 of that spec reinforce the
>> indication that jabber: is being used as a URI scheme (rather
>> than a namespace prefix).
> 
> server project when the core developers didn't really understand
> XML namespaces (which were quite new at the time). It is not a URI
> scheme, just a mistake. :)
> 
>> But looking at http://www.iana.org/assignments/uri-schemes.html
>> I'm not seeing any mention of jabber:.
> 
>> Assuming I'm reading this right... it's probably unfortunate
>> that that this use of jabber: has come about (like dav: before
>> it?) but I guess it's now entrenched and should at least be
>> registered?
> 
> I have never registered it and I hesitate to do so now because I
> think it would cause more confusion than it's worth. We do have the
> 'xmpp:' URI scheme for pointing to JabberIDs.

Alexey pointed out to me offlist that these old 'jabber:*' strings are
used in URI slots (as XML namespaces), so we probably do need to
register this "scheme". Sigh. I'll take care of that.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 26 Nov 2012 11:50:20 -0700

> <http://greenbytes.de/tech/webdav/rfc4918.html#rfc.section.21.1>.

Thanks for the pointer. And yes, as with "DAV:", the "jabber:" prefix
was defined before standard best practices emerged for XML namespaces...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Graham Klyne <[email-masked]>
Date: Mon, 26 Nov 2012 17:06:12 +0000

Peter,

I take your points, but...

As I read the XMPP spec, a string "jabber:client" or "jabber:server" is used in 
a context where a URI is required (i.e. an xmlns attribute).  Hence in this 
usage, "jabber:" *is* a URI scheme name.   (Consider - if someone introduced a 
genuine jabber: scheme, then wanted to use it for XML namespaces in an XMPP 
stream, they could run into problems.)  It's very similar to the way @dav:@ is 
used by WebDAV, and that *is* registered as a URI scheme.

To the extent that the registry aims to document actual usage, I think 
registration is appropriate, probably linked with some verbiage that makes it 
clear this is a historical "accident" rather than intended for general use.

#g
--

On 26/11/2012 15:28, Peter Saint-Andre wrote:
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with undefined - http://www.enigmail.net/
>
> iEYEARECAAYFAlCziqkACgkQNL8k5A2w/vwWLACeK92mGiyENuSi36azX09h2NxH
> 7RAAnjAYU89bIFoJec0qh9DxPBq0GgYa
> =PBrH
> -----END PGP SIGNATURE-----
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 26 Nov 2012 13:29:58 -0700

Agreed. We would register it immediately as historical.

http://tools.ietf.org/html/rfc4395#section-4

On 11/26/12 1:27 PM, Joe Hildebrand (jhildebr) wrote:
> Looping the XMPP wg list.  If we register it, let's make sure that
> registration says "DO NOT USE IN THE FUTURE".
> 
> On 11/26/12 11:50 AM, "Peter Saint-Andre" <[email-masked]> wrote:
>

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Mon, 26 Nov 2012 20:27:52 +0000

-- 
Joe Hildebrand

---

From: Graham Klyne <[email-masked]>
Date: Mon, 26 Nov 2012 22:45:24 +0000

> Agreed. We would register it immediately as historical.

Is this strictly true?  After all, doesn't XMPP still require use of 
jabber:client or jabber:server as namespaces for stanzas in XMPP streams?

My original email cited an out-of-date RFC, but I did check back later:
[[
    Definition of XML Stanza:  An XML stanza is the basic unit of meaning
       in XMPP.  A stanza is a first-level element (at depth=1 of the
       stream) whose element name is "message", "presence", or "iq" and
       whose qualifying namespace is 'jabber:client' or 'jabber:server'.
]]
-- http://tools.ietf.org/html/rfc6120#section-4.1

In light of this, my take is that jabber: is a current but very limited URI 
scheme, defining just two URIs (jabber:server and jabber:client) for use in XMPP 
streams.  No other URIs or uses for this scheme are sanctioned.

#g
--

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 26 Nov 2012 15:56:36 -0700

On 11/26/12 3:45 PM, Graham Klyne wrote:
> Is this strictly true?  After all, doesn't XMPP still require use
> of jabber:client or jabber:server as namespaces for stanzas in XMPP
> streams?

RFC 4395 says:

   In some circumstances, it is appropriate to note a URI scheme that
   was once in use or registered but for whatever reason is no longer in
   common use or the use is not recommended.

I definitely think that 'jabber:' is not recommended. Various XML
namespaces with the 'jabber:' "scheme" are still in wide use, but we
have not minted any such namespaces since 1999 or 2000.

> My original email cited an out-of-date RFC, but I did check back
> later: [[ Definition of XML Stanza:  An XML stanza is the basic
> unit of meaning in XMPP.  A stanza is a first-level element (at
> depth=1 of the stream) whose element name is "message", "presence",
> or "iq" and whose qualifying namespace is 'jabber:client' or
> 'jabber:server'. ]] --
> http://tools.ietf.org/html/rfc6120#section-4.1
> 
> In light of this, my take is that jabber: is a current but very
> limited URI scheme, defining just two URIs (jabber:server and
> jabber:client) for use in XMPP streams.  No other URIs or uses for
> this scheme are sanctioned.

Actually there are more namespaces than just those two (we minted
about twenty of them in the early days of XMPP before we realized the
error of our ways). A full list can be found at
http://xmpp.org/registrar/namespaces.html -- but we haven't minted any
new ones in a long time and we're not about to start doing so again.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Graham Klyne <[email-masked]>
Date: Tue, 27 Nov 2012 15:51:04 +0000

Peter,

To be clear about this, are you saying that the apparent requirement in RFC6120 
to use namespace jabber:server or jabber:client for "message", "presence" or 
"iq" stanzas no longer applies?  If I were implementing XMPP based on what I 
read here, I would think that these namespaces *are* required, which suggests a 
problem with the XMPP spec.

(I noticed the other namespaces, but since they all seemed to be urn: URIs I 
ignored them for this discussion.)

#g
--

On 26/11/2012 22:56, Peter Saint-Andre wrote:
> iEYEARECAAYFAlCz86QACgkQNL8k5A2w/vw3MQCg6UjFltp87J9ZfDbVD6/++S4i
> yqEAoKbjXUHPvAvVatJh8B9p4n1VB4lW
> =Imzk

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 27 Nov 2012 09:12:42 -0700

On 11/27/12 8:51 AM, Graham Klyne wrote:
> Peter,
> 
> To be clear about this, are you saying that the apparent
> requirement in RFC6120 to use namespace jabber:server or
> jabber:client for "message", "presence" or "iq" stanzas no longer
> applies?  If I were implementing XMPP based on what I read here, I
> would think that these namespaces *are* required, which suggests a

Yes, jabber:client and jabber:server are required by RFC 6120 (and RFC
6121 requires support for jabber:iq:roster).

> (I noticed the other namespaces, but since they all seemed to be
> urn: URIs I ignored them for this discussion.)

Other old namespaces currently in use are jabber:iq:last,
jabber:x:conference, jabber:iq:private, jabber:iq:version,
jabber:iq:register, jabber:iq:rpc, jabber:iq:oob,
jabber:component:accept, jabber:component:connect, jabber:iq:privacy,
and jabber:x:data.

After we deprecated the jabber:* form and before we started using
URN-based namespaces (see RFC 4854), we also used HTTP URIs at the
jabber.org domain.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Graham Klyne <[email-masked]>
Date: Tue, 27 Nov 2012 16:34:49 +0000

> 6121 requires support for jabber:iq:roster).

OK, that's what I originally thought.  In which case, I think the text from RFC 
4395 that you cited does not apply, since use of these jabber: URIs is still 
required (and others as you note below).

I think the appropriate course would be to register the URI scheme, maybe list 
the URIs in use for this scheme, and add a note that no more jabber: URIs should 
be minted.

#g
--

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Tue, 27 Nov 2012 17:04:24 +0000

>the URIs in use for this scheme, and add a note that no more jabber: URIs

(as individual)

As long as the registry has a policy of "Closed" or similar, I don't
really care what status the doc has.  Let's not bog down.

(as XMPP co-chair)

This isn't on our charter at the moment, so whoever wants to write an
individual draft first should just pick a status, and that will probably
stick.

-- 
Joe Hildebrand

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 27 Nov 2012 10:05:52 -0700

On 11/27/12 10:04 AM, Joe Hildebrand (jhildebr) wrote:
>>> Yes, jabber:client and jabber:server are required by RFC 6120
>>> (and RFC 6121 requires support for jabber:iq:roster).
>> 
>> OK, that's what I originally thought.  In which case, I think the
>> text from RFC 4395 that you cited does not apply, since use of
>> these jabber: URIs is still required (and others as you note
>> below).
>> 
>> I think the appropriate course would be to register the URI
>> scheme, maybe list the URIs in use for this scheme, and add a
>> note that no more jabber: URIs should be minted.
> 
> (as individual)
> 
> As long as the registry has a policy of "Closed" or similar, I
> don't really care what status the doc has.  Let's not bog down.
> 
> (as XMPP co-chair)
> 
> This isn't on our charter at the moment, so whoever wants to write
> an individual draft first should just pick a status, and that will
> probably stick.

I think it can be an informational I-D outside any WG, and will find
time to bang that out before the end of the year.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Barry Leiba <[email-masked]>
Date: Tue, 27 Nov 2012 12:45:34 -0500

> time to bang that out before the end of the year.

Independent Stream, even....

Barry

---

From: Graham Klyne <[email-masked]>
Date: Wed, 28 Nov 2012 18:06:31 +0000

Peter, all,

I don't think it even needs to be a draft.  XMPP spec already exists, so we 
should just be able to submit the registration template to IANA.

I was thinking I'd try and draft something and run it by you (but don't hold 
your breath).

#g
--

On 27/11/2012 17:05, Peter Saint-Andre wrote:
> iEYEARECAAYFAlC08vAACgkQNL8k5A2w/vwOcQCeJ8C2wtz74nbUX3N8/K4rl1y6
> XVQAoK/MHyRz8Sfx4FmHag/xGHcw7tdh
> =lR0y

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 28 Nov 2012 11:57:01 -0700

Something like this seems reasonable:

   URI scheme name.
      jabber
   Status.
      permanent
   URI scheme syntax.
      jabberuri = "jabber" ":" 1*(ALPHA) [ ":" 1*(ALPHA) ]
   URI scheme semantics.
      Strings of the form 'jabber:*' and 'jabber:*:*' were used as
      XML namespaces during development of the technology
      that became the Extensible Messaging and Presence
      Protocol (XMPP).  The scheme was never used for any
      other purpose.  The only namespace names minted with
      this scheme were:
      - jabber:client
      - jabber:component:accept
      - jabber:component:connect
      - jabber:iq:auth
      - jabber:iq:gateway
      - jabber:iq:last
      - jabber:iq:oob
      - jabber:iq:privacy
      - jabber:iq:private
      - jabber:iq:register
      - jabber:iq:roster
      - jabber:iq:rpc
      - jabber:iq:search
      - jabber:iq:version
      - jabber:server
      - jabber:x:conference
      - jabber:x:data
      - jabber:x:encrypted
      - jabber:x:oob
      - jabber:x:signed
      No other strings were minted, and no other strings
      shall be minted.
   Encoding considerations.
      Encoded as UTF-8 within XMPP protocol streams.
   Applications/protocols that use this URI scheme name.
      Extensible Messaging and Presence Protocol (XMPP).
   Interoperability considerations.
      The 'jabber' scheme must not be used to identify or
      enable interaction with XMPP addresses; the 'xmpp'
      scheme defined in RFC 5122 is to be used in such
      cases.
   Security considerations.
      See Section 13 of RFC 6120.
   Contact.
      Peter Saint-Andre <[email-masked]>
   Author/Change controller.
      XMPP WG <[email-masked]>
   References.
      RFC 6120

On 11/28/12 11:06 AM, Graham Klyne wrote:
> Peter, all,
> 
> I don't think it even needs to be a draft.  XMPP spec already exists, so
> we should just be able to submit the registration template to IANA.
> 
> I was thinking I'd try and draft something and run it by you (but don't
> hold your breath).
> 
> #g
> -- 
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 28 Nov 2012 12:41:09 -0700

[ removing apps-discuss ]

Actually that list of minted namespaces is incomplete. Here is what I
consider to be a complete list (note that some of these were rarely
used, some are no longer in use, some have been obsoleted, etc.):

      - jabber:client
      - jabber:component:exec
      - jabber:iq:agent
      - jabber:iq:agents
      - jabber:iq:auth
      - jabber:iq:autoupdate
      - jabber:iq:browse
      - jabber:iq:conference
      - jabber:iq:gateway
      - jabber:iq:groupchat
      - jabber:iq:last
      - jabber:iq:oob
      - jabber:iq:privacy
      - jabber:iq:private
      - jabber:iq:register
      - jabber:iq:roster
      - jabber:iq:rpc
      - jabber:iq:search
      - jabber:iq:time
      - jabber:iq:version
      - jabber:server
      - jabber:x:autoupdate
      - jabber:x:conference
      - jabber:x:data
      - jabber:x:delay
      - jabber:x:encrypted
      - jabber:x:envelope
      - jabber:x:event
      - jabber:x:expire
      - jabber:x:oob
      - jabber:x:roster
      - jabber:x:signed

On 11/28/12 11:57 AM, Peter Saint-Andre wrote:
> URI scheme name. jabber Status. permanent URI scheme syntax. 
> jabberuri = "jabber" ":" 1*(ALPHA) [ ":" 1*(ALPHA) ] URI scheme
> semantics. Strings of the form 'jabber:*' and 'jabber:*:*' were
> used as XML namespaces during development of the technology that
> became the Extensible Messaging and Presence Protocol (XMPP).  The
> scheme was never used for any other purpose.  The only namespace
> names minted with this scheme were: - jabber:client -
> jabber:component:accept - jabber:component:connect -
> jabber:iq:auth - jabber:iq:gateway - jabber:iq:last -
> jabber:iq:oob - jabber:iq:privacy - jabber:iq:private -
> jabber:iq:register - jabber:iq:roster - jabber:iq:rpc -
> jabber:iq:search - jabber:iq:version - jabber:server -
> jabber:x:conference - jabber:x:data - jabber:x:encrypted -
> jabber:x:oob - jabber:x:signed No other strings were minted, and no
> other strings shall be minted. Encoding considerations. Encoded as
> UTF-8 within XMPP protocol streams. Applications/protocols that use
> this URI scheme name. Extensible Messaging and Presence Protocol
> (XMPP). Interoperability considerations. The 'jabber' scheme must
> not be used to identify or enable interaction with XMPP addresses;
> the 'xmpp' scheme defined in RFC 5122 is to be used in such cases. 
> Security considerations. See Section 13 of RFC 6120. Contact. Peter
> Saint-Andre <[email-masked]> Author/Change controller. XMPP WG
> <[email-masked]> References. RFC 6120
> 
>> I don't think it even needs to be a draft.  XMPP spec already
>> exists, so we should just be able to submit the registration
>> template to IANA.
>> 
>> I was thinking I'd try and draft something and run it by you (but
>> don't hold your breath).
>> 
>> #g --
>> 
>> On 27/11/2012 17:05, Peter Saint-Andre wrote: On 11/27/12 10:04
>> AM, Joe Hildebrand (jhildebr) wrote:
>>>>>>> Yes, jabber:client and jabber:server are required by
>>>>>>> RFC 6120 (and RFC 6121 requires support for
>>>>>>> jabber:iq:roster).
>>>>>> 
>>>>>> OK, that's what I originally thought.  In which case, I
>>>>>> think the text from RFC 4395 that you cited does not
>>>>>> apply, since use of these jabber: URIs is still required
>>>>>> (and others as you note below).
>>>>>> 
>>>>>> I think the appropriate course would be to register the
>>>>>> URI scheme, maybe list the URIs in use for this scheme,
>>>>>> and add a note that no more jabber: URIs should be
>>>>>> minted.
>>>>> 
>>>>> (as individual)
>>>>> 
>>>>> As long as the registry has a policy of "Closed" or
>>>>> similar, I don't really care what status the doc has.
>>>>> Let's not bog down.
>>>>> 
>>>>> (as XMPP co-chair)
>>>>> 
>>>>> This isn't on our charter at the moment, so whoever wants
>>>>> to write an individual draft first should just pick a
>>>>> status, and that will probably stick.
>> 
>> I think it can be an informational I-D outside any WG, and will
>> find time to bang that out before the end of the year.
>> 
>> Peter

---

From: Larry Masinter <[email-masked]>
Date: Wed, 28 Nov 2012 14:05:45 -0800

How about avoiding giving BNF which you then prohibit using? Just list them:

URI scheme name
    jabber

Status:
    Permanent

URI scheme syntax:
     One of the following:
       - jabber:client

  URI scheme semantics.
        These URIs were used as   XML namespaces during development of the technology
        that became the Extensible Messaging and Presence Protocol (XMPP).  
       The scheme was never used (and should not be used) for any
        other purpose; no other "jabber:" URIs shall be minted.

   Encoding considerations.
        ASCII (UTF-8) within XMPP protocol streams.

  Security considerations.

  Contact.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 28 Nov 2012 15:10:02 -0700

Heh, I like that. :)

On 11/28/12 3:05 PM, Larry Masinter wrote:
> URI scheme name jabber
> Status: Permanent
> URI scheme syntax: One of the following: - jabber:client -
> jabber:x:oob - jabber:x:signed
> 
> URI scheme semantics. These URIs were used as   XML namespaces
> during development of the technology that became the Extensible
> Messaging and Presence Protocol (XMPP). The scheme was never used
> (and should not be used) for any other purpose; no other "jabber:"
> URIs shall be minted.
> 
> Encoding considerations. ASCII (UTF-8) within XMPP protocol
> streams.
> 
> Interoperability considerations. The 'jabber' scheme must not be
> used to identify or enable interaction with XMPP addresses; the
> 'xmpp' scheme defined in RFC 5122 is to be used in such cases.
> 
> 
> Security considerations. See Section 13 of RFC 6120.
> 
> 
> Contact. Peter Saint-Andre <[email-masked]>
> 
> 
> Author/Change controller. XMPP WG <[email-masked]> References. RFC
> 6120
> 
> 

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 28 Nov 2012 16:19:17 -0700

So here is the registration...

###

   URI scheme name.
      jabber

   Status.
      permanent

   URI scheme syntax.
      The only allowable strings are:
      - jabber:client
      - jabber:component:accept
      - jabber:component:connect
      - jabber:component:exec
      - jabber:iq:agent
      - jabber:iq:agents
      - jabber:iq:auth
      - jabber:iq:autoupdate
      - jabber:iq:browse
      - jabber:iq:conference
      - jabber:iq:gateway
      - jabber:iq:groupchat
      - jabber:iq:last
      - jabber:iq:oob
      - jabber:iq:privacy
      - jabber:iq:private
      - jabber:iq:register
      - jabber:iq:roster
      - jabber:iq:rpc
      - jabber:iq:search
      - jabber:iq:time
      - jabber:iq:version
      - jabber:server
      - jabber:x:autoupdate
      - jabber:x:conference
      - jabber:x:data
      - jabber:x:delay
      - jabber:x:encrypted
      - jabber:x:envelope
      - jabber:x:event
      - jabber:x:expire
      - jabber:x:oob
      - jabber:x:roster
      - jabber:x:signed

   URI scheme semantics.
      Strings of the form 'jabber:*' and 'jabber:*:*' were
      used as XML namespace names during development of the
      technology that became the Extensible Messaging and
      Presence Protocol (XMPP).  The scheme was never used
      for any other purpose.  The only namespace names
      minted with this scheme are listed above.  No other
      strings were minted, and no other strings shall be
      minted.  Note that defining new URI schemes for XML
      namespaces is now discouraged.  The 'jabber' scheme
      was defined before standard best practices emerged.

   Encoding considerations.

   Security considerations.

   Contact.

   References.
      RFC 6120

###

Feedback is welcome.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 29 Nov 2012 04:28:29 +0100

* Peter Saint-Andre wrote:
>[...]

I would prefer if this used some wording that avoids speculation whether
"JABBER:client" or "jabber:%63lient" are actually prohibited by this and
whether it is okay for individual schemes to specify such constraints.
Simply saying, for example, these strings are used as XML namespace
names and the scheme should not be used for other purposes would do.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 28 Nov 2012 21:10:49 -0700

> names and the scheme should not be used for other purposes would do.

I thought that was clear from the section on semantics:

Do you think we need to make this clear also under syntax? For instance
we could add a sentence like the following at the end of the syntax section:

      These strings are used literally as shown, with the
      specified case (e.g., "jabber" not "JABBER") and no
      possibility of percent-encoding (e.g., the string
      "jabber:%63lient" is not allowed and is not equivalent
      to or transformed into the string "jabber:client").

We could also perhaps make the semantics section even clearer, such as:

      Strings of the form 'jabber:*' and 'jabber:*:*' were
      minted for use as XML namespace names during development
      of the technology that became the Extensible Messaging
      and Presence Protocol (XMPP).  Note well that defining
      new URI schemes for XML namespaces is now discouraged,
      and that the 'jabber' scheme was (inadvertently) created
      before standard best practices emerged for XML namespaces.
      The 'jabber' scheme was never used for any purpose other
      than XML namespace names, and is not designed or intended
      for any other use.  In particular, the 'jabber' scheme
      must not be used to identify or enable interaction with
      XMPP addresses; the 'xmpp' scheme defined in RFC 5122 is
      to be used in such cases.  The only namespace names
      minted with this scheme are listed in the syntax definition
      section of this registration.  No other names were minted,
      and new names shall not be minted (i.e., the scheme is closed
      to generation of new URIs).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 29 Nov 2012 13:14:40 +0900

Hello Peter,

>        The only allowable strings are:
..
>        Encoded as UTF-8 within XMPP protocol streams.

This is irrelevant. See http://tools.ietf.org/html/rfc4395#section-2.6.

I would write this as following:

     Encoding considerations.
       None. All characters are within the characters allowed in URIs.

You may also be able to add the note that Björn suggested here.

Regards,   Martin.

>        Peter Saint-Andre<[email-masked]>
>
>        XMPP WG<[email-masked]>
> iEYEARECAAYFAlC2m/UACgkQNL8k5A2w/vyA2ACgkKPJN21QgVYrmN8Sk6ZShLpz
> 6BgAnAkyDYhv2/sbi4fcn3R2h/FmbZvj
> =abXm
> Uri-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uri-review
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 28 Nov 2012 21:21:17 -0700

>>       None. All characters are within the characters allowed in URIs.

You are right. How about the following...

   Encoding considerations.
      None. Because the limited number of URIs (XML namespace
      names) minted with this scheme contain characters only
      from the ASCII range, encoding of internationalized code
      points is out of scope.  In addition, these namespace names
      do not contain any text fields that would be subject to
      specialized encoding.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 29 Nov 2012 05:37:33 +0100

>I thought that was clear from the section on semantics:

The problem are the conformance requirements implied by "allowable". If
you develop a URI Validator and add support for the 'jabber' scheme, it
is not clear whether strings like "JABBER:client" or "jabber:%63lient", 
or even "jabber:client#" should be rejected. These strings are not on
the list of "allowable" strings, so some will argue they ought to be re-
jected, while others will argue per RFC 3986 they ought to be accepted.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 28 Nov 2012 21:51:36 -0700

On 11/28/12 9:37 PM, Bjoern Hoehrmann wrote:
>>>> URI scheme syntax. The only allowable strings are: -
>>>> jabber:client [...]
>>> 
>>> I would prefer if this used some wording that avoids
>>> speculation whether "JABBER:client" or "jabber:%63lient" are
>>> actually prohibited by this and whether it is okay for
>>> individual schemes to specify such constraints. Simply saying,
>>> for example, these strings are used as XML namespace names and
>>> the scheme should not be used for other purposes would do.
>> 
> The problem are the conformance requirements implied by
> "allowable". If you develop a URI Validator and add support for the
> 'jabber' scheme, it is not clear whether strings like
> "JABBER:client" or "jabber:%63lient", or even "jabber:client#"
> should be rejected. These strings are not on the list of
> "allowable" strings, so some will argue they ought to be re- 

They ought to be rejected.

Please understand that these namespace names are sent only as the
value of 'xmlns' in XMPP streams. They are not in general use anywhere
else. XMPP software implementations know what to do with them (and I
really doubt that they pass these strings to URI parsers anyway). This
is basically a whitelist of known strings and they are not treated as
URIs anywhere in the XMPP ecosystem.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 29 Nov 2012 14:08:03 +0900

>        do not contain any text fields that would be subject to

Ship it.    Regards,   Martin.

---

From: Graham Klyne <[email-masked]>
Date: Thu, 29 Nov 2012 14:27:04 +0000

On 29/11/2012 04:51, Peter Saint-Andre wrote:
> else.

That point may be worth making; e.g.

[[
Applications/protocols that use this URI scheme name.
       Extensible Messaging and Presence Protocol (XMPP).
       These URIs are used only as namespace names within XMPP sreams,
       and are not intended for use in any other situations.
]]

While it's possible to discuss finer points, I think that your draft performs 
the main required function; i.e. it provides essential information about the 
scheme.  Had this existed in the IANA registry, my original question would not 
have arisen.

(FWIW, I thought it was easier to just say "encoded as UTF-8 within XMPP 
streams" than to explain why that's not relevant or out-of-scope.)

So, as Martin says, just "ship it" (with or without the above point).

#g
--

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 29 Nov 2012 13:44:05 -0700

On 11/29/12 7:27 AM, Graham Klyne wrote:
>> Please understand that these namespace names are sent only as
>> the value of 'xmlns' in XMPP streams. They are not in general use
>> anywhere else.
> 
> [[ Applications/protocols that use this URI scheme name. Extensible
> Messaging and Presence Protocol (XMPP). These URIs are used only as
> namespace names within XMPP sreams, and are not intended for use in
> any other situations. ]]
> 
> While it's possible to discuss finer points, I think that your
> draft performs the main required function; i.e. it provides
> essential information about the scheme.  Had this existed in the
> IANA registry, my original question would not have arisen.
> 
> (FWIW, I thought it was easier to just say "encoded as UTF-8 within
> XMPP streams" than to explain why that's not relevant or
> out-of-scope.)
> 

Done (with the above point).

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/