Subject: [Crisp] Last Minute Last Call Comments on lwz-06

From: Marcos Sanz/Denic <[email-masked]>
Date: Mon, 28 Aug 2006 19:16:49 +0200

Dear all,

There were some comments during Last Call on the draft in the general list 
and my guess is that maybe Andy is going to do a new version with some 
additional text in the security/MTU/congestion/retry issues. Besides that, 
I think that the document is in good form and my company has implemented 
it without any problems. Here come some nitpicking remarks:

*Section 1: s/descretion/discretion/
*Section 2: s/numberic/numeric/
*Section 2: s/left most/leftmost/ (so does the RFC editor like nowadays)
*Section 3: s/prepared to accepted/prepared to accept/
*Section 3: "clients MUST NOT send packets larger than 4000 octets". 
Servers must not either.
*Section 3.1.1: s/lenght/length/
*Section 3.1.1: s/the total length of the UDP packet/the total length in 
octets of the UDP packet/
*Section 3.1.1: s/the length of the authority field/the length in octets 
of the authority field/
*Section 3.1.2: s/3 octets and/3 octets in length and/
*Section 3.1.2, 1st bullet: How realistic is that the transaction ID in 
the request could not be read due to truncation? The transaction ID 
occupies the bits in the positions 73rd to 88th!
*Section 3.1.2, 2nd bullet: s/MUST us/MUST use/
*Section 3.1.3: "The bits of the payload header are ordered..." I think 
this sentence is redundant, because terminology has been already 
introduced extensively in section 2.
*Section 3.1.3: s/bits 3/bit 3/
*Section 3.1.3: For the sake of completeness, add "If 0, the payload is 
not compressed".
*Section 3.1.5: s/comformant/conformant/
*Section 3.1.5: "...and use the <versions> element as the root element." 
That's true except for "vi" queries.
*Section 3.1.5, <dataModel>: s/IRIS registries/IRIS registry types/
*Section 3.1.5: s/PT flag/PT field/
*Section 3.1.5: One cause for sending 'vi' type is "The IRIS-based XML 
payload does not match a version the server supports." My gut feeling is 
that this shouldn't be dealt with at the transport level (neither XPC nor 
BEEP do that for instance!) and would drop this reason, but I don't have 
strong feelings about this.
*Section 3.1.7: s/interpretting/interpreting/
*Section 7.1.1: s/RFC2396/RFC3986/
*Appendix A: The same as with XPC, I'd drop all schemaLocation hints and 
temporaryReference attributes from the clients requests.
*Appendix A: s/verion/version/

Best regards
Marcos

_______________________________________________
Crisp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/crisp

---

From: Andrew Newton <[email-masked]>
Date: Mon, 28 Aug 2006 13:52:46 -0400

Marcos Sanz/Denic wrote:
> additional text in the security/MTU/congestion/retry issues. 

I was originally thinking about RFC Editor notes, but with the addition of 
this list, that might be too much.

> occupies the bits in the positions 73rd to 88th!

Highly unlikely, but odds things happen and this is a well described 
explanation of what to do when this particular odd thing happens.

> introduced extensively in section 2.

Yeah, but we kept discussing this on the list over and over again that I 
felt it was necessary to drive the point home.

> That's true except for "vi" queries.

Hmmm... that section could be better explained with regard to this matter. 
On a request, types of 'vi' do not contain anything, but on a response they 
contain the <versions> xml.

> strong feelings about this.

Actually, I believe both do (though the BEEP error code may be a little 
difficult to guess what it should be).

Thanks for the comments.

-andy

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Tue, 29 Aug 2006 11:46:39 +0200

Andy,

> this list, that might be too much.

Well, it's not too much for me. But I don't know who decides where the 
threshold for addition for notes is.

> explanation of what to do when this particular odd thing happens.

Fine by me. It was more like a sanity check, to see if I was overseeing 
something.

> contain the <versions> xml.

Exactly.

> difficult to guess what it should be).

Really?

As we seemed to agree in
http://www1.ietf.org/mail-archive/web/crisp/current/msg00413.html
the BEEP reply codes 500/501 refer to the XML of the transport protocol 
itself, not to the XML of the payload.

And the only usage for 'vi' type in XPC that I have been able to find is

   Clients MAY send a block with this type of chunk to a server.  These
   chunks SHOULD be zero length and servers MUST ignore any data in
   them.  When a server receives a chunk of this type, it MUST respond
   with a chunk of this type.  This interchange allows a client to query
   the version information of a server.

which doesn't mean that 'vi' must be sent by the server when the 
IRIS-based XML payload does not match a version the server supports.

Best
Marcos

---

From: Andrew Newton <[email-masked]>
Date: Tue, 29 Aug 2006 09:49:00 -0400

> IRIS-based XML payload does not match a version the server supports.

Your killin' me, Marcos!  :)

It would be 'oi' in both XPC and LWZ.  The difference between the mail 
message you pointed out and the issue you are talking about are:

  1) I understood what you said, I just won't do what you asked.
    - and -
  2) I don't understand what you said.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Tue, 29 Aug 2006 12:17:19 -0400

Marcos and I just had an off-line chat in hopes of coming to a clarification 
on this.  His point was that XPC and LWZ differ with regard to point 3 in 
section 3.1.5 of LWZ.  He appears to be correct about that.  I can't think 
of the reason why we put that in there, and he has suggested taking it out 
so that the behavior is more similar.  So, if nobody has objections, we'll 
yank it.

-andy