Peter Saint-Andre | 1 Nov 2005 19:09

Re: XMPP IRIs: feedback requested

Frank Ellermann wrote:

> Hi, I just looked at the fixed example, it should be okay now:
> 
> <xmpp:ji%C5%99i <at> %C4%8Dechy.example/v%20Praze>
> 
> Maybe - for readers like me, who don't know all these IRI and
> IDNA secrets - you could mention, that it's the job of the
> (implicit) server to convert the domain %C4%8Dechy.example to
> IDNA _iff_ needed.  If that's never necessary for xmpp please
> ignore me.

I've incorporated this feedback into my working copy and it will be 
reflected in draft-saintandre-xmpp-iri-03. Thanks!

Peter

Attachment (smime.p7s): application/x-pkcs7-signature, 3641 bytes
Mike Brown | 7 Nov 2005 06:20
Favicon

Re: updated mailto draft


Martin Duerst wrote:
> 
> Dear URI Experts,
> 
> There is now a new mailto draft at
> http://www.ietf.org/internet-drafts/draft-duerst-mailto-bis-01.txt.

Dates on the draft weren't updated. (published Feb., expires Aug.?)

> This takes into account a lot of comments, but we have unfortunately
> not yet had the time to deal with comments in the thread starting
> at http://www.w3.org/mid/0II90086I4VOX5 <at> mailsj-v1.corp.adobe.com,
> and also some comments from Bruce Lilly. We plan to deal with
> them in the next version (planned for after the upcomming IETF).
> 
> In the meantime, any further comments are highly appreciated.

Section 3 says 'A mailto URI designates an "internet resource", which is the 
mailbox specified in the address.'

Since multiple addresses/mailboxes can be put into a single mailto URI, this 
statement seems less than ideal. What is the 'resource' represented by a 
mailto URI that contains 5 addr-specs?

Since addr-specs are comma-separated, why require the use of "%2C" instead of 
a raw "," to separate them?  It seems to go against the conventional wisdom 
that percent-encoded reserved characters constitute part of the represented 
data while raw reserved characters constitute part of the structure of the 
URI.  The comma is being used as a sub-delim rather than data, and it isn't 
(Continue reading)

Felix Sasaki | 7 Nov 2005 08:26
Picon
Favicon

http://www.ietf.org/internet-drafts/draft-duerst-mailto-bis-01.txt


Hi Martin, cc'ing to uri <at> w3.org,

I saw a minor issue in  
http://www.ietf.org/internet-drafts/draft-duerst-mailto-bis-01.txt:

The security considerations of [RFC3986], [RFC3490], [RFC3491], and also  
apply. [RFC3987]

should mayb be

The security considerations of [RFC3986], [RFC3490], [RFC3491], and  
[RFC3987] also apply.

Also, I am wondering about this from text from RFC 3987:
The security considerations discussed in [RFC3986] also apply to IRIs. In  
addition, RFC 3987 cites 3940/1.

Would it then not be enough to cite the security conciderations from 3987?  
Am I missing something, which is not in RFC 3987 cited from 3986 / 3490/1?  
Or is it just normal to have such overlaps in citations?

Best regards,

Felix

Martin Duerst | 7 Nov 2005 11:04
Picon
Gravatar

Re: I-D ACTION:draft-fenner-literal-zone-02.txt


Hello Tatsuya, others,

[cross-posting the uri mailing list]

At 02:54 05/11/07, JINMEI Tatuya / 神明達哉 wrote:
 >>>>>> On Fri, 4 Nov 2005 17:01:33 -0800,
 >>>>>> Bill Fenner <fenner <at> research.att.com> said:
 >
 >>> Now I'm surprised to see the new version provides the answer to
 >>> questions 1-3 with removing alternatives.  Have we already made a
 >>> consensus which I simply missed?
 >
 >> The sense of the room that I got in Paris was that moving forward
 >> with option 1 was reasonable.  I admit to having forgotten to check
 >> on the list before proceeding with the document update.
 >
 >> I think that of options 2 or 3, only 2 is feasible, after updating
 >> RFC 3986 to allow pct-encoded in IPvFuture.  My impression is that
 >> the role of % as introducing a pct-encoded sequence is too deeply
 >> ingrained into the URI spec (i.e., section 2.1 and 2.4 of 3986)
 >> to be able to specify that a bare "%" is permitted to mean just "%".
 >
 >> Given that my impression was that the URI community would
 >> absolutely refuse option 3 (bare %) and it would be an uphill
 >> battle to use option 2 (pct-encoded %25) [since it would mean
 >> updating RFC3986], I chose to try to move forward with option 1.
 >> If the IPv6 WG cannot come to a consensus that option 1 is
 >> "good enough", then I'm happy to let someone else try to move
 >> forward with this document.
(Continue reading)

Martin Duerst | 7 Nov 2005 10:27
Picon
Gravatar

http://www.ietf.org/internet-drafts/draft-duerst-mailto-bis-01.txt


At 16:26 05/11/07, Felix Sasaki wrote:
 >Hi Martin, cc'ing to uri <at> w3.org,

Hi Felix,

 >I saw a minor issue in
 >http://www.ietf.org/internet-drafts/draft-duerst-mailto-bis-01.txt:
 >
 >The security considerations of [RFC3986], [RFC3490], [RFC3491], and also
 >apply. [RFC3987]
 >
 >should mayb be
 >
 >The security considerations of [RFC3986], [RFC3490], [RFC3491], and
 >[RFC3987] also apply.

Good catch. Hidden in my editing version by an otherwise very
convenient stylesheet.

 >Also, I am wondering about this from text from RFC 3987:
 >The security considerations discussed in [RFC3986] also apply to IRIs. In
 >addition, RFC 3987 cites 3940/1.
 >
 >Would it then not be enough to cite the security conciderations from 3987?
 >Am I missing something, which is not in RFC 3987 cited from 3986 / 3490/1?
 >Or is it just normal to have such overlaps in citations?

Well, strictly speaking, it may be enough. But especially for security
considerations, it's much better to have direct references, in particular
(Continue reading)

Martin Duerst | 7 Nov 2005 11:06
Picon
Gravatar

Fwd: Re: I-D ACTION:draft-fenner-literal-zone-02.txt


Forwarded to the URI list. Please put ipv6 <at> ietf.org back into
the distribution if you reply.

Regards,   Martin.

 >Date: Sun, 06 Nov 2005 19:10:53 +0100
 >From: Juergen Schoenwaelder <j.schoenwaelder <at> iu-bremen.de>
 >Subject: Re: I-D ACTION:draft-fenner-literal-zone-02.txt
 >To: "JINMEI Tatuya / ?$B? <at> L <at> C#:H" <jinmei <at> isl.rdc.toshiba.co.jp>
 >Cc: Bill Fenner <fenner <at> research.att.com>, duerst <at> w3.org,ipv6 <at> ietf.org
 >Reply-To: j.schoenwaelder <at> iu-bremen.de
 >Mail-Followup-To: "JINMEI Tatuya / ?$B? <at> L <at> C#:H"
 ><jinmei <at> isl.rdc.toshiba.co.jp>,Bill Fenner <fenner <at> research.att.com>,
 >duerst <at> w3.org, ipv6 <at> ietf.org

 >On Mon, Nov 07, 2005 at 02:54:18AM +0900, JINMEI Tatuya / ?$B? <at> L <at> C#:H wrote:
 >
 >[...]
 >
 >> It would be very confusing for the user to see they can simply reuse
 >> the output of the diagnostic tool in some cases and they need to
 >> convert the output in some other cases.
 >
 >I am with you here. And it might happen that implementations actually
 >accept the cut'n'paste friendly format #3, even if that is not what
 >the spec calls for.
 >
 >> Meanwhile, since the use of scope-zone notation must be limited within
 >> a single node, the auxiliary notation (with v1 and +) that conforms to
(Continue reading)

Felix Sasaki | 7 Nov 2005 15:29
Picon
Favicon

http://www.ietf.org/internet-drafts/draft-duerst-mailto-bis-01.txt


On Mon, 07 Nov 2005 18:27:50 +0900, Martin Duerst <duerst <at> it.aoyama.ac.jp>  
wrote:

>
> At 16:26 05/11/07, Felix Sasaki wrote:
>  >Hi Martin, cc'ing to uri <at> w3.org,
>
> Hi Felix,
>
>  >I saw a minor issue in
>  >http://www.ietf.org/internet-drafts/draft-duerst-mailto-bis-01.txt:
>  >
>  >The security considerations of [RFC3986], [RFC3490], [RFC3491], and  
> also
>  >apply. [RFC3987]
>  >
>  >should mayb be
>  >
>  >The security considerations of [RFC3986], [RFC3490], [RFC3491], and
>  >[RFC3987] also apply.
>
> Good catch. Hidden in my editing version by an otherwise very
> convenient stylesheet.
>
>  >Also, I am wondering about this from text from RFC 3987:
>  >The security considerations discussed in [RFC3986] also apply to IRIs.  
> In
>  >addition, RFC 3987 cites 3940/1.
>  >
(Continue reading)

Roy T. Fielding | 7 Nov 2005 21:58
Favicon
Gravatar

Re: I-D ACTION:draft-fenner-literal-zone-02.txt


On Nov 7, 2005, at 2:04 AM, Martin Duerst wrote:

> At 02:54 05/11/07, JINMEI Tatuya / 神明達哉 wrote:
> >>>>>> On Fri, 4 Nov 2005 17:01:33 -0800,
> >>>>>> Bill Fenner <fenner <at> research.att.com> said:
> >
> >>> Now I'm surprised to see the new version provides the answer to
> >>> questions 1-3 with removing alternatives.  Have we already made a
> >>> consensus which I simply missed?
> >
> >> The sense of the room that I got in Paris was that moving forward
> >> with option 1 was reasonable.  I admit to having forgotten to check
> >> on the list before proceeding with the document update.
> >
> >> I think that of options 2 or 3, only 2 is feasible, after updating
> >> RFC 3986 to allow pct-encoded in IPvFuture.  My impression is that
> >> the role of % as introducing a pct-encoded sequence is too deeply
> >> ingrained into the URI spec (i.e., section 2.1 and 2.4 of 3986)
> >> to be able to specify that a bare "%" is permitted to mean just "%".
> >
> >> Given that my impression was that the URI community would
> >> absolutely refuse option 3 (bare %) and it would be an uphill
> >> battle to use option 2 (pct-encoded %25) [since it would mean
> >> updating RFC3986], I chose to try to move forward with option 1.
> >> If the IPv6 WG cannot come to a consensus that option 1 is
> >> "good enough", then I'm happy to let someone else try to move
> >> forward with this document.
> >
> >I see your point, but IMO it's a compromise based on formalism that
(Continue reading)

Picon

Re: I-D ACTION:draft-fenner-literal-zone-02.txt

>>>>> On Mon, 07 Nov 2005 19:04:13 +0900, 
>>>>> Martin Duerst <duerst <at> it.aoyama.ac.jp> said:

>> It would be very confusing for the user to see they can simply reuse
>> the output of the diagnostic tool in some cases and they need to
>> convert the output in some other cases.

> An additional idea would be to change some of the tools such as
> ping6 to accept and use '+' rather than '%'. Given the software
> counts for URI-processing software and IPv6 software, that's
> probably much easier than trying to force the non-escaping
> '%' into URI syntax (already a full standard).

IMO (admitting YMMV), URI-processing software and IPv6 software are
both so deployed that we cannot simply make "this one is not fully
deployed so fixing this side should be easier".  I indeed made a
similar argument about a year ago:
http://www1.ietf.org/mail-archive/web/ipv6/current/msg03987.html

In addition, while I might buy this argument if the proposed syntax in
draft-fenner-... could avoid forcing special processing in
URI-processing software, it actually doesn't.  The fact is that
"URI-processing software" will need modification anyway, whether we
adopt the draft-fenner-... syntax or just allow the RFC4007 format.

Meanwhile, requiring the existing tools that understand the RFC4007
'%' format to support '+' effectively means deprecating the current
description of RFC4007 and updating the RFC itself, since this is
exactly the case when the proposed format defined in RFC4007 is
expected to be used.
(Continue reading)

Martin Duerst | 8 Nov 2005 11:03
Picon
Gravatar

Re: I-D ACTION:draft-fenner-literal-zone-02.txt


Hello Roy,

At 05:58 05/11/08, Roy T. Fielding wrote:
 >On Nov 7, 2005, at 2:04 AM, Martin Duerst wrote:

 >> In the latest version of the draft, v1. is used. I think my
 >> original proposal was to use v6., because we are talking about
 >> IPv6. Roy, others, what was the original intention for the vX.
 >> syntax? IP version, or just a sequential id?
 >
 >v1 should be used.  This is the second IPv6 form and there may
 >be others in the future -- the v has nothing to do with IPv.

Thanks for this clarification. Sorry I got this wrong.

 >> The URI community has a lot of experience with URIs leaking
 >> (the first experience was that URIs themselves were not
 >> intended for end-user consumption).
 >
 >What?  Of course they were intended for user consumption -- where
 >on earth did you get that idea?  There are whole sections on
 >transcription in the URI spec.

Well, I have to admit that I got that from Tim Berners-Lee himself.
He was probably talking about the time around 1990 or even earlier,
long before there was an URI spec.

Regards,   Martin. 

(Continue reading)


Gmane