Subject: [Simple] simple-presence-rules: Question on Component ID

From: [email-masked]
Date: Tue, 21 Jun 2005 13:03:18 +0300

Hi,

I have a question related to how tuple Contact addresses are handled in presence authorization. I copied the text in the current draft below. The draft says that by default the Contact URI should be "randomized". In SIP, I assume that this, as well as the "obfuscation" option, has to work so that the Presence Server assings the URI and maintains an internal mapping between the "randomized" URI and the original contact URI. This means that the Presence Server (or in theory some other elements who works together with the PS) becomes a SIP proxy/redirect for all requests that are destined to the "randomized" Contact URIs. Is this correct?

I can understand how this can work for SIP URIs. However, I think it becomes infeasible for any other type of URI, given the requirement that the advertised service must actually be reached using the randomized URI. For instance, how can a Presence Server reasonably do the randomization or obfuscation for tel: or mailto:, let alone to a URI scheme that it does not even understand? 

Regards,
	Markus

---

3.3.2.14  Component ID

   The service and device components both include identifiers (the
   <contact> and <device-id> elements, respectively), which can reveal
   information to a watcher about the presentity.  However, these
   identifiers must be present in the document in order for it to be
   meaningful.  As a result, the <component-ID> permission defines
   transformations that can be applied to these identifiers (both of
   which are URI).  It is an enumerated integer type.  Its values are:

   randomize: This instructs the presence server to randomize the
      service URI and device ID, such that its value is different in
      each notification sent to a watcher, and each value is chosen with
      a minimum of 128 bits of randomness.  The precise mechanism for
      this randomization is a matter of implementation.  The service URI
      MUST still be usable for reaching that particular service,
      however.  The value of this permission is assigned a numeric value
      of 0.

   obfuscate: This instructs the presence server to apply a static
      transformation to the service URI and device ID, such that the
      actual value is never revealed to the watcher.  However, since the
      transformation is done through a static function, the value seen
      by the watcher remains unchanged as long as the URI remains
      unchanged.  The service URI MUST still be usable for reaching that
      particular service, however.  The value of this permission is
      assigned a numeric value of 1.

   allow: This instructs the presence server to provide the service URI
      and device ID to the watcher without modification for the purposes
      of privacy.  The value of this permission is assigned a numeric
      value of 2.

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple