Subject: [Simple] NOTIFY without message-body

From: Pekka Pessi <[email-masked]>
Date: Wed, 15 Sep 2004 18:53:04 +0300

Hello all SUBSCRIBE/NOTIFY lawyers,

The RFC 3265 says that the NOTIFY sent in confirmation of a
subscription MAY contain and empty or neutral body if the resource
has no meaningful state. RFC 3856 (and partial-notify) also mention
that a NOTIFY MAY be sent without a body. 

Now, what a subscriber does when he receives a NOTIFY with
Content-Length: 0 in the middle of a subscription? Can he conclude
that the event state is not meaningful anymore and ditch the state
from previous NOTIFY? Or can he do that only if there is
a Content-Type header in the NOTIFY?

--Pekka

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 15 Sep 2004 13:00:07 -0400

If the Content-TYpe is present, and the length is zero, it means that 
the body is of that type but has no information in it. I'll note that 
this is probably illegal, since a PIDF document is supposed to be 
valid/well-formed, and null content doesnt have that property.

If the Content-Type is absent and the length is zero, it means that 
there is no body, and the state of the watched resource is unchanged.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Fatih "Ey�p" NAR <[email-masked]>
Date: Wed, 15 Sep 2004 10:59:38 -0700 (PDT)

does this comment only applicable to Notify or for all
content embedded SIP-Requests? (ex:Register)

ex:(as far as I saw/understood)
if REGISTER with content/xml with content.length=0 is
overriding the previously received/sent Register with
content/xml with full body(i.e content.length>0) ,
which is legal .

--- Jonathan Rosenberg <[email-masked]>

> > a Content-Type header in the NOTIFY?

		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 15 Sep 2004 23:46:54 -0400

It would be applicable to other requests where there is a 
content/non-content choice that is meaningful. REGISTER is not a good 
example since we don't actually define the meaning of content there. 
UPDATE is a better example. It can have an SDP offer (CT: 
application/sdp, CL: non-zero) or it can have none (no CT, CL: 0). There 
also, a CT of application/sdp and a CL of zero is not valid, since a 
null document would not be valid SDP.

MESSAGE is another example. There, there can be a text message (CT: 
text/plain, CL: non-zero), no content at all (no CT, CL: 0), or a 
message with content that is "null" (CT: text/plain, CL: 0).

-Jonathan R.

Fatih Eyüp NAR wrote:

>>>The RFC 3265 says that the NOTIFY sent in
>>
>>confirmation of a
>>
>>>subscription MAY contain and empty or neutral body
>>
>>if the resource
>>
>>>has no meaningful state. RFC 3856 (and
>>
>>partial-notify) also mention
>>
>>>Now, what a subscriber does when he receives a
>>
>>NOTIFY with
>>
>>>Content-Length: 0 in the middle of a subscription?
>>
>>Can he conclude
>>
>>>that the event state is not meaningful anymore and
>>
>>ditch the state
>>
>>>from previous NOTIFY? Or can he do that only if
>>
>>there is
>>

---

From: Pekka Pessi <[email-masked]>
Date: Thu, 16 Sep 2004 13:45:58 +0300

Hi Jonathan,

>If the Content-TYpe is present, and the length is zero, it means that the
>body is of that type but has no information in it. I'll note that this is
>probably illegal, since a PIDF document is supposed to be valid/well-formed,
>and null content doesnt have that property.

>If the Content-Type is absent and the length is zero, it means that there is
>no body, and the state of the watched resource is unchanged.

OK. So, if I understood the specs correctly, the notifier can send
a NOTIFY without body at any time. 

Now, let's assume that the subscriber is out of sync with, for
instance, partial presence notifications. How it can ask the
server to send a NOTIFY with full state? It could terminate and
recreate the subscription, but that potentially involve a large
number of message.

--Pekka

>> that a NOTIFY MAY be sent without a body. Now, what a subscriber does when
>> he receives a NOTIFY with

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Sep 2004 19:55:50 -0400

Jonathan,

What you suggest is plausible, but I don't recall ever seeing anything 
written that discusses the meaning of a Content-Type with an empty body.

That logic would imply that there is (conceptually) a special content 
type for which an empty body is valid and a non-empty body is not, and 
that this is a default content-type when the body is empty.

I believe I have seen stacks that considered the presence of a content 
type header invalid if there is no body. At the least there ought to be 
something that says this is valid usage.

	Paul

Jonathan Rosenberg wrote:
>>> If the Content-TYpe is present, and the length is
>>> zero, it means that the body is of that type but has no information in
>>> it. I'll note that this is probably illegal, since a PIDF document is
>>> supposed to be valid/well-formed, and null content doesnt have that
>>> property.
>>>
>>> If the Content-Type is absent and the length is
>>> zero, it means that there is no body, and the state of the watched
>>> resource is unchanged.
>>>
>>> -Jonathan R.
>>>
>>> Pekka Pessi wrote:
>>>
>>>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 20 Sep 2004 00:58:38 -0400

Pekka Pessi wrote:

> Hi Jonathan,
> 
> 
>> If the Content-TYpe is present, and the length is zero, it means
>> that the body is of that type but has no information in it. I'll
>> note that this is probably illegal, since a PIDF document is
> OK. So, if I understood the specs correctly, the notifier can send a
> NOTIFY without body at any time.

Right.

> instance, partial presence notifications. How it can ask the server
> to send a NOTIFY with full state? It could terminate and recreate the
> subscription, but that potentially involve a large number of message.

A subscribe refresh is supposed to trigger a state update, for most 
packages.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 20 Sep 2004 01:03:59 -0400

> that this is a default content-type when the body is empty.

I don't see how you would come to this conclusion. There is no default 
value for Content-Type.

> something that says this is valid usage.

It is written, in RFC 3261, section 20.15:

20.15 Content-Type

    The Content-Type header field indicates the media type of the
    message-body sent to the recipient.  The "media-type" element is
    defined in [H3.7].  The Content-Type header field MUST be present if
    the body is not empty.  If the body is empty, and a Content-Type
    header field is present, it indicates that the body of the specific
    type has zero length (for example, an empty audio file).

-Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Sep 2004 10:27:08 -0400

> I don't see how you would come to this conclusion. There is no default 

This is probably just splitting hairs, and not worth discussion.

>> type header invalid if there is no body. At the least there ought to 
>> be something that says this is valid usage.
> 
> 

OK - I didn't remember that was there.

	Paul

---

From: Alex Audu <[email-masked]>
Date: Tue, 21 Sep 2004 10:41:04 -0500

Hi Jonathan, Paul,

According to the following, rfc 2045 defines a default content type of  
text/plain; charset=us-ascii

Cheers,
Alex.

===========================================================================
RFC 2045                Internet Message Bodies            November 1996

5.2.  Content-Type Defaults

   Default RFC 822 messages without a MIME Content-Type header are taken
   by this protocol to be plain text in the US-ASCII character set,
   which can be explicitly specified as:

     Content-type: text/plain; charset=us-ascii

   This default is assumed if no Content-Type header field is specified.
   It is also recommend that this default be assumed when a
   syntactically invalid Content-Type header field is encountered. In
   the presence of a MIME-Version header field and the absence of any
   Content-Type header field, a receiving User Agent can also assume
   that plain US-ASCII text was the sender's intent.  Plain US-ASCII
   text may still be assumed in the absence of a MIME-Version or the
   presence of an syntactically invalid Content-Type header field, but
   the sender's intent might have been otherwise.

====================================================================

Paul Kyzivat wrote:

>>> What you suggest is plausible, but I don't recall ever seeing 
>>> anything written that discusses the meaning of a Content-Type with 
>>> an empty body.
>>>
>>> That logic would imply that there is (conceptually) a special 
>>> content type for which an empty body is valid and a non-empty body 
>>> is not, and that this is a default content-type when the body is empty.
>>
>>
>> I don't see how you would come to this conclusion. There is no 
>> default value for Content-Type.
>
>
>>> I believe I have seen stacks that considered the presence of a 
>>> content type header invalid if there is no body. At the least there 
>>> ought to be something that says this is valid usage.
>>
>>
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Sep 2004 14:23:25 -0400

> text/plain; charset=us-ascii

Well, if we assume the same applies to SIP (not necessarily the case, 
but plausible), then in the absence of any Content- headers:

- the Content-Type would default to 'text/plain'
- the Content-Disposition would default to 'render'

So it will amount to a request to render a null string of text.

If this is applied to NOTIFY, it *could* result in a 415 response.

Seems like the right thing to do would be for each event type where this 
can happen to define the null body that is meaningful. Either explicitly 
note a null body of type text/plain, or else define the relevant mime 
type to include a null body.

	Paul