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

[Patrik Fältström <[e-mail]>]

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 <[e-mail]>
> Date: tor jan 9, 2003  15:28:44 Europe/Stockholm
> To: Internet Engineering Steering Group <[e-mail]>
> 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:[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?
>
> 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/simple