Re: [Standards] use of XMPP protocols in HTML
Just to clarify a little, the specific advantage to XMPP would be that websites could offer the XMPP protocol by default, while allowing a fall-back to lead to either an explanatory HTTP page, or possibly, via the javascript: protocol, giving an alert or JavaScript-based message to indicate how the user could obtain support for the XMPP protocol. Links that put you on the road to nowhere in browsers that do not support the protocol do not exactly make for a user-friendly site (not to mention experimentation in the first place). Brett On 7/2/2010 1:37 PM, Brett Zamir wrote: Hi all, My Firefox extension, Open URIs, at https://addons.mozilla.org/en-US/firefox/addon/162154/ , has just been approved by the Mozilla review team. You can read the description there, but essentially, the aim of the add-on is to gain enough adoption and experience for the HTML5 working group to be convinced that supporting 2 new attributes on is merited. One attribute is @uris, which offers a higher priority than @href, allowing browsers that do not support the attribute (or the protocol) to fall-back to the @href. The other attribute is @alternateURIs which offers a potential trigger to browsers to highlight the element in such a way that the user may be aware that they can right-click these links to find alternative protocols (e.g., if Wikipedia linked to its own page for a given book by default, but offered the URN of the ISBN via right-click). Given the XMPP community's interest in allowing web users the ability to click on link while avoiding it doing nothing, I think these attributes might be of interest. In any case, it won't hurt websites to offer default or alternative URIs with their XMPP (or other) links. Just thought I'd welcome you all to add these attributes on your own pages, try out the extension in conjunction with it, and possibly voice your support in the HTML5 mailing list if you favor giving alternative protocols (or URNs) a leg up on HTTP links which are going to be the mainstay for some time, especially to the extent no attributes exist to facilitate transitioning to possible alternatives. thanks! Brett
[Standards] use of XMPP protocols in HTML
Hi all, My Firefox extension, Open URIs, at https://addons.mozilla.org/en-US/firefox/addon/162154/ , has just been approved by the Mozilla review team. You can read the description there, but essentially, the aim of the add-on is to gain enough adoption and experience for the HTML5 working group to be convinced that supporting 2 new attributes on is merited. One attribute is @uris, which offers a higher priority than @href, allowing browsers that do not support the attribute (or the protocol) to fall-back to the @href. The other attribute is @alternateURIs which offers a potential trigger to browsers to highlight the element in such a way that the user may be aware that they can right-click these links to find alternative protocols (e.g., if Wikipedia linked to its own page for a given book by default, but offered the URN of the ISBN via right-click). Given the XMPP community's interest in allowing web users the ability to click on link while avoiding it doing nothing, I think these attributes might be of interest. In any case, it won't hurt websites to offer default or alternative URIs with their XMPP (or other) links. Just thought I'd welcome you all to add these attributes on your own pages, try out the extension in conjunction with it, and possibly voice your support in the HTML5 mailing list if you favor giving alternative protocols (or URNs) a leg up on HTTP links which are going to be the mainstay for some time, especially to the extent no attributes exist to facilitate transitioning to possible alternatives. thanks! Brett
Re: [Standards] Fwd: [Members] proposed changes to XEP-0001
On 1/14/2010 10:57 PM, Dave Cridland wrote: On Thu Jan 14 14:49:12 2010, Peter Saint-Andre wrote: We AIM to please! Surely we XMPP to please? Dave. Oh, would you two please stop jabber-ing... Brett
Re: [Standards] XEP-0055 Jabber Search: first/last or given/family names?
On 8/25/2009 2:46 AM, Peter Saint-Andre wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/31/09 9:56 AM, Simon McVittie wrote: It would also be very useful to include a family-name-first (e.g. Chinese) name in at least one example to illustrate how that works, although unfortunately that breaks the convention of using examples from Shakespeare :-) I'll add a Chinese example. Peter To keep the theme, you could use: Liang Shanbo (梁山伯) and Zhu Yingtai (祝英台) (see http://en.wikipedia.org/wiki/Butterfly_Lovers )... Brett
Re: [Standards] Stream Error; Invalid XML Character
Etienne Philip Pretorius wrote: Peter Saint-Andre wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/13/09 1:33 PM, Etienne Philip Pretorius wrote: Hello List, What stream error would one use to best indicate that there was an invalid xml character in the stream? invalid-xml or bad-format? I think bad-format. The differences are described here: http://tools.ietf.org/html/draft-ietf-xmpp-3920bis-00#section-5.8.3.1 http://tools.ietf.org/html/draft-ietf-xmpp-3920bis-00#section-5.8.3.12 Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpbjKMACgkQNL8k5A2w/vxRwwCfWEDe22V4xX+fhknL390TzjfA O3wAoMbSVF62QHfNp2s8tQhOL1n85ouV =cdQA -END PGP SIGNATURE- Thank you Peter Saint-Andre. Looks like would be even better, since it covers the case most specifically (and choosing the most specific is recommended by the spec). With XML, there is the challenge of weaning ourselves from using the word "invalid" universally toward using the more cumbersome word "well-formedness" for cases such as this where the document isn't even parsable as XML. Validity would only be if the server was validating and the XML was found to violate constraints specified in a schema... best wishes, Brett
[Standards] Pubsub namespace consistency
Is there some reason why the element (XEP-0060) for creating a node is listed in the regular pubsub namespace, http://jabber.org/protocol/pubsub , but all other owner-related pubsub actions are in the pubsub owner namespace, http://jabber.org/protocol/pubsub#owner . And while I'm asking, should the subscriber and publisher actions be distinguished by namespace if the owner ones are? thanks, Brett
Re: [Standards] [Roster|Data] Versioning
Hi, Just curious about whether Service Discovery, specifically Service Discovery Extensions, were looked at to handle such versioning information? I think Disco Extensions would be especially suitable (and not create the need for more specs), especially if, as we all discussed here earlier, Data Forms could be adapted to change the 's into full namespaces while foregoing FORM_TYPE 's, or, to save potentially on bandwidth (and introducing some more orderliness), allow multiple FORM_TYPE 's, say changing the FORM_TYPE value child into an attribute and adding the 's in that namespace as children, rather than as siblinsg, of the FORM_TYPE ). While making such a change might be somewhat painful, I think it is a growing pain which would allow for much greater growth into the future, and one which would, I think, be ideal to get out of the way now rather than later. Data Forms, as such a necessary and otherwise brilliant specification (especially in combination with Data Forms Validation) is, imo, crying out to remove this last hurdle for greater extensibility... (and perhaps solve the issue in this thread in the process) :) best wishes, Brett
Re: [Standards] Error handling for "stream:error" like "see-other-host"
The stream error is defined at http://xmpp.org/rfcs/rfc3920.html#rfc.section.4.7.3 Brett On 2/7/2009 4:25 PM, imoracle wrote: My XMPP client library JAXL is currently having this issue. Once in a week or so, I can see a stream like: Code: talk.google.com being received from gtalk servers. I am not sure how to handle it. As of now I tried sending: Code: and then reconnect to the talk.google.com servers. But it just do not acknowledge back any xml stream/stanza for new connection. Can someone tell me the solution for this? Regards, Abhinav
Re: [Standards] [Fwd: [PubSub] Questions about pubsub/pep]
On 1/4/2009 5:29 AM, Eric Butler wrote: Should pep nodes be returned in the result of a disco#items query on a bare JID? Section 5.2 of XEP-0060 makes it sound like this should be the case, but it's not completely clear, and ejabberd does not return them. If not, what's the correct way to get a list of your pep nodes? Affiliations request? XEP-0163 section 6.1 says that a PEP server should return the pubsubs on behalf of a user for a disco#info request, however ejabberd 2.0.2_2 does not. Is this an implementation bug, or am I misunderstanding the specifications? Here's what I do get: http://jabber.org/protocol/disco#info";> http://jabber.org/protocol/commands"; /> That looks like a clear implementation bug based on section 6.1 of XEP-0163 as you mention. Section 5.2 of XEP-0060, however, I think is not relevant because that relates to a hierarchy of nodes, and PEP does not provide for this, allowing only one node per namespace (and not in a hierarchy). An affiliations request would get all affiliations, not only your owner ones, but I suppose the data should be extractable from there. I suppose the only other way would be to add Jabber Search support for this particular need. Even in the full Pubsub, I don't see a way to query for all nodes of a user, as one is apparently confined to constrain by payload namespace (12.14). How are clients expected to behave when they see a pubsub/pep ? What's the purpose of this, assuming you also get pubsub-relateds? http://xmpp.org/extensions/xep-0030.html#info-basic gives a definition of . For one, I think there is just one element to check, to know whether PEP is supported at all (and to know it is PEP, not full Pubsub). Since Service Discovery can also be used to discover other types of services, it could be possible that the node is just being queried to find out what kind of service it supports. XEP-0060 mentions that events can be "transient" or "persistent", could someoe please clarify what these are? I didn't find it very clear, though I may have missed the definitions. Transient means that items published to a node will not be retained for later retrieval there, except if the pubsub#last-published feature is supported, in which case, the node will retain the last item published there... Persistent means that they will be retained up to the maximum number defined by the option pubsub#max_items. best wishes, Brett
[Standards] Pubsub node ID problem
For XEP-0060, has any thought been given to allowing the same node IDs to be reused (for collection or leaf nodes) as long as they are held within different collection nodes? It might make for a more flexible and attractive expansion of a hierarchy, if one did not need to rely on ugly auto-generated node IDs nor forced a user to come up with unique names. Changing the node for a user (e.g., prepending the collection name to the node to be created, after checking whether the user attempted to use any characters needed by the prefix) would be too cumbersome for deep hierarchies, and Pubsub currently does not allow changing of the node name by the service (or returning the new name upon a create node request) anyways. Brett
[Standards] Requesting specific published items
Pubsub XEP-0060 states: "6.4.6 Returning Notifications Only "A service MAY return event notifications without payloads (e.g., to conserve bandwidth). If so, the client MAY request a specific item (using the ItemID) in order to retrieve the payload. When an entity requests items by ItemID, implementations MUST allow multiple items to be specified in the request." Is it possible to change this so as to specifically allow for the requesting of specific items even where the service does support payloads? Brett
[Standards] Pubsub extension idea
Hi, Along the lines of how Data Forms types and Data Forms Validation can influence display of forms, I'd like to see some standard way in which Pubsub payloads could be similarly extensible, not only by allowing different namespaces (as is now allowable within Atom extension elements or for a wholly different root namespace), but by some extensible standardization which could give more hints than either of these at input and display type. Data Forms & Data Forms validation might themselves be used as a payload, but I can see a need for more types targeting display of different types of GUI elements. For example, it would be nice to know whether an uploaded file (which could use sipub:file-transfer as the datatype) should be suggested as an image, an iframe, a link for download, etc.. This would allow: 1) As with DF, a uniform way to know how to display payloads 2) Allow semantic extensibility while also being able to suggest a display mode when the semantic namespace is not recognized. However, even with DF + DFV, there would need to be some way to indicate that DFV was also supported (if these are kept as separate specs), since Pubsub only allows for specification of one payload namespace--this might, I imagine, be done by requiring that both namespaces be supported if used as a Pubsub payload or, even better, by adding an option to Pubsub to indicate additional sub-namespace(s) that are required/supported). While Atom is extensible, there is no way to make a meta-data query to know what inner namespaces are supported (or to specify which ones during Node configuration), so DF+DFV (or any other option) is not so suitable as an Atom extension. DF + DFV could be used as the root, even indicating Atom namespaces+type within , but again, there would be no way to detect ahead of time which semantic namespaces (such as Atom) were being used within DF+DFV without first accepting the payload. Thus I'd like to suggest 1) a list-multi option be added to Pubsub to allow additional supported sub-namespaces to be indicated (whatever the top-level namespace). 2) Data Forms and DFV be extended to offer greater specificity in types suggesting various input and display elements. (Maybe some existing GUI kit could be used as the basis for such a namespace.) Also, I think it might be nice to have an option to be able to indicate whether the namespaces (or subnamespaces) were required for proper viewing, or just supplementary. Brett
[Standards] pubsub#language
Since a lot of users might not be familiar with language codes, I think it would make sense for pubsub#language (as with pubsub#type) to also be allowable as a "list-single" ( especially vaildation) so that some predefined choices could be listed for them... e.g., label="English">en Brett
[Standards] Also on DFV
Also on Data Forms Validation, why are jid-multi and jid-single discouraged for use with Basic validation, or even 'hidden' for that matter, if results ca be verified? Brett
[Standards] DFV and booleans
Also, as for Table 1, as note 10 states, "If a particular field type is not listed, the display MAY include validation support, but is not expected to do so", although it is pretty obvious, I think the "boolean" type should be added to the chart to forbid it for each type of validation (as with "hidden"). Brett
[Standards] Data Forms Validation
Hi, I love the Data Forms spec and the Data Forms Validation spec, but I have a number of questions and thoughts relating to Data Forms Validation, XEP-0122. 1) If Data Forms validation is approved, list-multi and list-single would need to changed as it says in section 3.3 of XEP-0004, that they "MUST NOT insert new options". 2) In 3.2, it states "Any validation method applied to a field of type "list-multi", "list-single", or "text-multi" (other than ) MUST imply the same behavior as , with the additional constraints defined by that method." What does this mean exactly? Why should the other methods require behavior like which allows open-ended choices for lists? 3) What should one do if one wants an open-ended list of JIDs? If validation should be used with jid-multi/jid-single (as expressly allowed in Table 1 of Data Forms Validation), what if one also or instead wants a jid-multi to be validated separately as with text-multi? Should there instead be a JID datatype, so a list-multi/list-single could be used in contrast to say text-multi which didn't arrange (or for submissions, require) the items in a constrained list? 4) If list-multi can become open-ended, why are range and regex validation discouraged for it in Table 1 in DFV? And what's wrong with jid-multi being validated against regex if they could be made to validate separately (as would seem to make sense). And shouldn't "jid-single" be listed as being not allowable under "range"? 5) Under "range" in Table 1, it states that "'For text-single', allow user to increment/decrement through possible values". What about decimal types? These can fall in a range, but not really be incrementable. I think discussion of increment/decrement (and about discussion of display issues in general) is a helpful one but might as a result of this be more suited under a discussion of data types and display. This would also allow mention, for example, that a date or time type could be presented with a calendar/clock selection or display, an integer could present an incrementing text box, a decimal type could be presented as a slider, etc. (or a progress meter in the case of results). 6) Shouldn't "fixed" be a type not allowed for "open" validation in Table 1? thanks, Brett
[Standards] Idea for Data Forms - Hierarchical results
Just a suggestion... Maybe data forms could, along the lines of / be enabled to also return hierarchical listings, such as via nesting of 's? I could see such a thing as useful for some search results (and it shouldn't be unimaginable that clients could display data returned hierarchically, such as with tree structures). Brett
[Standards] Data Forms schema
For XEP-0004, in addition to the correction in the schema we discussed earlier on loosening element ordering requirements within , the schema dealing with also ought to be updated to allow for Data Forms validation children: or if you want to allow more than just Data Forms Validation children... Brett
Re: [Standards] Data Forms and empty fields
On 12/22/2008 10:37 PM, Dave Cridland wrote: On Mon Dec 22 13:24:25 2008, Brett Zamir wrote: In the Data Forms spec XEP-0004, what is an implementation to do for each type if there are empty fields? Send an empty or an empty? An empty field would seem to make sense for lists at least, but I wasn't clear on what it should be for say, text-single. is semantically equivalent to , and therefore suggests an actual value of a zero-length string, rather than no value at all. Which doesn't answer your question, of course, but it suggests that the answer might depend on what you mean by "empty fields". Yeah. Or what the spec using Data Forms means (in whether to allow a distinction between the two). I think perhaps the specs using Data Forms should specify this. For example, in Pubsub, where it is used to send in configuration items, perhaps it wouldn't be a bad idea to require to indicate that the sender didn't mistakenly leave out the field. Otherwise, it is possible one server-side implementation will reject data that doesn't at least possess a child and spit out errors, while another may treat an empty and as the same, and yet another might spit out errors if there is a child, so I really think this should be specified in the specs using Data Forms, if not also mentioned in Data Forms. Brett
[Standards] Data Forms and empty fields
In the Data Forms spec XEP-0004, what is an implementation to do for each type if there are empty fields? Send an empty or an empty? An empty field would seem to make sense for lists at least, but I wasn't clear on what it should be for say, text-single. Brett
[Standards] Pubsub node creation with Node ID changed
After example 120 in section 8.1.1 of Pubsub XEP-0060, it states, "Similarly, if the node creation request specified a NodeID but the service modified the NodeID before creating the node (refer to XEP-0248), the service MUST also specify the modified node in the IQ result." I do not see any condition mentioned in XEP-0248 in which a given NodeID is modified... Brett
[Standards] Pubsub errata - Delete Nodes/Delete Items
I don't see that I submitted this one yet... In Pubsub XEP 0060, "7.2.3.6 Item Deletion Not Supported", reference is made to the feature "delete-nodes", but it presumably should be something like "delete-items", though the latter would first need to be listed elsewhere in the document. And under the "8.4 Delete Node" section, there is no reference to a potential error of feature "delete-nodes", as I imagine there should... Brett
[Standards] Meta-data in Pubsub XEP-0060
Might the meta-data query result (section 5.4 in XEP-0060) recommend the @type attribute on the 's children so that a client could, for example, know to display a boolean type as the more readable "true" and "false" as opposed to the potential values of 1 and 0? Brett
[Standards] Pubsub and subscription options for root
Hi, According to section 6.3.4.1 of Pubsub, "When requesting subscription options...SHOULD specify a node (if no node is specified, the service MUST assume that the requesting entity wishes to request subscription options for its subscription to the root collection node; refer to XEP-0248 for details)." However, under section 6.3.5 (Form Submission), there is no indication about how this lack of a node should be specified (by the absence of a "node" attribute or by one set to an empty string). XEP-0248 doesn't seem to answer this either... Brett
[Standards] Pubsub feature add: get default subscription configuration
Given the Subscribe-and-Configure option in Pubsub (at http://xmpp.org/extensions/xep-0060.html#subscriber-configure-subandconfig ), would it not make sense to be able to get a set of default values for subscription configuration, just as there is with default node configuration: http://xmpp.org/extensions/xep-0060.html#owner-default ? Granted, with node creation, there is no node to query ahead of time as is possible with subscription options, but a client might find it helpful to know the usual configuration to start with... Brett
Re: [Standards] XEP-0060: Example 89. Publisher publishes an item with an ItemID
Hi Jehan,
All of your points (in these Pubsub emails) sounded quite reasonable to me, but
I'm just a fringe subscriber...
I've been waiting on a number of Pubsub items too, but
Peter said that he was collecting the Pubsub errata
from me and would reply later, so maybe that's going on with your
questions on Pubsub...
best wishes,
Brett
- Original Message
From: Jehan <[EMAIL PROTECTED]>
To: standards@xmpp.org
Sent: Wednesday, December 10, 2008 9:07:53 PM
Subject: Re: [Standards] XEP-0060: Example 89. Publisher publishes an item with
an ItemID
Hi,
wasn't the 3 points I raised in my 2 emails about pubsub not consistent
enough? I had no answer on any of these... :-/
Moreover the two points in my second email may be discussed, but it
looks to me that the first email is obviously a small bug in the XEP
because the title and the example does not correspond. No?
Jehan
Jehan;5096 Wrote:
> Hi again,
>
> I have two other remarks I have just noticed.
>
> 1/ When one queries a "item discovery", an item has a "name" attribute
> which is the itemID (see 'section 5.5'
> (http://xmpp.org/extensions/xep-0060.html#entity-discoveritems)):
>
>
> But in this section '6.4 Retrieve Items from a Node'
> (http://xmpp.org/extensions/xep-0060.html#subscriber-retrieve), or
> during publication (cf. my previous email), the itemID is an attribute
> 'id'.
>
> So I think this is not very consistent. Why is the attribute "name"
> used sometimes, and "id" other times for the same thing?
>
> 2/ Note also that it says that (section 5.5 again):
>
>
>
> But in the "retrieve items" section, there is no mean proposed to
> request items based on IDs! The only section which propose to detail a
> request is section "6.4.7 Requesting Some Items", but it gives only
> examples to request the most recent items (with "max_items"
> attribute").
>
> I guess you may use the jabber search XEP ('xep-0055'
> (http://xmpp.org/extensions/xep-0055.html)), or maybe use the 'result
> set management' (http://xmpp.org/extensions/xep-0059.html), but then the
> text is not good and must be changed in section 5.5. Moreover I don't
> think this adresses exactly the same needs. One should be able to
> request only one or two specific items (when we know the itemID) without
> having to request everything then search in it with the result set
> management...
>
> Jehan
--
Jehan
Jehan's Profile: http://www.jabberforum.org/member.php?userid=16911
View this thread: http://www.jabberforum.org/showthread.php?t=1106
Re: [Standards] vs. in sequence
So, can this schema snippet from http://xmpp.org/extensions/xep-0004.html#schema * * * * . be changed to: * * * * . (to allow, as mentioned previously, to come before or after option, as they also occur after in example 57, etc. in http://xmpp.org/extensions/xep-0060.html ) Brett
[Standards] Pubsub Collection Nodes errata
Under example 18 at http://xmpp.org/extensions/xep-0248.html, it states, "To associate a node with the root collection node, the node owner MUST submit an empty element within the 'pubsub#collection' field." whereas in example 21, it states, "To disassociate the node from the root collection node, the node owner MUST submit an empty element within the 'pubsub#collection' field" This seems to be saying the opposite thing. Brett
[Standards] Getting pending subscription requests
In http://xmpp.org/extensions/xep-0060.html#owner-subreq-pernode , a per-node request (of pending subscriptions) is to be made using Ad-hoc Commands. The Openfire implementation returns a child and looking at the Ad-hoc Commands spec, http://xmpp.org/extensions/xep-0050.html#execute-multiple , under example 15, it looks like this is indeed the correct behavior. In the Pubsub spec, however, the success result (example 169) is an empty (no child). Should the Pubsub spec be corrected or should the Ad-hoc Command spec make clear that an iq response can be completely empty? Also the wording in Pubsub seems a little unclear: "the owner then MAY request pending subscription approval requests". I think it would be more clear that there is to be an actual change of state, if the word "submit" is used in place of the first "request". Also the example's title is similarly confusing: "Owner requests all pending subscription requests for a node", since it seems to me that this section is talking about approving the subscriptions. And lastly, any responses on my previous emails? thanks, Brett
[Standards] Pubsub collection nodes question
Hi, For http://xmpp.org/extensions/xep-0248.html#revs , does pubsub#children_association_policy relate to disassociating nodes as well, and if not, should it also be recommended to support a policy and whitelist for disassociation? Brett
Re: [Standards] vs. in sequence
Brett Zamir wrote: Ralph Meijer wrote: On Thu, Nov 20, 2008 at 07:26:53PM -0700, Peter Saint-Andre wrote: [..] The Data Forms schema for 'field' would indicate that instances must come before any instances... Ah, I see. I'll look into fixing that tomorrow. Did we really want to mandate a specific order? That doesn't seem necessary to me. Even if you don't mandate a specific order, the Data Forms schema still needs to be fixed, since by using , it is indicating that comes before . I believe you will need to use here in some manner if you want to allow any order... One further issue I think needs to be addressed is for cases where no options are present in a list-single or list-multi field. For example, if there are options relating to roster groups, but the user has no roster groups, the server-side implementation might wish to indicate that such an option exists, but not populate with any children. So, I think the discussion ought to also specify what to allow in such cases--is it ok for list-multi and list-single to have no children (but only if no options exist)? Brett
Re: [Standards] vs. in sequence
Ralph Meijer wrote: On Thu, Nov 20, 2008 at 07:26:53PM -0700, Peter Saint-Andre wrote: [..] The Data Forms schema for 'field' would indicate that instances must come before any instances... Ah, I see. I'll look into fixing that tomorrow. Did we really want to mandate a specific order? That doesn't seem necessary to me. Even if you don't mandate a specific order, the Data Forms schema still needs to be fixed, since by using , it is indicating that comes before . I believe you will need to use here in some manner if you want to allow any order... thanks, Brett
Re: [Standards] vs. in sequence
Peter Saint-Andre wrote: Brett Zamir wrote: According to the schema in Data Forms, http://xmpp.org/extensions/xep-0004.html , should precede : However, in the Pubsub spec, http://xmpp.org/extensions/xep-0060.html , the examples (57, 128, 141) all show (expressing the default value in a list) after . I guess the schema needs to be changed then? Option is defined thus: So a field can be either of the following: /psa I'm referring to cases where is used for a default value. For example, from XEP-0060, in example 128: publishers subscribers open *publishers* The Data Forms schema for 'field' would indicate that instances must come before any instances... Brett
[Standards] vs. in sequence
According to the schema in Data Forms, http://xmpp.org/extensions/xep-0004.html , should precede : However, in the Pubsub spec, http://xmpp.org/extensions/xep-0060.html , the examples (57, 128, 141) all show (expressing the default value in a list) after . I guess the schema needs to be changed then? thanks, Brett
[Standards] [Fwd: Pubsub collection nodes]
I never got an answer on this one... Anybody? thanks, Brett --- Begin Message --- In Examples 11-13, and 15, 16 (and 14 if you meant to have the original XML there too) of http://xmpp.org/extensions/xep-0248.html , there is no , whereas the other examples with a child in have it. If it is not to be there, when is it and when is it not needed? thanks, Brett --- End Message ---
[Standards] Pubsub collection nodes
In Examples 11-13, and 15, 16 (and 14 if you meant to have the original XML there too) of http://xmpp.org/extensions/xep-0248.html , there is no , whereas the other examples with a child in have it. If it is not to be there, when is it and when is it not needed? thanks, Brett
Re: [Standards] About posting new topics to the same thread
Jonathan Schleifer wrote: Oh, and if we're already at it, you should stop using TOFU[1], which is considered very impolite on mailing lists. -- Jonathan [1] http://en.wikipedia.org/wiki/TOFU#Top-posting I personally strongly dislike bottom-posting, and the Wikipedia article you cite also indicates there are preference differences out there, including within mailing lists. But instead of getting into a fruitless argument about what we think is the "right" way, how about we consider some way to solve the problem? Given that we already have the benefit of a formal hierarchical structure within XMPP via XML, how about a namespaced child of type=normal> (too late for ) to keep track of hierarchical content within a posting, which besides enabling posting order display to differ by user preference, would also more easily enable scripting to collapse or navigate a section of quotations, differentially auto-color replies from particular users or levels, etc.? Perhaps even XHTML-IM (XEP 0071) could be overloaded for such a purpose via 's @cite attribute (which could use an XMPP URI or email URI to indicate authorship) and/or the @class attribute (e.g., to distinguish citations from the "inner thread" from those outside of its context). For that matter, how about some mechanisms to enable forking of threads, even within a post? (along the lines of, and potentially supporting, wikis, discussion forums, blogs, versioning systems, etc., since, to my mind, these all should all only be slightly different in terms of protocol syntax so that one can easily treat one as (or convert one to) the other, as there is a lot of albeit inadequate convergence between them already). (Sorry I am not too well-informed on all of the numerous specs you all have marvelously already put out there, so my apologies to whatever extent this covers ground already covered.) best wishes, Brett
[Standards] list-single required?
In the Openfire implementation of Pubsub, the following is returned in a form (for default configuration of nodes): owner All of the other 's encapsulate the inside of . Should that be a standard requirement for the list-single type? I presume the behavior here is that with only one item (obviously the same as the default), the is being dropped, but should that be the case? The Data Form (XEP-0004) spec states " -- One of the options in a field of type "list-single" or "list-multi"", but I'm not clear that this requires the to be there in the first place... It might be inferable as such, however... Brett
[Standards] Pubsub node creation
In Pubsub XEP-0060, in example 113, for a request to create a node, there is this: However, just above, it states: "There are two ways to create a node: 1. Create a node with default configuration for the specified node type. 2. Create and configure a node simultaneously." Since all of the examples show an empty being added to use default configuration, I believe the above example should include some kind of place-holder for (which could represent an empty or one with content), since I understand that cannot be sent (with 'set') by itself. thanks, Brett
Re: [Standards] IM spec errata
Sorry again... Clearing the browser cache fixed it... Brett
Re: [Standards] IM spec errata
I meant to say the copy at http://xmpp.org/rfcs/rfc3921.html but mistakenly pasted the text version from ietf.org. Oddly, RFC3921 is blocked for me here in China, but only that page (I can get to it via a proxy)! Brett
Re: [Standards] IM spec errata
My errata was for RFC3921, at http://www.ietf.org/rfc/rfc3921.txt : IM and Presence. As I mentioned, the draft copy has already corrected the problem, but I just mentioned it in case you want to fix the non-draft copies until the draft one is ready. Brett Peter Saint-Andre wrote: Brett Zamir wrote: Sorry, was relying on the subject line--IM spec... That is, draft-saintandre-rfc3921bis?
Re: [Standards] IM spec errata
Sorry, was relying on the subject line--IM spec... Brett Peter Saint-Andre wrote: Brett Zamir wrote: If you're still taking errata on the non-draft spec... (the draft spec has fixed it already) Which spec? We have an awful lot of them... Peter
[Standards] IM spec errata
If you're still taking errata on the non-draft spec... (the draft spec
has fixed it already)
In the last example in section 7.4, both 's have a @to, though they
are not supposed to per Core spec 9.1.1 ("a stanza sent from a client to
a server for handling by that server (e.g., presence sent to the server
for broadcasting to other entities) SHOULD NOT possess a 'to' attribute.")
In section 7.5, the has a @subscription attribute not set to
remove (from section 7.6: "a compliant server MUST ignore any other
values of the 'subscription' attribute when received from a client").
thanks,
Brett
[Standards] Pubsub errata 3
1) There is a link in 7.1.2 to http://xmpp.org/extensions/xep-0060.html#impl-errors which should be to http://xmpp.org/extensions/xep-0060.html#impl-bounce 2) The link in 8.7.4 to http://xmpp.org/extensions/xep-0060.html#impl-unsub doesn't lead anywhere (and the section (by that name at least) seems to be non-existent). 3) Example 209 has a header of whereas the other 's merely have "SubID" as the attribute value 4) I think it might be helpful to clarify that the XSLT stylesheet indicated by #body_xslt should be transformed by the server (I know it should be clear since body would presumably only be used by clients not supporting the payload format). Brett
[Standards] Unsupported type errors in Pubsub
The following "unsupported" type errors are in the schema, but I'm not sure they can actually be triggered (and if so under what circumstances): 1) At the end of 8.1.3, it seems to me to indicate an error would not be returned: "If the create-and-configure option is not supported but the requesting entity sends such a request anyway, the service SHOULD ignore the configuration part of the request and proceed as if it had not been included.", so I don't see how the "create-and-configure" type of unsupported error would be triggered 2) "instant-nodes" (Example 118 is about instant nodes but has the error "nodeid-required"). Likewise, I didn't see the following covered as far as error conditions, so I just wanted to see if some of these might not get triggered, if some should be supplied with an error example in the spec, etc. 3) "delete-any" 4) "filtered-notifications" 5) "instant-nodes" 6) "item-ids" 7) "last-published" 8) "leased-subscription" 9) "meta-data" 10) "multi-collection" 11) "multi-subscribe" 12) "presence-notifications" 13) "presence-subscribe" 14) "publish-options" 15) "retract-items" 16) "subscription-notifications" thanks, Brett
[Standards] Pubsub errata 2
Hi, Also, in examples 191-194, I believe the sender's XML (sent back with the error) should have been related to an attempt to modify the affiliations since that is the subject of that section. Brett
[Standards] Pubsub errata
Hi, 1) I think Example 191 in http://xmpp.org/extensions/xep-0060.html should have "member-affiliation", "outcast-affiliation", or "publisher-affiliation" as a feature instead of "modify-affiliations" (which is covered in the previous example). 2) And immediately preceding example 122, there is reference to pubsub#node_type, but pubsub#access_model is used in the example. 3) Although this may be somewhat relying on pseudo-namespacing, in 8.7.2, I'd think the line "attribute value of "node"" should read "attribute value of "pubsub#node"". 4) In section 9.2, should this line "This set of namespaces would then be advertised by including the namespace in the identity+features hash" have the 2nd namespace as plural? 5) At the very end of Section 9.2 (before section 10), it says, "If Juliet publishes a geolocation item to the roster-access "http://jabber.org/protocol/geoloc"; node, her server will send notifications only to <[EMAIL PROTECTED]/orchard>." Example 223, however, seems to me to indicate that the nurse supports geoloc as well. 6) In section 14, "responsibility is misspelled as "responsbility". 7) Example 67 reports an error for form values which seem to be valid per example 57. best wishes, Brett
[Standards] Jabber search and var
Hi, In http://xmpp.org/extensions/xep-0055.html , examples 7-9, it looks like @var should be 'x-gender' and not 'gender' per Field Standardization... Brett
[Standards] Jabber search and var
Hi, In http://xmpp.org/extensions/xep-0055.html , examples 7-9, it looks like @var should be 'x-gender' and not 'gender' per Field Standardization... Brett
[Standards] Jabber Search var issue
Hi, In http://xmpp.org/extensions/xep-0055.html , example 8, we believe @var should be 'x-gender' and not 'gender' per Field Standardization... Brett
Re: [Standards] Full XML
Peter Saint-Andre wrote: Brett Zamir wrote: As comments, processing instructions, DTD subset, and entity reference are prohibited in XMPP, I was wondering whether there were or could be a standard way to escape at least processing instructions, comments, and the internal DTD subset (canonical features) so they could be reliably preserved? Why? Maybe you could tell us a bit more about your use cases. I had thought that such features could be preserved by making them the character data of particular elements in a special namespace (necessarily encapsulating such documents or fragments within a pseudo-root element in order to allow for document-root-level comments/processing instructions as well as Doctype declarations). I would think that providing some means for fidelity of an XML document transmitted over XMPP would be helpful (e.g., to share source code in band (without the need to escape), to allow full XHTML or SVG with 's to be shared, etc.). To do full XHTML, full SVG, or whatever, we would typically just include that data in a or stanza, properly namespaced of course. See for instance XEP-0071 (the XHTML-IM subset) and XEP-0072 (SOAP Over XMPP). But please note that XMPP is not designed for transferring complete XML documents as you seem to be envisioning. Yes. Is that not possible for any XMPP 2.0? :) Even if it is not so designed, an implementation (preferably in some agreed-upon standard way) could compensate for this: ..This could be converted back to a doctype. ..This should be converted back to a comment... ..This should be converted back to a processing instruction (like xml-stylesheet)... ..This should also be converted back to a comment... ... ... ..Might even send an external DTD's contents.. XML is such a ubiquitous standard, including with XHTML/SVG which use features like processing instructions, so I think it would be ideal to have some means of handling it (including the full-featured dialects) more thoroughly and with more fidelity. This wouldn't be all that hard to implement either, as an XSL stylesheet could do the trick to encode and add back the most important features (with doctype and entity references being likely (and unfortunate though less important) exceptions). If this could be allowed (at least the processing instructions), I would think that XMPP could be used as the mechanism for accessing (or otherwise transferring) a complete XHTML/SVG/MathML/etc. website (not only in the context of messages, but also, e.g., as a Pubsub delivery; instead of typing a URL, one could type a JID). (This should also make for an interesting means of auto-updating webpage content incrementally as well, I think.) I am aware that XML can be delivered ala the bytestream specs, but I think it could be more convenient to allow it in band and as XML. Brett
Re: [Standards] [Fwd: [Council] meeting minutes, 2008-10-08]
Peter Saint-Andre wrote: Brett Zamir wrote: In Jabber Search, is used to submit a search form whereas in the examples in 0059, the type used--also using the jabber:iq:search namespace--is 'get'. The Core spec defines an 'get' stanza as "a request for information or requirements." while a 'set' stanza "provides required data, sets new values, or replaces existing values." Since a search request is optional (even after requesting search fields)--i.e., it does not provide the "required data" (nor does it set or replace values) of the 'set' type, I would think that the Search spec (if not the Core spec) should be changed to use 'get'. If there is no replacement in sight for Jabber Search, however, I'm wondering how to reconcile the issue when implementing these specs together. We fix the typos. Thank you. But I'm still curious about how a Jabber Search search "provides required data, sets new values, or replaces existing values" if it is to match the description of in the Core spec. Perhaps whatever replacement there might be for the Jabber Search spec should avoid using "set"? Brett
Re: [Standards] ,
Kevin Smith wrote: Per the RFC3921 (including the newer draft), when is "normal", presumably appropriate for something like an email, it is stated that "A receiving client SHOULD present the message in an interface enabling the recipient to reply, but without a conversation history."> Although SHOULD != MUST, it's probably not correct to use normative language (MUST, SHOULD, MAY) with regard to UI recommendations like these, so I'll clean that up in the next version of rfc3921bis. I think the intention is that the client should provide a UI for messages that allows replies to be constructed and with large message bodies, while chat UI should be presented with the conversation history. Sure... Then I'd suggest the aspect about potentially large message bodies be spelled out instead (and/or a likely corollary to this, a less immediate expectation of a response). To change topic slightly... Since having a @type on is recommended and as the other types don't seem to apply, should Pubsub recommend use of type=headline> for all of its messages? If so (as really seems necessary if one type is to be chosen since the closest type, 'normal' seems excludable since there is no expectation of a reply in Pubsub), might the following description of the type 'headline' need to be adjusted: "message is probably generated by an *automated* service that delivers or broadcasts content (news, sports, market information, RSS feeds, etc.)" (emph. added)? 'Automated' to me seems to be implying that the service is taken from some other source and does not involve a conscious update by a publisher. I know there is a "probably" in there, but that would seem to me to be overemphasizing, especially if Pubsub (which of course allows manual publishing of new items rather than a mere aggregration and (re)distribution of news) is made to use this type. Brett
[Standards] multiple FORM_TYPEs
I had been wondering whether multiple FORM_TYPEs in Data Forms be added to allow for multiple /standard/ specs being represented at the same time... I have no particular need for this now, but I was curious about it for the sake of future extensibility... Jack, in the developer chat room today mentioned Pubsub Queueing at http://xmpp.org/extensions/inbox/pubsub-queueing.html (in example 1) as having such a need, but I thought I'd bring it up again here to bring it up formally... thanks, Brett
[Standards]
Per the RFC3921 (including the newer draft), when is "normal", presumably appropriate for something like an email, it is stated that "A receiving client SHOULD present the message in an interface enabling the recipient to reply, but without a conversation history." I wonder whether this SHOULD might be dropped since some message clients (as with email clients) might like to offer the option to automatically make the conversation history available, even if the messages are expected to be of a less transient (and longer) nature that those of type=chat. Off topic briefly, I tend to note errata when reading specs... Is this an appropriate place to report minor errata, or should I just communicate this to a particular editor(s)? thanks, Brett
[Standards] Full XML
As comments, processing instructions, DTD subset, and entity reference are prohibited in XMPP, I was wondering whether there were or could be a standard way to escape at least processing instructions, comments, and the internal DTD subset (canonical features) so they could be reliably preserved? I had thought that such features could be preserved by making them the character data of particular elements in a special namespace (necessarily encapsulating such documents or fragments within a pseudo-root element in order to allow for document-root-level comments/processing instructions as well as Doctype declarations). I would think that providing some means for fidelity of an XML document transmitted over XMPP would be helpful (e.g., to share source code in band (without the need to escape), to allow full XHTML or SVG with 's to be shared, etc.). By the way, as far as section 12.1 in http://xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-07.html referring to entity references as being in section 4.2 of the XML standard, I think it perhaps should instead be section 4.1, where "entity reference" is defined. thank you, Brett
Re: [Standards] [Fwd: [Council] meeting minutes, 2008-10-08]
Greetings! Was item #18 on the agenda, re: conflicting examples in the way the IQ type attribute is used in Jabber Search (0055) and Result Set Management (0059) tabled to another meeting? In Jabber Search, is used to submit a search form whereas in the examples in 0059, the type used--also using the jabber:iq:search namespace--is 'get'. The Core spec defines an 'get' stanza as "a request for information or requirements." while a 'set' stanza "provides required data, sets new values, or replaces existing values." Since a search request is optional (even after requesting search fields)--i.e., it does not provide the "required data" (nor does it set or replace values) of the 'set' type, I would think that the Search spec (if not the Core spec) should be changed to use 'get'. If there is no replacement in sight for Jabber Search, however, I'm wondering how to reconcile the issue when implementing these specs together. thanks, Brett Peter Saint-Andre wrote: FYI. Note that future minutes may be sent by your new Council Chair. :) /psa Original Message Date: Wed, 08 Oct 2008 14:15:32 -0600 From: Peter Saint-Andre <[EMAIL PROTECTED]> To: XMPP Council <[EMAIL PROTECTED]> Subject: [Council] meeting minutes, 2008-10-08 Results of the XMPP Council meeting held 2008-10-08... Agenda: http://xmpp.org/council/agendas/2008-10-08.html Log: http://logs.jabber.org/[EMAIL PROTECTED]/2008-10-08.html Scribe: Peter Saint-Andre 0. Roll call Present: Dave Cridland, Ralph Meijer, Jack Moffitt, Peter Saint-Andre, Kevin Smith. All members of the Eighth XMPP Council present, quorum achieved. 1. Agenda bashing None. 2. Orientation None required. 3. Choice of Chair for Eighth Council Peter Saint-Andre nominated Kevin Smith. Dave Cridland seconded. All in favor. Kevin Smith is the Chair for the Eighth Council (2008-2009). 4. XEP-0053: XMPP Registrar Function Approve version 1.4rc1? No final consensus on changes to the namespace issuance process. Discussion to be continued on the standards@xmpp.org list and at the next Council meeting. 5. Deprecated XEPs (78, 90, 91). These need to be extended in the Deprecated state or changed to Obsolete. 5a. XEP-0078: Non-SASL Authentication Consensus on changing this to Obsolete. 5b. XEP-0090: Entity Time Near consensus on changing this to Obsolete. 5c. XEP-0091: Delayed Delivery Consensus that we need to determine how widely XEP-0203 is deployed before changing this to Obsolete. 6. XEP-0012: Last Activity Consensus to issue Call for Experience in preparation for advancing this Standards Track XEP to Final. 7. XEP-0085: Chat State Notifications Consensus to issue Call for Experience in preparation for advancing this Standards Track XEP to Final. 8 - 18. [These items not covered.] 19. Any other business? None. 20. Next meeting Date: Wednesday, October 15, 2008. Time: 19:00 UTC. Place: xmpp:[EMAIL PROTECTED] Peter
