On ti, 2008-03-04 at 12:55 -0800, ext Eric Rescorla wrote:
> At Tue, 04 Mar 2008 22:44:01 +0200,
> Aki Niemi wrote:
> >
> >
> > On ti, 2008-03-04 at 12:20 -0800, ext Eric Rescorla wrote:
> > > > Then I'd appreciate any suggestion to make it clearer.
> > >
> > > Explicitly state that in the case I described that it's permissible
> > > to deliver the same Etag in the first and third versions.
> >
> > Something like in S 5.3:
> >
> > The subscriber MUST be
> > prepared to receive a NOTIFY with any entity-tag value, including a
> > value that matches any previous value that the subscriber might have
> > seen.
>
> Yeah, I don't think that's at all clear. For all I know, that
> could mean the server is running in a VM and was rolled back.
It could also mean the Lakers just fired Koby in order to make room in
their salary cap to hire me as their point guard.
It just doesn't matter; the subscriber is not supposed to even attempt
to infer such a meaning from the entity-tag value.
Perhaps you're looking for something like this:
The entity-tag is an opaque token to the subscriber. The
subscriber MUST NOT attempt to infer any meaning from the value
beyond a simple reference, or assume a specific formatting. The
relationship between the current entity-tag and any future or
past entity-tags is undefined.
> > > > > Given that when I asked this question I got two different answers from
> > > > > Dale and Dean, I submit that the draft might be improved by directly
> > > > > addressing this point. Note that I don't care about the resolution,
> > > > > but I do care that the draft be unambiguous.
> > > >
> > > > Can you point out the unambiguity?
> > >
> > > I think Dean did a good job with that, namely that one could
> > > view "versions" as instances, and that two versions with
> > > different content are different versions and so need
> > > different Etags.
> >
> > That's exactly what the model already says.
>
> Sorry, that should have said "the same content".
>
>
> > Your original question was whether "A" and "A" could have the same etag.
> > According to the draft, yes.
>
> But I don't think that's clear as you seem to think it is.
>
>
> > ALso according to the draft, if you decided
> > to give them a different etag, fine. Nothing would break. Everything
> > would work exactly the same way.
> >
> > I'm apparently missing what practical problem the draft is not
> > addressing.
>
> I'm not saying there's a practical problem the draft is not addressing.
> I'm saying the draft isn't unambiguous and it's simple to make it
> so.
Therein lies the problem. To make it unambiguous would mean we either
mandate different entity-tags for identical entities, or we mandate
identical entity-tags for identical entities.
But currently this is *intentionally* undefined. If my notifier
implements MD5 hash over the entity as the entity-tag value for event
package X, identical entities would indeed receive identical
entity-tags. That will work.
But if my notifier implements a timestamp as the entity-tag value for
event package Y, identical entities would receive different entity-tags.
That will also work.
Bottom line is, the subscriber doesn't care, and the notifier can do
what it wants. We require uniqueness of entity-tags as a friendly
suggestion not to shoot self in foot. If the notifier dishes out the
same entity-tag for different entities, it can cause the notifier to
suppress a NOTIFY that should have been sent.
If this is inline with how you think this should work, I can try to
sketch a paragraph or two into section 6.1 basically saying the above in
normative language.
Cheers,
Aki
_______________________________________________
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
