Re: [Standards] UPDATED: XEP-0276 (Presence Decloaking)

2012-07-18 Thread Peter Saint-Andre 
On 7/18/12 1:31 PM, Ralph Meijer wrote:
> On 2012-07-17 11:39, Kevin Smith wrote:
>> Right, I had assumed that. However, I'm not sure the protocol and the
>> UI tie in as closely as might first appear (given that a malicious
>> entity would just pick the session type most likely to be accepted).
>> That is: The UI could say"Alice wants to start a conversation with you
>> - this will reveal that you're online. [Reveal] [Ignore]" or whatever.
>> Including a machine-readable indication of what's going to happen
>> afterwards seems appealing - but ultimately I'm not sure that it helps
>> (and it introduces additional complexity and need for extensibility
>> and ...).
> 
> If I understand your argument correctly, the reason for decloaking would
> not be rendered by a client. Do we then actually need the element at all?

I think not.

> One argument in favor of identifiers for reasons v.s. just some text is
> localization. In that case I'd go with Kim's proposal.

If we need it, then providing a way for it to be localized is a good idea.

Peter

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

Re: [Standards] UPDATED: XEP-0276 (Presence Decloaking)

2012-07-18 Thread Ralph Meijer 

On 2012-07-17 11:39, Kevin Smith wrote:

Right, I had assumed that. However, I'm not sure the protocol and the
UI tie in as closely as might first appear (given that a malicious
entity would just pick the session type most likely to be accepted).
That is: The UI could say"Alice wants to start a conversation with you
- this will reveal that you're online. [Reveal] [Ignore]" or whatever.
Including a machine-readable indication of what's going to happen
afterwards seems appealing - but ultimately I'm not sure that it helps
(and it introduces additional complexity and need for extensibility
and ...).


If I understand your argument correctly, the reason for decloaking would 
not be rendered by a client. Do we then actually need the element at all?


One argument in favor of identifiers for reasons v.s. just some text is 
localization. In that case I'd go with Kim's proposal.


--
ralphm

Re: [Standards] UPDATED: XEP-0276 (Presence Decloaking)

2012-07-17 Thread Peter Saint-Andre 
On 7/17/12 2:34 AM, Kevin Smith wrote:
> On Mon, Jul 16, 2012 at 11:41 PM, Kim Alvefur  wrote:
>> If we want the `reason` bit to be flexible, why not make it some
>> combination of a text label and a registry, perhaps similar to stanza
>> errors.
>>
>> Maybe reuse the features (XEP 30, Disco) registry, like:
>> 
>>  Voice call
>> 
> 
> Or, we could dispense with the reason entirely and just leave it at
> something human readable?
> 
> 
>  I want to call you
> 
> 
> Including the use case seems to be somewhat conflating negotiation
> (which specs generally sort out themselves via Jingle, or just aren't
> negotiated) with discovery, which I think decloaking aids with.
> 
> Cutting it out makes this very simple and doesn't seem to harm us.

+1, I think. I don't believe that this would be used in an automated
fashion.

Peter

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

Re: [Standards] UPDATED: XEP-0276 (Presence Decloaking)

2012-07-17 Thread Kevin Smith 
On Tue, Jul 17, 2012 at 10:31 AM, Simon McVittie
 wrote:
> On 17/07/12 00:26, Lance Stout wrote:
>> The reason value is really just a hint or suggestion
>
> Yes, that was my intention when I wrote the XEP. It seems a bit more
> user-friendly if you can hint at the reason for requesting de-cloaking:
>
> /---\
> | Alice  is asking   |
> | whether you are currently online, but |
> | is not on your contact list.  |
> | [ Reveal presence ] [ Ignore ]|
> \---/
>
> ("what do I do about that?!") vs.
>
> /-\
> | Alice  wants to  |
> | call you, but is not on your contact list.  |
> | Allowing the call to be started will reveal |
> | that you are currently online.  |
> | [ Reveal presence ] [ Ignore ]  |
> \-/
>
> ("oh, this is just an incoming call from someone I don't know, I know
> what to think about that").

Right, I had assumed that. However, I'm not sure the protocol and the
UI tie in as closely as might first appear (given that a malicious
entity would just pick the session type most likely to be accepted).
That is: The UI could say"Alice wants to start a conversation with you
- this will reveal that you're online. [Reveal] [Ignore]" or whatever.
Including a machine-readable indication of what's going to happen
afterwards seems appealing - but ultimately I'm not sure that it helps
(and it introduces additional complexity and need for extensibility
and ...).

/K

Re: [Standards] UPDATED: XEP-0276 (Presence Decloaking)

2012-07-17 Thread Simon McVittie 
On 17/07/12 00:26, Lance Stout wrote:
> The reason value is really just a hint or suggestion

Yes, that was my intention when I wrote the XEP. It seems a bit more
user-friendly if you can hint at the reason for requesting de-cloaking:

/---\
| Alice  is asking   |
| whether you are currently online, but |
| is not on your contact list.  |
| [ Reveal presence ] [ Ignore ]|
\---/

("what do I do about that?!") vs.

/-\
| Alice  wants to  |
| call you, but is not on your contact list.  |
| Allowing the call to be started will reveal |
| that you are currently online.  |
| [ Reveal presence ] [ Ignore ]  |
\-/

("oh, this is just an incoming call from someone I don't know, I know
what to think about that").

The implementation in Telepathy supports either decloaking automatically
(a boolean option, off by default) or decloaking on-request (we signal
the UI to tell it about the decloak request, including the reason
attribute, and the UI can respond by sending directed presence if
desired). I don't think we actually have UI for it in either mode, though.

If I remember correctly, the original motivation was a SIP-to-XMPP
gateway, in which the gateway's virtual XMPP users always responded to
decloak requests, so that you could call arbitrary SIP addresses via
their corresponding XMPP address without adding it to your roster first;
in this case there was no meaningful presence to leak, because the
virtual users behaved as if they were always online anyway (we didn't
implement SIMPLE on the SIP side).

Part of the motivation for decloaking was that in 2010, it wasn't
obvious which of the incompatible dialects of Jingle and ICE-UDP
(Google/various expired XEP drafts/current XEP) would be supported by an
unknown client (perhaps one that pre-dated the then-current XEP, like an
older version of Telepathy). To perform a high-level, user-visible
action ("call Bob") we had to look at disco results and perform one of
several similar protocol actions, depending on the capabilities of Bob's
client.

Now that the Jingle and ICE-UDP XEPs are more widely-implemented, it
might be possible to define a way to initiate a call with a bare JID
using those XEPs (i.e. assume that if Bob's client supports calls at
all, then it supports modern XEP Jingle), and redirect to one particular
resource if Bob answers.

S

Re: [Standards] UPDATED: XEP-0276 (Presence Decloaking)

2012-07-17 Thread Kevin Smith 
On Mon, Jul 16, 2012 at 11:41 PM, Kim Alvefur  wrote:
> If we want the `reason` bit to be flexible, why not make it some
> combination of a text label and a registry, perhaps similar to stanza
> errors.
>
> Maybe reuse the features (XEP 30, Disco) registry, like:
> 
>  Voice call
> 

Or, we could dispense with the reason entirely and just leave it at
something human readable?


 I want to call you


Including the use case seems to be somewhat conflating negotiation
(which specs generally sort out themselves via Jingle, or just aren't
negotiated) with discovery, which I think decloaking aids with.

Cutting it out makes this very simple and doesn't seem to harm us.

/K

Re: [Standards] UPDATED: XEP-0276 (Presence Decloaking)

2012-07-17 Thread Dave Cridland 
My only argument against this is that this layers a metasyntax into
attribute values - for that reason alone I'm leaning toward Kim's reworking
using a child element.

That said, Kim's has the additional benefit that it is extensible, and
previous experience suggests that this is always a good option. The fact
we're discussing different ways of using the field suggests extensibility
may well be needed.
On Jul 17, 2012 12:44 AM, "Gunnar Hellström" 
wrote:

> On 2012-07-17 01:26, Lance Stout wrote:
>
>> Given that entity caps are expected to be transmitted in both the sent
>> and received presence (or failing that you now know a full JID which can be
>> queried for disco), what more do we really need other than saying that you
>> can include multiple values in the reason attribute?
>>
>>
>>
>>  >Answers should include details about the presence, such as supported
>>> codecs, and parameters, and encryption capabilities.
>>>
>> Any supported protocols, codecs, etc would be found via disco/entity caps.
>>
>> The reason value is really just a hint or suggestion, since the requester
>> may well attempt to subsequently establish a different type of session than
>> originally requested, or none at all (this should be mentioned in security
>> considerations, I think). Attempting to layer much more meaning than that
>> seems more complex than necessary.
>>
> Good reasoning,
> if we make it:
> 
>
> Real-time text and message text has very different usability
> characteristics, so they should not be intermixed. Real-time text is rapid
> without the wait for message composition that appears in message text. It
> is time to modernize text communication. Merging them under the single
> label "test" is as asking for streamed video and conversational video at
> the same time.
>
> /Gunnar
>
>

Re: [Standards] UPDATED: XEP-0276 (Presence Decloaking)

2012-07-16 Thread Gunnar Hellström 

On 2012-07-17 01:26, Lance Stout wrote:

Given that entity caps are expected to be transmitted in both the sent and 
received presence (or failing that you now know a full JID which can be queried 
for disco), what more do we really need other than saying that you can include 
multiple values in the reason attribute?

   


>Answers should include details about the presence, such as supported codecs, 
and parameters, and encryption capabilities.

Any supported protocols, codecs, etc would be found via disco/entity caps.

The reason value is really just a hint or suggestion, since the requester may 
well attempt to subsequently establish a different type of session than 
originally requested, or none at all (this should be mentioned in security 
considerations, I think). Attempting to layer much more meaning than that seems 
more complex than necessary.

Good reasoning,
if we make it:


Real-time text and message text has very different usability 
characteristics, so they should not be intermixed. Real-time text is 
rapid without the wait for message composition that appears in message 
text. It is time to modernize text communication. Merging them under the 
single label "test" is as asking for streamed video and conversational 
video at the same time.


/Gunnar

Re: [Standards] UPDATED: XEP-0276 (Presence Decloaking)

2012-07-16 Thread Lance Stout 
Given that entity caps are expected to be transmitted in both the sent and 
received presence (or failing that you now know a full JID which can be queried 
for disco), what more do we really need other than saying that you can include 
multiple values in the reason attribute?

  

> Answers should include details about the presence, such as supported codecs, 
> and parameters, and encryption capabilities.

Any supported protocols, codecs, etc would be found via disco/entity caps.

The reason value is really just a hint or suggestion, since the requester may 
well attempt to subsequently establish a different type of session than 
originally requested, or none at all (this should be mentioned in security 
considerations, I think). Attempting to layer much more meaning than that seems 
more complex than necessary.

-- Lance

Re: [Standards] UPDATED: XEP-0276 (Presence Decloaking)

2012-07-16 Thread Kim Alvefur 
If we want the `reason` bit to be flexible, why not make it some
combination of a text label and a registry, perhaps similar to stanza
errors.

Maybe reuse the features (XEP 30, Disco) registry, like:

 Voice call


--
Regards,
Kim "Zash" Alvefur



signature.asc
Description: OpenPGP digital signature

Re: [Standards] UPDATED: XEP-0276 (Presence Decloaking)

2012-07-16 Thread Mark Rejhon 
On Mon, Jul 16, 2012 at 4:56 PM, Gunnar Hellström <
gunnar.hellst...@omnitor.se> wrote:
>
>  6. The reason Attibute
>
> To signal the type of communication that is desired, the entity that first
> shares session presence MAY include a 'reason' attribute on the 
> element. Multiple values are allowed. The following values for the 'reason'
> attribute are defined:
>  *video*
>  Presence is requested for video medium of a call party, e.g. via Jingle
> RTP Sessions  
> [8
> ]. *audio*
>  Presence is requested for audio medium of a call party, e.g. via Jingle
> RTP Sessions  
> [8
> ]. **
>  *real-time-text* Presence is requested for a real-time text conversation
> using a medium of the call party or an extension that requires real-time
> text capabilities to be disclosed, such as In-Band Real Time 
> Text
>  [11 ], or Jingle
> RTP Sessions  
> [8]
> or real-time text capabilities beyond a gateway. *message-text* Presence
> is requested for a text communication using a message medium of the call
> party or an extension that requires text message capabilities to be
> disclosed, such asXHTML-IM  
> [9
> ], Chat State Notifications  
> [10
> ], or text message capabilities beyond a gateway.  ***file* Presence is
> requested for one or more file transfers, e.g. via Jingle File 
> Transfer
>  [12 ] or Stream
> Initiation  
> [13
> ].
>

Gunnar's ideas seem good (though the implementation details could be
reduced somewhat).

I wonder if there's a need for that many granular reasons, because I
consider real-time text to be the same category as message-text.  However,
it is my understanding that this isn't the case for the SIP / RFC4103 side
of things, because the SIP RTT / SIP messaging are more independent of each
other.   On the other hand, the text transmitted over RFC4103/T.140 over
SIP (for real time text) and SIP Message/MSRP can be brought into sync by
the implementor, much like  (XEP-0301) and  (XMPP Core) is
kept in sync by an implementation.

Side note: Right now, as far as I know, I don't see any standardization (as
far as I know) for synchronizing the text between RFC4103/T.140, and the
text in SIP Mesage, but it is possible, likely by transmitting the SIP
Message everytime someone hits Enter, or after a certain number of
characters.  (which may introduce ambiguity in backspacing to previous
message, but there are some solutions to even this too.  On the XMPP side
of things, it's XEP-0308 last message editing and a very minor extension to
XEP-0301 (It's just an "id" parameter for  elements containing a
event='new'/'reset') can theoretically allow XEP-0301 on last message
editing, and permit backspacing to the previous message, for backwards
compatibility to "linear RTT" (textphone style).Implementations would
have to be responsible for merging the user interface presentation.  But
this side-note paragraph is not XMPP talk, and probably needs to be brought
up on the appropriate IETF mailing list, to synchronize the text of the
messaging with the real-time text.

Thanks
Mark Rejhon

Re: [Standards] UPDATED: XEP-0276 (Presence Decloaking)

2012-07-16 Thread Gunnar Hellström 

On 2012-07-16 19:58, Mark Rejhon wrote:

I want to comment that XEP-0276 only allows mentioning "media" or
"text" as the reason, and not both.  XEP-0276 needs to be updated to
permit a single mechanism activating all three features simultaneously
(audio, video, real-time text).   This might be complicated by using
separate, concurrent negotiation mechanisms for out-of-band mechanisms
(audio, video) and in-band mechanisms (RTT).   Even several of you
agreed that Jingle is overkill for RTT.  It's assumed that clients
could detect multiple authentication mechanisms that happens within a
short period of time to each other, and an implementation can merge
them into a single confirmation message, for potential future
XMPP-based "Total Conversation"-compliant software clients.


I also see a great potential in XEP-0276 to make ad-hoc calls to parties 
not known in beforehand, e.g. sip adresses.


But on the SIP side there are at least the following media:
video, (Through RTP)
audio (Through RTP)
real-time text   ( through RTP  RFC 4103)
message text  ( Through SIP Message or MSRP, or maybe even some XMPP 
coexistence protocol)


on the XMPP side, there are the following media:

video ( through Jingle)
audio (through Jingle)
real-time text ( XEP-0301 in-line, or maybe even RTP based through Jingle )
message text ( plain XMPP, HTML, etc as already specified )

Of these, I think only SIP Message cause real problems , because it does 
not really have any reliable capability declaration.


More thoughts: Are there other features we would like to know of that 
need representation in the reason element?

Location?
Multi-user chat?
Camera control?
Encryption of media?

Thus, I agree with Mark that there is a need for a more simultaneous 
reasons in the  element.


I do not know if it is sufficient to just extend  to allow 
multiple values, or some more flexible way of coding the  and 
the answer values are needed.


 seems to be an optional parameter. I guess that that means 
that the answer may contain presence information outside of what was 
requested in the  element. If that interpretation is right, we 
can start developing an application behavior responding with all media 
of possible interest until a version with proper coding of multiple 
 values is published.


Modification proposal to section 6:


   6.The reason Attibute

To signal the type of communication that is desired, the entity that 
first shares session presence MAY include a 'reason' attribute on the 
 element. Multiple values are allowed. The following values 
for the 'reason' attribute are defined:


*video*
   Presence is requested for video medium of a call party, e.g.
   viaJingle RTP Sessions [8
   ].
*audio*
   Presence is requested for audio medium of a call party, e.g.
   viaJingle RTP Sessions [8
   ].
**
*real-time-text*
   Presence is requested for a real-time text conversation using a
   medium of the call party or an extension that requires real-time
   text capabilities to be disclosed, such asIn-Band Real Time Text
   [11
   ], or Jingle
   RTP Sessions [8
   ] or real-time
   text capabilities beyond a gateway.
*message-text*
   Presence is requested for a text communication using a message
   medium of the call party or an extension that requires text message
   capabilities to be disclosed, such asXHTML-IM
   [9
   ],Chat State
   Notifications [10
   ],or text
   message capabilities beyond a gateway.

***file*
   Presence is requested for one or more file transfers, e.g. viaJingle
   File Transfer [12
   ] orStream
   Initiation [13
   ].

Inclusion of the 'reason' attribute can be interpreted by the receiving 
client as a signal that communication is about to start; for instance, a 
call accept/reject dialog could double as a UI for accepting or 
rejecting a session presence request.


Answers should include details about the presence, such as supported 
codecs, and parameters, and encryption capabilities.


-
I am aware that there are gaps and complexities in this definition, and 
hope that others can contribute to refining it. .


/Gunnar

Re: [Standards] UPDATED: XEP-0276 (Presence Decloaking)

2012-07-16 Thread Mark Rejhon 
On Wed, Jul 11, 2012 at 2:01 PM, Peter Saint-Andre  wrote:
>> I suggest changing "explicit user configuration" with "explicit user 
>> confirmation" and then adding another sentence that the user confirmation 
>> can be per request, per first request per requestor, or by setting some 
>> "always decloak" configuration option, or other suitable means so long as 
>> decloaking doesn't occur by default.  That is, the first MUST is the key 
>> security requirement, how to override the default is necessary detail for 
>> implementors to address how they see fit.
>

I have a comment about XEP-0276.   "Total Conversation", specified in
ITU-T F.703 Multimedia Conversational Services, a standard used by
Reach112 (www.reach112.eu) used in real European emergency service
trials, specifies the simultaneous combination of audio, video, and
real-time text.

This is SIP-based real time text, and I envision potential
interoperability use cases for audio-video-RTT transcoding, via
gateways.  This is where XEP-0276 potentially comes in useful for
these European systems, seeing that XEP-0276 is the first XMPP
extension that mentions my XEP-0301 standard.

I want to comment that XEP-0276 only allows mentioning "media" or
"text" as the reason, and not both.  XEP-0276 needs to be updated to
permit a single mechanism activating all three features simultaneously
(audio, video, real-time text).   This might be complicated by using
separate, concurrent negotiation mechanisms for out-of-band mechanisms
(audio, video) and in-band mechanisms (RTT).   Even several of you
agreed that Jingle is overkill for RTT.  It's assumed that clients
could detect multiple authentication mechanisms that happens within a
short period of time to each other, and an implementation can merge
them into a single confirmation message, for potential future
XMPP-based "Total Conversation"-compliant software clients.

Thanks
Mark Rejhon

Re: [Standards] UPDATED: XEP-0276 (Presence Decloaking)

2012-07-11 Thread Peter Saint-Andre 
On 7/11/12 10:39 AM, Kurt Zeilenga wrote:
> A quick comment:
> 
> Security Considerations say "Because decloaking is a presence leak (albeit 
> intentional), an XMPP client that implements the receiving side of this 
> specification MUST disable sharing of session presence by default and MUST 
> enable the feature only as a result of explicit user configuration."
> 
> I suggest changing "explicit user configuration" with "explicit user 
> confirmation" and then adding another sentence that the user confirmation can 
> be per request, per first request per requestor, or by setting some "always 
> decloak" configuration option, or other suitable means so long as decloaking 
> doesn't occur by default.  That is, the first MUST is the key security 
> requirement, how to override the default is necessary detail for implementors 
> to address how they see fit.

Good point, and consistent with what we've said in other specs IIRC.
Will fix in the next version.

Peter

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

Re: [Standards] UPDATED: XEP-0276 (Presence Decloaking)

2012-07-11 Thread Kurt Zeilenga 
A quick comment:

Security Considerations say "Because decloaking is a presence leak (albeit 
intentional), an XMPP client that implements the receiving side of this 
specification MUST disable sharing of session presence by default and MUST 
enable the feature only as a result of explicit user configuration."

I suggest changing "explicit user configuration" with "explicit user 
confirmation" and then adding another sentence that the user confirmation can 
be per request, per first request per requestor, or by setting some "always 
decloak" configuration option, or other suitable means so long as decloaking 
doesn't occur by default.  That is, the first MUST is the key security 
requirement, how to override the default is necessary detail for implementors 
to address how they see fit.

-- Kurt