Re: editorial comments to routing document
Steve Kille <S.Kille@isode.com> Mon, 04 July 1994 12:11 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01250; 4 Jul 94 8:11 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01246; 4 Jul 94 8:11 EDT
Received: from mercury91.udev.cdc.com by CNRI.Reston.VA.US id aa03728; 4 Jul 94 8:11 EDT
Received: by mercury.udev.cdc.com; Mon, 4 Jul 94 06:56:10 -0500
X-From: S.Kille@isode.com Mon Jul 4 06:56 CDT 1994
Received: from zeus.cdc.com by mercury.udev.cdc.com; Mon, 4 Jul 94 06:56:09 -0500
Received: from glengoyne.isode.com by zeus.cdc.com; Mon, 4 Jul 94 06:56:05 -0500
To: Allan Cargille <cargille@cs.wisc.edu>
cc: mhs-ds@mercury.udev.cdc.com
Subject: Re: editorial comments to routing document
Phone: +44-81-332-9091
In-reply-to: Your message of Thu, 07 Apr 1994 11:56:50 -0500. <9404071656.AA20097@calypso.cs.wisc.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8424.773322972.1@glengoyne.isode.com>
Date: Mon, 04 Jul 1994 12:56:24 +0100
Message-ID: <8427.773322984@glengoyne.isode.com>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Steve Kille <S.Kille@isode.com>
Allan, I'd like to thank you for this comprehensive input. The document will benefit greatly from your efforts. I have been able to handle most of your input directly, but there are a couple of points that I'd like to share with the list. 22.1 - you agree that this is useful, but note that it goes beyond X.400, and may be argued to be non-conformant. I view that we should gain experience with this function. If it is found the be useful, and this utility cannot be handled within X.400, then we should raise detailed issues with the X.400 standards people. I think that submitting a defect report is premature. 22.2 - underspecified O/R addresses. I have mandated an approach to be followed, IN THE CONTEXT OF X.400, whereas you suggest that it should be optional. I have tightened the text in this area, and invite you to review it. I do not believe that this sort of thing should be left to implementor choice. Supplementary info bounds. This is set to 256. You say that Kevin says that it is 128 in 84. While 84 does not specify lengths, a number of profiles do. Is there an issue which needs to be addressed in this document (as opposed to a downgrading spec?) Steve
- editorial comments to routing document Allan Cargille
- Re: editorial comments to routing document Steve Kille
- Reply to editorial comments to routing document Kevin E. Jordan
- Reply to editorial comments to routing document Kevin E. Jordan