Subject: [Simple] Fwd: Evaluation: draft-ietf-simple-winfo-package - A Session Initiation Protocol (SIP)Event Template-Package for Watcher Information to Proposed Standard

From: Patrik Fältström <[email-masked]>
Date: Thu, 9 Jan 2003 18:05:23 +0100

Here are some questions from Harald...as a start (first) questions from 
IESG. Can you please quickly look at these and get back with an answer.

If you are confused by him saying "not a Discuss" etc, look at the 
draft tracker we have. It means "if there is an issue so the document 
need to be updated, I will place a discuss which I will clear when the 
document is updated".

So, first step now is just to ask if he is correct -- whether this 
should document should be updated or not.

If you are unsure, and need to think, just say so, and we will handle 
this the normal way with "comments".

    paf

Begin forwarded message:

> From: Harald Tveit Alvestrand <[email-masked]>
> Date: tor jan 9, 2003  15:28:44 Europe/Stockholm
> To: Internet Engineering Steering Group <[email-masked]>
> Subject: Re: Evaluation: draft-ietf-simple-winfo-package - A Session  
> Initiation Protocol (SIP)Event Template-Package for Watcher  
> Information to Proposed Standard
>
> Worry, not a DISCUSS.
> May be satisfied with an explanation from Patrik, otherwise I'll plant 
> a DISCUSS on it and ask for clarification.
>
> The simple-presence document says:
>
>> 5 Usage of Presence URIs
>>
>>    A presentity is identified in the most general way through a 
>> presence
>>    URI [3], which is of the form pres:user@domain. These URIs are
>>    protocol independent. They are resolved to protocol specific URIs,
>>    such as a SIP or SIPS URI, through domain-specific mapping 
>> policies.
>>
>>    If a subscriber is only aware of the protocol-independent pres URI
>>    for a presentity, it follows the procedures defined in [5]. These
>>    procedures will result in the placement of the pres URI in the
>>    Request-URI of the SIP request, followed by the usage of the DNS
>>    procedures defined in [5] to determine the host to send the SIP
>>    request to. Of course, a local outbound proxy may alternatively be
>>    used, as specified in RFC 3261 [1]. If the subscriber is aware of
>>    both the protocol-independent pres URI and the SIP or SIPS URI for
>>    the same presentity, it SHOULD use the SIP or SIPS URI.
>>
>>    SUBSCRIBE messages also contain logical identifiers that define the
>>    originator and recipient of the subscription (the To and From 
>> header
>>    fields). These SHOULD contain SIP or SIPS URIs whenever possible, 
>> but
>>    MAY contain a pres URI if a SIP or SIPS URI is not known or
>>    available.
>
> [5] is D. Crocker et al.  , "Address resolution for instant messaging
>   and presence," Internet Draft, Internet Engineering Task Force, Oct.
>   2002.  Work in progress.
>
> I assume this is draft-ietf-impp-srv-01.txt (same title!).
> That draft seems to envision DNS entries of the form
> "_pres._sip.example.com" to look up which host to contact when one 
> wants to use SIP to contact a presentity named 
> "pres:[email-masked]".
> There's no mapping from one type of URI to another - in either 
> direction.
>
> This has two problems:
>
> 1) If a client uses SIP, he presumably has SIP URIs for himself. So he 
> will use that SIP URI in the From field of a SUBSCRIBE, even though he 
> also has his own PRES URI.
> If the SUBSCRIBE has to be gatewayed to a non-SIP domain, per CPIM, 
> how is the gateway to find the corresponding PRES URI?
>
> 2) If a client starts with the PRES URI, and later learns the SIP URI 
> of someone, and those two identities part way for some reason (perhaps 
> the client stops using SIP, or the SIP URI was to a proxy service, or 
> something) - how does the client learn that it's time to go back to 
> the PRES URI?
>
> Both problems would be avoided if this document said to use PRES URI 
> when both are available.
>
> draft-ietf-impp-serv says:
>
>>    CPIM and CPP both specify operations that have 'source' and
>>    'destination' attributes.  While only the semantics, not the 
>> syntax,
>>    of these attributes are defined by CPIM and CPP, many instant
>>    messaging and presence protocols today support the use of URIs to
>>    reflect the source and destination of their operations.  Such
>>    protocols might be able to use the 'im' and 'pres' URI schemes
>>    directly to express the identities of the principals associated 
>> with
>>    a protocol exchange.  When these operations pass through a CPIM or
>>    CPP gateway, these URIs could be relayed without modification, 
>> which
>>    has a number of desirable properties for the purposes of
>>    interoperability.
>
> Seems to me like a good argument for preferring "pres:" here.
> I've added this comment to the tracker too.
>
>                        Harald
>
>

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 16 Jan 2003 19:25:26 -0500

Sorry for taking so long to respond. They are not obvious issues in 
fact, so I wanted to ponder them a bit and respond after thinking about it.

Anyway, Harald, thanks for the comments, I am glad to have them. 
Responses inline:

Patrik Fältström wrote:

>>>    A presentity is identified in the most general way through a presence
>>>    such as a SIP or SIPS URI, through domain-specific mapping policies.
>>>
>>>    originator and recipient of the subscription (the To and From header
>>>    fields). These SHOULD contain SIP or SIPS URIs whenever possible, but

Yes.

>> wants to use SIP to contact a presentity named "pres:[email-masked]".
>> There's no mapping from one type of URI to another - in either direction.
>>
>> This has two problems:
>>

This is a good question.

Unfortunately, this is a case which is unavoidable. We are going to run 
into cases where a SIMPLE client has no pres URI at all, and so the From 
field has a SIP URI. Worse yet, there is a great deal of SIMPLE deployed 
today, and most of it (unsurprisingly) using the URI format native to 
SIMPLE, the SIP URI.

So, what would happen at the gateway? I would imagine that, like happens 
in email systems today I believe, that when receiving a SUBSCRIBE 
request with From field sip:[email-masked], the gateway at 
gw.example.com would create a pres URI like this:

pres:[email-masked]

Should someone reply to this, it would route to the gateway, which would 
extract the user part, un-escape it, and send it using the sip URI 
within. Indeed, gateways might do such conversions directly between the 
native URIs of the various systems (SIMPLE and Jabber, for example).

Well, perhaps we would like to avoid this case as much as possible, even 
if it cannot be prevented altogether. So, making it a SHOULD to use a 
pres URI when you know both covers some cases. However, there is a 
practical issue that many existing presence servers don't use the pres 
URI at this time, and so there will be potential interop problems or 
bugs that surface.  No doubt this is a transient problem, but it is very 
possible that it will come up.

Thus, I would ask you, in your experience with other protocols, do you 
feel that given, (1) we will still have the issue you are worried about 
even if we make it a SHOULD to use the pres URI when you know both, and 
(2) there may be short term interoperability and deployment problems, 
that the benefit of this outweighs the cost?

>> something) - how does the client learn that it's time to go back to 

Another good question.

Really, it comes down to how you learn these URI in the first place. I 
might send a SIP SUBSCRIBE to a pres URI, and the Contact header that 
comes back in the 200 OK will definitely be a SIP URI. It identifies the 
specific SIP user agent device I am in contact with. Perhaps you would 
then use this SIP URI instead for future SUBSCRIBE. However, RFC 3261 
intends for the Contact URI to be scoped (in terms of temporal validity) 
to the duration of the dialog (aka subscription). Combing over the text 
in RFC3261 its not fabulously clear on this point, but thats the intent. 
So, there is a built in expiration mechanism which would make it invalid 
for future use. The SIP redirect response could also provide a SIP URI 
for the presence URI. Redirect responses have a built in mechanism for 
declaring the lifetime of the mapping, through the Expires header field.

Alternatively, if you somehow got the SIP URI from DNS when looking up 
the pres URI (note that the SRV spec does NOT give you back the SIP URI, 
but let us assume it did), the DNS TTLs would tell you when it expires.

So, I would argue that the only real way a user can get a hold of both 
the pres and the SIP URI for the user, and not be sure for how long the 
SIP URI is valid,  is if they were handed to that person, on a business 
card, or on a web page. In such cases, I would argue that it is not the 
role of the IETF to dictate which is more authoritative. After all, we 
do not say that if given an H.323 and a SIP URI you must use the SIP 
URI. Or, given a tel URI and a SIP URI, you must use the tel. This 
latter case is actually closer to the pres/sip case, since the tel URI 
can be looked up in DNS to obtain a SIP URI (using ENUM, RFC 2916).

The reason that the draft states a preference here is that within SIP, 
there will be interoperability problems with placeing the pres URI into 
the request URI. In many cases, SIP user agents use an outbound proxy, 
similar to an http proxy. This proxy must understand the request URI 
format in order to forward the request. If I place the pres URI in the 
request URI, and this goes to the outbound proxy, and it doesnt 
understand how to process the pres URI, the subscription will fail. 
Ultimately, our aim is to use our own native addressing format within 
SIP networks, since that promotes maximum interoperability.

So, once more, I would ask - do you think that the benefits of using the 
pres URI in the request URI (which are, that it is possibly more 
authoritative, although I am not so sure), outweigh the drawback of 
potential interoperability issues?

Thanks,
Jonathan R.

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

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 17 Jan 2003 08:51:43 +0100

--On torsdag, januar 16, 2003 19:25:26 -0500 Jonathan Rosenberg 
<[email-masked]> wrote:

> field has a SIP URI.

This case worries me not at all; if there is no pres: URL, we can't use it, 
and just have to live with that.

> Worse yet, there is a great deal of SIMPLE deployed
> in email systems today I believe, that when receiving a SUBSCRIBE request
> with From field sip:[email-masked], the gateway at

this is not exactly new - those of us who've been using email since the 80s 
will remember hosts of addresses like [email-masked] and 
the even more horrifying decwrl!some!where!else!user@gateway.

exactly the same problems abound - including "route pinning", gateway 
traversal authentication and so on (the gatway machine can easily be used 
as an open relay, with all the problems that causes for spam injection, for 
instance).

If there is value to the pres: format, just as there was value to the 
[email-masked] format, the pres: URL will eventually become 
ubiquitous.

> URI at this time, and so there will be potential interop problems or bugs
> that surface.  No doubt this is a transient problem, but it is very

If we were to change the document to say "SHOULD use pres: when one knows 
both pres: and sip:", I would be much happier. One may even include an 
explanatory paragraph that the reason it's not a MUST is for communication 
to environments with legacy SIP-only systems. If we agree that this is the 
only problem.

> but let us assume it did), the DNS TTLs would tell you when it expires.

I would be happier with this part if it added a note saying something like:
"NOTE: For many mechanisms that allow users to learn URIs, there is a 
validity period implied; for instance, RFC 3261 Contact: headers are 
implicitly scoped to the duration of the dialog on which they are sent, and 
URIs that are built using information from the DNS need to respect DNS TTL 
values."

Then it's up to the mechanisms from which you learn URIs to make sure you 
have a TTL when you query - I guess you have already noted this issue for 
the next time RFC 3261 is revised....:-)

This is really an orthogonal issue to which format you want to give 
preference to; the problem is equally valid for both possible preferences.

> card, or on a web page.

I'd be hesitant to predict the future. I suspect that there will be many 
more ways than we currently think of that URIs are handed around. I don't 
think we added TTL values to LDAP or the EPP protocol, for instance....

but back to arguing about which one should be preferred:

> In such cases, I would argue that it is not the
> role of the IETF to dictate which is more authoritative.

I could agree with this argument, if the current document didn't say the 
complete opposite.... if the IETF is to give guidance, I want the guidance 
to be what's best for the Internet.....

> After all, we do
> not say that if given an H.323 and a SIP URI you must use the SIP URI.
> Or, given a tel URI and a SIP URI, you must use the tel. This latter case
> is actually closer to the pres/sip case, since the tel URI can be looked
> up in DNS to obtain a SIP URI (using ENUM, RFC 2916).

[Red herring alert - arguing about analogous cases can lead the discussion 
far astray..... but anyway....

I don't think they're analogous - someone using a pres: URI will certainly 
have installed the <technology>._pres. DNS records for his domain, since 
the pres: URI is meaningless without such installed records.
there are lots of reasons why people can have a valid tel: URI without 
installing records into ENUM (including the fact that the ENUM subtree for 
my country and your country aren't even delegated yet).

If you want analogy, I would rather liken the pres: URI to a telephone 
number in the format +47 41 44 29 94 (international), while the SIP URI is 
41 44 29 94 (national). (Perhaps the analogy even fits.. in the US, I 
sometimes dial US numbers in international format - it's simply simpler 
than figuring out what number of digits I have to cut out/revise/add in 
order to get the right result in *this* particular location....)

.... end of analogy discussion]

> Ultimately, our aim is to use our own native addressing format within SIP
> networks, since that promotes maximum interoperability.

I think this is not the best thing for the Internet.

Using the SIP addressing format exclusively within SIP networks promotes 
maximum interoperability *within SIP networks*. It also promotes "walling 
off the SIP garden", making the cost of communicating with SIP users higher 
for people who are not using SIP services, and it does all the lock-in and 
lack of flexibility that we've seen with explictly-addressed email 
gateways. (No, I don't want to talk about NATs....)

> potential interoperability issues?

I think so.

No matter what you do, you will have interoperability issues. And if you 
allow people to avoid supporting pres: URIs in the first rollout of the 
service (when it can be added at the cost of a few extra DNS lookups), you 
make it that much harder to add support for it in the next version (when 
the "installed base" argument is a hundred times larger).

At the moment, there is no widely deployed presence service that conforms 
to the simple-presence document.

In a year, we both hope that there will be one.

                              Harald

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 20 Jan 2003 17:37:31 -0500

thanks for the quick response. Followups inline.

> If we were to change the document to say "SHOULD use pres: when one 
> knows both pres: and sip:", I would be much happier. One may even 
> include an explanatory paragraph that the reason it's not a MUST is for 
> communication to environments with legacy SIP-only systems. If we agree 
> that this is the only problem.

I think its the only problem, with the caveat that there are a lot of 
mini-problems encapsulated within it. For example, there is a whole body 
of work going on in the area of identity assertion. We have one RFC on 
this topic, RFC 3325, which specifies a private extension (not for 
general use on the Internet), for asserted identity across trusted 
elements. Interestingly, that mechanism as defined only supports the sip 
and tel URI. They would not be able to use it to assert a pres URI as an 
identity. Whether thats good or bad depends on whether you are a fan of 
that mechanism or not ;)

The more general work, using cryptographic identities:
http://www.ietf.org/internet-drafts/draft-ietf-sip-identity-00.txt
runs into an issue too. How does the authentication service (which 
asserts an identity by signing a SIP message fragment whose From header 
identifies the user) determine WHICH identity to assert? Does it assert 
the pres or sip URI? That depends on what the user is trying to do. I 
suppose it could assume that if it was signing a SUBSCRIBE request with 
the event presence, it should assert a pres URI.

Anyway, given the benefits of the pres URI over the 
<encoded-URI>@gateway approach, I would propose to go with your 
proposal, making it a SHOULD to use the pres URI. I'd also like to add a 
bunch of explanatory text around this. Here is my proposed text:

> {\SUBSCRIBE} messages also contain logical identifiers that define the
> originator and recipient of the subscription (the \header{To} and
> \header{From} header fields). These headers can take either a pres or
> SIP URI. When the subscriber is aware of both a pres and SIP URI for
> its own identity, it SHOULD use the pres URI in the From header
> field. Similarly, when the subscriber is aware of both a pres and a
> SIP URI for the desired presentity, it SHOULD use the pres URI in the
> To header field. The usage of the pres URI supports interoperability through
> gateways to other CPP-compliant systems. It provides a
> protocol-independent form of identification which can be passed
> between systems. Without such an identity, gateways would be forced to
> map SIP URIs into the addressing format of other protocols. Generally,
> this is done by converting the SIP URI to the form
> <foreign-protocol-scheme>:<encoded SIP URI>@<gateway>. This is
> commonly done in email systems, and has many known problems. The usage
> of the pres URI is a SHOULD, and not a MUST, to allow for cases where
> it is known that there are no gateways present, or where the usage of
> the pres URI will cause interoperability problems with SIP components
> that do not support the pres URI.

Harald further writes:
> implicitly scoped to the duration of the dialog on which they are sent, 
> and URIs that are built using information from the DNS need to respect 
> DNS TTL values."
> 
> Then it's up to the mechanisms from which you learn URIs to make sure 
> you have a TTL when you query - I guess you have already noted this 
> issue for the next time RFC 3261 is revised....:-)
> 

I agree that it is orthogonal. I've added the following text that 
discusses the issue genreally:

> In some instances, a user starts with one URI format, such as the pres
> URI, and learns a URI in a different format through some protocol
> means. As an example, a SUBSCRIBE request sent to a pres URI will
> result in learning a SIP or SIPS URI for the presentity from the
> Contact header field of the 200 OK to the SUBSCRIBE request. As
> another example, a DNS mechanism might be defined that would allow
> lookup of a pres URI to obtain a SIP or SIPS URI. In cases where one
> URI is learned from another through protocol means, those means will
> often provide some kind of scoping that limit the lifetime of the
> learned URI. DNS, for example, provides a TTL which would limit the
> scope of the URI. These scopes are very useful to avoid stale or
> conflicting URIs for identifying the same resource. To ensure that a
> user can always determine whether a learned URI is still valid, it is
> RECOMMENDED that systems which provide lookup services for presence
> URIs have some kind of scoping mechanism.

> more ways than we currently think of that URIs are handed around. I 
> don't think we added TTL values to LDAP or the EPP protocol, for 
> instance....

True. Such things would exist as part of the schema, though. Indeed, the 
point of the above text is that your LDAP schema should include some 
kind of expiration.

> complete opposite.... if the IETF is to give guidance, I want the 
> guidance to be what's best for the Internet.....

I was trying to argue that generally, I didn't want to impose a rule on 
determining which was authoritative, except to the extent that there 
were specific technical issues that would cause you to prefer one over 
the other.

> [Red herring alert - arguing about analogous cases can lead the 
> discussion far astray..... but anyway....
> 
> I don't think they're analogous - someone using a pres: URI will 
> certainly have installed the <technology>._pres. DNS records for his 
> domain, since the pres: URI is meaningless without such installed records.
> installing records into ENUM (including the fact that the ENUM subtree 
> for my country and your country aren't even delegated yet).

Sure. In fact, [and now we are really getting off topic] I have argued 
on the iptel list that I felt that the tel URI as defined was really 
capturing two different functions. One was a true URN, where the implied 
semantics were to do a lookup in the DNS (using enum) to resolve it. The 
second was to identify a telephone network endpoint, so that the implied 
semantics were to connect to that endpoint on the telephone network. I 
argued to create two URI to represent these separately, in fact. But, 
like I said, that is really a separate discussion, which, if you are 
interested in, I welcome you to comment on on the iptel list.

> maximum interoperability *within SIP networks*. It also promotes 
> "walling off the SIP garden", making the cost of communicating with SIP 
> users higher for people who are not using SIP services, and it does all 
> the lock-in and lack of flexibility that we've seen with 
> explictly-addressed email gateways. (No, I don't want to talk about 
> NATs....)
> 
> service (when it can be added at the cost of a few extra DNS lookups), 
> you make it that much harder to add support for it in the next version 
> (when the "installed base" argument is a hundred times larger).

OK, I will buy the argument that it is harder now than later. I changed 
the text to make usage of the pres URI a SHOULD.

-Jonathan R.