Re: clTRID element clarification

Aaron Roberts <[email protected]>
Newsgroups gmane.ietf.provreg
Message-ID <0E7B3A96BAA7334CB6D338433C5E61B93E93E6E68A@LISA.internal.domicilium.com>
> -----Original Message-----
> From: Luis Muñoz [mailto:[email protected]]
> Sent: 07 March 2012 17:11
> To: Hollenbeck, Scott
> Cc: Aaron Roberts; [email protected]
> Subject: Re: [provreg] clTRID element clarification
> 
> 
> On Mar 7, 2012, at 12:08 PM, Hollenbeck, Scott wrote:
> 
> > "MAY be used to uniquely identify the command *to the client*"
> >
> > (emphasis mine), and
> >
> > "Clients are responsible for maintaining their own transaction identifier space
> to ensure uniqueness."
> >
> > This doesn't seem ambiguous to me.
> 
> That language does not directly contradicts a server using it to provide a
> cached response to a command with the same (command, clTRID,
> arguments...) n-tuple, right?
> 

It is pretty clear that the cached response server behaviour is miles outside the definition of the clTRID.  However, all the stuff which should not be done with the clTRID, at the server end, is only covered by the implication of the statement that the clTRID "MAY be used to uniquely identify the command to the client".  One of the other registries, in their responses, said that they had seriously considered this sort of server behaviour, at points in their development.  If registries are making the decision to implement this cached response behaviour (or even thinking about it), a statement like "The server shouldn't make any assumptions about the clTRID" could stop the discussion, before it even started?

Aaron
_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.