[Sipping] Re: draft-ietf-sipping-uri-list-subscribe-02.txt

[Paul Kyzivat <[e-mail]>]

Section 6 says:

    A resource list server receiving a subsequent SUBSCRIBE request with
    a resource-list body, following standard SIP procedures, rejects it
    with a 415 (Unsupported Media Type) response.

This seems to be stretching the meaning of 415. With a 415 you are 
supposed to list the media types that you support. I don't think the 
server can honestly report that it doesn't support the media type - it 
does, but just not in this context.

The text tries to explain its way out of this with the following:

       Note that a difference between an initial SUBSCRIBE request and
       subsequent ones is that while the initial request is sent to the
       public URI of the resource list, subsequent ones are sent to the
       URI provided by the server when the dialog was established.
       Therefore, from the client's point of view, the resource
       identified by the former URI supports recipient-list bodies while
       the resource identified by the latter does not support them.

But this doesn't really hold water. There is no guarantee that the 
initial subscribe request is sent to a different address than the 
resubscribe. (It is entirely possible that the watcher had the contact 
address at the time of the initial subscription. And in any case the 
entity the subscription is with is determined by the response to the 
initial subscribe.

With the proposed new Accept-Disposition header, I suppose it could 
report that it doesn't support "recipient-list" disposition. But that 
suffers from the same problem - the lack of support is contextual.

As it stands, it would be reasonable for the watcher to conclude that 
this peer no longer supports this feature.

I think we need a new way to reflect that something isn't accepted for 
contextual reasons. Perhaps this could be handled with a Reason code in 
addition to the 415.

Or - the scope of Accept-* headers has never been specified. We could 
clarify some relationship between this and dialogs, though that would 
cause problems with its use outside dialogs, such as in OPTIONS.

	Paul

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