Re: [rfc-i] rfc-interest Digest, Vol 189, Issue 12

Un message en français suivra
Thank you for your email.
A response to your inquiry will be provided as quickly as possible within the next 24 hours, during business hours (Eastern Time).
If this is an urgent matter, please contact our office at 1-866-350-7710 and select Option 1 for Telephone or Option 2 for Internet, High-speed, IP/Broadband.
Thank you for contacting BBM -Bell Business Markets Collections
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Merci de votre courriel.
Nous répondrons à votre demande dans les plus brefs délais à l’intérieur des prochaines 24 heures , durant les heures normales de bureau (heure de l’Est).
Pour toute question urgente, veuillez appeler notre bureau aux 1 866 350-7710 et sélectionner l’option 1 pour les services téléphoniques ou l’option 2 pour les services Internet (haute vitesse, IP et large bande).
Merci d’avoir communiqué avec l’équipe Recouvrement de Bell Marchés Affaires.

From: rfc-interest-request@rfc-editor.org
Sent: Tuesday, July 21, 2020 03:00 PM
To: rfc-interest@rfc-editor.org
Subject: [EXT]rfc-interest Digest, Vol 189, Issue 12

Send rfc-interest mailing list submissions to
        rfc-interest@rfc-editor.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://www.rfc-editor.org/mailman/listinfo/rfc-interest
or, via email, send a message with subject or body 'help' to
        rfc-interest-request@rfc-editor.org

You can reach the person managing the list at
        rfc-interest-owner@rfc-editor.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of rfc-interest digest..."

Today's Topics:

   1. Re: [xml2rfc] use of sourcecode type (Paul Kyzivat)
   2. Re: [xml2rfc] use of sourcecode type (Henrik Levkowetz)

----------------------------------------------------------------------

Message: 1
Date: Tue, 21 Jul 2020 11:48:13 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
To: Carsten Bormann <cabo@tzi.org>
Cc: XML2RFC Interest Group <xml2rfc@ietf.org>, RFC Interest
        <rfc-interest@rfc-editor.org>
Subject: Re: [rfc-i] [xml2rfc] use of sourcecode type
Message-ID: <a4c96c4f-72da-e8b6-5a31-b1617bf518fb@alum.mit.edu>
Content-Type: text/plain; charset=utf-8; format=flowed

On 7/21/20 11:10 AM, Carsten Bormann wrote:
> A similar problem is giving examples that are intentionally bad in order to demonstrate a kind of error.

Good point.

> I typically tag them with a type that is derived from the one I would give for real code, e.g., ?CDDLx? for a bad CDDL example.  I think it would be good to agree on some way to indicate this.

I agree that we should have some agreed upon way to do this.

Perhaps a "+xyz" suffix, with some agreed up xyz values.

> A related problem is that often several code blocks combine to one valid instance of CDDL, for example see Figure 1, 2, 3 in RFC 8428.  There is no way to say that Figure 1 and 2 combine into a valid instance, and so do Figure 1 and 3, but not any other combination.

I'm also interested in this. I believe an obvious solution to this is
via the "name" attribute. All the ones with the same name should be
gathered together.

A problem I have with both name and type is that they are invisible in
the human readable formats. They provide semantic information that may
be of interest to a reader. Perhaps they could be available in html via
a popup?

> And, by the way, those type tags are conventionally lower-cased, but this is not made very explicit; you have to infer that from the list in Section 2.48.4 of RFC 7991 or the RFC editor?s updated copy of that list:

> https://www.rfc-editor.org/materials/sourcecode-types.txt
>
> (Ha, this doesn?t even have ?cddl? in it; I?m not sure how this is updated and whether there shouldn?t really be an IANA registry for these.)

For these to be useful for any sort of automated processing I think they
should be standardized. I agree with an IANA registry.

If we wanted to allow unstandardized usage there could be X- prefixes,
but we have banned those many other places.

        Thanks,
        Paul

------------------------------

Message: 2
Date: Tue, 21 Jul 2020 18:15:08 +0200
From: Henrik Levkowetz <henrik@levkowetz.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, Carsten Bormann
        <cabo@tzi.org>
Cc: XML2RFC Interest Group <xml2rfc@ietf.org>, RFC Interest
        <rfc-interest@rfc-editor.org>
Subject: Re: [rfc-i] [xml2rfc] use of sourcecode type
Message-ID: <9fbe057d-c820-2cfe-012f-dff4edcc03ca@levkowetz.com>
Content-Type: text/plain; charset="utf-8"

On 2020-07-21 17:48, Paul Kyzivat wrote:
> On 7/21/20 11:10 AM, Carsten Bormann wrote:
>> A similar problem is giving examples that are intentionally bad in order to demonstrate a kind of error.
>
> Good point.
>
>> I typically tag them with a type that is derived from the one I would give for real code, e.g., ?CDDLx? for a bad CDDL example.  I think it would be good to agree on some way to indicate this.
>
> I agree that we should have some agreed upon way to do this.
>
> Perhaps a "+xyz" suffix, with some agreed up xyz values.
>
>> A related problem is that often several code blocks combine to one valid instance of CDDL, for example see Figure 1, 2, 3 in RFC 8428.  There is no way to say that Figure 1 and 2 combine into a valid instance, and so do Figure 1 and 3, but not any other combination.
>
> I'm also interested in this. I believe an obvious solution to this is
> via the "name" attribute. All the ones with the same name should be
> gathered together.

Yes.  That's already mentioned in RFC7991:

  https://tools.ietf.org/html/rfc7991#section-2.48.2

and also in the documentation for the current xml2rfc release:

  https://xml2rfc.tools.ietf.org/xml2rfc-doc.html#name-name-attribute-4

Regards,

        Henrik

> A problem I have with both name and type is that they are invisible in
> the human readable formats. They provide semantic information that may
> be of interest to a reader. Perhaps they could be available in html via
> a popup?
>
>> And, by the way, those type tags are conventionally lower-cased, but this is not made very explicit; you have to infer that from the list in Section 2.48.4 of RFC 7991 or the RFC editor?s updated copy of that list:
>
>> https://www.rfc-editor.org/materials/sourcecode-types.txt
>>
>> (Ha, this doesn?t even have ?cddl? in it; I?m not sure how this is updated and whether there shouldn?t really be an IANA registry for these.)
>
> For these to be useful for any sort of automated processing I think they
> should be standardized. I agree with an IANA registry.
>
> If we wanted to allow unstandardized usage there could be X- prefixes,
> but we have banned those many other places.
>
>        Thanks,
>        Paul
> _______________________________________________
> rfc-interest mailing list
> rfc-interest@rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20200721/4c53427b/attachment-0001.asc>

------------------------------

Subject: Digest Footer

_______________________________________________
rfc-interest mailing list
rfc-interest@rfc-editor.org
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

------------------------------

End of rfc-interest Digest, Vol 189, Issue 12
*********************************************
------------------------------------------------------------------------------
External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints