Peter Saint-Andre wrote: > Dave Cridland wrote:
>> Kind of... Certainly the password element being deprecated is addressed. >> But you're still hung up on web pages being the only use of URLs. > > I'm not hung up on it personally. That was the use case people cared > about at the time. If folks want to store generic URIs (not web page > URLs), we can define a spec for that. After all, the "X" in XML stands > for Extensible, no? What I'm saying is that XEP-0048 addresses two use cases: (1) bookmarking XMPP groupchat rooms (<conference/> element) (2) bookmarking web pages (<url/> element) As far as I know, the fact that the XML element for bookmarking web pages is <url/> was not intended to imply that you could store any URL or URI in that element. Now, that is my understanding. It may be that: (1) I misunderstand the original intent. (Sounds like interpretation of the U.S. Constitution.) (2) It doesn't matter because people think it's fine to store any old URI in the <url/> element. If so, I'm open to being corrected or to changing the spec so that any URI is allowed, in which case the XMPP client just hands to URI off to the appropriate local helper application and Bob's your uncle. Special case here: what if the we allow any URI and the URI is an XMPP URI? IMHO it is best to leave things as they are and if we want to store generic URIs let's come up with a separate spec for that, and deprecate XEP-0048 once the new spec is adopted. /psa
smime.p7s
Description: S/MIME Cryptographic Signature
