Hi Keith, >I notice that the current document does define the validity of these elements for REG, but leaves the section describing the use empty. If the purpose of inclusion was to somehow register this things in >the registrar against the contact, surely this should be left to feature tags, as I think has already been suggested on the list. Or was there some other purpose? If not, I would suggest removal.
As indicated earlier, being able to register the supported packages, and use them for forking, would be very useful, and I think that is the intention of the text. Yes, maybe we need to define a feature tag, or feature tags. The question is whether we would need a single feature tag which can list all supported info packages, or a feature tag for each package (in which case each info package definition would have to specify a feature tag value). The advantage of having separate feature tags is that it gives you much more flexibility. >The other method that crossed my mind was OPTIONS. Should OPTIONS provide a mechanism of identifying what the entity at the Request-URI supports, in the same manner as it does for SDP and option tags, or >should be ignore this possibility on the grounds of simplicity. >Thoughts? I see no reasons why the Info headers couldn't be included in OPTIONS, so I think that should be fixed. Regards, Christer _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
