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

[[e-mail]]

SIP allows any scheme to be carried in the From header. It is up to the entities in the network to understand, interpret and forward that request.

eg:
SUBSCRIBE xmpp:[e-mail]

The sip entity at the edge of the sip network (the request reached there using pre-configured route set, for instance), or any entity on the way needs to know how to parse the xmpp uri and do an SRV lookup on the domain nokia.com. This look up could be _sip.nokia.com, just to find the next hop. If no entity on the network understands the scheme, then an error response is returned.


To increase interoperability success, I would think that other protocols derived from IMPP must also support scheme agnostic URIs. In this way, the gateway will just copy the URI in the from-header of a sip SUBSCRIBE into the corresponding from-header of the x-protocol SUBSCRIBE. When a reply comes from x-protocol carrying sip scheme, this time in the corresponding To-header of x-protocol, then an entity in the x-protocol domain must perform the same logic as described above in case of the sip network.

Regards,
Hisham

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:[e-mail]]
> Sent: Friday, January 17, 2003 2:25 AM
> To: Patrik Fältström
> Cc: [e-mail]; Harald Alvestrand; Allison Mankin
> Subject: Re: [Simple] Fwd: Evaluation: 
> draft-ietf-simple-winfo-package -
> A Session Initiation Protocol (SIP)Event Template-Package for Watcher
> Information to Proposed Standard
> 
> 
> 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:
> 
> >> 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!).
> 
> Yes.
> 
> >> 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:[e-mail]".
> >> 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?
> 
> 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:[e-mail], the gateway at 
> gw.example.com would create a pres URI like this:
> 
> pres:[e-mail]
> 
> 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?
> 
> 
> >>
> >> 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?
> 
> 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
> [e-mail]                     FAX:   [phone]
> http://www.jdrosen.net                      PHONE: [phone]
> http://www.dynamicsoft.com
> 
> _______________________________________________
> Simple mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/simple
> 
_______________________________________________
Simple mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/simple