Re: [Standards] Using .well-known/ to supplement XEP-0156

[Peter Waher]

Hello Lance.

UPnP is mostly used for local discovery. However, it is not limited to local 
discovery, as recent vulnerabilities have shown [1]. It permits you to go as 
far out as IGMP allows you to go. In networks supporting IP-TV, IGMP is allowed 
in all routers from the home firewall all the way to the video servers.

So, if UPnP is to be used, it's important to define security measures to avoid 
undesired exposal of devices: For instance, only respond to UPnP requests from 
the local network, and ignore other types of requests.

Sincerely,
Peter Waher

[1] 
http://leaksource.wordpress.com/2013/02/01/upnp-vulnerability-exposes-50-million-network-enabled-devices-to-be-hacked-controlled-remotely/
 


-Original Message-
From: Lance Stout [mailto:lancest...@gmail.com] 
Sent: den 20 maj 2013 13:51
To: XMPP Standards
Subject: Re: [Standards] Using .well-known/ to supplement XEP-0156


On May 19, 2013, at 7:09 PM, Yusuke DOI  wrote:
> 
> (2013-05-19 03:13), Peter Waher wrote:
>> What about the UPnP method? Using SSDP? Creating some well defined 
>> UPnP Device interface for XMPP Servers & XMPP Clients, perhaps 
>> exposing the features of each device at the same time? Saves time as 
>> you don't have to do service discovery on each device.
> 
> UPnP is not for browsers and I think this is not what Lance needs.


Right, a .well-known/ document would be the easier/faster win since that uses 
technology readily available in browsers without the need for any plugins, and 
it follows the recent standards trends (POSH, Webfinger, BrowserID/Persona, 
etc). So I want to push to get that sorted out and standardized first.

That said, I do like the idea of using UPnP, so Peter if you have ideas on what 
that would look like, please share. I'm not familiar enough with how it works 
yet. Is it only intended for local network discovery?


-- Lance

Re: [Standards] Using .well-known/ to supplement XEP-0156

[Peter Waher]

Hello Johannes.

The thought has crossed my mind. It has been nagging me as a good thing to do, 
but I haven't come to the point yet to try it out.

But, the reasons to use UPnP, instead of, or in parallel with DNS, include the 
following:

* UPnP is server-less. Works using multi-cast and single-cast UDP in the local 
network. (Controlling TTL and enabling IGMP in routers, can take you further 
out in the network.)
* UPnP allows you to send spontaneous notifications of existence, and also 
request notifications from devices when you need them.
* UPnP has well defined interfaces, including class definitions, with data and 
methods that can be called.
* UPnP is used in home environments.
* UPnP, as part of DLNA is also used in home entertainment systems.

With the move towards IoT, especially using IP-TV, and similar approaches, UPnP 
is a natural way to publish presence of devices with well-defined interfaces 
that can be used by IP-TV applications running on the set-top-box. Many 
set-top-boxes already have a natural API for DLNA (and therefore UPnP). I think 
It would be worth-while to define one or more UPnP interfaces for XMPP-capable 
devices.

Needless to say, I'm happy to join an effort to create such interfaces and 
related XEP(s).

Sincerely,
Peter Waher


-Original Message-
From: Hund, Johannes [mailto:johannes.h...@siemens.com] 
Sent: den 21 maj 2013 07:30
To: XMPP Standards
Subject: Re: [Standards] Using .well-known/ to supplement XEP-0156

Hello Peter,

would you see UPNP/SSDP discovery also orthogonal to XEP-0174, which uses 
MDNS/DNS-SD a.k.a. zeroconf/Bonjour to discover xmpp clients? In that case for 
serverless p2p-Messaging.
I understood that UPNP basically does the same thing zeroconf does in terms of 
discovery, but on a more application-layer-focused approach.
Or would it make sense to offer UPNP as an alternative discovery method in 
XEP-0174?

I know the OP was about XEP-0156, but I think both XEPs are related in terms of 
out-of-band discovery methods.

Is my assumption right Both use DNS flavors, but could also be solved by UPNP?

Best regards,
Johannes

-Ursprüngliche Nachricht-
Von: standards-boun...@xmpp.org [mailto:standards-boun...@xmpp.org] Im Auftrag 
von Peter Waher
Gesendet: Montag, 20. Mai 2013 19:16
An: XMPP Standards
Betreff: Re: [Standards] Using .well-known/ to supplement XEP-0156

Hello Yusuke.

Work for implementing support for UPnP (and so DLNA) into browsers has been 
done in many places. It's one of the use cases in IP-TV applications, to be 
able to connect to home entertainment equipment and Home Automation devices 
through the set-top-box, which normally runs a browser.

Support for UPnP in browsers has not been standardized (yet, anybody interested 
to create a proposal?). What people have done is creating plugins, particular 
for a given browser, being a STB-browser, Smart TV, or a more common browser 
supporting plugins, like Firefox or Opera. These plugins then publish a 
JavaScript API that allows the web applications to access UPnP (& DLNA) devices.

Some links:

http://html5.cablelabs.com/upnp/html5-upnp-integration.html
http://dev.opera.com/articles/view/network-service-discovery-api-support-in-opera/
http://upnp.org/sdcps-and-certification/resources/sdks/

I personally like UPnP & DLNA. It would be a great way to find XMPP-based 
devices, particularly IoT devices, in your vicinity, and be able to interact 
with them.

Sincerely,
Peter Waher


-Original Message-
From: Yusuke DOI [mailto:yusuke@toshiba.co.jp]
Sent: den 19 maj 2013 22:09
To: XMPP Standards
Cc: Peter Waher
Subject: Re: [Standards] Using .well-known/ to supplement XEP-0156

Peter,

(2013-05-19 03:13), Peter Waher wrote:
> What about the UPnP method? Using SSDP? Creating some well defined 
> UPnP Device interface for XMPP Servers & XMPP Clients, perhaps 
> exposing the features of each device at the same time? Saves time as 
> you don't have to do service discovery on each device.

UPnP is not for browsers and I think this is not what Lance needs.

Regards,

Yusuke

Re: [Standards] Comments on "HTTP over XMPP"

[Peter Waher]

Hello Matt (again) and Council members.

Seems I sent the last mail (below) too quickly, and started to think a little, 
with regards to IBB. I have a set of questions/reflections:

The IBB requires an open iq-stanza (with response and possible handshake) and a 
closing iq-stanza (with response) for each transfer. For streamBase64 I see no 
problem in converting to IBB for transport. I agree that IBB is better suited 
for this, as it is already defined.

But for normal chunked transfer, this seems very impractical. This may result 
in hundreds of additional messages that needs to be sent for a simple 
API-transaction, invoking a set of calls, etc. Or a normal web page (containing 
links to much embedded content).

Note that chunked transfer is often used when content size (Content-Length) is 
not known, and the server decides to start transmitting anyway to maintain 
buffers small. This is often the case as I mentioned for dynamic content, not 
necessarily large, for instance in results to API calls. To add such a large 
extent of messages for each response will decrease performance radically 
without much gain.

I therefore wanted to ask if it is possible to leave the chunkedBase64 encoding 
as it is, and only convert streamBase64 to IBB? I believe the overhead of 
messages merits a separate handling in this case.

The chunk message contains a last attribute also that is a convenient way to 
avoid the last close iq stanza in IBB. This saves a lot during small transfers. 
Consider a relatively small HTTP GET with a response of 3 chunks. Using IBB it 
would require at least 2+2+3+2=9 messages (http get+reponse+ibb open+ibb open 
response+3 chunks+close+close response), while as it is now, only 5 messages 
are required.

The streamBase64 part is different however, as it is probable that very few 
(probably at most one) stream is active from a client at a given time. Having 
the additional open and close commands here gives no visible additional cost in 
terms of messages.

What is the opinion of the council:

Is the use of IBB so important in this case that a performance degradation is 
preferred in the chunked case?

Or is it sufficient to use IBB only in the streamBase64 case, and leave the 
chunkedBase64 case as is?

Sincerely,
Peter Waher


-Original Message-
From: Peter Waher [mailto:peter.wa...@clayster.com] 
Sent: den 22 maj 2013 22:19
To: XMPP Standards
Subject: Re: [Standards] Comments on "HTTP over XMPP"

Hello Matt.

Thank you for your input. I'll answer them one at a time:

> I have some comments regarding the Proto-XEP "HTTP over XMPP":
>
> * I don't think the use of  is appropriate here, as per the 
> guidelines in RFC6120 § 8.2.3.  At a minimum, the unsafe methods (e.g., 
> DELETE, POST, PUT, et al) ought to be , although a strong 
> argument can be made that all ought to be .

I've changed to type='set' for all methods, to avoid complications.

> * This protocols seems like an appropriate place to use [SHIM].

SHIM is already used. The newer version has not been copied to the inbox 
however. I've attached the new version. A special note has been added (§6.2) 
addressing semantic differences between SHIM, and how headers are using in 
HTTP, and in this XEP.

> * I note that "Response formats" seem to be useable in requests.  I would 
> consider changing the term to something a little more generic.

This has also been changed in the new version, but not published to the inbox 
yet. The new term is "Encoding formats", found in §4.2 in the new document.

> * Are there any concerns about what data transfer mechanisms/resposne formats 
> an entity is expected to accept?   This document seems to imply all entities 
> MUST understand all of them, and I'm not sure that's a reasonable implication.

Not explicitly. Each entity is supposed to understand it only to a certain 
point: It is required for instance to know how to handle a stream, or more 
explicitly, how to close one. Or clean up current streams if a client goes 
off-line.

But when it comes to file transfer (sipub), or Jingle, it's still an active 
choice of the client to continue with the actual negotiation and request 
transfer.

> * It would seem to me that the actual data transmission of chuckedBase64 and 
> streamBase64 are better implemented as [IBB], or use Jingle with [XEP-261] 
> IBB candidates.

I will rework the specification so that it uses IBB instead of chunkedBase64 or 
streamBase64 encoding types. Will send you an updated version with this 
hopefully tomorrow.
 
Sincerely,
Peter Waher

Re: [Standards] LAST CALL: XEP-0297 (Stanza Forwarding)

[Lance Stout]

So, for the Last Call that was supposed to expire in December but we all 
forgot...


> 1. Is this specification needed to fill gaps in the XMPP protocol stack or to 
> clarify an existing protocol?

Yes

> 2. Does the specification solve the problem stated in the introduction and 
> requirements?

Yes

> 3. Do you plan to implement this specification in your code? If not, why not?

Yes, it has been included in SleekXMPP for a while now, as well as Carbons and 
MAM which require it.

> 4. Do you have any security concerns related to this specification?

None beyond what is already called out in the XEP.

> 5. Is the specification accurate and clearly written?

Yes.

Given the other recent mail on the standards list about Carbons nesting its 
content inside the  element, and the currently published version 
of MAM using the old sibling method, it might be useful to go ahead and mandate 
that nesting the using protocol's content is a MUST instead of a SHOULD. We'll 
just need to bother MattJ into submitting his updated version of the MAM spec 
to the editor.


-- Lance

smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Forward Stanza Inconsistency between XEP-0280 and XEP-0313

[Matt Miller]

On May 22, 2013, at 1:57 PM, Spencer MacDonald 
 wrote:

> Thanks Lance,
> 
> OK so the xmlns element should be a parent not a sibling. 
> 
> 

Yes, the extension using stanza forward is supposed to contain it.  This is a 
SHOULD in XEP-0297 (hrm, I wonder if this ought to be a MUST?)...now (-:


- m&m

Matthew A. Miller
< http://goo.gl/LK55L >

> On Wednesday, 22 May 2013 at 20:37, Lance Stout wrote:
> 
>> On May 22, 2013, at 12:27 PM, Spencer MacDonald 
>>  wrote:
>> 
>>> Hi,
>>> 
>>> Maybe there is a good reason for it, but in XEP-0280 Message Carbons the 
>>> forwarded stanza is nested in either a received or sent element with the 
>>> carbons xmlns.
>>> 
>>> In XEP-0313 Message Archive Management the result element with the mam 
>>> xmlns is a sibling of the forwarded stanza.
>>> 
>>> Should there be a standard for this in terms of wether the xmlns element 
>>> should be the parent or sibling of the forwarded stanza?
>> 
>> This is just because MAM hasn't been updated to match yet. See 
>> http://matthewwild.co.uk/uploads/xep-0313.html
>> 
>> 
>> -- Lance 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Forward Stanza Inconsistency between XEP-0280 and XEP-0313

[Spencer MacDonald]

Thanks Lance,

OK so the xmlns element should be a parent not a sibling. 

Regards

Spencer


On Wednesday, 22 May 2013 at 20:37, Lance Stout wrote:

> On May 22, 2013, at 12:27 PM, Spencer MacDonald 
>  wrote:
> 
> > Hi,
> > 
> > Maybe there is a good reason for it, but in XEP-0280 Message Carbons the 
> > forwarded stanza is nested in either a received or sent element with the 
> > carbons xmlns.
> > 
> > In XEP-0313 Message Archive Management the result element with the mam 
> > xmlns is a sibling of the forwarded stanza.
> > 
> > Should there be a standard for this in terms of wether the xmlns element 
> > should be the parent or sibling of the forwarded stanza?
> 
> This is just because MAM hasn't been updated to match yet. See 
> http://matthewwild.co.uk/uploads/xep-0313.html
> 
> 
> -- Lance 

Re: [Standards] Forward Stanza Inconsistency between XEP-0280 and XEP-0313

[Lance Stout]

On May 22, 2013, at 12:27 PM, Spencer MacDonald 
 wrote:

> Hi,
> 
> Maybe there is a good reason for it, but in XEP-0280 Message Carbons the 
> forwarded stanza is nested in either a received or sent element with the 
> carbons xmlns.
> 
> In XEP-0313 Message Archive Management the result element with the mam xmlns 
> is a sibling of the forwarded stanza.
> 
> Should there be a standard for this in terms of wether the xmlns element 
> should be the parent or sibling of the forwarded stanza?

This is just because MAM hasn't been updated to match yet. See 
http://matthewwild.co.uk/uploads/xep-0313.html


-- Lance

[Standards] Forward Stanza Inconsistency between XEP-0280 and XEP-0313

[Spencer MacDonald]

Hi, 

Maybe there is a good reason for it, but in XEP-0280 Message Carbons the 
forwarded stanza is nested in either a received or sent element with the 
carbons xmlns.

In XEP-0313 Message Archive Management the result element with the mam xmlns is 
a sibling of the forwarded stanza.

Should there be a standard for this in terms of wether the xmlns element should 
be the parent or sibling of the forwarded stanza?


Regards

Spencer

Re: [Standards] LAST CALL: XEP-0297 (Stanza Forwarding)

[Matt Miller]

< http://joeyandchristy.com/images/artextras/logos/awebreadylogos/resurrect.jpg 
>

On Nov 28, 2012, at 9:34 AM, XMPP Extensions Editor  wrote:

> This message constitutes notice of a Last Call for comments on XEP-0297 
> (Stanza Forwarding).
> 
> Abstract: This document defines a protocol to forward a stanza from one 
> entity to another.
> 
> URL: http://xmpp.org/extensions/xep-0297.html
> 
> This Last Call begins today and shall end at the close of business on 
> 2012-12-14.
> 
> Please consider the following questions during this Last Call and send your 
> feedback to the standards@xmpp.org discussion list:
> 
> 1. Is this specification needed to fill gaps in the XMPP protocol stack or to 
> clarify an existing protocol?

Yes.

> 2. Does the specification solve the problem stated in the introduction and 
> requirements?

Yes.

> 3. Do you plan to implement this specification in your code? If not, why not?

Yes, at least as needed for [CARBONS] and [XMPP-E2E].

> 4. Do you have any security concerns related to this specification?

No further security concerns that are not already covered in the document.

> 5. Is the specification accurate and clearly written?


Yes, typos not withstanding ("There are many situations is which an entity 
needs" --> "There are many situations in which an entity needs", is the first I 
noticed).


- m&m

Matthew A. Miller
< http://goo.gl/LK55L >

[CARBONS] XEP-0280: Message Carbons < http://xmpp.org/extensions/xep-0280.html >
[XMPP-E2E] End-to-End Object Encryption and Signatures for the Extensible 
Messaging and Presence Protocol (XMPP) < 
http://tools.ietf.org/html/draft-miller-xmpp-e2e.html >

smime.p7s
Description: S/MIME cryptographic signature

[Standards] Comments on "Pubsub Subscription"

[Matt Miller]

I really only have one comment, and that is around the need (and algorithm) for 
itemID generation.

* I think it would help greatly to add a statement or paragraph explaining why 
it's necessary.  I personally don't really see the need, given a pubsub service 
MUST generate unique item IDs.

* I think the algorithm is susceptible to collisions.  If item ID generation is 
really necessary, I would suggest coming up with a stronger algorithm.


- m&m

Matthew A. Miller
< http://goo.gl/LK55L >



smime.p7s
Description: S/MIME cryptographic signature

[Standards] Comments on "HTTP over XMPP"

[Matt Miller]

I have some comments regarding the Proto-XEP "HTTP over XMPP":

* I don't think the use of  is appropriate here, as per the 
guidelines in RFC6120 § 8.2.3.  At a minimum, the unsafe methods (e.g., DELETE, 
POST, PUT, et al) ought to be , although a strong argument can 
be made that all ought to be .

* This protocols seems like an appropriate place to use [SHIM].

* I note that "Response formats" seem to be useable in requests.  I would 
consider changing the term to something a little more generic.

* Are there any concerns about what data transfer mechanisms/resposne formats 
an entity is expected to accept?   This document seems to imply all entities 
MUST understand all of them, and I'm not sure that's a reasonable implication.

* It would seem to me that the actual data transmission of chuckedBase64 and 
streamBase64 are better implemented as [IBB], or use Jingle with [XEP-261] IBB 
candidates.
 

- m&m

Matthew A. Miller
< http://goo.gl/LK55L >

[SHIM] XEP-0131: Stanza Headers and Internet Metadata < 
http://xmpp.org/extensions/xep-0131.html >
[IBB] XEP-0049: In-Band Bytestreams < http://xmpp.org/extensions/xep-0047.html >
[XEP-261] XEP-0261: Jingle In-Band Bytestreams Transport Method < 
http://xmpp.org/extensions/xep-0261.html >

smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] XEP 202

[Noah Schwartz]

Oh -- well I feel foolish :) Thanks Sergey!


On Wed, May 22, 2013 at 9:15 AM, Sergey Dobrov  wrote:

> You don't need to find any code in the ejabberd sources. Ejabberd will
> just route a full-jid addressed stanza to a xmpp-client and IT will
> answer your query. Ejabberd just has no idea of timezones of it's clients.
>
> This code is responsible only to ejabberd's self time, no more, no less.
> Anyway, it seems to be a bug that it answers this to a query that
> addressed to bare client's jid. But this bug shall not affect you, just
> use full JIDs in your queries and you'll be fine.
>
> On 05/22/2013 08:07 PM, Noah Schwartz wrote:
> > Its possible theres another IQ handler elsewhere in the code but, that
> > seems really unlikely. For those of you that know Erlang, see below.
> >
> > process_local_iq(_From, _To, #iq{type = Type, sub_el = SubEl} = IQ) ->
> > case Type of
> > set ->
> >IQ#iq{type = error, sub_el = [SubEl, ?ERR_NOT_ALLOWED]};
> > get ->
> >Now = now(),
> >Now_universal = calendar:now_to_universal_time(Now),
> >Now_local = calendar:now_to_local_time(Now),
> >{UTC, UTC_diff} = jlib:timestamp_to_iso(Now_universal, utc),
> >Seconds_diff = calendar:datetime_to_gregorian_seconds(Now_local)
> > - calendar:datetime_to_gregorian_seconds(Now_universal),
> >{Hd, Md, _} = calendar:seconds_to_time(abs(Seconds_diff)),
> >{_, TZO_diff} = jlib:timestamp_to_iso({{0, 0, 0}, {0, 0, 0}},
> > {sign(Seconds_diff), {Hd, Md}}),
> >IQ#iq{type = result,
> >  sub_el = [{xmlelement, "time",
> > [{"xmlns", ?NS_TIME}],
> > [{xmlelement, "tzo", [],
> >   [{xmlcdata, TZO_diff}]},
> >  {xmlelement, "utc", [],
> >   [{xmlcdata, UTC ++ UTC_diff}]}]}]}
> > end.
> >
> >
> >
> > On Wed, May 22, 2013 at 8:25 AM, Sergey Dobrov  > > wrote:
> >
> > On 05/22/2013 07:22 PM, Ralph Meijer wrote:
> > > Version 2.1.12 ignores to in the IQ
> > It sounds like smth impossible. I use ejabberd and iq:time works just
> > fine when addressing stanza appropriately.
> >
> > --
> > With best regards,
> > Sergey Dobrov,
> > XMPP Developer and JRuDevels.org founder.
> >
> >
> >
> >
> > --
> > Noah
>
>
> --
> With best regards,
> Sergey Dobrov,
> XMPP Developer and JRuDevels.org founder.
>



-- 
Noah

Re: [Standards] XEP 202

[Sergey Dobrov]

You don't need to find any code in the ejabberd sources. Ejabberd will
just route a full-jid addressed stanza to a xmpp-client and IT will
answer your query. Ejabberd just has no idea of timezones of it's clients.

This code is responsible only to ejabberd's self time, no more, no less.
Anyway, it seems to be a bug that it answers this to a query that
addressed to bare client's jid. But this bug shall not affect you, just
use full JIDs in your queries and you'll be fine.

On 05/22/2013 08:07 PM, Noah Schwartz wrote:
> Its possible theres another IQ handler elsewhere in the code but, that
> seems really unlikely. For those of you that know Erlang, see below. 
> 
> process_local_iq(_From, _To, #iq{type = Type, sub_el = SubEl} = IQ) ->
> case Type of
> set ->
>IQ#iq{type = error, sub_el = [SubEl, ?ERR_NOT_ALLOWED]};
> get ->
>Now = now(),
>Now_universal = calendar:now_to_universal_time(Now),
>Now_local = calendar:now_to_local_time(Now),
>{UTC, UTC_diff} = jlib:timestamp_to_iso(Now_universal, utc),
>Seconds_diff = calendar:datetime_to_gregorian_seconds(Now_local)
> - calendar:datetime_to_gregorian_seconds(Now_universal),
>{Hd, Md, _} = calendar:seconds_to_time(abs(Seconds_diff)),
>{_, TZO_diff} = jlib:timestamp_to_iso({{0, 0, 0}, {0, 0, 0}},
> {sign(Seconds_diff), {Hd, Md}}),
>IQ#iq{type = result,
>  sub_el = [{xmlelement, "time",
> [{"xmlns", ?NS_TIME}],
> [{xmlelement, "tzo", [],
>   [{xmlcdata, TZO_diff}]},
>  {xmlelement, "utc", [],
>   [{xmlcdata, UTC ++ UTC_diff}]}]}]}
> end.
> 
> 
> 
> On Wed, May 22, 2013 at 8:25 AM, Sergey Dobrov  > wrote:
> 
> On 05/22/2013 07:22 PM, Ralph Meijer wrote:
> > Version 2.1.12 ignores to in the IQ
> It sounds like smth impossible. I use ejabberd and iq:time works just
> fine when addressing stanza appropriately.
> 
> --
> With best regards,
> Sergey Dobrov,
> XMPP Developer and JRuDevels.org founder.
> 
> 
> 
> 
> -- 
> Noah


-- 
With best regards,
Sergey Dobrov,
XMPP Developer and JRuDevels.org founder.

Re: [Standards] XEP 202

[Noah Schwartz]

Its possible theres another IQ handler elsewhere in the code but, that
seems really unlikely. For those of you that know Erlang, see below.

process_local_iq(_From, _To, #iq{type = Type, sub_el = SubEl} = IQ) ->
case Type of
set ->
IQ#iq{type = error, sub_el = [SubEl, ?ERR_NOT_ALLOWED]};
get ->
Now = now(),
Now_universal = calendar:now_to_universal_time(Now),
Now_local = calendar:now_to_local_time(Now),
{UTC, UTC_diff} = jlib:timestamp_to_iso(Now_universal, utc),
Seconds_diff = calendar:datetime_to_gregorian_seconds(Now_local)
 - calendar:datetime_to_gregorian_seconds(Now_universal),
{Hd, Md, _} = calendar:seconds_to_time(abs(Seconds_diff)),
{_, TZO_diff} = jlib:timestamp_to_iso({{0, 0, 0}, {0, 0, 0}},
{sign(Seconds_diff), {Hd, Md}}),
IQ#iq{type = result,
  sub_el = [{xmlelement, "time",
 [{"xmlns", ?NS_TIME}],
 [{xmlelement, "tzo", [],
   [{xmlcdata, TZO_diff}]},
  {xmlelement, "utc", [],
   [{xmlcdata, UTC ++ UTC_diff}]}]}]}
end.



On Wed, May 22, 2013 at 8:25 AM, Sergey Dobrov  wrote:

> On 05/22/2013 07:22 PM, Ralph Meijer wrote:
> > Version 2.1.12 ignores to in the IQ
> It sounds like smth impossible. I use ejabberd and iq:time works just
> fine when addressing stanza appropriately.
>
> --
> With best regards,
> Sergey Dobrov,
> XMPP Developer and JRuDevels.org founder.
>



-- 
Noah

Re: [Standards] Serverless communication, XEP-0174 & XEP-0246

[Peter Saint-Andre]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 5/22/13 6:30 AM, Dave Cridland wrote:
> Yes, I think it's a useful thing. And useful to be distinct from
> '174, too.

Right, which is why I removed the reference to it in XEP-0174 as a
"generalization" -- that was just confusing.

Peter

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


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRnL0BAAoJEOoGpJErxa2pNnEP+wYkUNejEXUQTjnmG/9DUUpS
sfaV8gbl1EV5+94Iz6c5BTxRedANReXVJPxvuUb44axXSh3XEXm32rbmtzYKKQh+
BUI7pQb3h/NkQq//ffPmS2+DCI8FuQ7Z5yYLCvxIuzQ1dFKKuv6P3uIjTo8fD7QN
sKOMd+9JvPcQKusG2ohnnSFomxQh8VX8TwET+xL6vUWcTglvV5Gk05E1L26p5eQc
MQr9xtlJW5peN/6llGwpl++nHK0Y6aRjjw8F7HgL31h9PRqEVAFnJoAWtSiPBrS3
e3ulVlELs/Uyo2DsGq/QtpqUiLuXZlj2vdVU9eS4JoQK1+Wi1zzsuNvws4XP8zJp
iKNeTw5ZzxBBcj3w1TmVmg6UPH9VomI7jpPOVGBHZZRec1uyBK2BXVU3Yzkrdc/B
0Wu6uijiQ0B00AD3N93RPPxAFm9dToYk8No2rVmDla/BzJMHxvmUSI376Z1sNY+i
BV0mYFl7YVhCeanSDITO2FJYYpWJQ66cB7kdBu9Xurttxxc2GoxFTNzgHGhcgBt/
B0BbWb6p7hq1VnQddcpdXRrgjWiR91IEgHe9p+B+3LVaXuwdqnInsCU1Bk4s5Ley
QyxdZ432uwdpArw6jiW6mHxgHr5mbDRaPwcBRpz4Wd7X3XRrGcpcabEEU6Q7Z94o
AA+HENy73sfqHh/R2XcV
=w7LS
-END PGP SIGNATURE-

Re: [Standards] Serverless communication, XEP-0174 & XEP-0246

[Dave Cridland]

Yes, I think it's a useful thing. And useful to be distinct from '174, too.

Dave.

Re: [Standards] XEP 202

[Sergey Dobrov]

On 05/22/2013 07:22 PM, Ralph Meijer wrote:
> Version 2.1.12 ignores to in the IQ
It sounds like smth impossible. I use ejabberd and iq:time works just
fine when addressing stanza appropriately.

-- 
With best regards,
Sergey Dobrov,
XMPP Developer and JRuDevels.org founder.

Re: [Standards] XEP 202

[Ralph Meijer]

On 2013-05-22 14:15, Noah Schwartz wrote:

I'm basing the question on the ejabberd code. Version 2.1.12 ignores to in the 
IQ. Ill be looking to patch this...


Are you saying that ejabberd intercepts  stanzas addressed to full 
JIDs (with resource)? That'd would be a major bug per section 10.5.4 of 
RFC 6120:


[..] If the JID contained in the 'to' attribute is of the form
, the user exists, and there is
a connected resource that exactly matches the full JID, the server
MUST deliver the [IQ] stanza to that connected resource.

--
ralphm

Re: [Standards] XEP 202

[Noah Schwartz]

I'm basing the question on the ejabberd code. Version 2.1.12 ignores to in the 
IQ. Ill be looking to patch this...

Sent from my iPhone

On May 22, 2013, at 7:33 AM, Ralph Meijer  wrote:

> On 2013-05-22 12:22, Sergey Dobrov wrote:
>> Hello,
>> 
>> Don't you forget to specify user's resource in the "to" iq's attribute?
> 
> This is a very good point. Let me clarify.
> 
> If you send  stanzas to a user's bare JID, these are to be handled by 
> the server on behalf of the user. It makes sense that the server just 
> responds with its view on time. However, if you send it to a specific 
> resource, the stanza should be handled by a client, hopefully giving you its 
> view on time instead.
> 
> -- 
> ralphm

Re: [Standards] Serverless communication, XEP-0174 & XEP-0246

[Ralph Meijer]

On 2013-05-22 13:56, Dave Cridland wrote:




On Wed, May 22, 2013 at 12:47 PM, Ralph Meijer mailto:ral...@ik.nu>> wrote:

It is a nice, broader explanation of how things work. XEP-0174's
description on how to set up the connection is pretty minimal.
XEP-0246 goes into detail and, for example, specifies the values of
the addressing information in the stream header. I am not entirely
sure why that document never got further along in our standards
process and maybe we should reconsider that.


Isn't it still a useful thing by itself? I also want to note that this 
has been discussed in the Telepathy project as late as June 2012 [1]. 
This was again referred to by Simon McVittie on this list back in 
February [2].


[1] 


[2] 

--
ralphm

Re: [Standards] XEP-0060: Ability of the node to modify subscriptions along with subscription options

[Ralph Meijer]

On 2013-05-10 05:04, Peter Saint-Andre wrote:

On 5/8/13 2:05 AM, Krishna Chaitanya (kchaitan) wrote:

Hi,

I would like to submit an enhancement to XEP-0060 specification to
provide a mechanism for the node owner to subscribe a client /*with
subscription options*/.  As per section 8.2.2 (Modify Subscriptions) of
the specification, the node owner can change the subscription state of a
client to 'subscribed' using  the below stanza.


Hi Krishna,

It does seem to be an oversight that a plain user can subscribe,
configure subscription options, or subscribe-with-options, but an owner
can only subscribe a plain user. The solution you propose appears
reasonable to me.


The reason that changing the subscription status is a different 
protocol, is that allows for batch processing. We don't really like that 
so much these days, and in retrospect we probably should just have used 
the existing protocol for subscribe/unsubscribe with proper 
authorization checking. Also, this protocol doesn't support multiple 
subscriptions (with SubIDs) at all.


I would like to suggest using the existing protocol in section 6.3 
(Configure Subscription Options) for changing a user's subscription 
options and implement proper authorization checking on the sender JID 
against the affiliations for that particular node.


--
ralphm

Re: [Standards] Serverless communication, XEP-0174 & XEP-0246

[Dave Cridland]

On Wed, May 22, 2013 at 12:47 PM, Ralph Meijer  wrote:

> It is a nice, broader explanation of how things work. XEP-0174's
> description on how to set up the connection is pretty minimal. XEP-0246
> goes into detail and, for example, specifies the values of the addressing
> information in the stream header. I am not entirely sure why that document
> never got further along in our standards process and maybe we should
> reconsider that.


It was part of the XTLS effort, which stalled.

Dave.

Re: [Standards] Serverless communication, XEP-0174 & XEP-0246

[Ralph Meijer]

On 2013-05-17 18:18, Peter Saint-Andre wrote:

[..]

It doesn't really normatively reference XEP-0246. I'd propose the
following wording change:

OLD
Once discovery has been completed, the clients are able to negotiate
an XML stream between themselves (as generalized in End-to-End XML
Streams [2]) and then exchange messages and other structured data
using the XMPP  and  stanzas.

NEW
Once discovery has been completed, the clients are able to negotiate
an XML stream between themselves and then exchange messages and other
structured data using the XMPP  and  stanzas.

XEP-0246 was a generalization of how things work in such environments,
but it's certainly not necessary here.


Did you already change this in the currently published version? I cannot 
see the old version of the text, and I also don't see why we wouldn't 
point to XEP-0246. Maybe even normative.


It is a nice, broader explanation of how things work. XEP-0174's 
description on how to set up the connection is pretty minimal. XEP-0246 
goes into detail and, for example, specifies the values of the 
addressing information in the stream header. I am not entirely sure why 
that document never got further along in our standards process and maybe 
we should reconsider that.


--
ralphm

Re: [Standards] XEP 202

[Ralph Meijer]

On 2013-05-22 12:22, Sergey Dobrov wrote:

Hello,

Don't you forget to specify user's resource in the "to" iq's attribute?


This is a very good point. Let me clarify.

If you send  stanzas to a user's bare JID, these are to be handled 
by the server on behalf of the user. It makes sense that the server just 
responds with its view on time. However, if you send it to a specific 
resource, the stanza should be handled by a client, hopefully giving you 
its view on time instead.


--
ralphm

Re: [Standards] XEP 202

[Sergey Dobrov]

Hello,

Don't you forget to specify user's resource in the "to" iq's attribute?

On 05/22/2013 04:49 AM, Noah Schwartz wrote:
> I'm looking to add a feature to my client that will show the user the
> timezone of the person they're talking to. We have a number of offices
> around the world and I feel this will help set expectations on whether
> or not you can expect a response.
> 
> Am I completely misunderstanding XEP 202? In the ejabberd implmentation,
> it completely ignores the From and To and gives the user back the UTC
> and TZO of the server. Am I correct in understanding that this XEP
> should allow Romeo to find out Juliets timezone?
> 
> -- 
> Noah


-- 
With best regards,
Sergey Dobrov,
XMPP Developer and JRuDevels.org founder.