Subject: message-id attribute issues

From: Andy Bierman <[email-masked]>
Date: Mon, 19 Dec 2005 11:52:58 -0800

Hi,

I just noticed a couple more details in the schema in prot-10:

  - the message-id is mandatory to use in the <rpc> element
    but optional in the <rpc-reply> element.  It should also be
    mandatory in the <rpc-reply>, since all attributes passed in
    the <rpc> have to be copied in the <rpc-reply>.

 - the data type for this attribute is xsd:string
   This means everyone has to accept a message-id size of 65535 octets.
   That is a bit excessive IMO.
   Can we limit this mandatory attribute to a reasonable size, like 255?

thanks,
Andy

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: "Rob Enns" <[email-masked]>
Date: Thu, 22 Dec 2005 12:47:51 -0800

> What about 4095 octets?   That's 20 times
> bigger than any message-id I would have thought we needed.
> Big enough to be useful, small enough to be mandatory-to-accept.
> 
> I realize that this whole issue is sort of
> covered by the max-message-size issue.
> After all, that is the real limit here that matters.
> 
> I understand that 4095 is just an arbitrary a limit as 65535.
> However, we envision this field being around 16 bytes in
> actual use.  IMO, if we come up with new semantics over
> time, then we add an additional parameter with an appropriate
> data type at that time.
> 
> I want to make sure that manager application developers
> can reasonably expect to code to the limits in the standard
> and have agents accept the request.
> 
> IMO this is different than the size of the <config> element that
> obviously grows in proportion to the size of the device.

4095 bytes seems plenty large, but as you say it's still arbitrary.
If you really think message-id should be capped, I'm fine with this
value. 
Any other opinions out there?

Rob