[Council] need for Last Call on JEP-0147 (was: [Fwd: GenART reviewof draft-saintandre-xmpp-iri-03])

Peter Saint-Andre stpeter at jabber.org
Mon Mar 13 16:59:31 CST 2006


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks, I issued it a few hours ago, sorry for the hurry but I really
want to get the xmpp URI scheme out there and published as an RFC. :-)

Ian Paterson wrote:
> +1
> 
>> -----Original Message-----
>> From: council-bounces at jabber.org 
>> [mailto:council-bounces at jabber.org] On Behalf Of Peter Saint-Andre
>> Sent: 13 March 2006 17:40
>> To: council at jabber.org
>> Subject: [Council] need for Last Call on JEP-0147 (was: [Fwd: 
>> GenART reviewof draft-saintandre-xmpp-iri-03])
>>
>>
> As part of the IETF Last Call process for 
> draft-saintandre-xmpp-iri, the expert reviewer of that I-D 
> suggested that the registry for XMPP URI query components be 
> created before the IESG approves of the I-D. Because the 
> Jabber Registrar cannot create the registry until JEP-0147 is 
> advanced to a status of Draft, I would like to request a 
> (JSF) Last Call on this JEP (and I don't particularly want to 
> wait on issuing the Last Call until the next Jabber Council 
> meeting on March 23, since I'd prefer not to hold up the IETF 
> process). Therefore, I would appreciate it if Council members 
> could indicate if they have any objections to issuing a Last 
> Call for JEP-0147. If not, I would like to issue the Last 
> Call by the end of today if possible.
> 
> Also, given that JSF Last Calls normally are for a period of 
> not less than 10 days and that a 10-day Last Call would end 
> at the close of business on March 23 if issued today, we have 
> two options if we want to expedite advancement of JEP-0147: 
> (1) issue a 9-day Last Call or (2) move the next Council 
> meeting to something like Monday, March 27. Please indicate 
> your preference.
> 
> Thanks!
> 
> Peter
> 
> 
> Message from IETF reviewer follows...
> 
> 
> -------- Original Message --------
> Subject: GenART review of draft-saintandre-xmpp-iri-03
> Date: Thu, 9 Mar 2006 21:55:26 -0500
> From: Black_David at emc.com
> To: gen-art at ietf.org, stpeter at jabber.org
> CC: sah at 428cobrajet.net, Black_David at emc.com
> 
> Background for those who may be unaware of GenART:
> 
> GenART is the Area Review Team for the General Area of the 
> IETF. We advise the General Area Director (i.e. the IETF/IESG 
> chair) by providing more in depth reviews than he could do 
> himself of documents that come up for final decision in IESG 
> telechat.  I was selected as the GenART member to review this 
> document.  Below is my review, which was written specifically 
> with an eye to the GenART process, but since I believe that 
> it will be useful to have these comments more widely 
> distributed, others outside the GenART group are included.
> 
> This review was done as part of IETF Last Call.
> 
> Review criteria: "Is this document a reasonable contribution 
> to the area of Internet engineering which it covers?  If not, 
> what changes would make it so?"
> 
> This draft is on the right track but has open issues, 
> described in the review.
> 
> Section 2.5 contains the following note:
> 
>    (Note: In pursuit of interoperability, it may be helpful 
> to maintain
>    a registry of query types and perhaps even of keys for use in XMPP
>    query components.  Given that such values will most likely be
>    specific to particular applications of XMPP rather than 
> core to XMPP
>    itself, it seems reasonable that such a registry, if created, would
>    be maintained by the Jabber Registrar function of the 
> Jabber Software
>    Foundation as described in [JEP-0053], rather than by the IANA.  A
>    proposal for creating such a registry can be found in [JEP-0147].)
> 
> Given the importance of interoperability to the IETF, IESG 
> approval of this draft should probably be delayed until that 
> registry is functional so that the draft can document 
> registration requirements for query components. This problem 
> is ironically caused by XMPP's success in being used by 
> multiple independent applications (e.g., list in Section 
> 2.1), requiring a registry like this to prevent collisions 
> among their use of URIs/IRIs.
> 
> Nit - In Section 3.6 add "RFC " before "XXXX" and add an RFC 
> Editor note to tell the RFC Editor to replace "XXXX" with the 
> number of the published RFC and delete the note.
> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> black_david at emc.com        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEFflTNF1RSzyt3NURAkVUAKDIkJXCp6QNqzwnrjFfeyLDu7pqSACg1sbV
NRXVuoEF++W3u3m6vhx4WqA=
=FpAH
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/council/attachments/20060313/b9ddd3b6/smime-0001.bin


More information about the Council mailing list