Subject: [Sip] WGLC for PUBLISH

From: Rohan Mahy <[email-masked]>
Date: Mon, 12 Jan 2004 16:59:38 -0800

Hi,

I'd like to begin Working Group Last Call for PUBLISH:

	http://www.ietf.org/internet-drafts/draft-ietf-sip-publish-02.txt

This WGLC will end on January 28, 2004.

thanks,
-rohan

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

---

From: OKUMURA Shinji <[email-masked]>
Date: Thu, 15 Jan 2004 18:10:55 +0900

奥村です。
お疲れ様です。

以下のメールを英訳してください。

-----------------------------------------------------------------------
[1] 12. Examplesの
	M1の
	      Contact: <sip:[email-masked]>
	は
	      Contact: <sip:[email-masked]>
	
	M2の
	      Contact: <sip:[email-masked]>
	は
	      Contact: <sip:pa.example.com>

	M3の
	      NOTIFY sip:[email-masked] SIP/2.0
	      Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK8sdf2
	      To: <sip:[email-masked]>;tag=12341234
	      From: <sip:[email-masked]>;tag=abcd1234
	      Call-ID: [email-masked]
	      CSeq: 1 NOTIFY
				.....
	は
	      NOTIFY sip:[email-masked] SIP/2.0
	      Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK8sdf2
	      To: <sip:[email-masked]>;tag=12341234
	      From: <sip:[email-masked]>;tag=abcd1234
	      Call-ID: [email-masked]
	      CSeq: 1 NOTIFY
	      Contact: <sip:pa.example.com>
				.....
	ではないか。

[2] 12. Examplesの例は
       PUA <---> PA <---> WATCHER
の他に
       PUA <---> proxy <---> PA
という例も欲しい。
例えば
       PUA <-----> proxy <------> PA
        | M1 PUBLISH |            |
        |----------->| M2 PUBLISH |
        |            |----------->|
        |            | M3 200 OK  |
        | M4 200 OK  |<-----------|
        |<-----------|            |

	M1
      PUBLISH sip:[email-masked] SIP/2.0
      Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge
      From: <sip:[email-masked]>;tag=1234wxyz
      To: <pres:[email-masked]>
      Call-ID: [email-masked]
      CSeq: 1 PUBLISH
      Max-Forwards: 70
      Expires: 3600
      Event: presence
      Content-Type: application/pidf+xml
      Content-Length: ...

	M2
      PUBLISH sip:pa.example.com SIP/2.0
      Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKpx123
      Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge
      From: <sip:[email-masked]>;tag=1234wxyz
      To: <pres:[email-masked]>
      Call-ID: [email-masked]
      CSeq: 1 PUBLISH
      Max-Forwards: 70
      Expires: 3600
      Event: presence
      Content-Type: application/pidf+xml
      Content-Length: ...

	M3
      SIP/2.0 200 OK
      Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKpx123
      Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge
      From: <sip:[email-masked]>;tag=1234wxyz
      To: <pres:[email-masked]>;tag=1a2b3c4d
      Call-ID: [email-masked]
      CSeq: 1 PUBLISH
      SIP-ETag: dx200xyz
      Expires: 1800
      Content-Length: 0

	M4
      SIP/2.0 200 OK
      Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge
      From: <sip:[email-masked]>;tag=1234wxyz
      To: <pres:[email-masked]>;tag=1a2b3c4d
      Call-ID: [email-masked]
      CSeq: 1 PUBLISH
      SIP-ETag: dx200xyz
      Expires: 1800
      Content-Length: 0

[3] Request-URIはメッセージの宛先として使い、プレゼンスリソースの
	指定はToヘッダで行うようにした方が良いと思う。
	REGISTERによるロケーション登録と同じ動作に方がわかりやすい。
	この点はRFC3265についても同じことが言える。
	なぜなら、RFC3256には

	|3.1.5. Proxy SUBSCRIBE Behavior
	|  Proxies need no additional behavior beyond that described in SIP [1]
	|  to support SUBSCRIBE.

とあるからである。

[4]プレゼンスリソースをあらわすURIはsip-URIではなく、
pres-URI(draft-ietf-impp-pres-04)が良いと思う。

結局[3][4]を合わせると以下のようなURIの使い方が良いと思う。
+------------+-----------------------------+-----------------------------+-----------------------------+
|            | PUBLISH                     | SUBSCRIBE                   | NOTIFY                      |
+------------+-----------------------------+-----------------------------+-----------------------------+
|Request-URI | URI of PA                   | URI of PA                   | Contact-URI of SUBSCRIBE    |
|            | sip:[email-masked]          | sip:[email-masked]          | sip:watcher.example.com     |
+------------+-----------------------------+-----------------------------+-----------------------------+
|To-URI      | URI of presence resource    | URI of presence resource    | From-URI of SUBSCRIBE       |
|            | pres:[email-masked] | pres:[email-masked] | sip:[email-masked]     |
+------------+-----------------------------+-----------------------------+-----------------------------+
|From-URI    | URI of presentity           | URI of watcher              | To-URI of SUBSCRIBE         |
|            | sip:[email-masked]  | sip:[email-masked]     | pres:[email-masked] |
+------------+-----------------------------+-----------------------------+-----------------------------+

Rohan Mahy wrote in <[email-masked]>
>This WGLC will end on January 28, 2004.
___________________________________________________________
奥村 伸二 (株)ソフトフロント 〒060-0009 北9条西15丁目28-195
tel:+81-11-623-1003             mailto:[email-masked]
fax:+81-11-623-1005                sip:[email-masked]

---

From: OKUMURA Shinji <[email-masked]>
Date: Thu, 15 Jan 2004 19:49:09 +0900

Hi,

[1] I believe it requires following changes in some headers of
    the illustrated example in section 12.

    In M1,   Contact: <sip:[email-masked]> should be rewritten as
             Contact: <sip:[email-masked]>

    In M2,   Contact: <sip:[email-masked]> should be
             Contact: <sip:pa.example.com>

    In M3,    NOTIFY sip:[email-masked] SIP/2.0
              ....

              should be

              ....
 
[2] It could be helpful if the following example (2) is added in 
    the document as an addition to the only example (1) illustrated 
    in section 12.

    (1) PUA <---> PA <---> WATCHER

    (2) PUA <---> proxy <---> PA

        For example:

         |            |            |
 
        M1:
 
        M2:
 
        M3:
            SIP/2.0 200 OK
 
        M4:
            SIP/2.0 200 OK
 
[3] It could be better if the "Request-URI" is used as the message's
    target address and the 'Presence Resource' is specified using "To"
    header.

    It would be easy for understanding if REGISTER's location 
    registration operation like mechanism is considered.

    The same point could also be said about RFC3265. This is because,

[4] For expressing 'Presence Resource', the pres-URI(draft-ietf-impp-pres-04)
    would be better than that of the sip-URI.

    Finally, when [3] & [4] are considered together, the various usages 
    of URI can be expressed as listed below.

Regards,
shinji

>This WGLC will end on January 28, 2004.
_________________________________________________
OKUMURA Shinji        E-mail:[email-masked]

---

From: [email-masked]
Date: Fri, 16 Jan 2004 14:05:07 +0200

Hi Shinji,

Thanks for the comments. Answers inline.

 > -----Original Message-----
 > From: ext OKUMURA Shinji [mailto:[email-masked]]
 > Sent: 15 January, 2004 12:49
 > To: Rohan Mahy
 > Cc: [email-masked]; Dean Willis; Niemi Aki (Nokia-M/Helsinki)
 > Subject: Re: [Sip] WGLC for PUBLISH
 > 
 > 
 > Hi,
 > 

All true. Also, since the Via contains a domain name, I will add a "received" param to the Via in the response.

It's very good that you pointed out these mistakes in the examples. I swear, I've looked at them a few times before, but I guess my internal SIP parser is so well built that it never gave me an error message. ;-)

I'll fix these for the next revision.
  
 >     the document as an addition to the only example (1) illustrated 

I'm a little reluctant to adding this. There are excellent SIP call flows already documented elsewhere (see RFC 3665, e.g., Section 3.2), and to this particular method, adding a proxy in between the PUA and the PA works no  different from how this works for other methods (MESSAGE, INVITE). I.e., the proxy rewriting the Request-URI follows the same logic as the other methods would.

However, since this issue has come up before, it might be a good idea to add a proxy between the PUA and PA. Any other views on this? 

 >          |----------->| M2 PUBLISH |

Note that the Request-URI needs to be 'sip:[email-masked]'. PUBLISH is specifically addressed to the resource, not the presence agent.
  
 >             Content-Type: application/pidf+xml

The proxy would rewrite the Request-URI, but probably to something like 'sip:[email-masked]'. Note that when the request is received by the PA/ESC, it specifically uses the Request-URI to determine what resource the PUBLISH is targeted for. This is identical to a SUBSCRIBE.  

 >     registration operation like mechanism is considered.

This is actually how PUBLISH used to work. But having the Request-URI point to a PA requires special handling from the proxies and/or a specific naming convention for PAs to be able to route the request. So we decided to reject the REGISTER-like operation (determining the resource by the To-field) in favor of the SUBSCRIBE-like behavior the draft currently has.

 > +------------+-----------------------------+-----------------
 > ------------+-----------------------------+
 > |            | PUBLISH                     | SUBSCRIBE       
 >             | NOTIFY                      |
 > +------------+-----------------------------+-----------------
 > ------------+-----------------------------+
 > |            | sip:[email-masked]          | 
 > sip:[email-masked]          | sip:watcher.example.com     |
 > +------------+-----------------------------+-----------------
 > ------------+-----------------------------+
 > |            | pres:[email-masked] | 
 > pres:[email-masked] | sip:[email-masked]     |
 > +------------+-----------------------------+-----------------
 > ------------+-----------------------------+
 > |            | sip:[email-masked]  | 
 > sip:[email-masked]     | pres:[email-masked] |
 > +------------+-----------------------------+-----------------
 > ------------+-----------------------------+

Adding to my previous comments, how would the UA find out the address of a PA that services the presentity? We can't mandate a specific naming convention for PAs in general, which is why the Request-URI is always the address of the subscribed/published resource.

Note that one valid location for a PA is in the client device. Because of the way PUBLISH and SUBSCRIBE currently work, this requires nothing special from a proxy - it simply forwards/redirects these requests to the UA like any other request for that AoR.

Cheers,
Aki

---

From: OKUMURA Shinji <[email-masked]>
Date: Tue, 20 Jan 2004 19:59:15 +0900

Hi Aki,

Thank you for your comments.

You say that R-uri is used to determine what resource the
PUBLISH is targeted for. But R-uri has the possibility to 
be rewritten by proxy.

Even if PUA sends "sip:[email-masked]",
"sip:[email-masked]" may reach to PA.

Now my questions are:

a) PUBLISH message MUST NOT pass proxy?

b) proxy MUST NOT rewrite R-uri?

   b-1. the uri MUST NOT be registered?
   b-2. Register-Contact is <sip:[email-masked];maddr=pa.example.com> ?
   b-3. original message has Route: <sip:pa.example.com;lr> ?

c) PA MUST determine the target resource ONLY by username of R-uri?

Best regards,

Shinji

[email-masked] wrote in <[email-masked]>
>It's very good that you pointed out these mistakes in the examples. I swear, 
>I've looked at them a few times before, but I guess my internal SIP parser is 
>so well built that it never gave me an error message. ;-)
>
>I'm a little reluctant to adding this. There are excellent SIP call flows 
>already documented elsewhere (see RFC 3665, e.g., Section 3.2), and to this 
>particular method, adding a proxy in between the PUA and the PA works no  
>different from how this works for other methods (MESSAGE, INVITE). I.e., the 
>proxy rewriting the Request-URI follows the same logic as the other methods 
>would.
>
>However, since this issue has come up before, it might be a good idea to add a 
>proxy between the PUA and PA. Any other views on this? 
>
>Note that the Request-URI needs to be 'sip:[email-masked]'. PUBLISH is 
>specifically addressed to the resource, not the presence agent.
>  
> >         M2:
>The proxy would rewrite the Request-URI, but probably to something like 
>'sip:[email-masked]'. Note that when the request is received by the 
>PA/ESC, it specifically uses the Request-URI to determine what resource the 
>PUBLISH is targeted for. This is identical to a SUBSCRIBE.  
>
> >         M3:
> >             SIP/2.0 200 OK
>This is actually how PUBLISH used to work. But having the Request-URI point to 
>a PA requires special handling from the proxies and/or a specific naming 
>convention for PAs to be able to route the request. So we decided to reject the 
>REGISTER-like operation (determining the resource by the To-field) in favor of 
>the SUBSCRIBE-like behavior the draft currently has.
>
> > 
>Adding to my previous comments, how would the UA find out the address of a PA 
>that services the presentity? We can't mandate a specific naming convention for 
>PAs in general, which is why the Request-URI is always the address of the 
>subscribed/published resource.
>
>Note that one valid location for a PA is in the client device. Because of the 
>way PUBLISH and SUBSCRIBE currently work, this requires nothing special from a 
>proxy - it simply forwards/redirects these requests to the UA like any other 
>request for that AoR.
>
>Cheers,
>Aki
>
> > 
> > Regards,
> > shinji
> >

---

From: "Niemi Aki (Nokia-M/Helsinki)" <[email-masked]>
Date: Tue, 20 Jan 2004 16:00:53 +0200

Hi Shinji,

The key thing here is that there is nothing special about how a proxy 
determines the next hop target for PUBLISH requests. There are several 
options to doing this:

	- A domain has configured all PUBLISH requests to be
	  forwarded to a PA
	- A PA has explicitly added an address binding for that
	  AOR, possibly using the SIP registration
	- All requests get forwarded to a UA (no matter what the
	  method is) that has an active address binding in the
	  domain's location service for that AoR
	- The request gets targeted using some other, undefined
	  logic

The administrator for that domain just needs to pick a way of doing 
this. So when proxying a PUBLISH request, Section 16 in RFC 3261 applies 
in full.

Cheers,
Aki

ext OKUMURA Shinji wrote:

> You say that R-uri is used to determine what resource the PUBLISH is
> targeted for. But R-uri has the possibility to be rewritten by proxy.
> 
> 
> b-1. the uri MUST NOT be registered? b-2. Register-Contact is
> <sip:[email-masked];maddr=pa.example.com> ? b-3. original
> message has Route: <sip:pa.example.com;lr> ?
> 
> [email-masked] wrote in
> <[email-masked]>
> 
>> Hi Shinji,
>> 
>>> -----Original Message----- From: ext OKUMURA Shinji
>>> [mailto:[email-masked]] Sent: 15 January, 2004 12:49 To:
>>> Rohan Mahy Cc: [email-masked]; Dean Willis; Niemi Aki
>>> (Nokia-M/Helsinki) Subject: Re: [Sip] WGLC for PUBLISH
>>> 
>>> 
>>> Hi,
>>> 
>>> In M1,   Contact: <sip:[email-masked]> should be rewritten
>>> as Contact: <sip:[email-masked]>
>>> 
>>> 
>>> In M2,   Contact: <sip:[email-masked]> should be Contact:
>>> <sip:pa.example.com>
>>> 
>>> In M3,    NOTIFY sip:[email-masked] SIP/2.0 Via:
>>> SIP/2.0/UDP pa.example.com;branch=z9hG4bK8sdf2 To:
>>> <sip:[email-masked]>;tag=12341234 From:
>>> <sip:[email-masked]>;tag=abcd1234 Call-ID:
>>> [email-masked] CSeq: 1 NOTIFY ....
>>> 
>>> should be
>>> 
>>> NOTIFY sip:[email-masked] SIP/2.0 Via: SIP/2.0/UDP
>>> pa.example.com;branch=z9hG4bK8sdf2 To:
>>> <sip:[email-masked]>;tag=12341234 From:
>>> <sip:[email-masked]>;tag=abcd1234 Call-ID:
>>> [email-masked] CSeq: 1 NOTIFY Contact: <sip:pa.example.com> 
>>> ....
>> 
>> All true. Also, since the Via contains a domain name, I will add a
>> "received" param to the Via in the response.
>> 
>> It's very good that you pointed out these mistakes in the examples.
>> I swear, I've looked at them a few times before, but I guess my
>> internal SIP parser is so well built that it never gave me an error
>> message. ;-)
>> 
>> I'm a little reluctant to adding this. There are excellent SIP call
>> flows already documented elsewhere (see RFC 3665, e.g., Section
>> 3.2), and to this particular method, adding a proxy in between the
>> PUA and the PA works no different from how this works for other
>> methods (MESSAGE, INVITE). I.e., the proxy rewriting the
>> Request-URI follows the same logic as the other methods would.
>> 
>> However, since this issue has come up before, it might be a good
>> idea to add a proxy between the PUA and PA. Any other views on
>> this?
>> 
>> 
>>> PUA <-----> proxy <------> PA |            |            | | M1
>>> PUBLISH |            | |----------->| M2 PUBLISH | |
>>> |----------->| |            | M3 200 OK  | | M4 200 OK
>>> |<-----------| |<-----------|            |
>>> 
>>> M1: PUBLISH sip:[email-masked] SIP/2.0 Via: SIP/2.0/UDP
>>> pua.example.com;branch=z9hG4bK652hsge From:
>>> <sip:[email-masked]>;tag=1234wxyz To:
>>> <pres:[email-masked]> Call-ID: [email-masked] 
>>> CSeq: 1 PUBLISH Max-Forwards: 70 Expires: 3600 Event: presence 
>>> Content-Type: application/pidf+xml Content-Length: ...
>> 
>> Note that the Request-URI needs to be 'sip:[email-masked]'.
>> PUBLISH is specifically addressed to the resource, not the presence
>> agent.
>> 
>> 
>>> M2: PUBLISH sip:pa.example.com SIP/2.0 Via: SIP/2.0/UDP
>>> proxy.example.com;branch=z9hG4bKpx123 Via: SIP/2.0/UDP
>>> pua.example.com;branch=z9hG4bK652hsge From:
>>> <sip:[email-masked]>;tag=1234wxyz To:
>>> <pres:[email-masked]> Call-ID: [email-masked] 
>>> CSeq: 1 PUBLISH Max-Forwards: 70 Expires: 3600 Event: presence 
>>> Content-Type: application/pidf+xml Content-Length: ...
>> 
>> The proxy would rewrite the Request-URI, but probably to something
>> like 'sip:[email-masked]'. Note that when the request is
>> received by the PA/ESC, it specifically uses the Request-URI to
>> determine what resource the PUBLISH is targeted for. This is
>> identical to a SUBSCRIBE.
>> 
>> 
>>> M3: SIP/2.0 200 OK Via: SIP/2.0/UDP
>>> proxy.example.com;branch=z9hG4bKpx123 Via: SIP/2.0/UDP
>>> pua.example.com;branch=z9hG4bK652hsge From:
>>> <sip:[email-masked]>;tag=1234wxyz To:
>>> <pres:[email-masked]>;tag=1a2b3c4d Call-ID:
>>> [email-masked] CSeq: 1 PUBLISH SIP-ETag: dx200xyz 
>>> Expires: 1800 Content-Length: 0
>>> 
>>> M4: SIP/2.0 200 OK Via: SIP/2.0/UDP
>>> pua.example.com;branch=z9hG4bK652hsge From:
>>> <sip:[email-masked]>;tag=1234wxyz To:
>>> <pres:[email-masked]>;tag=1a2b3c4d Call-ID:
>>> [email-masked] CSeq: 1 PUBLISH SIP-ETag: dx200xyz 
>>> Expires: 1800 Content-Length: 0
>>> 
>>> [3] It could be better if the "Request-URI" is used as the
>>> message's target address and the 'Presence Resource' is specified
>>>  using "To" header.
>>> 
>> This is actually how PUBLISH used to work. But having the
>> Request-URI point to a PA requires special handling from the
>> proxies and/or a specific naming convention for PAs to be able to
>> route the request. So we decided to reject the REGISTER-like
>> operation (determining the resource by the To-field) in favor of 
>>> |3.1.5. Proxy SUBSCRIBE Behavior |  Proxies need no additional
>>> behavior beyond that described in SIP [1] |  to support
>>> SUBSCRIBE.
>>> 
>>> [4] For expressing 'Presence Resource', the 
>>> pres-URI(draft-ietf-impp-pres-04) would be better than that of
>>> the sip-URI.
>>> 
>>> Finally, when [3] & [4] are considered together, the various
>>> usages of URI can be expressed as listed below.
>>> 
>>> ------------+-----------------------------+ |            |
>>> PUBLISH                     | SUBSCRIBE | NOTIFY
>>> | +------------+-----------------------------+----------------- 
>>> ------------+-----------------------------+ |Request-URI | URI of
>>> PA                   | URI of PA | Contact-URI of SUBSCRIBE    | 
>>> ------------+-----------------------------+ |To-URI      | URI of
>>> presence resource    | URI of presence resource    | From-URI of
>>> SUBSCRIBE       | |            | pres:[email-masked] | 
>>> ------------+-----------------------------+ |From-URI    | URI of
>>> presentity           | URI of watcher | To-URI of SUBSCRIBE
>>> | |            | sip:[email-masked]  | 
>> Adding to my previous comments, how would the UA find out the
>> address of a PA that services the presentity? We can't mandate a
>> specific naming convention for PAs in general, which is why the
>> Request-URI is always the address of the subscribed/published
>> resource.
>> 
>> Note that one valid location for a PA is in the client device.
>> Because of the way PUBLISH and SUBSCRIBE currently work, this
>> requires nothing special from a proxy - it simply
>> forwards/redirects these requests to the UA like any other request
>> for that AoR.
>> 
>> Cheers, Aki
>> 
>> 
>>> Regards, shinji
>>> 
>>> Rohan Mahy wrote in
>>> <[email-masked]>
>>> 
>>>> Hi,
>>>> 
>>>> thanks, -rohan

---

From: OKUMURA Shinji <[email-masked]>
Date: Wed, 21 Jan 2004 13:01:53 +0900

Hi Aki, 

Thank you for your quick response. 

Now I understand.

The important point I think is that PA determines the target resource 
using the r-uri of PUBLISH message "received by PA". 

In other words, the r-uri sending by PUA and the one received by PA
need not to be same. 

Am I right or missing something? 
 
Cheers,

Shinji

---

From: "Niemi Aki (Nokia-M/Helsinki)" <[email-masked]>
Date: Wed, 21 Jan 2004 14:36:33 +0200

Hi Shinji,

Exactly, that's the way it goes.

Cheers,
Aki