Subject: Re: [Sipping] Binding published data to services

From: <[email-masked]>
Date: Wed, 24 Apr 2002 23:46:20 +0900

All,

There was the discussion on binding published data to services about two
weeks ago.
Even I have read through the discussion and minute in last IETF meeting,
I could not have the big picture as a whole system.
Maybe I misunderstand something important.
I appreciate your kind help.

What I have in mind based on the emails, which Ben Campbell started in
this list, is as follows:

In general, SIP UA has a need to upload some data towards a SIP service
network.
CPI script and presence info are examples of those data.
Before considering a particular mechanism (i.e., protocol) for uploading
the data,
this SIPPING WG decided to investigate the fact that the uploaded data
onto SIP network must be
binded some SIP service element. For example,
in the case of presence, in order for a presentitiy to update presence
info,
the presentitiy uploads his or her updated presence info towards some
URI.
It is needed to ensure that the URI should be right point for the
presentitiy to upload his
updated presence info, otherwise, his presence info could not be handled
nor notified to correct
watchers.
The assumption here is that we do not discuss underlying uploading
mechanism but
we focus only on binding URI of data publication point to URI of SIP
service element.
The whole discussion was all about how this binding should be archived (
if I could
correctly read mails).

But I think that other kind of bindings seems to be managed for making 
the whole system work.
Let me give an example about presence.
(I think CPL uploading has same issue)

The uploaded presence received by a uploading target point will be
passed to a presence server to which
the uploading target point is binded. When the data will be passed to
the presence server,
the data must be treated as the presence info for intended presentity.
In some cases, the entity uploading the data is exactly the intended
presentity,
but I can imagine that third party entities may upload presence info for
some presentity.
In this case ( the third party entity upload), the uploaded info must be
treated as for correct presentity.
This kind of binding, "binding data to SIP identity" should be kept in
mind, I believe.

Apart from "binding data to SIP identity" problem,
authentication of uploading entity by uploading target point does not
seem to be easy especially
on the third party upload, because this authentication is not
independent
from authentication of SIP UA by SIP service element.

Is this worth to take care? Tiny thing? Or, I dropped some assumption?
If this is important, do we have to make some standardized way of the
new type of binding?
Or, out of scope?

Best regards,
Noboru Iwayama

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 24 Apr 2002 13:21:05 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Wednesday, April 24, 2002 9:46 AM
> To: [email-masked]
> Subject: Re: [Sipping] Binding published data to services
>
>
> All,
>

That is a fair summary.

> This kind of binding, "binding data to SIP identity" should be kept in

This simply means that the authorization mechanism for whatever protocols
get chosen allow for the possibility that identities _other_ than the
principle may be allowed to upload publish information. I don't think we
have made any assumptions so far that preclude this.

> If this is important, do we have to make some standardized way of the

I agree authentication will be an important consideration for any protocol
used to upload service data. However, I think that is a consideration for
those protocols, and out of scope for the binding discussion.

Or are you refering to authentication those who wish to _learn_ where to
publish service information? So that we might release that information only
to those with the proper privilige? I am not sure if that is a requirement
or not. It would certianly not be possible with any algorithmic
transformation, or any approach based on DNS. It could be possible with a
query based approach. I suspect that requirement would do us more harm than
good. We may be better off saying that the publication point is public
knowledge, but that any protocol used for publication must allow
authentication.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 25 Apr 2002 00:19:58 -0400

inline.

> The whole discussion was all about how this binding should be archived (

Thanks for the summary. We need to continue this thread.

I am not convinced that we even have the right model for this
discussion. There is an implicit assumption that the publication URI
needs to be discovered, computed, or derived at all from the SIP URI of
the user for whom the data is to be published. That is, we have assumed
that if I want to publish presence data for sip:[email-masked],
part of the problem will be to define a system for mapping that URI to
some other URI for publishing presence data,
http://publisher.dynamicsoft.com/user/jdrosen, for example. I am not
sure yet that we really need this.

I don't see the problem in configuring a UA with the URL for supporting
publication services. For example, consider presence publication. My UA
would be configured to perform an HTTP POST to sip:pub.dynamicsoft.com,
and include my SIP URI as part of a header or part of the body. The
pub.dynamicsoft.com server would probably need to do a few things with
that data. It might need to write it to a DB, and it needs to make sure
it gets pushed to the presence servers handling subscriptions for me
(there could be more than one). This could happen with a POST from the
pub.dynamicsoft.com servers to the presence servers in the
dynamicsoft.com network.

What is gained by computing this publication URL, or looking it up in a
dynamic sysem? Surely, it is one of a bunch of different service URIs
that will need to be configured in the UA.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 25 Apr 2002 00:00:13 -0500

> Jonathan Rosenberg
> Sent: Wednesday, April 24, 2002 11:20 PM
> To: [email-masked]
> Cc: [email-masked]

I don't have a problem with that approach at all--but lots of people seem to
object to provisioning anything like this. It does presume your publication
destination is static, i.e. it doesn't change much over time. That is
probably OK.

So, does it make sense to apply RFC3087 to the publication URL? (realizing
of course that it is a non-SIP URI, but the concepts seem to apply.)

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Apr 2002 09:34:59 -0400

Comments below.

	Paul

> that will need to be configured in the UA.

I still have an open mind about this. But every new thing that must be provisioned adds to the complexity of managing devices, so schemes that don't require provisioning
are attractive.
 
> and include my SIP URI as part of a header or part of the body.

The problem seems to be a bit more than just provisioning the URL. To permit interoperation between independently built clients and presence servers, it is essential that
everything about publication technique either be provisionable or else be standard. Your description above suggests that the content of the POST must perhaps be tailored to
provide extra context to the server. (Sorry if I have misinterpretted you.)

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 25 Apr 2002 11:13:40 -0400

To amplify earlier remarks: I think the goal should be that a SIP entity
has exactly one configurable attribute, namely the user's SIP URI (and
possibly a secret of some kind). That's easy to explain to users -
everybody knows their email address today. Anything beyond that is
likely to be error prone. (Configuring, for example, a PC to do IMAP is
very tedious - you have to remember the server address, distinguish
between SMTP and IMAP addresses, remember the directory and prefix and
whether the system uses SSL or not, plus probably some parameters I'm
not recalling right now. We don't want to go there.)

We can't assume that configurations are easily movable, so having to key
in half a dozen different, random-looking URIs when borrowing a PC for a
day is just not good design. This is even more of a problem if you have
to do this using a 12-key keypad.

While one extra URI may not seem that bad, the basic problem is that
presence is likely to be just one such URI. We already know about the
need to push CPL and to retrieve configuration information and I suspect
that conferencing will add other parameters.

This is why I like a REGISTER-based model that ties the AOR to other
URIs, by function. What exactly is the problem with that?

---

From: <[email-masked]>
Date: Fri, 26 Apr 2002 01:23:05 +0900

Ben and Jonathan,
thank you for your comments,

Jonathan's example seems to let me know on what point I am not so clear
and
what I am afraid.

It is not clear for me  why binding upload point to SIP service is
current focus of discussion.
The original proposal was on a new SIP method for data upload, and this
proposal was the starting point of
current discussion of "binding" in Minneapolis meeting.
I cannot find logical steps from the new method to binding dicussion.

I do not try to say "binding" is not important. Rather, 
it is reasonable to separate upload point from SIP service element.
Data upload point should be distinguishable from SIP service element and
the upload point should be referred by different URI from the URI of SIP
service element.
Things become more simple by this way, I think.
Is this right understanding? is there any other rational bind binding
discussion?

About authentication, I do not care about authentication for "binding
resolution" procedure.
As Ben said, it is ok to be open for public.
My concern was authentication of data upload mechanism itself.
I agree that that is out of scope of binding discussion.

Here, I was trapped in the following assumption.
Since the proposal of the new method for data publication makes use of
SIP notions,
I have assumed that the protocol used for data upload is also SIP.
With regard to this assumption, I do not see any difficulty on
authentication for data upload.
Just reuse of SIP mechanism.
Same information (password, etc) for authentication as usual SIP
transactions is utilized for data
upload SIP transaction.

However, the "binding" of URI allows us any protocol for data upload
theoretically,
and the allowed protocol may use its own security mechanism which is
different
from SIP security framework. If we can avoid this, we had better avoid.
I cannot imagine delivering two different passwords or keys, one for
data upload and one
for SIP transaction.

How about this thought?

Noboru Iwayama

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 25 Apr 2002 13:58:50 -0400

Paul Kyzivat wrote:
> I still have an open mind about this. But every new thing that must be
> provisioned adds to the complexity of managing devices, so schemes that
> don't require provisioning
> are attractive.
> 
> The problem seems to be a bit more than just provisioning the URL. To
> permit interoperation between independently built clients and presence
> servers, it is essential that
> everything about publication technique either be provisionable or else
> be standard. Your description above suggests that the content of the
> POST must perhaps be tailored to

No, I wasn't proposing that it all be proprietary. Of course you need to
standardize the content of the POST as well. Right now, we are
determining how you learn that URL to make the POST to in the first
place.

-Jonathan R.