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

[BBMcoll <[e-mail]>]

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.
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.
Merci d’avoir communiqué avec l’équipe Recouvrement de Bell Marchés Affaires.

From: [e-mail]
Sent: Thursday, July 23, 2020 12:22 AM
To: [e-mail]
Subject: [EXT]rfc-interest Digest, Vol 189, Issue 14

Send rfc-interest mailing list submissions to
        [e-mail]

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
        [e-mail]

You can reach the person managing the list at
        [e-mail]

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 (Martin Thomson)
   2. Re: [xml2rfc] use of sourcecode type (John Levine)
   3. Re: [xml2rfc] use of sourcecode type (Martin Thomson)
   4. Re: [xml2rfc] use of sourcecode type (John R Levine)
   5. Re: [xml2rfc] use of sourcecode type (Carsten Bormann)
   6. Re: [xml2rfc] use of sourcecode type (John R Levine)


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

Message: 1
Date: Thu, 23 Jul 2020 11:37:35 +1000
From: "Martin Thomson" <[e-mail]>
To: [e-mail]
Subject: Re: [rfc-i] [xml2rfc] use of sourcecode type
Message-ID: <[e-mail]>
Content-Type: text/plain;charset=utf-8

In rust documentation, there is a flag for example code that says "this code is invalid".  That is separate from the (implied) type.

I don't see it being necessary to fix the "this is invalid, but it is if you add it to this other thing".  But that might be fixed with an excerpt flag that says "this is an excerpt (from X?) and therefore not valid on its own".

As for IANA maintaining a registry of types, sure.  I had no idea that this was a thing until the tls-syntax tag was added by the editor to one of my drafts.

On Wed, Jul 22, 2020, at 01:10, Carsten Bormann wrote:
> A similar problem is giving examples that are intentionally bad in
> order to demonstrate a kind of error.
>
> 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.
>
> 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.
>
> 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.)
>
> Gr??e, Carsten
>
>
> > On 2020-07-21, at 16:36, Paul Kyzivat <[e-mail]> wrote:
> >
> > I have a question about specification of type in sourcecode elements:
> >
> > In RFC4566bis there are many examples that have fragments of SDP. But they aren't compliant to SDP syntax, since it requires that many things be present - that are intentionally omitted from these examples.
> >
> > Is it valid to tag these with type="SDP"?
> >
> > (In sip we had a similar problem. There is a mime-type message/sip, but we sometimes also return fragments of sip in error messages. We ended up defining a separate message/sipfrag mime-type for this.)
> >
> >      Thanks,
> >      Paul
> >
> > _______________________________________________
> > xml2rfc mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/xml2rfc
>
> _______________________________________________
> rfc-interest mailing list
> [e-mail]
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
>


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

Message: 2
Date: 22 Jul 2020 22:45:52 -0400
From: "John Levine" <[e-mail]>
To: [e-mail]
Subject: Re: [rfc-i] [xml2rfc] use of sourcecode type
Message-ID: <[e-mail]>
Content-Type: text/plain; charset=utf-8

In article <[e-mail]> you write:
>In rust documentation, there is a flag for example code that says "this code is invalid".  That is
>separate from the (implied) type.
>
>I don't see it being necessary to fix the "this is invalid, but it is if you add it to this other
>thing".  But that might be fixed with an excerpt flag that says "this is an excerpt (from X?) and
>therefore not valid on its own".

If people can come up with a list of conventional code types, we can encourage people to use them.

>As for IANA maintaining a registry of types, sure.  I had no idea that this was a thing until the
>tls-syntax tag was added by the editor to one of my drafts.

Once again, no.  The RSE keeps a list of conventional artwork types, not IANA.  See RFC 7991, sec 2.5.7.

R's,
John


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

Message: 3
Date: Thu, 23 Jul 2020 13:23:26 +1000
From: "Martin Thomson" <[e-mail]>
To: "John R Levine" <[e-mail]>, [e-mail]
Subject: Re: [rfc-i] [xml2rfc] use of sourcecode type
Message-ID: <[e-mail]>
Content-Type: text/plain

On Thu, Jul 23, 2020, at 12:45, John Levine wrote:
> Once again, no.  The RSE keeps a list of conventional artwork types,
> not IANA.  See RFC 7991, sec 2.5.7.

We documented this format in an RFC because we thought that interoperability matters.  I don't think that the RSE gets to be above that.


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

Message: 4
Date: 22 Jul 2020 23:40:46 -0400
From: "John R Levine" <[e-mail]>
To: "Martin Thomson" <[e-mail]>, [e-mail]
Subject: Re: [rfc-i] [xml2rfc] use of sourcecode type
Message-ID: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed

> On Thu, Jul 23, 2020, at 12:45, John Levine wrote:
>> Once again, no.  The RSE keeps a list of conventional artwork types,
>> not IANA.  See RFC 7991, sec 2.5.7.
>
> We documented this format in an RFC because we thought that
> interoperability matters.  I don't think that the RSE gets to be above
> that.

That section of RFC 7991 says:

2.5.7.  "type" Attribute

    Specifies the type of the artwork.  The value of this attribute is
    free text with certain values designated as preferred.

    The preferred values for <artwork> types are:

    o  ascii-art

    o  binary-art

    o  call-flow

    o  hex-dump

    o  svg

    The RFC Series Editor will maintain a complete list of the preferred
    values on the RFC Editor web site, and that list is expected to be
    updated over time.  Thus, a consumer of v3 XML should not cause a
    failure when it encounters an unexpected type or no type is
    specified.  The table will also indicate which type of art can appear
    in plain-text output (for example, type="svg" cannot).



Regards,
John Levine, [e-mail], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly


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

Message: 5
Date: Thu, 23 Jul 2020 06:15:11 +0200
From: Carsten Bormann <[e-mail]>
To: John R Levine <[e-mail]>
Cc: Martin Thomson <[e-mail]>, [e-mail]
Subject: Re: [rfc-i] [xml2rfc] use of sourcecode type
Message-ID: <[e-mail]>
Content-Type: text/plain;       charset=utf-8

On 2020-07-23, at 05:40, John R Levine <[e-mail]> wrote:
>
>   o  svg

In an authoring system such as kramdown-rfc, you get to use source-code (e.g., some form of UML) to generate artwork (right now limited to our SVG subset, or plaintext (?ASCII?) art).

The existing vocabulary cannot represent this.
But that is maybe mostly OK, because at the author-publisher interface, the source code (i.e., editable form) is no longer needed.
Until it is.

Gr??e, Carsten



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

Message: 6
Date: 23 Jul 2020 00:22:31 -0400
From: "John R Levine" <[e-mail]>
To: "Carsten Bormann" <[e-mail]>
Cc: "Martin Thomson" <[e-mail]>, [e-mail]
Subject: Re: [rfc-i] [xml2rfc] use of sourcecode type
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

On Thu, 23 Jul 2020, Carsten Bormann wrote:
> On 2020-07-23, at 05:40, John R Levine <[e-mail]> wrote:
>>
>>   o  svg
>
> In an authoring system such as kramdown-rfc, you get to use source-code (e.g., some form of UML) to generate artwork (right now limited to our SVG subset, or plaintext (?ASCII?) art).
>
> The existing vocabulary cannot represent this.
> But that is maybe mostly OK, because at the author-publisher interface, the source code (i.e., editable form) is no longer needed.
> Until it is.

This list of artwork types isn't cast in stone.  If we need new ones, we
can add them.

Regards,
John Levine, [e-mail], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Subject: Digest Footer

_______________________________________________
rfc-interest mailing list
[e-mail]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest


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

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

_______________________________________________
rfc-interest mailing list
[e-mail]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest