headers
Eric Johnson | 14 Nov 17:53
Favicon

Submitted jms scheme - draft-merrick-jms-iri-00.txt - request for further review...

As per IETF process, and per Martin Duerst's previous suggestion on this
mailing list, we have submitted our proposed jms URI scheme as an
internet draft.

You may have already reviewed this specification, or perhaps you were
waiting until we properly submitted it to internet-drafts <at> ietf.org.  If
the latter, we have now done so:

https://datatracker.ietf.org/drafts/draft-merrick-jms-iri/

We welcome any and all feedback you might have.

Thanks.
-Eric Johnson
Permalink | Reply |
headers
Ted Hardie | 14 Nov 20:08

Re: Submitted jms scheme - draft-merrick-jms-iri-00.txt - request for further review...

Hi Eric,
	Going through the document, I did see some areas where clean-up
would be useful.  First, the document appears to register a URI scheme
and an IRI scheme; it's probably best to call that out in the title and abstract.
A reference to RFC 4395/BCP 115 is probably required, since it defines
the registration process for URIs. 
	In the document you say:

   The required particles in the JMS IRI are the scheme name ("jms"),
   the variant identifier, and the "jms-dest" portions.  The two
   recognized variants (jms-variant above) are "jndi", and "context".
   The "jms-dest" portion identifies the JMS destination object in a way
   that is determined by the particular variant.

The description of those two variant identifiers as "recognized"
seems to treat them as tokens.  Would a token registry for variant
identifiers enhance the interoperability of the result?  As it
stands now, the variants are defined by isegment-nz-nc, which
seems to mean minting a new variant will be trivial.  Is that
needed, or would an IANA first-come-first-served registry be
better?

I found the following:

   Each variant may have query parameters specific to that variation.
   All such parameters that cannot be shared across schemes should use
   the name of the variant as the prefix to the parameters.  Parameters
   that apply across multiple variants, perhaps because they are
   generally applicable, such as JMS settings, should not have any
   particular prefix, and should not begin with any known prefix.  This
(Continue reading)

Permalink | Reply |
headers
Peter Saint-Andre | 14 Nov 21:05

Re: Submitted jms scheme - draft-merrick-jms-iri-00.txt - request for further review...

Ted Hardie wrote:
> Hi Eric,
> 	Going through the document, I did see some areas where clean-up
> would be useful.  First, the document appears to register a URI scheme
> and an IRI scheme; it's probably best to call that out in the title and abstract.

As I learned when I wrote RFC 4622, there is no such thing as an IRI
scheme. Just register the URI scheme and provide appropriate details
about how it's used with IRIs.

Peter

--

-- 
Peter Saint-Andre
https://stpeter.im/
Attachment (smime.p7s): application/x-pkcs7-signature, 7338 bytes
_______________________________________________
Uri-review mailing list
Uri-review <at> ietf.org
https://www1.ietf.org/mailman/listinfo/uri-review
Permalink | Reply |
headers
Frank Ellermann | 15 Nov 08:37

Re: Submitted jms scheme - draft-merrick-jms-iri-00.txt- request for further review...

Peter Saint-Andre wrote:

> As I learned when I wrote RFC 4622, there is no such thing
> as an IRI scheme. Just register the URI scheme and provide
> appropriate details about how it's used with IRIs.

RFC 3987 uses the term 'scheme' many times, it's just the 
same 'scheme' as in RFC 3986.  And of course there's only a
IANA registry for URI schemes.

 Frank
Permalink | Reply |
headers
Peter Saint-Andre | 15 Nov 15:39

Re: Re: Submitted jms scheme - draft-merrick-jms-iri-00.txt- request for further review...

Frank Ellermann wrote:
> Peter Saint-Andre wrote:
> 
>> As I learned when I wrote RFC 4622, there is no such thing
>> as an IRI scheme. Just register the URI scheme and provide
>> appropriate details about how it's used with IRIs.
> 
> RFC 3987 uses the term 'scheme' many times, it's just the 
> same 'scheme' as in RFC 3986.  And of course there's only a
> IANA registry for URI schemes.

If a scheme falls in the forest but the IANA doesn't register it, does
it make a sound?

You are right that, to be precise, according to the IANA one does not
register an IRI scheme because there is no registry for IRI schemes,
there is only a registry for URI schemes. Ted noted that this draft
"appears to register a URI scheme and an IRI scheme" but as far as I can
see the IANA won't do anything with the registration of an IRI scheme.

Peter

--

-- 
Peter Saint-Andre
https://stpeter.im/
Attachment (smime.p7s): application/x-pkcs7-signature, 7338 bytes
_______________________________________________
(Continue reading)

Permalink | Reply |
headers
Eric Johnson | 18 Jan 06:45
Favicon

Re: Submitted jms scheme - draft-merrick-jms-iri-00.txt - request for further review...

Hi Ted,

Thanks for your feedback. We're looking to address many of the points
you've raised. After the holidays, and consulting with the other people
working on this specification, we realized we had some follow up
questions. They follow:

Ted Hardie wrote:
> Hi Eric,
>   
[snip]
> _Warning_: Vendors and applications SHOULD NOT include sensitive
>    information (such as authorization tokens) in an IRI.
>
> at a SHOULD strength level?
>   
Not clear what you're implying here. That it should read "MUST NOT"
instead? We were thinking that there could be scenarios where the IRI
was stored together with a user name and password, and in some
circumstances, it could possibly make sense to store all of the
information in a single string. So "MUST NOT" seemed overly strong.

[snip]
> This may also be important when considering Section 7.  You say:
>
> As JMS is an API rather than a protocol, it therefore specifies no
>    interoperable wire-level representation.  However, because the jms
>    IRI scheme is defined with reference to the API, this lack of wire-
>    level compatibility does not create an interoperability issue.
>
(Continue reading)

Permalink | Reply |
headers
Ted Hardie | 26 Jan 01:34

Re: Submitted jms scheme - draft-merrick-jms-iri-00.txt - request for further review...

At 9:45 PM -0800 1/17/08, Eric Johnson wrote:
>Hi Ted,
>
>Thanks for your feedback. We're looking to address many of the points
>you've raised. After the holidays, and consulting with the other people
>working on this specification, we realized we had some follow up
>questions. They follow:
>
>Ted Hardie wrote:
>> Hi Eric,
>>  
>[snip]
>> _Warning_: Vendors and applications SHOULD NOT include sensitive
>>    information (such as authorization tokens) in an IRI.
>>
>> at a SHOULD strength level?
>>  
>Not clear what you're implying here. That it should read "MUST NOT"
>instead? We were thinking that there could be scenarios where the IRI
>was stored together with a user name and password, and in some
>circumstances, it could possibly make sense to store all of the
>information in a single string. So "MUST NOT" seemed overly strong.

MUST NOT means never.  SHOULD NOT means don't do this unless
you understand why you're breaking the rule.  There is nothing in
the document to indicate when it would be okay to break the
rule and I don't know of any general context where it would be
understood to be okay for this.  So, I think you need to give an
example context where this makes sense.  The one you've given
doesn't seem particularly compelling to me (since the IRI could
(Continue reading)

Permalink | Reply |

Gmane