Unfortunately there are two separate issues. One is about keeping
people informed, and I have no objections to that. The second one is
about release of ITU-T and ISO Working Documents, and that is more
difficult. Once the ITU-T approval is in place (hopefully no later than
Jan of next year), the texts for XCN/VXER will become freely available
as pre-published specs.
John L
Phil Griffin wrote:
>
> Ed,
>
> I agree that such work should not appear to be
> so secretive. If as John has stated XCBF is a
> primary and important user of this technology
> then the XCBF list would be a good one keep
> notified of developments.
>
> Also, there is still an asn1xml list hosted by
> OSS that seems to get little mail, and the ASN1
> list hosted by ITU-T. I'm on all of these and
> have seen no discussions of such work there.
>
> On the ITU-T list noted above, I would also
> mention that OASIS has a communication process
> with ITU-T that was formed with XCBF and SG17
> specifically mentioned.
>
> Would it be possible for John or Bancroft or
> Alessandro or Paul, all of whom attend the SG17
> meetings, to volunteer to serve as liaison to
> XCBF? If so, I will gladly update the XCBF web
> page to note this liaison and this channel could
> be used to keep XCBF members informed.
>
> Phil
>
> Phil
>
> Ed Day wrote:
>
> >>VXER - Variant XER - *will* provide a BASE64 transfer, but VXER is not
> >>canonical
> >>
> >
> > What is this? There is no mention of it anywhere I can find on the web
> > (this is also true of the XCN acronym used in some prior XCBF e-mails). It
> > seems that if you are going to be using these standards to define new specs,
> > they should at least be published somewhere..
> >
> > Regards,
> >
> > Ed
> >
> > ----- Original Message -----
> > From: "John Larmouth" <>
> > To: "Ed Day" <>
> > Cc: "Phil Griffin" <>; "xcbf"
> > <>
> > Sent: Monday, August 12, 2002 11:36 AM
> > Subject: Re: [xcbf] SignedData Attributes - DigitalSignature Attributes
> >
> >
> >
> >>CXER does not support encoding instructions. So an octet string value
> >>in CXER can only be transferred using hex.
> >>
> >>VXER - Variant XER - *will* provide a BASE64 transfer, but VXER is not
> >>canonical.
> >>
> >>(We have discussed providing a CVXER - Canonical Variant XER, but we
> >>have almost agreed not to, at least at present, for some very good
> >>reasons: it is very difficult, and it will delay the progression of
> >>VXER, which we know is needed.)
> >>
> >>As Ed rightly says, there is no way you can have canonical encodings
> >>that allow both hex and base64 for an OCTET STRING, even if you have a
> >>"format=" attribute. For canonical encodings, there is just one, and
> >>only one, way of encoding an octet string. For CXER, that is hex.
> >>
> >>John L
> >>
> >>
> >>Ed Day wrote:
> >>
> >>>I thought in a canonical XER encoding things could be done one way and
> >>>
> > only
> >
> >>>one way. Doesn't introducing these attributes violate the canonical
> >>>
> > rules?
> >
> >>>Regards,
> >>>
> >>>Ed Day
> >>>Principal Engineer
> >>>Objective Systems, Inc.
> >>>Tel: +1 (484) 875-3020
> >>>Fax: +1 (484) 875-2913
> >>>Toll-free: (877) 307-6855 (USA only)
> >>>mailto:
> >>>http://www.obj-sys.com
> >>>
> >>>----- Original Message -----
> >>>From: "Phil Griffin" <>
> >>>To: "xcbf" <>
> >>>Sent: Monday, August 12, 2002 9:02 AM
> >>>Subject: [xcbf] SignedData Attributes - DigitalSignature Attributes
> >>>
> >>>
> >>>>I proposed on 8/6 that the following XML markup be used
> >>>>in XCBF.
> >>>>
> >>>> <version> ........................ </version>
> >>>> <digestAlgorithms> ............... </digestAlgorithms>
> >>>> <encapContentInfo> ............... </encapContentInfo>
> >>>> <certificates format='base64'> ... </certificates>
> >>>> <crls format='base64'> ........... </crls>
> >>>> <signerInfos> .................... </signerInfos>
> >>>>
> >>>>The signature component of the SIGNATURE parameterized
> >>>>type identifies a value of type BIT STRING. These bits
> >>>>are not used as bit flags, and signatures tend to be in
> >>>>the thousands of bits in length and can more easily and
> >>>>compactly be represented as OCTET STRINGs. I propose that
> >>>>the following XML markup be used for these values:
> >>>>
> >>>> <signature format='hex'> ... </signature>
> >>>>
> >>>>So far, I have received no comments. Unless I hear comments
> >>>>that use of these attributes is unacceptable, I will include
> >>>>them in the next release of the XCBF document.
> >>>>
> >>>>Phil
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>----------------------------------------------------------------
> >>>>To subscribe or unsubscribe from this elist use the subscription
> >>>>manager: <http://lists.oasis-open.org/ob/adm.pl>
> >>>>
> >>>----------------------------------------------------------------
> >>>To subscribe or unsubscribe from this elist use the subscription
> >>>manager: <http://lists.oasis-open.org/ob/adm.pl>
> >>>
> >>--
> >> Prof John Larmouth
> >> Larmouth T&PDS Ltd
> >> (Training and Protocol Development Services)
> >> 1 Blueberry Road
> >> Bowdon
> >> Cheshire WA14 3LS Tel: +44 161 928 1605
> >> England Fax: +44 161 928 8069
> >>
> >>----------------------------------------------------------------
> >>To subscribe or unsubscribe from this elist use the subscription
> >>manager: <http://lists.oasis-open.org/ob/adm.pl>
> >>
> >
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
> >
--
Prof John Larmouth
Larmouth T&PDS Ltd
(Training and Protocol Development Services)
1 Blueberry Road
Bowdon
Cheshire WA14 3LS Tel: +44 161 928 1605
England Fax: +44 161 928 8069
