Hi Jonathan, There's a more substantial issue you raised which I'll cover in a separate email. I think what you suggest makes sense, but requires a bit of redesign. What I will do is submit the working version I have ready. At this point there's quite a backlog of fixes so it makes sense to get that out now. Then we can address the redesign issue.
ext Jonathan Rosenberg wrote: >> The entity-tag MUST be unique across all versions of all entities for >> a resource. >> >> I think we should also add "...and event package" just to be clear. > > I'm not sure what that means. You mean, if the same object is delivered > in multiple event packages? When does that happen? I mean that entity-tags for presence can collide with entity-tags for the conference package. I think it makes sense to include the Event header field as being part of the entity. >> I think we should also add that the subscriber should never assume >> that the entity-tags are shared between notification and, say, SIP >> event publication or HTTP. > > Right, that would be a good clarification. > > The other issue is you need to be clear about what you mean by > 'resource' in your text above. For example if two SIP URI are different > but happen to resolve to the same user, is that the same resource and > would the etags be the same? (I think no). I have put in quite a bit of text around this, so let's defer this to when I get the new version out. I think this is now covered, and that there isn't a problem even if the entity-tags collide for notifications in subscriptions that were made to a different URI. <snip /> >> I can add text to the numbered lists of 4.x sections about storing >> the entity tags. The very last bullets of each of 4.x sections do >> talk about what the subscriber is to do with the 204. Should there be >> a sub-section in section 4 that has normative text on these though? > > Yes. Generally the right structure for extensions is something like: > > UA Behavior > > Sending Requests > > > Processing Responses > > > and you are mostly covering the sending of requests. This is fixed in the upcoming version. Cheers, Aki _______________________________________________ Sip mailing list https://www1.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
