Subject: [Sip] draft-ietf-sip-refer-02.txt clarification

From: Vijay Gurbani <[email-masked]>
Date: Thu, 21 Mar 2002 13:18:13 -0600

Robert:

Going through draft-ietf-sip-refer-02.txt, I note that sending a NOTIFY to 
REFER is a SHOULD strength.  Any reason why not a MUST, since notification
appears to be an integral part of the dialog (and the service) since it 
passes information on the result of the subsequent INVITE.

Also, in section 3.5.3.2 you say that "Each NOTIFY MUST contain a body of type
"message/sipfrag" (see IANA)."  I interpret "see IANA" to mean see Section 5
(IANA Considerations) for more information about message/sipfrag
MIME type.  But there isn't any information on it in Section 5.

Thanks,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Internet Software and eServices Group 
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216   Fax: +1 630 713 0184

_______________________________________________
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: Robert Sparks <[email-masked]>
Date: 21 Mar 2002 14:37:02 -0600

> passes information on the result of the subsequent INVITE.

This was heavily debated when we shifted to the
implicit subscription model. The consensus landed on SHOULD strength
because there were people who were not interested in the ability to
transmit the result and were not willing to pay the overhead of the
NOTIFY transaction.

> MIME type.  But there isn't any information on it in Section 5.

No, it really meant see IANA. That's where you would go to get
information on registered mime types. -02 was written under the
expectation that the registration described in sip-mimetypes would
have already taken place.

Since message/sip was defined in bis, message/sipfrag will probably
be pulled back into the next iteration of REFER.

RjS