Subject: [Sipping] PUBLISH in SIP Performance Report Event

From: Adam Roach <[email-masked]>
Date: Thu, 11 Nov 2004 12:40:33 -0600

I just want to make a quick comment on the use of PUBLISH in this
document. I think there needs to be some clarification on when this is
sent -- that is, how the UA knows that the proxy *wants* these
publication messages. From the text currently in the draft, this looks
an awful lot like using PUBLISH as an end-around sending unsolicited
NOTIFY messages by simply changing the method name. I hope that I've
misunderstood -- in which case some clarifying text might be in order;
otherwise, I'm very concerned about the precedent this document sets.

/a

_______________________________________________
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: David R Oran <[email-masked]>
Date: Thu, 11 Nov 2004 14:19:59 -0500

On Nov 11, 2004, at 1:40 PM, Adam Roach wrote:

> publication messages.
If the server (not proxy, necessarily...) doesn't want them, it can 
send an error.

> From the text currently in the draft, this looks
No you haven't fundamentally misunderstood - that's more or less what's 
going on. Just being honest here...

> otherwise, I'm very concerned about the precedent this document sets.
Could you elaborate on why you think this is a bad precedent?

The underlying motivation is so that the authorization is moved to the 
data collector rather than having the endpoint have to authorize 
subscriptions for this information.

> /a
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 11 Nov 2004 16:07:24 -0500

David R Oran wrote:

> If the server (not proxy, necessarily...) doesn't want them, it can send an error. 

Which error? Section 5 of RFC 3903 does not point out a condition which 
means,
"don't publish to this aor any more".

> Could you elaborate on why you think this is a bad precedent?

I don't follow why its a bad precedent here and not everywhere else; 
PUBLISH is fundamentally about an unsolicited push of data to a 
collector. If doing that is bad, then PUBLISH is bad.

When you use PUBLISH, you do want to be sure that it is wanted. I think 
that is generally done by end system configuration/provisioning. You 
would only PUBLISH for a particular resource for a particular event 
package if a particular flag was set to do so.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Aki Niemi <[email-masked]>
Date: Thu, 11 Nov 2004 16:52:03 -0500

Inline.

> "don't publish to this aor any more".

Perhaps there is nothing specific to PUBLISH here. So either 488 or 606 
might work?

>> No you haven't fundamentally misunderstood - that's more or less 
>> what's going on. Just being honest here...
>>

Yeah, but there is explicit text in the RFC that says it isn't a generic 
transport of arbitrary data, but of event state. However, that is 
clearly a statement that is open to interpretation.

I really can't tell whether this particular use of PUBLISH goes against 
RFC 3903. Probably not, but it is close -- the POST method really might 
be a better fit ;-)

At least the draft should really spend some more time talking about the 
specifics, like how expiration is set, or etags are used, etc. It should 
also talk about the things RFC 3903 lists in section 10. (I made this 
comment on the list a while back.).

> package if a particular flag was set to do so.

Exactly. This part is no different from, say, presence.

Cheers,
Aki

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 16 Nov 2004 02:23:10 -0500

inline.

Aki Niemi wrote:

>> Which error? Section 5 of RFC 3903 does not point out a condition 
>> which means,

I don't think so.

There is a PUBLISH-specific semantic you need here - namely, "please 
stop sending future PUBLISH requests for this resource and event package 
  until you are notified through other means that it is supported". 
PUBLISH would normally be resent periodically to refresh the soft-state, 
and you want to turn of those refreshes. No response code does that 
generally, afaik.

> clearly a statement that is open to interpretation.

If you think that the performance data is a reasonable thing to turn 
into an event package, then PUBLISH usage with it is reasonable. The 
current draft posits and event package.

-Jonathan R.

---

From: Aki Niemi <[email-masked]>
Date: Tue, 16 Nov 2004 02:44:33 -0500

Inline.

ext Jonathan Rosenberg wrote:
>> Perhaps there is nothing specific to PUBLISH here. So either 488 or 
>> 606 might work?
> 
> 
> I don't think so.
> 

The composer could return a really long Expires value. That would quench 
the refreshes for the next 100 years or so. ;)

This is one of the things lacking specification in the draft. To me, 
expiry for the reports seems meaningless, and so does refreshing them. 
Also, will they ever need to be modified or removed? I don't think so, 
but again the draft doesn't (AFAIK) talk about this.

Cheers,
Aki

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 16 Nov 2004 09:22:30 -0500

> and you want to turn of those refreshes. No response code does that 

A 603 may be appropriate.

Or how about a 480 with an extremely large (e.g. many years) Retry-After 
time? The semantics aren't quite right, but the effect should be.

I am somewhat concerned that the level of detail in our error codes may 
be too high, so that we are constantly having to assign new ones from a 
limited namespace.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Thu, 18 Nov 2004 18:16:18 -0600

Paul Kyzivat wrote:

> Or how about a 480 with an extremely large (e.g. many years) 
> Retry-After time? The semantics aren't quite right, but the effect 
> should be.
>
> I am somewhat concerned that the level of detail in our error codes 
> may be too high, so that we are constantly having to assign new ones 
> from a limited namespace.
>
Aren't we saying "I am disallowing your PUBLISH request at this time. 
Don't bother me again unless you have reason to think the situation has 
changed."

How is that different from 405 "The method specified in the Request-Line 
is understood, but not allowed for the address identified by the 
Request-URI.".

--
Dean