Hi, I was wondering what implementations exist for RFC 3923 (e2e)? - Nolan -- -- http://www.semanticgap.com/people/sneakin/
It has been brought to my attention that the schema for XML streams in RFC 3920 lacks xs:import statements for the 'jabber:client', 'jabber:server', and 'jabber:server:dialback' namespaces. I have fixed the online version of the schema [1] and also have noted this erratum at a wiki page [2] that I maintain for the inevitable "bis" versions of the XMPP RFCs. /psa [1] http://www.xmpp.org/schemas/streams.xsd [2] http://www.jabber.org/wiki/index.php/XmppBis
You should also send it to the RFC Editor for their errata. See: http://www.rfc-editor.org/errata.html regards, Ted Hardie At 3:31 PM -0700 11/5/04, Peter Saint-Andre wrote: >It has been brought to my attention that the schema for XML streams in >RFC 3920 lacks xs:import statements for the 'jabber:client', >'jabber:server', and 'jabber:server:dialback' namespaces. I have fixed >the online version of the schema [1] and also have noted this erratum at >a wiki page [2] that I maintain for the inevitable "bis" versions of the >XMPP RFCs. > >/psa > >[1] http://www.xmpp.org/schemas/streams.xsd >[2] http://www.jabber.org/wiki/index.php/XmppBis > >_______________________________________________ >xmppwg mailing list >xmppwg <at> jabber.org >http://mail.jabber.org/mailman/listinfo/xmppwg
Done. On Fri, Nov 05, 2004 at 02:50:02PM -0800, Ted Hardie wrote: > You should also send it to the RFC Editor for their errata. See: > > http://www.rfc-editor.org/errata.html > > regards, > Ted Hardie > > > > At 3:31 PM -0700 11/5/04, Peter Saint-Andre wrote: > >It has been brought to my attention that the schema for XML streams in > >RFC 3920 lacks xs:import statements for the 'jabber:client', > >'jabber:server', and 'jabber:server:dialback' namespaces. I have fixed > >the online version of the schema [1] and also have noted this erratum at > >a wiki page [2] that I maintain for the inevitable "bis" versions of the > >XMPP RFCs. > > > >/psa > > > >[1] http://www.xmpp.org/schemas/streams.xsd > >[2] http://www.jabber.org/wiki/index.php/XmppBis > >
I've found and corrected several errors in the XMPP URI I-D. A preliminary version of the -07 draft is here: http://www.jabber.org/~stpeter/ietf/draft-saintandre-xmpp-uri-07-pre1.txt http://www.jabber.org/~stpeter/ietf/draft-saintandre-xmpp-uri-07-pre1.htm l Because I would like to begin the process of pursuing publication as an independent submission soon after IETF 61, feedback is most welcome. Thanks! Peter
In article <cm60hl$u7m$1 <at> sea.gmane.org>, Nolan Eakins <sneakin <at> semanticgap.com> wrote: > Hi, I was wondering what implementations exist for RFC 3923 (e2e)? I am not aware of any implementations yet. The requirement to build in a CPIM parser may be inhibiting development, since AFAIK no such parsers exist. /psa
THE PHILOSOPHY OF THE FRAGMENT: A DISCOURSE ON XMPP RESOURCES It seems [1] that the text about fragment identifier components in the current xmpp-uri I-D [2] is not clearly understood by all readers. Thus it seems appropriate to try to clarify the reasoning behind that text. 1. BACKGROUND Most XMPP entities (resources) are identified by an XMPP address, which we call a JID. Several XMPP extensions, in particular JEP-0030: Service Discovery [3] and JEP-0060: Publish-Subscribe [4], supplement the JID with an additional addressing parameter called a "node". It would be desirable to be able to include NodeIDs in XMPP URIs in order to fully address the relevant entities, and the example of a fragment identifier component in the xmpp-uri draft does just that (without limiting the use of the fragment identifier component to representation of NodeIDs). Another option would be to represent NodeIDs in the path component. We now describe each option more completely. 2. NODEIDS IN THE FRAGMENT IDENTIFIER COMPONENT Section 3.5 of rfc2396bis [5] uses the language of "primary resources" and "secondary resources" with regard to fragment identifiers: The fragment identifier component of a URI allows indirect identification of a secondary resource by reference to a primary resource and additional identifying information. The identified secondary resource may be some portion or subset of the primary resource, some view on representations of the primary resource, or some other resource defined or described by those representations. A(Continue reading)
On Thu, Nov 11, 2004 at 02:31:05PM -0600, Peter Saint-Andre wrote: > 4. CONCLUSION > > Given the foregoing, does the WG have a strong preference between the > available options? > > 1. Put NodeIDs in the fragment identifier component > 2. Put NodeIDs in the path component, separated by a reserved delimiter > > Feedback welcome as always. I think the second option is better. I can even imagine that some application that could use xmpp: URIs (e.g. web browser) won't pass the fragment identifier to the URI handler (XMPP client). They would expect the fragment identifier to used on the result of the URI action. That is how most URIs work now and how, IMHO, they are expected to be used. There is also the third option: 3. Put NodeIDs in the query part Which also seems better than 1. to me. Greets, Jacek
Hi, new to the list so my apolgies for messing up the threading. PSA wrote: > Following the recommendation in the current xmpp-uri I-D to encapsulate > a NodeID in the fragment identifier component of an XMPP URI, we now can > imagine that the XMPP URI for that request is as follows: > xmpp:juliet at capulet.com/balcony?disco&type=info#vcard What if I want want to make a uri that points to the photo field of a VCARD? I can't request part of the VCard, just the whole VCARD. Still, I want whoever uses this uri to see that specific item. My uri is something that points to a resource. Without the fragment part, this is the primary resource. I add a fragment part to indicate the secondary resource within the primary resource. You're thinking of resources in terms of servers, addresses, nodes, etc. Those are merely used to resolve and potentially dereference the uri to *obtain* the resource. They are, if you like, the means to get the resource. Because in this case I can only construct a uri that points to a resource that is (in this case) a superset of my desired resource, I can add a fragment so my uri now points indirectly to a secondary resource, the photo field of the VCard. The syntax of the fragment part is not part of the uri scheme but depends on the representation, in this case a VCard. So my uri would look something like this:(Continue reading)
I have taken a deep dive in URI-land and came up with the following. It is a long piece of text, so please bare with me! First, I want to point out that the bare JID represented in a URI is actually also part of the URI path component, and not, like it is stated in draft, only the resource part. This URI scheme does not have an authority component. Section 3.3 of RFC2396bis explain this using the <mailto:fred <at> example.com> example. More specifically, the <xmpp:ralphm <at> ik.nu> URI has two components, a scheme and a path, where the path component is represented by path-rootless rule and contains one segment "ralphm <at> ik.nu". The <xmpp:ralphm <at> ik.nu/my/client> URI has a path component with three segments "ralphm <at> ik.nu", "my" and "client". Now, back on topic: On Thu, Nov 11, 2004 at 02:31:05PM -0600, Peter Saint-Andre wrote: > THE PHILOSOPHY OF THE FRAGMENT: A DISCOURSE ON XMPP RESOURCES > > [snip] > > 4. CONCLUSION > > Given the foregoing, does the WG have a strong preference between the > available options? > > 1. Put NodeIDs in the fragment identifier component > 2. Put NodeIDs in the path component, separated by a reserved delimiter I favour the second option, using the ; for separating the JID and node in the(Continue reading)
RSS Feed2 | |
|---|---|
18 | |
9 | |
4 | |
2 | |
85 | |
44 | |
5 | |
1 | |
3 | |
1 | |
3 | |
20 | |
3 | |
2 | |
4 | |
6 | |
1 | |
7 | |
42 | |
4 | |
4 | |
17 | |
5 | |
5 | |
3 | |
6 | |
12 | |
9 | |
4 | |
11 | |
2 | |
5 | |
2 | |
7 | |
17 | |
19 | |
14 | |
14 | |
24 | |
17 | |
16 | |
14 | |
10 | |
30 | |
42 | |
25 | |
18 | |
30 | |
113 | |
132 | |
56 | |
142 | |
61 | |
96 | |
31 | |
181 | |
186 | |
141 | |
99 | |
141 | |
90 | |
137 | |
91 | |
129 | |
61 | |
77 | |
7 | |
1 |
