Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context S specifications

From: "Gary Kenward" <[email-masked]>
Date: Thu, 8 Aug 2002 17:57:01 -0400

Madjid:

 I snip because the back and forth replies become long, and the email
rejects messages over 40K (which is not as big as it might seem).

 The text you quote does not address my concern. James used the particular
phrase "standard option format" in a paragraph discussing context transport,
not type codes. It is possible I misinterpreted his intent, but that is
why I asked the question.

 Even so, I would question the rationale of standardizing the mapping 
of type codes into option format fields of specific transport protocols.
It implies that each transport protocol could have different mappings. 
I see no advantage, and much risk in such an approach.

Gary

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
> Sent: August 8, 2002 16:57
> To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri Madjid-MNAKHJI1; 'James
> Kempf'; [email-masked]
> Subject: RE: [Seamoby] New Section 5.8 - Requirements on 
> Feature Context
> S pecifications
> 
> 
> Gary,
> 
> I am sorry, I think you took the "context" out of the 
> discussion by snipping
> the rest of the comments :)
> The following text suggested by James captures the issue:
> 
> Madjid
> 
> > 5.8.1 A feature context specification MUST contain an IANA 
> assigned type
> code
> > for the particular feature context. If an experimental 
> feature context
> protocol
> > is being developed, a type code from the context transfer protocol's
> > experimental range SHOULD be used. The type code is used in 
> the context
> transfer
> > container to identify the feature context.
> 
> 
> 
> -----Original Message-----
> From: Gary Kenward [mailto:[email-masked]]
> Sent: Tuesday, August 06, 2002 12:32 PM
> To: 'Nakhjiri Madjid-MNAKHJI1'; 'James Kempf'; [email-masked]
> Subject: RE: [Seamoby] New Section 5.8 - Requirements on 
> Feature Context S
> pecifications
> 
> 
> Madjid: 
> > -----Original Message----- 
> > From: Nakhjiri Madjid-MNAKHJI1 
> [mailto:[email-masked]] 
> > Sent: July 22, 2002 18:56 
> > To: 'James Kempf'; [email-masked] 
> > Subject: RE: [Seamoby] New Section 5.8 - Requirements on 
> > Feature Context 
> > S pecifications 
> > 
> > 
> *snip* 
> > 
> > If the feature context is transferred as an 
> > option on another IETF protocol, then the feature context 
> > specification MUST 
> > define the mapping of the context transfer container into the 
> > other protocol's 
> > standard option format. If the feature context is transferred 
> What did you mean by "standard option format"? CT, as we have 
> been discussing it, is a container protocol, defined around 
> context "chunks". Are you implying that it should also allow 
> for encoding of context into the option fields of other protocols??? 
> Gary 
> *snip* 
>